Automating Bank Payment Reconciliation from Email

Automated payment reconciliation reads the notification email your bank sends when money arrives, pulls out the payer, amount, currency, value date and reference, finds the matching open invoice in your accounting system, and marks it paid. Anything it cannot match with confidence goes to a review queue instead of being guessed.

The work it removes is specific. Someone opens the finance mailbox each morning, reads the notifications, searches the invoice register for a number, ticks the invoice off, and starts again on the next one. The same handful of decisions repeat all morning. That is the profile of work a machine can take over: high repetition, low attention, and rules that already exist in someone's head but have never been written down.

Reconciliation rarely arrives on its own. It comes bundled with supplier invoice extraction, sales orders synced from the ERP into shared spreadsheets, delivery planning built from order dates, and monthly file archiving. Incoming payments and the payables side, where supplier invoices are approved, scheduled and paid run on the same matching and review machinery, so the second workflow costs less to build than the first. Operations buyers ask a scoping question before they ask a price question: is this kind of API and AI integration inside your scope of expertise. The wider set of processes is covered in our guide to AI back-office automation for SMEs.

Parse the email with deterministic rules per bank template, and use a language model only for layouts the rules do not cover. Bank notifications are machine-generated from a small number of templates, so most of the time you are matching a known structure rather than interpreting prose. That makes bank mail the easy end of document parsing. Pulling structured fields out of supplier invoices, where every vendor uses its own layout is the case that genuinely needs a model doing the reading.

The practical shape is this. Identify the bank and the notification type from the sender address and subject line. Extract values from the labelled cells of the HTML body rather than from the flattened text, because the flattened version loses the field labels. Store the raw message exactly as received. Write the parsed result as a record with per-field confidence, so the matching stage knows which fields it can trust.

The language model gets a narrow job: given a message body that no template matched, return payer, amount, currency, date and reference. It never does arithmetic, and it never chooses which invoice this payment belongs to. We hold to the same rule in our own products. The AI-readiness checker on our homepage runs eight deterministic checks with no model-based scoring, so running it twice on the same site returns the same result. Reconciliation needs that property even more. A finance process that returns a different answer on a second run is not usable.

Parsing fails in predictable ways. Digest emails contain several transactions in one message. Forwarded notifications have lost their original headers. Marketing footers contain numbers that look like amounts. Banks change templates without notice. Each of those needs a rule, and the unmatched-template rate needs an alert on it.

Five fields decide everything: reference, amount, currency, value date and payer name. Only the reference is designed to work as a key. The rest are supporting evidence.

The reference number is the strongest signal. Structured reference schemes, whether the ISO 11649 RF creditor reference used for cross-border payments or a national reference-number format, are built around a checksum, so a malformed reference can be rejected before you query the invoice register at all. When the reference is present and passes that check, confidence is high. It still goes wrong in ordinary ways: customers type the invoice number into the free-text description instead of the reference field, reuse a reference from an older invoice, or send one payment for four invoices under one reference.

Payer name is the field that causes most of the bad matches. Payments arrive from a spouse, a parent company, the customer's accountant, a marketplace or a card processor, so the name on the transfer often does not equal the name on the invoice. Treat it as evidence and never as identity. The fix that works is an alias table: once a person confirms that a given account name belongs to a given customer, store the mapping and the next payment matches on its own.

Amount looks exact and is not. Cross-border transfers can arrive short by the correspondent bank charge, and conversion leaves cents behind. Amount matching therefore needs a tolerance, and that tolerance has to be a written policy with a number in it, not a constant somebody chose while coding.

Run the tiers in order and stop at the first one that produces exactly one candidate. Every tier is an explicit rule with an explicit confidence, and only the top tiers are allowed to post without a person.

The uniqueness rule is what keeps this safe. A tier auto-posts only when it produces one candidate and no more. Two open invoices for the same amount from the same customer is an ordinary case, not an edge one. A system that picks one of them will be wrong about as often as it is right, and it will not tell you which.

One approach to avoid: scoring every open invoice for similarity and taking the highest score. A ranked list always has a top entry, including when the correct answer is not on the list at all. Tiers with hard conditions fail loudly. Similarity scores fail quietly, and quiet failure in a ledger is the expensive kind.

A partial payment must never close an invoice. Record the receipt against the invoice, leave the balance open, mark the invoice as partly paid, and let the reminder cycle continue on the remainder.

Overpayments go the other way. Post the invoice amount, leave the difference as a credit on the customer account, and flag it for a person. Whether that credit is refunded or offset against the next invoice is a commercial decision, and it should not be made by a rule.

One transfer covering several invoices is the case worth building carefully, because it is slow by hand and fast by machine. Search the open invoices of that customer for a subset whose total equals the transfer amount within tolerance. If exactly one subset fits, propose the allocation and have a person confirm it for the first weeks until the pattern is trusted. If two subsets fit, it goes to review. A customer settling several invoices with one transfer is a routine pattern in receivables, and it is exactly the case that stays expensive if the allocation is left manual.

Write the tolerance policy down in the same document as the tier table. The finance lead will be asked by their auditor why a payment 3 € short of the invoice was accepted, and the answer needs to be a policy with a date on it rather than a developer's memory.

The review queue shows the original email and the best-guess invoice side by side, with a one-line reason the system was not confident. That layout is the whole point: a person decides from one screen instead of opening three systems to investigate. The wider rules for designing a review queue, deciding what is allowed to reach it and measuring whether it shrinks apply here without modification.

The question we get asked most often about this kind of build is what happens when the AI gets it wrong. It will get things wrong. What matters is where the wrong answers land. Confident cases post automatically. Uncertain ones arrive in the queue with the document and the machine's best guess next to each other, so the human effort goes into judgment instead of typing.

Cases that belong in the queue by design: unknown payer, missing or invalid reference, amount outside tolerance, several plausible candidates, currency mismatch, a notification that looks like a duplicate, and anything that appears to be a refund or a reversal.

Every confirmation a person makes should become a rule rather than a vague signal. A confirmed alias, a confirmed subset allocation, a confirmed fee tolerance for one payer: each of them removes a future exception. The queue should be visibly shorter in week four than in week one. If it is not shrinking, the rules are wrong and no amount of model tuning will fix that.

Give the queue a named owner and a time limit. An unwatched review queue is worse than no automation at all, because everyone assumes the payments are handled.

Every posting has to be reconstructable from the audit record alone, without anyone opening the mailbox. That is the standard an accountant will hold the system to, and it is also what makes an incident debuggable six months later.

The minimum per transaction: the raw message with its message id and received timestamp, the extracted fields together with the parser version that produced them, the tier that fired and its confidence, the candidate invoices that were considered and rejected, the actor as either the automation or the named person who confirmed, the ERP write result including document id and posting date, and a link to the correcting entry if it was later reversed.

Deduplication belongs in the same layer. Use the bank transaction id when the notification carries one, and otherwise a key built from message id, amount and value date. Banks resend, mail servers duplicate, and a colleague forwarding the same notification a second time must not create a second payment.

Keep the log append-only. Corrections are new entries that reference the original, never edits to it. The practical benefit shows up the first time a customer disputes an allocation: you can show what arrived, what the system decided, which rule decided it, and who confirmed it, in one screen.

Treat the notification email as a trigger and the bank statement as the record. Build on the email for speed, then verify against the statement or the account API, which is what has to balance at month end. Where a bank API is available, make it the source of truth and let the email decide when the automation runs, which turns a once-a-day batch into a job that fires within minutes of the money landing.

The failure modes worth naming before you start: notifications that never arrive because the bank suppresses them for certain transaction types, digest emails that batch a day of activity into one message, direct debits and card settlements that land as aggregated totals with no per-invoice detail, refunds that look like incoming payments, and multi-currency accounts where the notification amount and the booked amount differ. Each one is solvable with an explicit rule. None of them is solved by pointing a language model at the mailbox.

On scope and price: a single well-defined workflow like this one is typically a one to three week build, and automation work is quoted per project after we have seen real material. The fuller picture of what an AI automation project costs and which factors move the number is set out separately. Our published website prices are 290€ for the AI-readiness audit, which is credited against follow-up work, and from 3 999€ for a new build. Scoping an automation quote needs a realistic sample of notification emails covering a full month, including the messy ones, plus a snapshot of the open invoice register. The number of distinct exception types drives the effort, not the number of emails per day.

Start with one process, measure the hours it returns, then extend. The same property that makes this work, facts a machine can read without guessing, also decides whether AI assistants name your business when a customer asks for a recommendation. To see what a machine currently reads on your own site, run the free readiness check.