Why the settlement break is never where you look for it
Provider statements, your ledger and the trading platform disagree for structural reasons: cut-off times, conversion timing, and fee netting. Most reconciliation effort is spent rediscovering this.
A provider settles a number that does not match your ledger. The instinct is to look for a missing transaction. It is almost never a missing transaction. Four structural causes explain the overwhelming majority of differences, and only one of them is anybody’s fault.
The four break classes
| Class | Cause | Resolves by itself? | Action |
|---|---|---|---|
| Timing | Cut-off times differ between you and the provider | Yes, next cycle | Carry forward, do not adjust |
| Conversion | FX applied at different rates or moments | No | Book the difference to FX |
| Netting | Fees, refunds or chargebacks deducted before settlement | No | Gross up and reclassify |
| Genuine | Transaction settled, never arrived | No | Claim, with evidence |
Timing is the loudest and least important
Your ledger day ends at midnight in your reporting timezone. The provider’s settlement window ends at some other hour in some other timezone, often with a cut-off that shifts on weekends and local holidays. Every transaction between the two cut-offs appears as a difference and disappears next cycle. Adjusting for it creates a second break in the opposite direction.
Δ_timing = Σ transactions with timestamp ∈ [cutoff_provider, cutoff_ledger)A reconciliation that produces the same exception every day has stopped being a control. It is a report nobody reads.
Conversion, and why the rate is never the issue
Multi-currency settlement breaks are usually blamed on the rate. The rate is rarely wrong. What differs is the moment of conversion, authorisation, capture, settlement or payout, and the two sides have picked different moments. Over a month of ordinary volatility this produces a difference far larger than anyone expects from “a rounding issue”.
- 01AuthorisationClient sees this rate
- 02CaptureHours to days later
- 03Provider settlementTheir treasury rate, their window
- 04Your payoutYour bank, your timing
Netting hides the interesting movements
Providers frequently settle net of fees, refunds and chargebacks. A net figure that matches your gross expectation by coincidence is worse than one that visibly disagrees, because it conceals two offsetting movements. Gross-up before comparing, always, and reconcile the deductions as their own population, since chargeback timing is the one deduction that carries real information about client behaviour.
| Component | Amount | Class |
|---|---|---|
| Expected from ledger | $2,482,317 | , |
| Reported by provider | $2,463,897 | , |
| Difference | −$18,420 | , |
| Transactions after provider cut-off | −$11,240 | Timing |
| Conversion struck at settlement, not capture | −$3,110 | Conversion |
| Chargebacks netted pre-settlement | −$2,890 | Netting |
| Unexplained | −$1,180 | Genuine |
Illustrative figures, chosen to show the mechanism. Your own numbers will differ.
The discipline that matters: never plug
When three of four classes are explained and a residual remains, the pressure is to post an adjustment and close the period. That is the moment a reconciliation stops being one. The residual is the only output of the entire exercise with information in it; absorbing it into an adjustment account destroys the thing you did the work to find.
- Explained differences are carried, reclassified or booked to a named account, never to “adjustments”.
- Unexplained differences stay unexplained, visibly, with the transactions attached.
- A residual that recurs at similar magnitude is a systematic issue, not a series of small ones.
- Anything automated here must be able to say “I cannot explain this” rather than forcing a match.
This is the reason reconciliation automation so often disappoints. A system that always produces a tidy answer is not doing reconciliation; it is doing bookkeeping with extra steps. The valuable behaviour is the refusal to close.