The problem with the general purpose tool
A general account reconciliation tool models a balance, a sub-ledger and a sign-off. That is enough for a corporate close. It is not enough for a bank, where the same account can hold a payment instructed on Tuesday, settled on Wednesday and priced on a rate the correspondent chose. When the tool cannot express the value date, the reconciler puts the difference in a comment box and the control lives in a person.
The result is familiar. Match rates look acceptable, but the residue is where the money and the risk are: a handful of items a day that need a decision, and no consistent way to record which decision was made or why.
What account reconciliation looks like when it is built for a bank
Step 01
Accounts have a shape
Each account carries its source formats, its tolerances, its owning queue and its certifier. A nostro account is not configured like a fee account, and the system knows the difference.
Step 02
Matching is two pass
An exact key match on reference, amount and value date, then a tolerance pass that can absorb a one day timing difference or a cent of rounding, with the rule that fired recorded on the match.
Step 03
Differences become items
Anything unmatched becomes a worklist item with a classification, an age, an owner and a suggested action, rather than a highlighted row in a workbook.
Step 04
Certification is evidence
Sign-off is a state on the account with the preparer, the reviewer, the rule versions in force and the attachments already collected.
Tolerances are a control, not a convenience
Every tolerance you set is a decision to accept a class of difference without a human looking at it. That is legitimate, and it is exactly what auditors ask about. Bankautomation treats a tolerance as a versioned object: who proposed it, who approved it, when it took effect, and which matches it absorbed while it was in force.
| Tolerance | What it absorbs | What it must not hide |
|---|---|---|
| Value date window | Cut-off and settlement timing between two systems | A payment that never settled at all |
| Amount, absolute | Rounding and small posting differences | A deducted fee nobody accrued |
| Amount, percentage | FX rate source differences on the same trade | A partial settlement dressed as a rate difference |
| Reference normalization | Prefix and formatting noise between formats | Two genuinely different references treated as one |
From difference to closed item
Input
- Statement · 2026-09-03 · REF//TRF/554121 · 61,880.00 USD · HALCYON TRADING
- Ledger · 2026-09-03 · TRF/554121 · 123,760.00 USD · HALCYON TRADING
Output
- Partial settlement difference 61,880.00 USD, 50 percent short against a matched reference.
- Suggested action: split the ledger posting, match the settled leg, leave the residual open against the same reference.
- Routed to Payments Ops, aged from the value date, audit note written and attached.
What to ask a vendor
- Can the tool read a camt.053 or an MT940 without a mapping project, and can it read the settlement file too?
- Is a tolerance change versioned and approved, or is it a setting anyone with access can move quietly?
- Does an unmatched item become a workflow object with an owner and an age, or a row in an exceptions report?
- Can you export the evidence for one account, one period, with the approvals attached, in one action?
- Who edits a matching rule: your team, or the vendor on a change request?
Account types, and why one configuration will not serve them
The phrase account reconciliation covers work that varies enormously in shape. Treating every account the same way is the most common reason a deployment stalls after the first success: the configuration that suited a nostro is wrong for a fee account, and the team concludes the tool does not fit.
| Account type | External side | Frequency | What usually breaks |
|---|---|---|---|
| Nostro | Correspondent statement, camt.053 or MT940 | Daily, intraday where available | FX rate source, charges, value date timing |
| Settlement and clearing | Scheme or network settlement file | Daily | Fees, netting, partial settlement |
| Suspense and clearing internal | None, sub-ledger to ledger | Daily or weekly | Items with no owner and no age |
| Fee and commission | Billing or scheme invoice | Monthly | Accruals that do not match what was charged |
| Customer deposit control | Sub-ledger totals | Daily | Mapping changes after a product launch |
| ATM and card settlement | Network settlement report, switch log, cash counts | Daily, by switch cutover | Cutover timing, partial dispenses, interchange fees |
Each row implies a different set of tolerances, a different owning queue and a different certification cadence. A system that holds those as properties of the account, rather than as global settings, is the difference between adding the second account in a day and adding it in a quarter. The ATM row is the one most banks and credit unions still balance by hand, which is why it has its own page: ATM reconciliation software. Credit unions, with share draft, corporate and shared branching accounts on top, are covered on credit union reconciliation software.
Match rate is the wrong headline number
A match rate is easy to report and easy to improve in ways that make the control weaker. Widening a tolerance raises it. So does matching on a key loose enough to pair items that are not actually the same item. A program managed on match rate alone reliably drifts toward both, because the number improves and nothing in the reporting shows what it cost.
The measures that hold up are the ones describing the residue: how many open items exist, how old the oldest is, how much value they carry, and how many were absorbed by a tolerance rather than genuinely matched. An automated reconciliation that reports those alongside the match rate is describing its own limits, which is the property that makes it defensible in a review. Further detail on tolerance design is on automated reconciliation software.
Ownership, and the question that finds the gaps
Ask, for every account on the balance sheet, who prepares the reconciliation and who reviews it. In most banks a portion of the list has no confident answer, and that portion is almost exactly the portion where problems accumulate. An account inventory with a named preparer, a named reviewer, a cadence and a source is not glamorous work, and it usually finds more than the first month of matching improvements does.
If the answers are unconvincing, the reconciliation will keep happening in a spreadsheet next to the tool, which is the outcome you were trying to buy your way out of.
Questions about account reconciliation software
Is account reconciliation software different from bank reconciliation software?
The terms overlap. Account reconciliation is the broader control: every account on the balance sheet gets reconciled and certified. Bank reconciliation is the specific case of an external statement against your internal ledger, which for a bank means nostro, vostro, settlement and suspense accounts as well as the operating account.
Can it handle high volume daily accounts?
The plans are sized by matched items a month, from 250,000 on Operations to unlimited on Institution, precisely because bank accounts reconcile daily rather than monthly. See pricing for the limits.
Does it replace our general ledger?
No. It reads from the ledger and from the external source, and it produces matches, exceptions and evidence. Postings are made in your systems, by your people, under your approvals.
How does certification work?
An account moves to certified when its reconciliation is complete, its open items are classified and owned, and a reviewer separate from the preparer approves it. The certification carries the rule versions that were in force, which is what an auditor actually wants to see.
What about accounts with no external statement?
Internal accounts are reconciled sub-ledger to ledger, which is the general ledger reconciliation case: same engine, same exception workflow, different sources.