Automated bank reconciliation is a process in which the daily bank statement imports itself into the accounting system, and every incoming payment is matched to the exact invoice by pre-defined rules. Lines that match are closed without a human; the ones that do not — the exceptions — are gathered in one place for a colleague to review. The goal is not to remove control, but to point it only where it is genuinely needed.

Why does manual reconciliation eat so much time?

In most companies reconciliation looks like this: someone logs into online banking, downloads the statement, opens it next to the list of open invoices and starts matching line by line. A payment of 1,240 leva — which invoice is it? A customer paid two invoices with one transfer. Another rounded down and sent a few stotinki short. A third forgot to write the invoice number in the reference. Every such line needs attention, and there are dozens of them a day.

The cost of this is not just lost time. While reconciliation lags, nobody knows for certain who has paid and who has not. Reminders go out to customers who have already paid. Receivables reports are inaccurate. And at month-end it all piles up into a few tense days. Manual matching is exactly the kind of repetitive, tiring work that a machine does better than a tired person on a Friday afternoon.

How does the statement import itself?

The key to reliable reconciliation is that the statement arrives in structured form — as a file with clearly separated fields, not as a picture. Banks here issue exactly such files: MT940 is the classic format for bank statements, while the newer CAMT.053 is part of the international ISO 20022 standard that is fast becoming the norm. In these files the amount, the date, the payer's IBAN and the transfer reference sit in separate, machine-readable places.

The file can reach the system by several routes: it is downloaded automatically from the banking portal, arrives over a secure channel, or — at some banks — comes directly through a PSD2 connection, the regulation that required banks to open account access through secure interfaces. The result is the same: in the morning the statement is already inside, without anyone downloading and uploading it by hand. This is the same logic of "data enters on its own instead of being retyped" that we describe in What is business process automation.

How does a payment find its invoice?

Once the statement is inside, matching runs by rules — from the most certain to the softer ones:

1. Exact match by reference and amount — if the invoice number is written in the transfer and the amount matches to the stotinka, the line is closed automatically. This is the cleanest case and covers a large share of payments.

2. Match by counterparty and amount — when the number is missing, the system recognises the customer by IBAN and looks for an open invoice of theirs with the same amount.

3. One payment against several invoices — if a customer paid three invoices with one transfer, the rule assembles the combination whose total equals exactly the amount received.

4. Allowed tolerance — small differences from rounding or a bank fee are accepted within a pre-set threshold, so the whole line is not held up over a few stotinki.

5. Everything else goes to the exceptions — a payment with no clear recipient, an overpayment, an unknown payer. These lines are not guessed by the machine; they are gathered in a separate list for a person.

In practice the bulk of payments pass through the first rules and are closed without intervention. The person no longer checks everything — they look only at what the system has honestly flagged as unclear.

Why not rely on PDF and paper statements?

The temptation is understandable: "there is OCR, just scan the statement." In theory it sounds fine; in practice it is not worth it. Every bank lays out its PDF statement differently: other columns, another order of fields, a different place for the reference. OCR copes with one bank after long tuning, but stumbles on the next, and its accuracy on this kind of document stubbornly plateaus around 70%. For reconciling money, 70% is unacceptable — every third line would need a manual check, and one wrong amount undermines trust in the whole match.

So we draw a clear line between the two worlds. Where the bank provides a structured file — and that is almost everywhere — reconciliation is automatic and reliable. Where only a PDF or paper exists, those lines stay with a human, and we do not pretend the machine has closed them. We describe the same sober view of what recognition can and cannot do in Accounting process automation.

What does a company gain when payments match themselves?

First — clarity in real time. As soon as the statement arrives in the morning and is spread across the invoices, at any point you can see who has paid and who has not. That also makes reminders accurate: they go only to those who genuinely have not paid, not to customers whose money has already arrived. How to set those reminders to run on their own we cover in Automated payment reminders.

Second — a calm month-end. When lines are closed every day, the monthly close does not turn into a few panicked days; only the handful of real exceptions remain. And third — a clean audit trail: for each automatically closed line you can see which rule matched it, and the human decisions on exceptions are recorded too.

That is exactly what our Automation service does: we describe the rules with you, connect the bank file to the accounting system, and leave the routine matching to the machine, while people decide only the unclear cases. What this looks like in real accounting practice — with less manual retyping and a tidier document flow — we show in Case study: digitalizing document flow in an accounting firm.

Frequently asked questions