Reconciliation automation: matching bank lines to the ledger without hiding the breaks

Reconciliation automation compares two sets of records, usually bank statement lines and ledger entries, and matches the ones that agree. Good automation uses a ladder of methods, from exact matches to AI suggestions, and sends everything it can't match to a review queue with an owner. It never forces the balance to zero.

A reconciliation that always balances is either perfect or hiding something, and it is rarely perfect.

#The match ladder

Treat matching as a ladder. Start at the top with the cheapest, most certain method, and move down only for what's left.

The earlier rungs should clear most of the work, and the exact share depends on your data. Measure it on a month of your own transactions before you promise a number.

Rungs 1 and 2 are deterministic. They give the same answer every time, and you can show an auditor the rule. Rung 3 needs agreed tolerances, which are policy decisions, so set them with the controller. Rung 5 is where AI helps, and where a human must stay. A model is good at saying two descriptions probably refer to the same party. Whether that probability is good enough to book is a decision about risk, so let a person make it.

Take a morning with 600 bank lines in the feed. Several hundred clear on rungs 1 and 2 before anyone opens the file: invoice payments quoting a reference, bank fees, card settlements. About eighty are tolerance or grouped matches, which the preparer approves in a batch after scanning the amounts. A few dozen go to suggestions. The last handful, say a wire with no reference from a payer nobody recognizes, land in the queue with an owner. The preparer spends the morning on that handful instead of all 600. (Counts are illustrative; yours will differ.)

#Why unmatched items go to review, not to a plug account

When a reconciliation won't balance, there is a quick way out. Post the difference to a suspense or "miscellaneous" account, and the report ties out.

Don't. Plugs bury the actual causes: a duplicate payment, a missed fee, a bank transfer posted to the wrong customer, a timing difference that never reversed. Month-end gets easier and the problems get bigger. Auditors treat large suspense balances as a warning sign.

Send the break to a review queue instead. Each break should carry:

• The bank line or ledger item, with date and amount.
• The best candidate matches the system found, and why it rejected them.
• An owner and a due date.
• An age, so you can see how long it has been open.

Report the queue by age. Breaks under a week old are mostly timing. Breaks over thirty days old are usually real problems, and they are what the preparer and the reviewer need to see before sign-off.

#What to reconcile first

Most finance teams reconcile several account types. They don't all need the same treatment.

Bank accounts are the obvious start. Inputs are statement files or bank feeds, and the ledger side is your cash account. Banks deliver data in different formats, such as BAI2, MT940, ISO 20022 camt.053 files and plain CSV. Normalize them into one shape first.

Payment processors and card settlements are next. A processor deposit is usually a batch net of fees and refunds. Matching it means breaking the deposit into its component sales, then comparing the fee to what the contract says.

Subledger to general ledger checks come after: AP and AR balances against their control accounts. These should agree exactly, and a difference points to a manual journal posted straight to a control account.

Intercompany reconciliation is the hardest. Two entities each record a transaction, in their own currency, on their own dates. The balances should mirror each other. They rarely do.

#Intercompany reconciliation

Intercompany items go wrong in predictable ways: one side books it this month and the other next month, the two sides use different exchange rates, or the amounts differ by a withholding tax or a fee.

Automation can match intercompany items across ledgers by reference, amount and counterparty, propose matches for the leftovers and list the differences by cause: timing, FX, missing entry. What it shouldn't do is post the elimination or true-up journals. A controller reviews those, because they change reported results.

#Where AI belongs on the ladder

We keep AI away from rungs 1 to 4. It adds cost and variance where a rule works fine. It belongs on rung 5 and in two other places.

Reading messy input. A remittance advice that arrives as a PDF or an email body needs extraction before it can be matched, which is the same document problem as invoices.

Explaining a break. Instead of showing "unmatched, $1,284.00", a good tool shows "this looks like a duplicate of the payment on the 3rd, same payee and amount, one day apart." The preparer still decides, but starts with a hypothesis.

Finally, accepted suggestions can become rules. When a preparer accepts a rung 5 suggestion, offer to turn it into a rung 2 rule, and review that rule before it goes live.

Key point: Automated reconciliation is only trustworthy if the breaks stay visible. Measure unmatched items by age and owner, and never let the system balance an account by posting to a plug.

#What the tools already do

Check what you already have before building. Xero, for example, says its reconciliation engine only reconciles automatically when it is highly confident, and otherwise suggests a match and leaves the final say to you; it also applies bank rules (Xero (opens in a new tab)). QuickBooks Online has bank rules too, and suggests matches to transactions already in your books (Intuit (opens in a new tab)). Built-in matching works well for a single bank account and a modest volume.

Gaps tend to appear with several entities and currencies, high transaction volumes, one-to-many matches, intercompany balances, or processor settlements that need splitting. That's where an external layer is worth building. Our Xero integration page shows how we work alongside the built-in features.

#Controls to keep

Whatever you automate, keep these:

• A preparer and a reviewer for each reconciliation, with sign-off dates.
• A log of every automated match: which rung, which rule, which version.
• Approval for new matching rules and tolerances.
• Read-only access to statements, and no ability for the matching tool to post journals without approval.
• Reconciliations completed by a deadline each month, tracked on your close calendar.

Our month-end close checklist shows where reconciliations sit in the close, and the month-end close blueprint shows how the pieces connect. For a specific flow, see our use case on reconciling bank transactions to the ledger, and the reconciliation glossary entry for definitions.

#How to start

1. Pick one account with enough volume to matter, and pull three months of statement and ledger data.
2. Reconcile it by hand once and record how you matched each item. These patterns become your rules.
3. Build rungs 1 and 2, then run them against the three months and compare with the hand result.
4. Add tolerances and grouping. Review with the controller.
5. Add suggestions for the rest, in shadow mode at first.
6. Go live with the review queue and the age report. Add accounts one at a time.

#When it isn't worth it

If you have forty bank lines a month, bank rules in your accounting software are enough. Automation pays off with thousands of lines, several accounts, intercompany balances or a close that always runs late because of reconciliations.

If that describes your team, talk to us. We'll look at a sample of statements and ledger data and tell you how much would match at each rung.

#Frequently asked questions

#What is reconciliation automation?

It's software that matches records from two sources, such as bank statement lines and ledger entries, and flags the differences. Rules handle the clear cases, AI can suggest matches for the rest, and people review the breaks.

#How does automated bank reconciliation work?

The system imports the bank data, matches lines to ledger entries by amount, date and reference, applies approved rules for recurring items and groups one-to-many payments. Anything left goes to a review queue for a person to resolve.

#Should automated reconciliation post journal entries?

Not without approval. Auto-posting recurring items under an approved rule, such as a fixed bank fee, is reasonable. Journals that adjust balances or clear differences should be reviewed by a person.

#Can AI do intercompany reconciliation?

It can match items across entities, suggest pairs and explain differences by timing, FX or missing entries. Elimination and true-up journals should still be approved by a controller.

#How do we know the matches are right?

Log every match with the method and rule used, review a sample each period, and track how often a person overrides a match. A rising override rate means a rule needs fixing.