Resolving a sync exception
Resolving a sync exception means deciding what a field-collected payment that could not auto-post should actually do to the books. It is a review-and-clear workflow: you examine the queued collection, confirm what happened on the ground, and either post it correctly or reject it — closing the gap between the device and the ledger.
Before you start
Open the sync-exception queue in the portal. Each entry is a field collection that reached the server but could not reconcile cleanly — so each one represents money that may have moved and needs a decision.
The workflow
- 1Review the exceptionLook at what the agent captured — the borrower, the amount, the receipt and, where present, the visit's GPS and timestamp — and compare it against the loan it was meant to apply to.
- 2Confirm what happenedEstablish whether the payment is genuine and which loan and instalment it belongs to. The agent's receipt and worklist are your evidence.
- 3Clear itApply the payment to the correct loan so it posts to the ledger, or reject it if it is a duplicate or error. Either way the exception leaves the queue with an explicit outcome.
Offline collections each carry an idempotency key, so a payment that was actually already recorded will not be posted twice even if it also appears as an exception. This is why some exceptions resolve simply by confirming the payment already landed.
Why clearing them matters
An unresolved exception is an unconfirmed payment. Until it is cleared, the borrower's balance and the loan's DPD may be wrong, which can trigger the dunning ladder against someone who has already paid. Working the queue to zero keeps collections accurate and keeps borrowers from being chased in error.