Ask a POS vendor whether their system is cloud-based and they will say yes. Ask whether it works offline and they will also say yes. Both answers can be technically true and still leave you unable to sell during a power cut.
The useful question is narrower: when the network drops mid-afternoon, exactly which functions keep working? This guide explains the real difference between the architectures and gives you a test you can run during a trial.
The three architectures
Most systems marketed in Kenya fall into one of three categories.
Legacy on-premise
Software installed on a specific computer in your shop, with the database on that same machine. No internet required for day-to-day trading.
This is how most older Kenyan retail systems work. The strengths are real: it is fast, and a network outage is irrelevant. The weaknesses are also real. You cannot see your sales unless you are physically in the shop. Multi-branch means separate systems that someone consolidates manually. Backups depend on someone remembering. If the machine dies, the business data dies with it unless you were disciplined. Updates require a technician visit.
Pure cloud
The application and the database live on a server; your device is essentially a browser. Fast to set up, accessible from anywhere, automatically backed up, and updates itself.
The problem is the failure mode. No connection means no POS. In a market where power cuts and network drops are routine, a pure cloud POS goes down exactly when you can least afford it — during a busy trading period, with a queue in front of you.
Offline-first cloud (the hybrid)
The application runs locally on your device with a local copy of the data it needs, and syncs to the cloud continuously in the background. When the connection drops, trading continues against the local copy. When it returns, everything queued is sent up.
This is what a Kenyan business actually needs, and it is what the rest of this guide assumes you are shopping for.
What "works offline" needs to mean
Vendors use "offline mode" loosely. Some mean the app opens but cannot complete a sale. Some mean you can sell but stock does not deduct. Get specific. Here is what genuinely matters:
| Function | Should work offline? | Why |
|---|---|---|
| Complete a cash sale | Yes | This is the baseline. Without it there is no offline mode |
| Deduct stock | Yes | Otherwise your stock count is wrong the moment you reconnect |
| Print a receipt | Yes | Customers need proof of purchase regardless of your connectivity |
| Queue the eTIMS submission | Yes | Sale proceeds now, KRA receives it on reconnect |
| Look up product and price | Yes | Requires a local catalogue copy |
| Record the customer | Yes | Loyalty and credit tracking should not pause |
| M-Pesa STK Push | No — cannot | Requires reaching Safaricom's servers. Physics, not a limitation of the software |
| Card payment | No — cannot | Same reason |
| Live multi-branch reporting | No | Needs data from other locations |
The two "no" rows are worth dwelling on, because a vendor claiming otherwise is misleading you. M-Pesa confirmation requires talking to Safaricom. No POS can confirm an M-Pesa payment without a network.
What a good system does instead is handle it gracefully: let the cashier record the sale as an M-Pesa payment pending confirmation, complete the transaction, and reconcile automatically when the connection returns. What a bad system does is block the sale entirely.
The sync question nobody asks
Offline mode is the easy half. Sync is where systems actually fail, and it is worth understanding before you buy.
What happens when two branches sell the last unit offline? Both devices thought they had stock. On reconnect, the system must resolve this. A good system records both sales, flags the negative stock, and tells you. A bad one silently overwrites one of them, and you have lost a sale from your records.
What is the sync order? Transactions should sync in the order they occurred, not in the order devices happen to reconnect. Otherwise your daily sales sequence and your eTIMS submissions come out scrambled.
How long can you stay offline? Some systems queue for hours, others for days. If you trade in an area with genuinely unreliable connectivity, ask for the actual limit.
What if a device is lost while holding unsynced sales? Those sales existed only on that device. Ask what the exposure window is — a system that syncs every few seconds when connected loses far less than one that batches hourly.
Which do you need? A decision guide
Single shop, reliable fibre, low volume. You could run pure cloud and mostly be fine. But offline-first costs nothing extra and removes the risk entirely, so there is no good reason to accept the exposure.
Any shop where a lost hour of trading hurts. Offline-first, without question. Calculate what an hour of your peak trading is worth and compare it to the price difference. The comparison is not close.
Multi-branch. Cloud is mandatory — you need consolidated reporting and stock visibility across locations. Offline-first is equally mandatory, since one branch losing connectivity should not stop it trading. See our multi-branch operations guide.
Market stalls, pop-ups, events, delivery vans. Offline-first is the entire proposition. You will trade in places with no reliable connection at all, and the system needs to treat that as normal rather than exceptional.
Rural and upcountry locations. Offline-first, and specifically ask about the maximum offline duration and how the system behaves on a slow connection rather than a dead one. Intermittent, high-latency connections are often harder for software to handle well than a clean outage.
The test to run during your trial
Do not accept offline capability on a vendor's word. Fifteen minutes will tell you the truth.
- Load some real products into the trial account and let it sync.
- Put the device into flight mode.
- Complete a cash sale. Did it go through? Did the receipt print?
- Check the stock level for what you just sold. Did it decrease?
- Try an M-Pesa sale. Does it fail gracefully with a clear message, or does it hang or crash?
- Complete two or three more sales offline.
- Turn the network back on. Wait a minute.
- Open the dashboard on a different device. Are all the offline sales there, with the right times, amounts and stock movements? Were the eTIMS receipts submitted?
Any failure in steps 3, 4, 7 or 8 disqualifies the system for Kenyan trading conditions.
How sell.ke handles it
sell.ke is offline-first by design. The POS runs locally with your catalogue and prices cached on the device, so sales, stock deduction and receipt printing continue during an outage. eTIMS submissions queue and are sent automatically on reconnect. M-Pesa payments are recorded as pending and reconciled the moment connectivity returns.
Because it is also fully cloud-backed, you get the other half: consolidated multi-branch reporting, access from any device, automatic backups, and updates without a technician visit.
There is more detail on the offline POS page and the cloud POS page.
Frequently asked questions
Can any POS accept M-Pesa without internet? No. Confirming an M-Pesa payment requires contacting Safaricom's servers. What a good POS does is record the sale immediately and reconcile the payment when the connection returns, so the queue keeps moving.
Does offline mode work during a power cut? The software does, if your device has battery. A tablet or laptop keeps running. A desktop connected to mains does not. For this reason many Kenyan shops standardise on tablets — the battery is the backup.
How long can sell.ke stay offline? Sales queue locally and sync when connectivity returns. For extended outages, the practical limit is device storage rather than a fixed time window.
Will my stock be wrong after an offline period? Not if the system deducted stock locally during the outage — it will match once synced. The exception is the genuine edge case of two locations both selling the last unit while offline, which should be flagged rather than silently resolved.
Is offline-first slower than pure cloud? The opposite. Reading from a local database is faster than a round trip to a server, which is why offline-first systems usually feel quicker at the till even when the connection is good.