eTIMS at the Point of Sale: What Actually Changes at the Counter
eTIMS is the one fiscal regime on this blog we integrate with rather than reconcile against — which makes Kenya the exception in our own product. What actually changes at the counter, what happens to returns, and what to confirm with KRA.
We have spent a great deal of this blog telling businesses in Nigeria, Ghana, Uganda, Tanzania and Rwanda that their fiscal e-invoicing regime is not something we ship as standard, that they should not buy on the assumption it is, and that a vendor claiming otherwise should be made to demonstrate it live. Kenya is the country where that argument reverses, and it would be strange not to say so as plainly as we said the opposite.
eTIMS is the fiscal integration we actually built. Which means the honest thing to do here is not to celebrate it but to be precise about what it changes at the counter, where the awkward cases are, and which parts remain yours to confirm with KRA.
What changes at the counter, and what does not
The most common misconception is that fiscalisation is an extra step a cashier performs. Done properly it is not a step at all — it is a consequence of ringing up the sale, and the cashier's job does not change.
Fiscalisation as a separate step
- A sale is recorded, then somebody fiscalises it separately
- Two records that can disagree, and regularly do
- Busy periods produce sales that were never fiscalised
- Reconciling the two becomes a monthly project
- The gap is discovered by someone official rather than by you
Fiscalisation as a consequence
- Ringing up the sale is the whole action
- One record, mapped and transmitted from that record
- A busy period cannot produce an unfiscalised sale by omission
- There is nothing to reconcile because there is one source
- Failures surface as failures rather than as silence
That last point on the right is worth dwelling on, because it is the question to ask any vendor about any fiscal integration anywhere: what happens when a transmission fails? Integrations fail — networks drop, endpoints time out, credentials expire. A system built properly treats a failed transmission as a visible state that somebody has to clear, not as something that silently did not happen. If a vendor answers that question by explaining how rarely it fails, they have not built it.
Ask what happens when transmission fails. A vendor who has built it describes retries and a failure state without pausing. A vendor who has not describes how rarely it fails.
Fiscalisation does not fix your records
This is the argument we have made in every market and it applies with equal force in the one where the integration exists. Connecting a messy operation to a fiscal pipeline does not make it compliant — it makes it faster at transmitting a mess, and it shortens the distance between your errors and the authority.
So the sequence matters. Every sale moving stock in the same transaction, prices coming from a price list rather than a cashier's memory, returns recorded against the original sale, and the till reconciling per shift — those come first, because fiscalisation transmits whatever they produce. The wider stock discipline is in stock control in Kenya and the quote-to-cash chain in sales software in Kenya.
The awkward cases
Straightforward sales are straightforward. The situations worth thinking about before go-live are the ones where something has to be undone or corrected.
| Situation | Why it is awkward | What the records need to show |
|---|---|---|
| A return or refund | The original sale was fiscalised; the reversal has to be traceable to it | The return linked to the original sale, with a reason and the refund tender |
| An exchange rather than a refund | Two movements — goods back, different goods out | The return linked to a replacement sale, not just a cash-neutral note |
| A price corrected after ringing up | A corrected figure differs from what was transmitted | A documented correction, never a silent edit of the original |
| A sale rung up on the wrong customer | The document is out but attributed wrongly | A correction trail rather than a deletion |
| A transmission that failed | The sale happened; the transmission did not | A visible failed state somebody clears, not silence |
The returns row is the one that catches retailers out at go-live, and it is why it matters that a return is a document in its own right rather than a negative sale typed at the till. A return recorded against its original sale, carrying a reason, the refund tender, whether the goods were restocked and who processed it, gives you something explicable. A cash refund typed as an adjustment gives you a till shortage and no story.
What we do and do not do
What AWRA OpsHub does today
- eTIMS integration for Kenya — POS sales are mapped and transmitted from the sale record rather than re-entered, and invoices are mapped through the same layer.
- Per-organization eTIMS configuration, so your own credentials and settings govern transmission.
- VAT-aware records with net, tax and gross separated per line, on purchases as well as sales.
- Returns as documents linked to the original sale, with reason, refund tender, restock decision and who processed them.
- Every sale moving stock in the same transaction, so the fiscal record and the stock position cannot drift apart.
- Discounts recorded against the sale and the line, so a discounted sale is legible.
What it does not do
- We do not interpret KRA rules for you. What must be fiscalised, when, at what rate and with what exemptions is KRA's domain and your tax adviser's call.
- We do not file your VAT returns. Fiscalisation and filing are different things; filing remains your accountant's work.
- We do not supply or certify hardware, and we do not sell tills or fiscal devices.
- We do not guarantee acceptance of any particular transaction — the authority's validation rules are theirs and they change.
eTIMS requirements, VAT rates, thresholds and exemptions are set by KRA and change. Confirm your current obligations — including what your specific business is required to fiscalise and by when — with KRA or your tax adviser. Nothing here is tax advice, and you should verify the current integration behaviour with us before making a commitment that depends on it.
What to do before go-live
-
Get your obligations in writing from your adviser
What must be fiscalised, at what rate, with what exemptions for your specific business. This is the artefact you configure against, and it is worth paying for once properly rather than inferring from a software setting.
-
Test the awkward cases, not the easy one
A straightforward sale will work. Run a return, an exchange, a corrected price and a deliberately failed transmission before you trust the setup — those are where go-live problems actually live.
-
Reconcile a period you have already filed
Take a month your accountant has already dealt with, run it through, and confirm the figures reproduce. It is the only real proof your configuration is right.
-
Decide who clears failed transmissions
A named person, checked on a daily rhythm. A failure state nobody owns is functionally the same as no failure handling at all.
-
Train cashiers on returns, not on fiscalisation
Fiscalisation should require nothing of them. Returns and corrections do, and that is where errors get created at the counter.
The demo standard we hold others to
Throughout this blog we have told buyers to make vendors demonstrate fiscal integration live rather than describe it — for FIRS, EFRIS, EFD and EBM. That standard applies to us on eTIMS equally. Ask us to show a sale fiscalise on a live connection, then ask us to show you a failed one. If we cannot do both, treat our claim exactly as sceptically as we have told you to treat everyone else's.
If you also operate outside Kenya
This is where the asymmetry has to be stated clearly, because groups get caught by it. eTIMS is the fiscal integration that ships, and it is Kenya-only. Nothing about it travels to your Nigerian, Ghanaian, Ugandan, Tanzanian or Rwandan operation — those run on the general operations, multi-currency and VAT-aware layer, with fiscalisation handled by whatever process you already use and reconciled against your records. Where a specific country integration is essential, treat it as scoped work to be agreed in writing rather than as something already in the box.
The honest positions for each are set out in FIRS, VAT and naira operations, GRA, VAT levies and cedi operations, EFRIS in Uganda, TRA and EFD in Tanzania and EBM in Rwanda. A group buying on the strength of the Kenyan integration should read whichever of those applies before assuming coverage.
Our take
Fiscalisation should be invisible to your cashiers and impossible to skip by omission — a consequence of the sale rather than a step after it. Get your obligations in writing from an adviser, test returns and a failed transmission rather than a clean sale, and name the person who clears failures daily. And hold us to the same demonstrate-it-live standard we have asked you to apply to every other vendor in every other market.
See a sale fiscalise from the sale record
eTIMS mapped and transmitted from the POS sale itself, VAT-aware records, returns as documents linked to the original sale, and every sale moving stock in the same transaction.
Explore eTIMS & taxFrequently asked questions
Do cashiers have to do anything extra to fiscalise a sale?
They should not, and in a properly built setup they do not. Fiscalisation is a consequence of ringing up the sale rather than a separate step performed afterwards, which matters because any step that can be performed separately can be skipped during a busy period — and then you have two records that disagree and a reconciliation project. Train cashiers on returns and corrections instead; that is where errors actually get created at the counter.
What happens when a transmission fails?
It should become a visible failed state that a named person clears, rather than silence. This is the question we have told buyers to ask vendors in every market and it applies to us: ask to see a failed transmission, not just a successful one. Then decide internally who checks the failure queue and on what rhythm, because a failure state nobody owns is functionally the same as having no failure handling.
How are returns and refunds handled?
A return is a document in its own right, linked to the original sale, carrying a reason, the refund tender, whether the goods were restocked, support for an exchange rather than a refund, and who processed it. That matters both fiscally and operationally — a properly recorded return is explicable, whereas a cash refund typed in as an adjustment produces a till shortage with no story attached.
Does this mean we are compliant?
No, and we would be overreaching to claim it. What must be fiscalised, when, at what rate and with what exemptions for your specific business is KRA's domain and your tax adviser's call, and we do not file your returns — fiscalisation and filing are different things. Get your obligations in writing from an adviser, configure against that, and then reconcile a period you have already filed to prove the configuration reproduces the right figures.
Does the eTIMS integration cover our other African operations?
No — eTIMS is Kenya-only and nothing about it travels. Nigeria, Ghana, Uganda, Tanzania and Rwanda run on the general operations, multi-currency and VAT-aware layer, with fiscalisation handled by your existing process and reconciled against your records. This asymmetry catches groups out, so if you are buying partly on the strength of the Kenyan integration, read the country-specific guide for wherever else you operate before assuming coverage.
