Guide
Invoice payment reconciliation: matching bank deposits to invoices
Invoice payment reconciliation is the process of proving that each deposit on your bank statement corresponds to a specific invoice — and that each open invoice is either paid, partly paid, or genuinely outstanding. Done properly it takes two inputs, a receivables list and a bank statement, and produces one output: a decision per invoice, with the reason recorded.
Written 2026-08-18. Applies to CSV-based accounts receivable reconciliation for small businesses and bookkeepers.
What you need before you start
Two CSV exports covering the same period. The receivables export should contain, at minimum, invoice number, customer, gross amount and issue date; a due date helps date scoring. The bank export needs transaction date, description or reference, and amount. Most accounting packages and online banking portals can produce both in a few clicks, and column names vary — mapping them once at import is normal.
Restrict the bank export to deposits where you can. Outgoing payments, transfers between your own accounts and card settlements add noise that competes with genuine customer receipts.
How matching actually works
A dependable match rests on four independent signals, in descending order of strength:
- Reference. The invoice number appearing in the bank description is the strongest single piece of evidence, because customers rarely type someone else's invoice number.
- Amount. An exact to-the-cent agreement is strong; a near agreement within about 1% is suggestive and usually means a fee or rounding.
- Name. Token overlap between the customer and the description survives abbreviations and reordering — "V AND SONS LTD" against "Verrall & Sons" — but is weak alone, especially for common names.
- Date. A payment dated after the invoice was issued and near its due date is plausible; a payment before issue is not.
Signals should be added, not treated as gates, and ambiguity should reduce confidence: if three deposits could equally settle the same invoice, none of them deserves a high score. That is exactly how SettlePair's scoring works — deterministic rules with fixed weights, so the same files always yield the same result and you can audit why a row scored what it did.
The exceptions that cost the most time
| Exception | What you see | How to resolve it |
|---|---|---|
| Partial payment | Deposit is smaller than the invoice; the customer paid on account or deducted a fee. | Allocate the deposit against the invoice and leave the balance open. Never close the invoice. |
| Grouped payment | One deposit settles several invoices, often with a remittance advice sent separately. | Split the deposit across each invoice until it is fully applied; any remainder stays unapplied. |
| Split payment | One invoice is settled by two or more deposits, sometimes weeks apart. | Allocate each deposit to the same invoice and watch the remaining balance fall to zero. |
| Missing reference | The description carries only a trading name, a card processor label, or nothing useful. | Match on amount, name tokens and date window, then confirm against the remittance. |
| Duplicate rows | The same invoice number appears twice, or a statement export overlaps the previous period. | Report duplicates explicitly rather than dropping them, and decide which row is real. |
| Bank fees and FX | The deposit is short by a processing fee or moves with the exchange rate. | Allocate what arrived, then post the shortfall as a fee or FX difference in your ledger. |
Handling partial payments without losing the balance
The common error in partial payment reconciliation is closing the invoice because a payment "belongs" to it. Keep three numbers per invoice — original amount, allocated amount, remaining balance — and three per deposit — original amount, applied amount, unapplied balance. Work in integer cents rather than floating-point currency; a cent-level residue on a 2,970.00 invoice is the difference between a clean ledger and an hour of hunting.
Grouped payments and remittance advice
When a customer pays weekly, one deposit may cover five invoices. Automatic one-to-one matching cannot honestly resolve this, and a tool that guesses a combination is inventing an audit trail. The reliable approach is to let the person with the remittance advice allocate the deposit invoice by invoice, with the running unapplied balance visible, and to leave anything unexplained as unapplied rather than forcing it to zero.
A repeatable monthly routine
- Export receivables and bank transactions for the same date range.
- Check the import summary: accepted rows, rejected rows, duplicates, total value.
- Clear the high-confidence, reference-matched deposits first.
- Work the review queue, reading the evidence rather than the score alone.
- Allocate partial and grouped payments against remittance advice.
- List what remains — unpaid invoices and unapplied deposits — and chase it.
- Export the reconciliation and post the decisions to your books.
Where SettlePair fits
SettlePair is a CSV reconciliation tool that performs the mechanical part of this routine: it reads both exports, scores every plausible pairing with visible evidence, queues the uncertain ones for review, and gives you an allocation sheet for partial and grouped payments. It does not connect to your bank, does not upload your files, and does not post to your ledger — you export the reviewed result and record it yourself. It is a review aid, not an accounting system, and it makes no claim of accounting accuracy.
See the step-by-step workflow or open the workbench with sample data.