Offline Sync: What the Word Should Mean
Offline is the word that gets used loosest in this market. What it means here: operations captured on a device with no connection, replayed with an idempotency key so a retry cannot duplicate, device trust that expires, and conflicts surfaced rather than silently resolved.
Every vendor selling in East Africa claims offline capability, and most of them mean one of three quite different things: the app does not crash when the signal drops; the app caches a read-only copy so you can look things up; or the app genuinely records work with no connection and reconciles it later. Only the third is worth anything to a delivery driver in Kitui, and only the third has hard problems in it.
The hard problems are duplication and conflict, and how a system handles those two is the only thing worth asking about.
How duplication is prevented
A device with no connection records an operation and holds it. When it reconnects it sends a batch. If the response is lost — which on a bad connection is more likely than an outright failure — the device has no way to know whether the server received it, so it sends again. Without protection, one stock issue becomes two.
The mechanism is a client-generated operation identifier attached to each captured operation. The server records what it has already applied against that identifier, so a resend is recognised and acknowledged rather than reapplied. This puts the responsibility in the right place: the device knows what it captured, and it does not need to know whether the server heard.
A driver in a dead zone
Batches are capped — a couple of hundred operations at a time — so a device that has been offline for two days uploads in chunks rather than in one request that times out on a weak connection and starts the whole cycle again.
Conflicts are surfaced, not resolved
Two devices offline at the same time can capture operations that contradict each other. The last unit of stock issued twice. A delivery confirmed by one person and marked failed by another. Any system that resolves this automatically has picked a winner using a rule you did not choose, and in stock terms that means a figure that is quietly wrong.
Here, an operation that cannot be applied cleanly is given a conflict status and surfaced for a person to deal with, in an operations centre for exactly this purpose. That is slower and it is correct — a conflict is information about your process, and hiding it converts a discoverable problem into an unexplained variance at the next count.
The honest limit at the till
Two disconnected tills selling the same last unit is a case with no clean resolution and no automatic handling. If you run multiple tills on unreliable connectivity, know that this specific scenario needs a human, and that the alternative — a system that silently picked one — would have given you a wrong stock figure with no flag on it.
Device trust, and why it expires
A device permitted to work offline is a device holding business data and authority away from any control you can exercise in the moment. So offline trust is granted per device, visible in a register, and it expires — a trusted device stops being trusted after a period rather than remaining trusted because nobody revisited it.
What is held per device
Attribute Why it exists
Registration and heartbeat So you can see which devices are alive and which have gone quiet
An offline trust expiry So a lost phone stops being able to capture work on its own
Location with accuracy, where captured So "delivered" has a place attached to it, not just a time
Operation status, including conflicts So a stuck operation is visible rather than lost
The whole register sits behind its own permission, which is the correct shape — approving a device to work unsupervised is a security decision and not an operational one, and it should not travel with the permission to receive stock.
What offline covers, and what it does not
What AWRA OpsHub does today
- Operations captured on a device with no connection and replayed when it reconnects.
- A client-supplied operation identifier making a resend safe, so lost responses do not duplicate work.
- Batched upload with a cap per batch, so a long offline period does not become one request that cannot complete.
- Conflict statuses surfaced to a person in an operations centre rather than resolved by a rule.
- Per-device registration, heartbeat and an expiring offline trust, behind its own permission.
- Location with accuracy recorded where the device captured it.
What it does not do
- eTIMS cannot transmit while offline. A sale captured offline carries no fiscal reference until it reconnects, which makes a connectivity gap a compliance question as well as an operational one.
- No offline card or mobile-money authorisation. A payment needs a connection.
- No automatic resolution when two disconnected devices sell the same last unit.
- No offline capability in the web interface — this is the mobile path.
The eTIMS point is the one to decide policy on before go-live rather than after. The eTIMS integration post sets out the three possible policies and why the workable one is a check at cash-up.
Questions to ask any vendor claiming offline
Three questions, and what the answers reveal
If the response to a sync is lost, what stops the device duplicating the work?
What you will hear
"It handles that."
How to read it
Ask for the mechanism by name. If there is no client-side operation identifier or equivalent, duplication is prevented by luck. This is the single most diagnostic question in the whole area.
What happens when two offline devices contradict each other?
What you will hear
"Last write wins" or a confident "it merges".
How to read it
Both are answers to avoid. Last-write-wins on stock means a wrong figure with no flag. A system that surfaces the conflict is admitting it cannot decide, which is the truth.
Can a device work offline indefinitely once approved?
What you will hear
"Yes, once it's trusted."
How to read it
Then a lost phone can capture work forever. Expiring trust is the difference between a control and a one-time decision nobody revisits.
Our take
Offline is only meaningful if resending is safe and conflicts are visible — everything else is caching. Ask any vendor how a lost response is prevented from duplicating work, and whether device trust expires. Then decide your eTIMS offline policy explicitly, because that is the part where a connectivity problem becomes a compliance one.
Capture work where the signal is not
Operations held on the device, replayed with an [idempotency](/glossary/idempotency) key so a retry cannot duplicate, batched uploads, conflicts surfaced to a person, and per-device trust that expires rather than lasting forever.
See plans & pricingFrequently asked questions
What does offline mode actually do?
Operations are captured on a mobile device with no connection and replayed when it reconnects, in capped batches. Each operation carries a client-generated identifier, so if the response is lost and the device resends, the server recognises it and does not apply it twice. Location with accuracy is recorded where the device captured it.
How is duplicate work prevented?
A client-supplied operation identifier on every captured operation. The server records what it has already applied against that identifier, so a resend is acknowledged rather than reapplied. This matters because on a weak connection a lost response is more likely than an outright failure — the device cannot tell whether the server heard, so it will send again.
What happens when two offline devices conflict?
The operation that cannot be applied cleanly is given a conflict status and surfaced for a person to resolve in a dedicated operations centre. It is deliberately not resolved automatically: a last-write-wins rule on stock produces a figure that is quietly wrong, and a conflict is information about your process rather than noise to suppress.
Can two disconnected tills sell the same last unit?
Yes, and there is no automatic resolution for it. If you run multiple tills on unreliable connectivity, know that this specific case needs a human — and that the alternative would be a system silently choosing a winner and handing you an unflagged wrong stock figure.
Can a device work offline indefinitely?
No. Offline trust is granted per device and expires, so a trusted device stops being trusted after a period rather than staying trusted because nobody revisited the decision. The device register sits behind its own permission, since approving a device to work unsupervised is a security decision rather than an operational one.
Does eTIMS filing work offline?
No. A sale captured offline carries no fiscal reference until the device reconnects, which turns a connectivity gap into a compliance question. Decide the policy before go-live: the workable answer is to keep selling and check at cash-up that every sale carries a fiscal reference, filing whatever does not.
