Bank reconciliation agent: statement matching at scale

Bank reconciliation is the most automatable process in finance and one of the most frequently still done by hand. The reason is not that matching software does not exist — it has existed for decades. The reason is that most implementations automate the easy majority, dump the remainder into a spreadsheet, and leave a person doing the hardest twenty per cent with none of the context that made the other eighty per cent easy.

The result is a process that is nominally automated and practically still manual, because the residue is where the time was always going. A team reconciling several thousand transactions a month may match the large majority automatically and still spend days on the rest — one-to-many payments, partial settlements, transactions with a reference that does not correspond to anything in the ledger, foreign currency receipts that arrived net of a fee nobody anticipated.

The valuable design work in a reconciliation agent is therefore not the matching engine. It is the handling of exceptions: classifying them, resolving the ones that are mechanically resolvable, and presenting the genuinely ambiguous remainder to a human with everything needed to decide in seconds rather than minutes.

Why this matters

Bank reconciliation sits on the critical path of the close. An unreconciled bank account means cash cannot be confirmed, which means the balance sheet cannot be signed, which means nothing downstream can complete. Any delay here propagates in full.

It is also the control that detects a specific and serious class of problem. Unmatched cash out is how misappropriation is found. Unmatched cash in is how unapplied customer payments are found — and unapplied receipts are the reason collections teams chase invoices that have in fact been paid, which damages customer relationships and wastes controller time. A reconciliation performed monthly finds these things up to thirty days late. Performed daily, it finds them the next morning.

And it is the enabling condition for the wider shift from a periodic to a continuous close. Continuous reconciliation is only sustainable if a human is not reviewing every match — which is precisely what an agent makes possible.

At a glance: exception types and how they should be handled

In our engagements the residue that genuinely requires a human decision typically settles at under ten per cent of transaction volume once the agent has been tuned for a few months. That figure is a practitioner observation from mid-market implementations, not a benchmark, and it varies considerably with payment mix — a business with heavy cross-border and marketplace settlement traffic will sit higher.

What works, and what to be honest about

What works:

Confidence thresholds rather than binary rules. A match at 99% confidence and a match at 70% should be treated differently: the first posts, the second is presented to a human as a suggestion with the reasoning shown. Systems that treat matching as pass or fail either auto-post errors or refer far too much.

Learning from human resolutions. When a controller resolves an exception, that resolution is training data. A counterparty who always pays net of a fixed fee, or who references purchase orders rather than invoices, should need explaining once. Agents that do not incorporate resolution history recreate the same exception monthly forever.

Exceptions presented with context, not as a list. The productivity gain in the residue comes almost entirely from presentation: the bank line, the candidate matches ranked with reasoning, the counterparty's payment history, related open items, and one-click resolution. The same exception takes four minutes in a spreadsheet and twenty seconds in a properly designed queue.

Daily running. An agent reconciling daily works with a small volume of fresh exceptions where context is still recoverable. Monthly running produces a large batch of stale ones. The work is identical; the difficulty is not.

Deterministic rules first, inference second. Anything expressible as a rule should be a rule — auditable, testable, explainable. Inference should handle what rules cannot. Systems built inference-first are harder to audit and harder to trust.

What to be honest about:

The last few per cent will not automate, and chasing it is a poor investment. Beyond a certain point, each additional per cent of automated matching costs more in configuration and carries more risk than the human minutes it saves. Identify where that curve flattens for your payment mix and stop there deliberately.

Auto-matching errors are quiet. A wrong match does not raise an exception — it produces a reconciled account with two misallocated transactions, and it may not surface for months. This is why thresholds should be conservative initially and why a sampled review of auto-matched items should continue permanently, even when the agent is performing well.

Bank data quality varies more than expected. Reference field length, character handling, formats, whether a counterparty name is passed at all — these differ by bank and by payment scheme, and the differences directly determine achievable match rates. A multi-bank environment is a materially harder problem than a single-bank one.

It will surface an unapplied-receipts backlog. Most companies deploying this discover customer payments that were never applied to invoices, sometimes going back years. That is a benefit, but it arrives as work, and it needs an owner.

Auditors will ask how the agent decides. Have the answer documented before they ask: the rules, the thresholds, the logic, the audit trail, the sampled review procedure. An agent whose decisions cannot be explained is an audit finding regardless of accuracy.

Decision framework: where to start

Run in order. Stop at the first match.

1. Are you reconciling monthly rather than daily?
Move to daily first, even manually, for a few weeks. It reduces exception difficulty immediately and shows you your real exception profile — which is the input to every subsequent decision.

2. Do you have automated bank feeds, or are you importing files manually?
Establish reliable automated feeds before anything else. An agent dependent on a manual import inherits a manual dependency and will not run unattended.

3. Do you know your exception profile by category?
If not, log a month of exceptions by type using the table above. The distribution determines what to configure and where the return is. Most teams guess wrong about their own profile — cross-border fees and one-to-many settlements are routinely underestimated.

4. Do you have a backlog of unapplied receipts or historical unreconciled items?
Clear it before deploying. An agent working against a ledger with historical noise generates exceptions for problems that predate it, and the queue becomes unusable in the first week.

5. Are your matching rules documented and deterministic where they can be?
Write the rules explicitly, including tolerances for fees and FX variance. This is the substance of the configuration and it should be reviewable by your auditor.

6. All of the above in place?
Deploy with conservative thresholds and human review of every auto-match for the first two weeks, then tighten as evidence accumulates. Build the exception queue with proper context from day one — it is not a phase two.

7. Running well, exception rate still high?
Look upstream. A persistently high exception rate is usually caused by something outside reconciliation: invoices without stable references, a customer base that pays on statement rather than invoice, or an ERP configuration that does not expose open items usefully.

Indicative cost and effort

Assumes one to three bank accounts in one or two currencies with a single ERP instance. Multi-bank, multi-currency environments with marketplace settlement traffic sit at the upper end or beyond. Get a quote for a scoped estimate.

Frequently asked questions

What match rate should we expect?
It depends far more on your payment mix and bank data quality than on the agent. A domestic B2B business with disciplined invoice referencing achieves a high rate quickly. A cross-border business with marketplace settlements and heavy partial payments will sit lower and should not treat that as failure. Profile your exceptions first and set the target from your own distribution rather than from a vendor's figure.

Can the agent post journal entries itself?
For deterministic, rule-bound postings within defined tolerances — bank fees, FX differences — yes, and it should. For anything requiring judgement about classification, no. The boundary should be written into policy and shown to your auditor, not left to configuration.

How do we prevent the agent hiding a problem by auto-matching it?
Conservative thresholds, permanent sampled review of auto-matched items, and an alert on any unusual pattern change in match rates. A sudden improvement in auto-matching is as worth investigating as a sudden deterioration.

Does this replace our controller?
No, and companies that deploy it expecting that are disappointed twice. It changes what the controller does: less matching, more investigation of genuine exceptions, more time on the receivables and payables quality problems the reconciliation surfaces. In mid-market teams the usual outcome is the same headcount handling considerably more volume with a shorter close.

Where does this sit relative to shortening our close?
It is typically the single highest-return technical intervention available, because bank reconciliation is on the critical path and its automation is well understood. It is not sufficient on its own — intercompany matching, AP cut-off policy and data ownership outside finance all need addressing too.

Closing — Next steps

The measure of a reconciliation agent is not its match rate. It is how quickly a human can resolve what the agent could not, and whether the agent learns from that resolution. Two implementations with identical matching performance can differ by a factor of several in total time consumed, entirely because of exception design.

If you want to know what you are dealing with before committing: log one month of reconciliation exceptions by category, with the time each took to resolve. The distribution will tell you what to automate, and the time column will tell you whether your problem is match rate or exception handling. In most mid-market companies it is the latter.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

• Oracle NetSuite, bank reconciliation and bank feed documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• European Payments Council, SEPA scheme rulebooks — remittance information and data field specifications — https://www.europeanpaymentscouncil.eu
• ISO 20022, payment message standard documentation — structured remittance data — https://www.iso20022.org
• APQC, Open Standards Benchmarking — general accounting and reporting cycle times — https://www.apqc.org
• Atypical Tech engagement experience, mid-market finance automation across Iberia