
August 17, 20265 min readАдминистратор
The reconciliation nets to zero. Why the day may still be open
Matching totals can hide two errors. Check report completeness, transaction links and exception age against the expected deadline.
Two errors of 500 can cancel each other perfectly. A matching total does not establish that money belongs to the right orders or that a payout reached the bank. Daily reconciliation should leave a traceable path for every material movement, from the internal record through the provider’s report to the bank.
A worked day, using hypothetical figures
Suppose the opening processor balance is 10,000. Receipts add 250,000, refunds remove 8,000, fees remove 4,500, and a bank payout removes 232,500. The expected closing balance is 10,000 + 250,000 − 8,000 − 4,500 − 232,500 = 15,000. A reported closing balance of 15,000 explains the overall movement. It does not yet prove that each refund belongs to the correct order, each fee is correct, or the bank has received the payout.
If the bank credit is missing, create an in-transit item linked to the batch and its expected arrival date. Do not initiate another payout simply to make the bank statement match. Similarly, two payments of 1,200 are not interchangeable matches. When the identifying reference is missing, obtain additional evidence instead of selecting whichever row clears the exception.
Zero can still deserve an investigation
In a hypothetical example, a 500 refund for order A is missing while a 500 refund for order B is counted twice. The total agrees with the report. Two order-level errors remain, and both can affect the next support decision. Check movement count, type and identifiers alongside the aggregate amounts.
Start automated matching with stable keys. Where those keys are unavailable, label the result a probable match and define the evidence required for manual confirmation. Do not quietly widen amount tolerances to improve the automation percentage. A one-cent difference could follow a documented rounding rule or belong to another transaction. Retain the reason used to resolve it.
Check input completeness too: row counts, earliest and latest timestamps, currencies, period boundaries and every export segment. If a report stops at 5 p.m. instead of the agreed 11:59 p.m., looking for “missing” evening payments merely creates false exceptions. Restore the complete source first.
Define the day before matching it
Set the reporting timezone, cutoff, legal entity, currency, and account scope. Keep transaction creation time, booking time, and funds-availability time in separate fields. A late-evening payment can belong to another settlement batch without anything being wrong. If you rerun the reconciliation, preserve the same boundaries and identify which version of each input file you used.
Reports serve different purposes. Stripe explains that its Balance summary report contains period activity and payouts but does not associate individual payments with each payout. It supports a balance roll-forward rather than a reconstruction of every payout batch. Source: Stripe, Balance summary report.
Match three layers
- 1.Order to transaction. Link your internal reference to the processor identifier, event type, amount, and currency. A refund should reference its original payment while remaining a distinct movement.
- 2.Transactions to settlement batch. Combine gross receipts, refunds, fees, and documented adjustments. Check the resulting net batch value.
- 3.Batch to bank. Match the payout to the bank credit using the available reference, currency, and amount. Define timing tolerances separately from amount tolerances.
Adyen’s Settlement details report includes transactions, fees, deposit adjustments, and payouts. Its MerchantPayout entry provides information for connecting a settlement batch to the bank receipt. A list containing only successful payments cannot provide this full picture. Source: Adyen, Settlement details report.
Build an exception queue that can be worked
Use separate categories for exact matches, expected timing differences, documented adjustments, and unexplained discrepancies. For every open item, record its value, age, owner, evidence, and next review date. A timing difference remains open until the expected movement is confirmed. “Check later” is not a resolution category.
Stripe’s payout reconciliation report is designed around automatic payouts; Stripe cannot automatically identify the transactions belonging to an instant payout. Your matching approach therefore needs to reflect the actual payout mode. Source: Stripe, Payout reconciliation report.
Age exceptions against the expected event
A five-day-old transaction is not necessarily overdue if its payout is expected tomorrow. A one-day-old item may already require intervention if its agreed deadline has passed. Keep both the first-detected date and the time at which the expected movement becomes late. The queue can then distinguish normal waiting from an interrupted sequence.
Make reasons specific enough to drive action: no bank match for the batch, missing report segment, or refund without an original-payment link. Other should trigger classification rather than become permanent storage. When a reason recurs, open a process-fix task as well as resolving the current row.
Close the daily report with two figures: unexplained value and explained-but-unresolved expected movements. They call for different management discussions. The second can be large and still on schedule; the first can be small but reveal a systematic error. Show large items separately so netting cannot hide them again. A signed-off daily report can retain documented open items, provided their owners and next checks remain visible rather than disappearing into a balancing adjustment.
What stays open after the daily close
Report matching rates by both count and value, the age of unresolved items, and the unexplained balance. Matching thousands of small transactions is little comfort if a large payout remains missing. A P2P operator should also reconcile the allocation of funds to user liabilities: agreement with the bank balance does not prove that individual user balances are correct.
Report matches by both count and value. For a P2P service, reconcile the allocation of liabilities between users: agreement with the aggregate bank balance does not establish that every individual user balance is correct.
Ask a colleague to select one large open item and trace it from the internal order to the bank. If the path breaks, mark the exact gap and expected evidence. This spot check tests reconciliation quality more effectively than another green match-rate percentage.
Comments · 0
No comments yet — be the first.
Log in · log in to leave a comment.