Why reconcile: four sources of truth that never agree
Reconciliation proves, line by line, that every euro sold became a euro collected, and then a euro booked. Between the order on the website and the general ledger entry, the money passes through several systems, each with its own clock, its own level of detail and its own definition of the amount. The same payment shows up with several amounts and several dates, each one correct in the system it comes from.
These four sets of records never match on their own. A sale made on Monday evening is captured on Tuesday, settled by the PSP on Thursday in a batch that also contains two refunds and a chargeback, and then paid out net. The resulting bank transfer matches no individual sale, because its amount nets out transactions that move in opposite directions. Without proper reconciliation tools, the differences pile up in suspense accounts and quickly become impossible to audit, because no document links the amount received to the sales behind it.
The three levels of reconciliation
A mature reconciliation process has three nested levels, each defined by the sources it compares, its level of detail and the discrepancies it reveals. Level 1 compares sales with PSP transactions, level 2 compares those transactions with the settlement batch, and level 3 compares the batch with the bank statement. Collapsing all three into one check (“the transfer roughly matches the week's sales”) leaves every discrepancy unexplained, and the open items that result can never be cleared, because the intermediate document is missing.
| Level | Question it answers | Sources compared | Granularity | Frequency |
|---|---|---|---|---|
| 1. Transaction level | Does every order have exactly one captured payment transaction? | ERP / e-commerce ↔ PSP transaction reports | Individual transaction (order reference ↔ pspReference) | Daily, ideally continuous |
| 2. Settlement level | Does the settlement batch contain the right transactions with the right fees, and is the stated net amount correct? | Transaction reports ↔ PSP settlement reports | The batch and its gross-to-net breakdown | Every batch (daily or weekly) |
| 3. Bank level | Did the payout announced by the PSP reach the bank, for the right amount and on the right date? | Settlement reports ↔ bank statements (CFONB120, MT940, camt.053) ↔ general ledger | The bank entry (aggregated payout) | Daily (statement on D+1) |
Ledger matching: making reconciliation visible in the books
In French accounting, matching (lettrage) tags the entries in an account that offset each other with the same code (AA, AB, etc.). A receivable is cleared against its payment, and a gross sale against the net payout plus fees. Once an account is properly matched, its balance contains only unmatched entries: funds still in transit or anomalies to investigate. The balance therefore reflects transactions that are still being settled, not a buildup of old entries that were never offset.
411(Customers): matched invoice by invoice against payments.511(Items in collection): checks and bills deposited, awaiting credit to the bank account.512(Bank): reconciled against the bank statement with a bank reconciliation statement, not matched in the strict sense.467/471-472(clearing and suspense accounts): one sub-account per PSP (467-Adyen, 467-Stripe, etc.) is the key to a readable reconciliation.627(Bank charges): PSP fees, account maintenance fees, chargeback fees.654(Bad debt losses): chargebacks that are definitively lost.
# Account 467 "PSP Adyen" acts as a buffer between sales and the bank.
# Match code AA offsets gross sales against the net payout + fees.
467100 - PSP Adyen, funds receivable Debit Credit Match
--------------------------------------------------------------------------------
07/08 Card sales for 07/08 (automatic 12,638.45 AA
feed from the e-commerce platform)
07/10 Payout batch 42 (offset account 512) 12,500.00 AA
07/10 Fees batch 42 (offset account 627) 138.45 AA
--------- ---------
12,638.45 12,638.45
# Balance of match AA = 0: sales for 07/08 are fully accounted for.
# Any unmatched entry = funds in transit OR an anomaly to investigate.471 account balance that grows month after month is the classic sign of broken reconciliation, since every unresolved difference is parked there until someone explains it. Auditors look at this account first, because it holds the transactions nobody has documented. Hence the golden rule every back office should adopt: no entry in a suspense account older than 30 days without an open, dated investigation assigned to a named owner.Types of discrepancies: the usual suspects
A reconciliation discrepancy is any difference between two sets of records that remains after matching, with no identified offsetting item. A good reconciliation engine does more than detect these discrepancies: it classifies them automatically using a stable taxonomy that does not depend on the provider. Almost every discrepancy seen in production falls into one of the families below, and that classification determines the automated treatment that follows.
| Difference | Driver | Typical pattern | Processing |
|---|---|---|---|
| Fees | A “net” PSP deducts its fees from each payout; a “gross” acquirer invoices them separately | Payout below total sales; difference = sum of the fee columns in the settlement report | Book in 627, check against the contract's rate card |
| Refunds | Refunds are deducted from the next payout | Negative lines in the batch; payout sometimes negative (the PSP debits the merchant) | Link each refund to its original transaction |
| Chargebacks | Retroactive debit of the transaction + flat fee (€15 to €50 depending on the PSP) | Stand-alone debit several weeks after the sale, carrying the original transaction reference | Reinstate the customer receivable in 411 or book a loss in 654; track the representment cycle |
| Foreign exchange (FX) | Sale in a foreign currency, settlement in euros; scheme/PSP rate ≠ the day's accounting rate | A few tenths of a percent off on foreign-currency transactions | In France, FX gains and losses in 656/756 (trade items, PCG as revised in 2025); check the contractual FX markup |
| Timing differences | Capture on D, settlement on D+1/D+2, payout on D+2/D+7, weekends and public holidays | Friday's sale hits the bank on Wednesday; month-end cutoff | Matching windows of ± n days; cut-off entries at period close |
| Rolling reserve | The PSP holds back 5% to 10% of volume for 90 to 180 days (high-risk sectors: travel, ticketing) | Payout consistently x% lower; deferred releases | Receivable from the PSP, tracked in a dedicated account with a release schedule |
| Partial / multiple captures | Authorized amount ≠ captured amount(s) on split shipments | n settlement lines for 1 order | One-to-many matching on the order reference |
| Rounding | Currency conversion and pro-rated fees, rounded line by line | Recurring differences of ± €0.01 | One-cent matching tolerance, rounding differences account |
Why it matters: cash, audit, fraud detection
- Cash management: knowing, day by day, how much cash is actually available and how much is still “in transit” at the PSPs.
- Revenue completeness: catching captured transactions that were never settled (PSP failure, technical dispute). They do happen, and no one else will claim them for the merchant.
- Fee control: recalculating fees and spotting billing errors or pricing creep (FX surcharges, scheme fees passed on incorrectly).
- Internal and external fraud detection: refunds with no original sale, diverted payouts, cash register discrepancies.
- Auditability: documenting every clearing account balance at period close, with no catch-all provision.