Selling When the Internet Drops: Offline POS in Kenya
A till that stops working when the connection drops does not fail gracefully — it teaches your cashiers to keep a paper book, and then you are running two systems. What offline selling actually requires, and what to decide before it happens.
The connection will drop. Not as a rare disaster — as a normal Tuesday. A fibre cut on the road outside, a router that needs restarting, a power interruption the UPS covers for the till but not for the switch, a mobile network that degrades for twenty minutes at 5pm. In a Kenyan retail environment this is an operating condition rather than an incident.
What matters is not whether it happens but what your counter does when it does. And the failure that costs most is not the lost twenty minutes of sales — it is that a till which stops working teaches the cashier to reach for a paper book, and a paper book that worked once will be reached for again.
The real cost of a till that stops
Businesses evaluate offline capability as insurance against downtime revenue. That undersells it substantially, because the expensive consequences are behavioural rather than financial.
- A parallel process gets established. Once a paper fallback exists and works, it becomes the thing people use whenever the system is inconvenient, not only when it is unavailable.
- Back-entry is lossy. Sales written on paper and typed in later lose the detail — the customer, the exact items, the discount, sometimes the sale entirely if the paper is mislaid.
- Stock drifts silently. Goods left the shop and inventory did not move, so your position is wrong from that moment and nobody knows by how much.
- The shift cannot be reconciled. Cash in the drawer includes sales the system has never heard of, so the variance is meaningless and gets absorbed.
- Trust in the system erodes. People remember the day it stopped working far more vividly than the months it worked, and they plan around it.
The cost of an outage is not the sales you missed. It is the paper book your cashier learned to trust, which they will now reach for whenever the system is merely inconvenient.
What offline actually has to mean
Offline is a word vendors use loosely, so it is worth being specific about what a counter needs in order to keep trading through an outage.
| Requirement | Why | The failure if missing |
|---|---|---|
| Sell without a connection | The queue keeps moving; no paper fallback is created | A parallel process is born and never dies |
| Hold the sale locally, then sync | Nothing depends on the network at the moment of sale | Back-entry from memory, with everything it loses |
| Sync without duplicating | Reconnection must not create a second copy of the same sale | Doubled revenue, doubled stock movement, an evening lost |
| Keep the shift reconcilable | Cash and sales still have to tie at close | The variance is meaningless and gets absorbed |
| Make the pending state visible | Somebody has to know what has not yet reached the server | Silent gaps discovered at month-end |
The third row is where implementations genuinely go wrong, and it is worth testing rather than trusting. Duplication on reconnection is a real failure mode — it produces sales counted twice, stock moved twice and a reconciliation nobody can complete. In the demo, take the device offline, record several sales, reconnect, and count what arrives.
What AWRA does here
Offline capture runs on ordinary Android devices as an offline-first design rather than a degraded mode bolted on: operations are captured on the device and held, then synchronised when the connection returns, with registered devices and their pending operations tracked so the outstanding state is visible rather than assumed.
What AWRA OpsHub does today
- Offline-capable capture on ordinary Android devices, with sales held locally and synchronised when connectivity returns.
- Registered offline devices with their pending operations tracked, so what has not yet reached the server is visible.
- Stock movements syncing with the sales that caused them, so the position corrects itself on reconnection rather than needing manual repair.
- Shift sessions still reconcilable, with float, drops, expected and counted cash — see till and shift reconciliation.
- The same pattern across the product — field, depot, farm-gate and site capture use it too, not only the till.
What it does not do
- eTIMS transmission cannot happen while offline. Fiscalisation requires a connection, so it occurs on synchronisation rather than at the moment of sale. Confirm with KRA or your tax adviser what timing is acceptable for your business before relying on offline trading — this is the single most important thing to check on this page.
- No offline card or mobile money authorisation. Those tenders need their own networks; offline capture records the sale, it does not authorise a payment.
- No conflict resolution for the same stock sold twice offline at two disconnected tills — if two counters both sell the last unit while disconnected, both sales sync and the stock position goes negative for you to resolve.
- We do not supply tills, tablets or UPS, and we do not control cash drawers.
The eTIMS point is a genuine constraint rather than a caveat. If your obligation requires fiscalisation at the point of sale, an outage is a compliance question and not merely an operational one, and you should establish your position with KRA or your adviser rather than inferring it from what the software permits.
Decide these before an outage, not during one
The technical capability is the easy half. The half that determines whether an outage is a non-event is a set of decisions somebody has to make in advance, in writing, and tell the counter staff about.
-
Decide what you will and will not sell offline
Cash sales, straightforwardly. Card and mobile money need their own networks. Credit sales to account customers may need a check you cannot perform. Write the answer down before a cashier has to improvise it.
-
Establish your fiscal position with an adviser
Because fiscalisation happens on sync rather than at sale, get a written view on whether and for how long offline trading is acceptable for your business. Do this once, properly.
-
Name who monitors pending operations
Someone checks that everything captured has synced, on a daily rhythm. Pending operations nobody watches become the gap discovered at month-end.
-
Ban the paper book explicitly
Not because paper is evil, but because the device works. If the device is genuinely unavailable, paper is a documented exception with a manager's name on it, not a habit.
-
Rehearse it
Take a till offline deliberately during a quiet hour, trade on it, reconnect and reconcile. A rehearsed outage is an inconvenience; an unrehearsed one is the day the paper book comes back.
Rehearse the reconnection, not just the outage
Most teams test whether they can sell offline and stop there. The half that goes wrong is reconnection: whether sales arrive once, whether stock lands correctly, whether the shift still reconciles, and whether anything sat pending unnoticed. Test that with real transactions before you depend on it, ideally during onboarding while somebody is available to help.
Offline is not only a till problem
The same capability matters wherever work happens away from a reliable connection, and in most Kenyan businesses that is more places than the shop floor. A van selling on a route, a storekeeper receiving a delivery at a depot, a supervisor counting stock at a site, a buying agent at a farm gate, a field officer capturing a service visit.
The reason this matters commercially is that a system which only works in the office quietly relocates all record-keeping to the office — where it becomes back-entry from paper, days late, by someone who was not there. The distribution version is in inventory and distribution in Lagos, the field version in offline field workflows and van stock and site custody.
Our take
Treat connectivity loss as an operating condition rather than an incident, and test reconnection rather than just the outage. Then settle two things in advance: your written fiscal position, since eTIMS transmission happens on sync rather than at the sale, and who checks daily that nothing is stuck pending. Those two decisions are what separate an outage that nobody remembers from the day your counter learned to use paper again.
See a counter that keeps trading
Offline-first capture on ordinary Android devices, pending operations visible per device, stock movements syncing with the sales that caused them, and shifts that still reconcile.
Explore offline operationsFrequently asked questions
Can we keep selling when the internet goes down?
Yes — capture is offline-first on ordinary Android devices, so sales are recorded on the device and synchronised when the connection returns, with stock movements syncing alongside the sales that caused them. The important caveat is fiscal rather than technical: eTIMS transmission requires a connection, so fiscalisation happens on synchronisation rather than at the moment of sale, and you should establish with KRA or your tax adviser whether and for how long that is acceptable for your business.
What about card and mobile money during an outage?
Those tenders need their own networks and cannot be authorised offline — offline capture records a sale, it does not authorise a payment. So decide in advance what you will accept while disconnected, which in practice usually means cash, and make sure counter staff know the answer before they have to improvise it in front of a queue.
Will sales be duplicated when the connection returns?
They should not be, and this is the specific thing worth testing rather than trusting. Duplication on reconnection is a real failure mode in offline systems and it produces sales counted twice, stock moved twice and an evening lost to reconciliation. In your demo or onboarding, take a device offline, record several sales, reconnect and count exactly what arrives.
What if two disconnected tills sell the same last unit?
Both sales sync and your stock position goes negative for you to resolve — there is no automatic conflict resolution for that case, and we would rather say so than let you discover it. In practice it is rare in a single shop with shared visibility and more likely across genuinely separate locations, so if you run multiple disconnected points selling from one scarce pool, treat that as a process question rather than assuming the software arbitrates.
Why does a paper fallback matter so much?
Because a paper process that worked once will be used again whenever the system is merely inconvenient rather than unavailable, and then you are running two systems permanently. Sales written on paper and typed in later lose detail, stock drifts from the moment goods leave, and the shift cannot be reconciled because the drawer holds cash for sales the system never saw. If the device is genuinely unusable, paper should be a documented exception with a manager's name on it rather than a habit anyone reaches for.
