How offline sync and replay works
Offline collections, receipts and visit logs are recorded on-device and queued while there is no signal. The moment connectivity returns, that queue replays to the server — and the design ensures a replay is always safe to run, however many times the network forces it.
What is queued while offline
Everything an agent does off-grid is written to a local on-device queue: cash collections, the receipts issued for them, and GPS-verified visit logs with any promise-to-pay. Each write carries its own idempotency key, so it can be identified uniquely on the server no matter when it arrives.
What happens the moment signal returns
- 1The queue begins syncingAutomatically — the agent does not have to trigger it. Queued writes upload in order.
- 2The server deduplicatesBy idempotency key, so a write resent after a dropped connection is posted exactly once.
- 3Records confirm or flagA clean write is confirmed; a genuinely broken one is routed to a recoverable exception queue rather than lost.
Receipts and collections replay together
A collection and the receipt issued for it share the same idempotency key, so they move as a single unit — both reach the server together and finalise together. There is never a scenario where a receipt exists without its matching ledger entry, or the reverse.
If a write cannot post cleanly — for example a mismatched loan reference — it surfaces as a sync exception for an operations supervisor to review and clear. This is why sync exceptions are treated as money-authority alerts in the portal rather than background noise.