Chasing, cash reporting and deduction management all depend on knowing what has actually been paid. Done badly, reconciliation is worse than nothing, because a wrong match stops the money being chased.
Reconciliation is the automation that makes every other finance automation safe. Chasing, reporting, cash forecasting and deduction management all depend on knowing, reliably, what has actually been paid.
Done badly it is worse than nothing, because a wrong match marks an unpaid invoice as settled and the money silently stops being chased.
Why naive matching fails
The obvious approach is to match on amount. It works in demonstrations and fails immediately in practice, because most of what arrives is not a clean full payment.
Build for the exceptions from the start. The clean matches were never the problem; the queue is the product.
How to build it
1. Fix the reference discipline first
Every invoice needs a unique reference, and every payment request needs to ask for it. This single change does more for match rates than any matching logic you can write. It is unglamorous and it is the highest-leverage step here.
2. Match in tiers, highest confidence first
Exact reference and exact amount is tier one. Exact reference with a different amount is tier two, which usually means a partial payment or a deduction. Payer name plus amount is tier three. Anything else goes to the queue.
3. Never let the system guess
Set a confidence threshold and route everything below it to a person. The temptation is to add fuzzy matching to raise the auto-match rate; resist it, because a false match is far more expensive than a queued item.
4. Handle partials explicitly
A partial payment reduces the balance and leaves the invoice open. This must be a first-class case in your logic, not an exception someone fixes by hand, or your ageing report will be wrong.
5. Separate deductions from errors
When a payer short-pays deliberately, the gap is a claim with a deadline attached, not a data problem. Route it to whoever handles disputes rather than to whoever fixes typos.
6. Make the queue small and worked daily
An exception queue nobody clears becomes an unreliable ageing report within a fortnight, at which point every downstream automation is publishing wrong numbers.
Tools and what they cost
| Option | What it costs | Honest trade-off |
|---|---|---|
| Accounting software bank feeds | Included in Xero, QuickBooks and similar. | Rules-based matching that handles the clean cases well. Partials and batch payments still need manual attention. |
| Payment gateway reporting (Stripe, PayPal) | Included with transaction fees. | Reliable structured data including fees deducted, which removes one whole failure case. Only covers payments through that gateway. |
| Apps Script joining bank exports to your ledger | Free with Google Workspace. | You control the tiering and the confidence threshold. You also own the edge cases, which is most of the work. |
| Dedicated reconciliation tools | Monthly, typically scaling with transaction volume. | Purpose-built matching engines. Rarely proportionate below meaningful transaction volume. |
What it is actually worth
Two things, and the second is the larger one.
Time saved is straightforward: count the hours currently spent reconciling per month.
The accuracy dividend is worth more and is harder to see. Every downstream automation inherits your reconciliation quality. Automated chasing that emails clients about paid invoices, cash reports built on wrong balances, deductions never spotted because the short payment looked like a full one: all of these are reconciliation failures wearing other costumes.
The measure worth tracking is the proportion of payments matched automatically at high confidence, and separately, the number of false matches found later. The second number should be zero, and if it is not, your threshold is too loose.
How it breaks
Fuzzy matching creeps in. Somebody widens the tolerance to clear the queue faster and false matches begin. Treat the auto-match rate as a diagnostic rather than a target.
The queue is abandoned. A backlog of unmatched payments means your ageing report is fiction, and everything built on it is too.
Fees are treated as shortfalls. Gateway charges make the received amount permanently different from the invoiced amount. Handle fees as a known deduction rather than letting every card payment land in the exception queue.
How to tell whether it worked
Auto-match rate at high confidence, exception queue age, which should be under two days, and false matches discovered, which should be zero. The last one is the only measure that really matters.