The short answer
A POS already knows what was sold, at what price, to whom, and when. That is most of an invoice. Joining it to eTIMS is about not typing the same sale twice.
The other system
Our reading, not a rule. Nothing below is a statement of what KRA requires.
A point-of-sale system is what runs the counter: it holds the price list, records each sale, usually tracks stock, and produces the receipt. It is the system with the most complete picture of what the business actually sold.
Why a business joins them
Our reading, not a rule. Nothing below is a statement of what KRA requires.
Because re-keying is where the errors come from and where the time goes. A counter that sells two hundred items a day and issues invoices separately is doing the same work twice and getting two versions of the truth. The invoice should be a by-product of the sale, not a second task somebody remembers.
What would move, and which way
Our reading, not a rule. Nothing below is a statement of what KRA requires.
- From the POS: the line items, quantities, prices and the tax treatment the price list already carries
- From the counter, at the time: the buyer's PIN where the buyer is a business, which is the field most often lost
- Back to the POS: whatever identifies the invoice, so the receipt and the record refer to the same document
Settle these first
Our reading, not a rule. Nothing below is a statement of what KRA requires.
- What the setup does during an outage. A business that cannot sell when the connection drops has a worse problem than a compliance one.
- Whether a correction is a new document referencing the original, or an edit. A system that edits invoices will produce a problem that only appears at audit.
- How the buyer's PIN is captured at the counter, with a queue behind them, rather than reconstructed afterwards - which mostly does not happen
- More than one till, or more than one branch: whether they behave identically, and who notices when one stops
What this does not solve
Our reading, not a rule. Nothing below is a statement of what KRA requires.
- A POS integration does not decide whether a supply is taxable or what rate applies. That sits in the price list, and it is wrong in the price list more often than anyone expects.
- It does not make a business compliant. It makes a compliant business faster and a non-compliant one fail more visibly.
The question to ask a vendor. Ask what the system does when a submission fails mid-sale: retry, queue, or drop it silently. A silent drop is the one that costs you, because nothing looks wrong until someone reconciles.
What the rules say
This page explains how a requirement generally works. It is not tax advice, and it cannot account for the specifics of any one business. For a position you intend to rely on, confirm with KRA directly or with a registered tax agent.
Tax rules in Kenya change with each Finance Act and with regulations made during the year. Before acting on any figure, deadline or threshold, check the current position on KRA's own website.
Common questions
How do I know this information is current?
Tax rules in Kenya change with each Finance Act and with regulations made during the year. Before acting on any figure, deadline or threshold, check the current position on KRA's own website.
Related integrations
Sources
- officialeTIMS (Electronic Tax Invoice Management System) — Kenya Revenue Authority, checked 2026-09-18
- officialTax Procedures (Electronic Tax Invoice) Regulations, 2024 — Kenya Gazette / Kenya Law, checked 2026-09-18
- officialKenya Revenue Authority — Kenya Revenue Authority, checked 2026-09-18