Two-way reconciliation, which matches your bank statement to your general ledger, is the version most finance teams grow up on. Three-way reconciliation adds a third source: the payment gateway or processor sitting between the customer and the bank. It's more accurate, and considerably more painful to do by hand.
The three legs
- Bank statement. The actual settled cash movement, often batched and net of fees.
- Payment gateway log. The transaction-level detail (individual charges, refunds, and gateway fees) before batching.
- Accounting ledger. The invoices and receivables your finance system expects to be paid.
For a transaction to be considered fully reconciled, all three need to agree, not just in amount but in timing, since gateway settlement often lags the transaction date by one to three business days.
A worked example (illustrative numbers)
A customer pays AED 1,000 online. The gateway records the charge and a AED 25 fee. Two days later the bank shows one batched deposit of AED 4,875, which combines five payments like it, net of fees. The ledger expects AED 1,000. No two of these records match on amount, yet all three are correct. A 3-way match ties each gateway charge to its invoice, groups the charges by settlement batch, and checks that the batch total less fees equals the bank deposit.
Why manual 3-way matching breaks down
The moment volume passes a few hundred transactions a month, spreadsheet-based matching stops being viable. Batched bank deposits don't map 1:1 to gateway transactions. FX variances and gateway fees create small, legitimate discrepancies that look like errors. Someone ends up manually annotating a growing exception list every single cycle.
What automated matching actually does differently
A rule-based reconciliation engine doesn't try to force exact-amount matching: it applies tolerance margins for known, expected variances like bank charges and FX movement, and only flags what falls genuinely outside those bounds. Matching runs on a schedule, typically daily, so exceptions are caught within a day of occurring rather than discovered in an end-of-month scramble.
The goal isn't zero exceptions. It's making sure every exception that does surface is a real one worth a human's attention.
The five exceptions you will see
- Timing difference: the gateway settles one to three business days after the transaction. Held open until the deposit lands, then cleared.
- Fee variance: a small gap between expected and actual fees. Cleared within a set tolerance, flagged above it.
- Refund or chargeback: matched back to the original charge and posted as its own entry.
- FX difference: cleared within a set tolerance, flagged above it.
- Genuine mismatch: a duplicate, a missing deposit or a wrong amount. This is the only type that needs a person.
What "done" looks like
A functioning 3-way reconciliation bridge produces a daily run log, an exception dashboard with clear categorization (timing difference, fee variance, genuine mismatch), and an audit trail that satisfies external auditors without anyone re-running the matching by hand.
Frequently asked questions
What is the difference between two-way and three-way reconciliation?
Two-way matches the bank to the ledger. Three-way adds the payment gateway, so batched deposits can be explained transaction by transaction.
How often should it run?
Daily for any meaningful volume, so exceptions are caught within a day of occurring and not at month-end. For how daily matching fits into a faster close, see the 48-hour month-end playbook.
Do I need new software?
No. The matching layer reads exports or feeds from your existing bank, gateway and ledger. See our automated reconciliation service for how it is set up.
See this applied to your own data.
Book a 20-minute audit and bring a sample export, and we'll show you the fix live.