Bank reconciliation automation (also called cash application) matches deposits that land in a bank account to the open invoices they're paying for — automatically, instead of a person cross-referencing a bank statement against an AR aging report line by line.
It sounds like a small job. In practice it's one of the more error-prone parts of the whole billing chain, because the two records being matched — the bank line and the invoice — almost never describe the same transaction in the same words.
Why matching is genuinely hard
A bank statement line has an amount, a date, and a payer name — often a legal entity name, a bank's internal reference code, or a name that has nothing to do with how the customer is recorded in the billing system. An invoice has a customer name, an amount, and (if you're lucky) a reference number the payer chose to include or didn't.
Three specific mismatches cause most of the manual work:
- Payer name isn't customer name. A payment might come from a parent company, a subsidiary, or a third-party payment processor rather than the exact legal name on the invoice. Reliable matching needs to check the payer against the billed party and its known contacts, not just an exact string match.
- Partial payments. A customer pays $8,000 against a $10,000 invoice. That's not a failed match — it's a partial payment that should reduce the invoice balance while leaving the remainder open.
- Amounts that split across invoices. One wire transfer sometimes pays two or three invoices at once. A rigid one-deposit-to-one-invoice matching model can't represent that correctly.
Confident matches vs the queue
The honest way to handle automated matching is a confidence tier, not a binary match/no-match: deposits with a strong signal (exact amount, exact reference number, known payer) settle automatically. Everything else — ambiguous amounts, unrecognized payer names, deposits that could plausibly match more than one open invoice — goes into a queue for a person to resolve, rather than getting force-matched incorrectly or left unmatched indefinitely.
An unmatched deposit sitting in that queue is real cash that already arrived. It's worth treating as a small emergency, not a backlog item — every day it sits unmatched is a day collections might still be chasing a customer who already paid.
The connection to collections that's easy to miss
Bank reconciliation isn't just an accounting nicety — it's the thing that turns off the chase. A dunning sequence that doesn't check bank-matching status will keep emailing a customer about an invoice they already paid, purely because nobody's connected the bank line to the invoice yet. The two systems (collections and cash application) have to share the same invoice record for "paid" to mean the same thing in both places.
What to check before trusting a reconciliation tool
- Does payer matching check against the billed party and its known contacts, or only an exact name match?
- Can a partial payment reduce an invoice's balance correctly, rather than treating anything short of the full amount as unmatched?
- Can one deposit split across multiple invoices, and can multiple deposits apply to one invoice?
- Are low-confidence matches routed to a queue for a person, or does the system force-match and hope?
- Does a confirmed match actually stop the dunning sequence on that invoice, automatically?
Sonic AI's bank reconciliation matches deposits on amount, reference, invoice numbers, and payer name against the billed party's contacts, supports partial and split payments, routes ambiguous cases to an operator queue, and turns off Watchtower's dunning cadence the moment a match confirms. See how bank reconciliation works, or the deeper mechanics on the Monday morning reconciliation problem, bank reconciliation matching, and two systems, one truth.
Related terms: unmatched deposit, payer matching, accounts receivable, days sales outstanding.