PSP reconciliation: why the bank never quite matches
Anyone who collects payments through a payment service provider knows the pattern: revenue sits in the webshop or POS system, the payout sits on the bank statement, and in between is an amount that never quite adds up. That is not sloppiness. It is built into the model.
A PSP does not pay out per transaction but in batches. One payout bundles the transactions of one or more days, net of transaction fees, with refunds and chargebacks settled in the same batch. What lands on the bank is a single amount that is the sum of hundreds of transactions, minus fees, minus refunds, plus corrections. Working that amount back to revenue is exactly the searching that swallows hours every month.
Why the suspense account fills up
The classic approach books the payouts to a suspense account and tries to empty it afterwards. As long as everything matches that works, but every deviation stays behind: a chargeback without a contra entry, a payout that straddles the month boundary, fees that differ slightly from what was expected. By the end of the quarter there is a balance nobody can trace back, which eventually gets written off as a “difference”.
"The gap between webshop and bank is not a rounding difference. It is the sum of transaction fees, refunds and clearing times, and once you book those three separately, there is nothing left to search for."
Three flows, three postings
The reconciliation only becomes deterministic when you build it from the source that specifies everything, and pull apart the flows that currently sit in one pile:
- Reconcile against the settlement report, not the bank statement. Every PSP provides a report per payout that specifies exactly which transactions, fees and refunds it contains. That report is the bridge between revenue and bank; the bank statement only shows the outcome.
- Book fees and refunds as separate flows. Transaction fees to the cost account, refunds against revenue. What remains matches the payout one-to-one, and differences get a name instead of a dumping ground.
- Turn the suspense account into a check instead of a parking lot. An empty suspense account at period end is the proof that the reconciliation holds. Any remainder is a finding with an identifiable cause, not an item to write off next quarter.
What this looks like in practice
Settlement reports are available from virtually every PSP via an API or export, and matching lines against revenue and bank is work for a system, not for a controller. An integration fetches the reports automatically, records the three flows and leaves only the lines that cannot be explained automatically.
The month-end close then gains a fixed check: are the suspense accounts empty, and if not, what is on them and why? An agent that runs that check the same way every month and investigates the remainders turns the suspense account into a control point instead of a risk, and nothing is posted without your approval.
