Integrations
Reconciliation work needs an exception ledger before numbers are adjusted
Reconciliation should not begin by editing the number that looks wrong. It should begin by recording the mismatch: source records, compared fields, timing, expected tolerance, owner, proposed explanation and allowed next action.
The answer: record the mismatch before fixing it
Reconciliation should not begin by editing the number that looks wrong. It should begin by recording the mismatch: source records, compared fields, timing, expected tolerance, owner, proposed explanation and allowed next action. An exception ledger gives the team a place to hold disagreement without hiding it.
Imagine an illustrative order system, payment processor and accounting tool. One shows a customer payment, one shows a payout after fees and one shows an invoice balance. The numbers differ because they represent different events. If staff adjust the accounting balance without preserving the comparison, the immediate report may look better while the underlying process remains unclear.
Compare records, not totals alone
Totals are useful for spotting drift, but they rarely explain it. A reconciliation workflow should compare record identity, amount, currency, event time, availability time, status, fee, tax, refund and adjustment references. Some differences are normal timing differences. Some are classification differences. Some are errors.
Stripe API documentation for balance transactions describes transactions that contribute to the account balance and includes fields such as amount, fee, net, status, type, source and payout filtering. The lesson for broader reconciliation is that the comparison needs enough structured fields to explain why two systems report different values.
Give every exception a state
An exception ledger should distinguish new, investigating, explained timing difference, awaiting source correction, approved adjustment, rejected adjustment and resolved. Those states prevent the same mismatch from being discovered again every morning. They also separate observed disagreement from a decision to change business data.
Store the comparison snapshot. If either source system changes later, the team still needs to know what was true when the exception was opened. The ledger should link back to source records without copying sensitive data unnecessarily.
Adjustments need approval and traceability
Some exceptions require no adjustment. A payout fee, pending refund or settlement delay may simply need explanation. Other exceptions may require correcting a mapping, reversing a duplicate entry or posting an approved adjustment. The ledger should define which actions are allowed for each exception type and who can approve them.
Avoid free-text corrections with no classification. A short reason code plus a note usually gives better reporting than a paragraph alone. Over time, repeated reasons reveal whether the problem is timing, integration mapping, missing source data or staff training.
Start with one reconciliation boundary
Choose one boundary that matters: payment processor to accounting, warehouse shipments to invoices, subscription system to CRM or support credits to billing. Define the source of truth for each field, the accepted timing window and the owner for exceptions. Then run the ledger alongside manual review before automating adjustments.
The practical takeaway: reconciliation is an evidence workflow. The exception ledger protects that evidence so corrections become explainable rather than mysterious edits.