Bank Reconciliation: The Accountant's Guide to Matching Payments to Invoices

It's the 6th of the month. You've pulled the bank statement for one of your clients — a small distributor with maybe 140 movements in May. You have the supplier invoices in one folder and the sales invoices in another. Now you sit down to do the thing nobody warns you about in accounting school: line up every payment in and out of that account against the invoice it belongs to.

The first twenty are easy. A round €1,230 lands and there's a sales invoice for exactly €1,230. Tick. Then it gets messy. A client paid €4,800 against an invoice for €5,000 — short by €200, no note, no explanation. A supplier was paid in two transfers, €1,500 and €1,500, for a single €3,000 invoice. There's a €340 debit with a reference that reads "TRF 06/05" and nothing else. And there are eleven invoices in the folder that have no payment against them at all — some genuinely overdue, some paid in cash, some just not due yet.

This is bank reconciliation. Every accountant managing real clients does it, and most do it the same way: a bank statement export, two folders of invoices, and an afternoon of eyeballing amounts.

What Bank Reconciliation Actually Is

Strip away the jargon and bank reconciliation is one question repeated hundreds of times: does this money movement match a document I already have?

On the receivables side (AR), it's: which sales invoice does this incoming payment settle? On the payables side (AP), it's: which supplier invoice does this outgoing payment cover? The goal is to end the month with every line on the bank statement explained — tied to an invoice, tied to a documented adjustment, or deliberately set aside as something that will never have an invoice.

That last category matters more than people expect. A bank account is full of movements that are not, and never will be, an invoice: salaries, payroll taxes, bank fees, loan repayments, the accountant's own fee, a recurring direct debit. These are real, they're legitimate, and they clog up reconciliation precisely because every month you look at them again and wonder, for a half-second, "is this one supposed to have an invoice?"

A clean reconciliation has three outcomes for every line, and only three:

• Matched — this payment is this invoice. Done.
• Flagged — this payment is close to an invoice but not equal (a partial payment, a discrepancy, a rounding gap), or there's an invoice with no payment at all. Needs a human decision.
• Ignored — this movement has no invoice and never will. Recorded as such, so it never resurfaces.

When all three buckets are filled and nothing is left floating, the account is reconciled. Everything else is just the work of getting there.

Why It Explodes at Month-End and Year-End

For a handful of movements, reconciliation is trivial. The pain is not linear — it compounds with volume, and it compounds again with time.

Volume. A client with 140 monthly movements across two or three accounts is a few hundred lines to reconcile. Multiply that by a portfolio of fifteen clients and you have thousands of decisions a month, every one of which is "match, flag, or ignore." Each individually takes seconds. In aggregate it takes days.

Timing mismatches. A payment and its invoice rarely share a date. An invoice dated 28 May gets paid on 4 June. A direct debit clears two days after the supplier issued the document. So you're never comparing two tidy lists of the same length — you're comparing a bank statement that runs on settlement dates against invoices that run on issue dates, and the two are permanently a few days out of phase.

Partial and bundled payments. One invoice paid in three instalments. Three invoices paid in one lump transfer. A payment that covers an invoice minus a credit note the client applied unilaterally. These break the one-payment-one-invoice assumption that every manual reconciliation quietly relies on.

Year-end concentration. At year-end, every unreconciled movement from every month comes due at once. The €200 short payment you flagged in May and meant to chase is still sitting there in January, now mixed in with eleven other loose ends, and it's the difference between your client's debtor balance and what the client thinks they're owed. This is the same dynamic that makes the year-end close painful: the shortcuts taken monthly all surface at the deadline, exactly when your books, your tax filings, and any statutory audit all need to agree.

The Manual Reality

Here is how bank reconciliation actually gets done in most practices, step by step, because naming it is the first step to fixing it.

You log into the client's online banking and export the statement — usually a CSV or a PDF, occasionally a structured bank file if the bank supports it. You open it next to your invoice records: a spreadsheet, the accounting software, or a folder of PDFs. Then you go line by line.

For each bank movement, you scan the invoice list for a matching amount. If you find an exact match, you mark it. If you find a near-match, you stop and think: is this a partial payment? A discrepancy? A fee deducted by the bank? You make a judgement call, often without enough information, and either resolve it or set it aside "for later." Then you do the inverse pass — you go through the invoices looking for any that have no corresponding payment, and you start a list of who to chase.

The references rarely help. A bank transfer description might be the payer's name, might be an invoice number, might be "TRF" and a date, might be empty. Card and instant-payment references are often opaque. So matching falls back to amount and timing, which works until two invoices have the same value or a payment is split.

By the end you have a reconciled statement, a list of discrepancies you couldn't resolve, and a list of clients to chase. And next month you do it again from scratch — including, every single month, re-confirming that the salaries and the bank fees are still not invoices.

How Automated Matching Works, at a High Level

Automated reconciliation doesn't do anything magical. It does exactly what you do by hand — match, flag, ignore — but it does it across thousands of lines in seconds and it remembers its own decisions. The logic, conceptually, rests on a few signals combined:

• Amount. The strongest signal. An incoming payment of €1,230 is checked against open invoices for €1,230. Exact matches are proposed with high confidence.
• Date proximity. A payment on 4 June is far more likely to settle an invoice dated late May than one from February. Closeness in time raises confidence; a large gap lowers it.
• Reference and counterparty. When the transfer description carries an invoice number, a tax ID, or a recognisable supplier or client name, that confirms a match the amount alone only suggested. Over time, the system learns that payments from a given counterparty map to a given client account.

The interesting cases are the ones the amount alone can't settle:

• Partial payments. A €4,800 payment against a €5,000 invoice isn't a non-match — it's an invoice that's 96% settled with €200 outstanding. Good matching flags it as a partial, not a miss, and tracks the remaining balance.
• Bundled payments. A €3,000 transfer that equals the sum of two €1,500 invoices should be proposed as a match against both. So should an instalment that's one of three.
• Duplicates. The same invoice appearing twice, or the same payment imported twice from overlapping statement exports, has to be caught before it produces a phantom reconciliation.

The output isn't a finished ledger — it's a triaged worklist. The confident matches are done. The ambiguous ones are surfaced, with the reasoning attached, for you to confirm or correct in seconds rather than reconstruct from a raw statement. The deeper mechanics of this are worth a post of their own; we go into the matching logic in how automatic payment-to-invoice matching works, and into the monthly grind it replaces in the manual bank reconciliation month-end close.

How This Ties Into Your Books and Year-End

Bank reconciliation and tax reconciliation are two views of the same data, and they meet at year-end.

Your billing records tell you what was invoiced. Your bank statement tells you what was paid. The gap between the two — invoices issued but not yet collected, payments received against invoices not yet recorded — is exactly the debtor and creditor position that has to be right when you close the year, file your VAT/sales-tax returns, and sign off the annual accounts.

If your monthly bank reconciliation is clean, the year-end debtor and creditor balances reconcile almost on their own: every open invoice either has a known partial payment or is a documented receivable, and every payment is tied to a document. If your monthly reconciliation is improvised, year-end becomes the forensic exercise of reconstructing eleven months of loose ends under deadline pressure. The same data also feeds the wider compliance picture — periodic tax filings, ledger cross-checks, and any regional audit files (like SAF-T in some jurisdictions) — that every finance team already manages. The deeper mechanics are worth a post of their own; see how automatic payment-to-invoice matching works.

Your Data Stays Yours

Most tools that touch bank and invoice data pull everything into a closed system you don't control, and getting it back out is its own project. For an accountant that's not a detail: the invoices and the reconciliation record are the evidence behind every figure you file with your tax authority — you need them in your hands, fully under your own data-protection (GDPR) control, not held hostage in someone's database.

Faturiza is deliberately different. Your invoices live in your own Google Drive. The extracted data lives in your own Google Sheets. Faturiza never stores your invoices — the reconciliation works on top of your data rather than locking it away. You own everything, and you can walk away with all of it at any moment.

How Faturiza Reconciles

Bank Reconciliation is available now in Faturiza, built around exactly the three outcomes above. Today you reconcile by importing your bank statement; one-click automatic bank connection via Open Banking is coming next.

It automatically matches incoming and outgoing bank payments to the right invoices using amount, date, and reference together. It flags partial payments and discrepancies as what they are — a €4,800 payment against a €5,000 invoice shown as 96% settled with €200 outstanding, not a mystery. It surfaces overdue invoices that have no payment against them, so the chase list builds itself. And it lets you permanently ignore the movements that never have an invoice — salaries, bank fees, your own accountant's fee — so you never reconfirm them month after month. All of it on top of invoices that stay in your own Drive and your own Sheets.

If this is the part of the month you'd most like to get back, see how Faturiza reconciles — import a statement and let it match the payments to your invoices.

In the meantime, if you want to see how Faturiza already keeps invoice data clean and reconciliation-ready across a whole client portfolio, see what we've built for accountants. The cleaner the data going in, the less there is to reconcile coming out.

Part of our bank reconciliation guide series. See also how automatic payment-to-invoice matching works and the manual month-end close.