eTIMS offline: what happens when the internet drops
eTIMS can work offline in a limited but important sense: invoices can be signed locally on a compliant control unit and queued for transmission to KRA when connectivity returns. This is built into the eTIMS Client for desktop, into VSCU and OSCU integrations, and into POS systems that implement it. The eTIMS Lite phone app does not store-and-forward in the same way and depends more directly on a live connection.
For a Kenyan business with unreliable internet, the offline behaviour of your eTIMS channel is the difference between continuous selling during an outage and turning customers away.
What "offline" actually means under eTIMS
Offline eTIMS is not "no eTIMS". The invoice still has to be signed by a compliant control unit at the moment of sale; that is what makes it valid. Where the control unit lives (in the desktop client, in an integrated POS, or in a virtualised VSCU service) determines whether a missing internet connection blocks the signing.
For OSCU integrations like Veira, the control unit is part of the integrator's certified stack. The invoice is signed locally on the POS at the sale, with a placeholder for the KRA control number, then the transmission is queued and sent the moment the link is back. To the customer at the counter, nothing visible happens differently.
For the eTIMS Client desktop app, similar local signing happens. Invoices are queued and sent on reconnection.
For eTIMS Lite on a phone, the design is much more dependent on connectivity. Invoices created without a live connection sit in a draft state until they can transmit.
What KRA expects you to do during an outage
KRA's guidance is that compliant invoices must be transmitted in real time where possible, and stored-and-forwarded when not. The regulations do not let you simply skip the eTIMS step because the line was down; the invoice must still be signed by your control unit and transmitted as soon as the connection returns.
In practice this means two things. First, your channel must support local signing and queuing. Second, you have to confirm the queued invoices flush through to KRA once connectivity is back, rather than leaving them sitting in a pending state for days.
How to reconcile after an outage
Once the connection is back, check the eTIMS status panel on your POS or eTIMS Client. Queued invoices should transmit in batches over the next few minutes. The KRA control number and QR code come back per invoice as each transmission succeeds.
For any invoice that fails (for example, because the tax code on a line was rejected by KRA validation), the system flags it for correction. The fix is to amend the invoice and re-transmit; the original sale stays in your records.
At the end of every day where there was an outage, run a quick check: total sales in your POS report should equal the total of transmitted-and-confirmed eTIMS invoices, plus any still queued, plus any rejected. If those numbers do not reconcile, there is an untransmitted sale somewhere that needs resolution before the next day.
Why offline-first design matters in Kenya
Kenyan internet is good but not flawless. A burst of bad weather, a fibre cut, a Safaricom outage, or simply moving an Android terminal beyond a Wi-Fi router can interrupt connectivity in the middle of a busy lunch or evening rush. A POS that stops selling during those minutes is the wrong tool for the job, even if its eTIMS integration is otherwise correct.
Offline-first means the POS expects to work without a connection: invoices sign locally, payments record locally, M-Pesa confirmations queue, and the transmission catches up later. Online-when-possible POS systems freeze during the outage, customers walk, and the day's reconciliation gets harder.
The regulatory backstop
Under Legal Notice No. 64 of 2024, the obligation is to issue a compliant invoice for every sale. An untransmitted sale during a long outage is still a sale that must end up with a compliant eTIMS invoice transmitted to KRA. The penalty for failure runs up to KES 1 million or 10% of the tax involved, whichever is higher, per untransmitted sale.
The practical implication: businesses cannot use "the internet was down" as a defence for a long-term gap. KRA accepts short outages because the architecture supports queue-and-forward; it does not accept extended absence from eTIMS that conveniently coincides with high-margin trade.
Staying compliant through outages
- Pick a channel that supports offline signing. eTIMS Client and OSCU integrations support local signing and queuing. eTIMS Lite is much more dependent on a live connection.
- Verify your POS does what it claims. Run a deliberate offline test: disconnect from the internet, ring up a sale, confirm the invoice is signed locally with a placeholder, reconnect, and confirm the transmission completes.
- Reconcile every day there was an outage. Match your POS sales total to the transmitted-confirmed eTIMS total plus queued plus rejected. Resolve any gap before the next day.
- Keep a contact for the bad day. Have a number for your eTIMS integrator and your iTax-trained accountant. If a problem turns out to be something you cannot fix from the panel, you do not want to find that out at 5pm on a Friday.
How Veira handles this
Veira is offline-first by design. Every sale on a Veira terminal is signed locally at the moment of the sale, then transmitted to KRA the moment the connection comes back. To the customer at the counter, nothing changes during an outage; to the books at the end of the day, the eTIMS step has happened the same way it always does.
Related articles
Mandatory fields, B2C vs B2B differences, and the format KRA accepts.
How KRA auto-fills VAT returns from eTIMS, the common mismatches, and how to reconcile cleanly.
Mixed VAT rates, high transaction volume, barcode scanning, multi-cashier setups.
The hub for every eTIMS topic, basics, how-to, by business type, and accountant resources.
Veira handles KRA eTIMS automatically, on your phone, even offline. See Veira pricing or try our free tax and business calculators.