At a glance
- Reconciliation matching isn't one algorithm — it's a set of rules, and each one carries a different amount of risk.
- A match strategy matrix maps seven rule types to when to use them, their risk, and whether they may auto-clear or only suggest.
- AI-suggested and fuzzy matches should route to a person for confirmation, not auto-clear, until you've measured how often they're right.
- Unmatched items need an exception taxonomy with a named owner and a resolution path — not a suspense account that quietly grows.
- Test every new matching rule against a period you've already closed before it's allowed to auto-clear anything.
Matching is a set of rules, not one algorithm
Reconciliation matching can look like one setting inside one engine, but a bank reconciliation, an intercompany reconciliation, and a subledger-to-ledger reconciliation don't match the same way. Some pairs of records should only ever be compared one-to-one on an exact reference. Others need to sum several transactions on one side against one entry on the other, or allow a small difference in amount or date before calling something a match.
Treating every reconciliation as one setting is how automation goes wrong: a rule loose enough to catch the comparisons that need tolerance is also loose enough to wave through something that shouldn't clear automatically. Choose the rule, and the control around it, per reconciliation, not globally.
Use the matrix and taxonomy below as a working reference for each reconciliation your team runs, and check its control column against your process. Check for a spreadsheet macro or old system default auto-clearing a match type the matrix marks suggest-only.
The match strategy matrix
The table groups common reconciliation matching problems into seven types, each with a typical risk level and the control it needs before you let it clear on its own.
| Match type | When to use it | Risk | Required control | Example reconciliation |
|---|---|---|---|---|
| Exact one-to-one | A stable, unique reference exists on both sides (check number, transaction ID) | Low, if the reference is genuinely unique | Auto-clear | Bank reconciliation on cleared checks by check number |
| One-to-many | One side records a summary that several entries on the other side add up to | Moderate: a wrong grouping can hide a missing item inside a correct-looking total | Suggest-only until the grouping logic is validated on closed periods | One deposit matching several point-of-sale batches |
| Many-to-many | Both sides record multiple entries that only balance in aggregate | Higher: the hardest case to validate by eye | Suggest-only, always | Intercompany reconciliation with netting across several invoices each side |
| Tolerance on amount | Small, explainable differences are routine (rounding, fees) | Moderate: depends entirely on the tolerance band being set deliberately | Auto-clear only within a documented, approved band; log every auto-cleared difference | Card-processor settlement net of a known fee |
| Tolerance on date | Timing differences between systems are routine (post date vs. value date) | Moderate: a date window can mask a genuinely missing entry that happens to fall inside it | Auto-clear only with a fixed maximum window and a log of what cleared under it | Wire received a day or two after the ledger entry |
| Reference normalization | References differ in format only (leading zeros, dashes, case) but represent the same value | Low, if the normalization rule is narrow and tested | Auto-clear once the normalization rule is validated | Invoice numbers formatted differently in two systems |
| Fuzzy / AI-suggested | No reliable exact key exists; matching depends on similarity across amount, date, description, and counterparty | Highest: false matches look plausible and are hardest to catch on review | Suggest-only; a person confirms every match before it clears | Matching a vague bank-statement description to an AP payment |
Tolerances: who sets them and why
A tolerance band is the maximum dollar or day difference the system will clear automatically. It's a policy decision, not a technical default, and it should be set by the controller, documented, and revisited — not left at whatever a vendor shipped.
- Base the band on evidence: sample several closed periods and see which differences were genuinely immaterial, and which a wider band would have hidden.
- Set different bands for different accounts. A high-volume, low-dollar account can tolerate a wider band than a low-volume, high-dollar one.
- Log every item that clears under a tolerance, with the difference amount, so the log itself becomes evidence the band is still appropriate.
- Review the band on a schedule. A tolerance that was reasonable at one transaction volume can quietly hide a growing problem at a higher one.
Date tolerance works the same way: define a fixed number of days, not an open-ended “close enough” window. One open-source import-and-matching tool for a plain-text ledger treats postings as candidates only within a set window — up to five days apart [2] — an explicit, bounded rule to aim for.
One accounting system reconciles what agrees and leaves the remainder open on the invoice or transaction, rather than clearing or failing the whole item at once [1]. We recommend the same principle: keep a difference outside tolerance visible until someone accounts for it, not folded into a rounding adjustment.
A one-to-many amount tolerance is really two checks — the total and the grouping — see the FAQ below.
Where AI suggestions fit, and where they must not auto-clear
A model is useful where no reliable rule exists: ranking candidate matches by how well they fit on amount, date, description, and counterparty, and handing the best guesses to a reviewer instead of a blank unmatched list.
A scoring approach worth borrowing: an open-source matching tool computes a set of candidate matches for each unmatched item, lists the proposal that explains the most postings first, and keeps the original unmatched entry in the list [2].
- Exact one-to-one and reference-normalization matches can auto-clear once their rule is tested end to end.
- Grouped and tolerance matches graduate one pattern or band at a time, not as a blanket switch, once closed periods show that pattern or band is safe.
- Fuzzy and AI-suggested matches stay suggest-only until that evidence exists. The operating controls for any type that does graduate are on the Financial reconciliation automation page.
What a model shouldn't do is clear that match on its own. A fuzzy or AI-suggested match can look highly plausible and still be wrong, and unlike a broken exact-match rule, a wrong fuzzy match doesn't announce itself — it quietly nets two unrelated transactions together. Keep every AI-suggested match in suggest-only mode until you've measured, over enough closed periods, how often that category of suggestion turns out correct — evidence to decide whether a narrower version could graduate to auto-clear.
The exception taxonomy
Items that don't match at all need their own classification, because “unmatched” isn't a diagnosis on its own — it's the absence of one. A taxonomy turns a growing pile of unmatched items into a set of specific problems, each with an owner and a path to resolution.
| Exception type | What it looks like | Owner | Resolution path |
|---|---|---|---|
| Timing difference | An item exists on both sides but posts in different periods | Preparer, with a note for the reviewer | Verify it will clear next period; don't force a match across periods |
| Missing entry | An item exists on one side with nothing corresponding on the other | Preparer investigates the source system for the missing side | Book the missing entry once source-verified, or escalate if the source can't confirm it |
| Duplicate | The same transaction appears to be recorded twice on one side | Preparer identifies and confirms with the originating system | Reverse the duplicate; document why it occurred to prevent recurrence |
| Amount mismatch | Both sides show the item but for different amounts, beyond tolerance | Preparer, escalate to reviewer if the cause is unclear | Trace both amounts to source documents; correct the one in error |
| FX difference | A multi-currency item's translated amount differs between systems | Treasury or the preparer, per your FX rate policy | Confirm which rate and rate date each system used; correct the one that used the wrong convention |
Duplicates deserve a specific mention because prevention beats detection after the fact: tie every imported item back to its original source data so the same transaction can't load twice in the first place [2]; catching a duplicate once both copies have posted is harder than never creating it.
Not every exception needs the same clock. Escalate an item past its preparer once it crosses the materiality threshold your controller sets, once it's aged beyond the current close, or once it needs confirmation from outside your own systems — a bank, a processor, another entity — that the preparer can't get alone.
Testing rules on a closed period
Before any rule auto-clears in production, replay it against a period you've already closed and reviewed. A rule that looks reasonable on paper can behave differently against real reference formats, timing gaps, and duplicate entries.
- Replay against a closed period
Run the new rule against a period your team already reconciled and signed off, without changing that period's recorded outcome.
- Compare outcomes item by item
Confirm the rule reproduces every match your team actually made, and doesn't clear anything your team would have flagged as an exception.
- Check what it missed
Confirm the rule doesn't leave a known-good match unmatched because it was written too narrowly.
- Validate against an outside source where you can
Where possible, check a sample against an independent source — a bank statement, a counterparty confirmation — not just against your own systems agreeing with themselves.
When this doesn't apply
- Every item on both sides already carries a unique, shared reference. Exact one-to-one covers that case on its own, and building out the rest of the matrix adds nothing.
- Your systems can't log or version a rule or tolerance change once it's made, so a grouping or tolerance rule couldn't be reviewed after the fact. Fix that gap before adding either kind of rule.
- Whether to build new matching logic or configure rules an ERP or reconciliation tool you already own is a separate question from this matrix — see Financial reconciliation automation's "When this isn't the right approach" for that.
- The reconciliation turns on a judgment call — an estimate, a disputed balance, a write-off decision — that a matching rule was never meant to make.
Frequently asked questions
What order should matching rules run in?
Run the safest rules first: exact one-to-one matches on a stable reference, then reference normalization, then tolerance and grouping rules within a documented band, and fuzzy or AI-suggested matches last. Each stage should only see what the stage before it couldn't already resolve.
Can amount tolerance apply to one-to-many matches?
Yes, but treat it as two checks, not one: whether the total falls within your tolerance band, and whether the grouping itself is right. A correct-looking total can still hide a missing or duplicate item, so we recommend suggest-only for one-to-many matches until the grouping logic is validated on a closed period, even when the arithmetic would otherwise clear it.
What is a good auto-match rate?
There's no target we'd publish. Measure it per match type, not one blended number — exact one-to-one clears far more often than fuzzy, and averaging hides which rule needs work. Pair it with a false-match rate from a sampled, closed-period check, and treat a jump after a tolerance-band change as a signal to review, not celebrate.
How do you score candidate matches?
Rank candidates by how closely they agree on amount, date, description, and counterparty, and by how many postings a grouped candidate explains. List the one explaining the most postings first, and always keep “no match” as an option so reviewers are never forced to pick.
How do you prevent false matches?
Keep tolerance and grouping rules narrow and documented, sample matches that clear automatically, and never let a fuzzy or AI-suggested match clear itself — a person confirms it first. Log who reviewed each one, and separate whoever tunes a rule from whoever approves what it suggests.
When should an unmatched item escalate?
Escalate past the preparer once an item crosses the materiality threshold your controller sets, once it ages beyond the current close so it's no longer a same-period timing difference, or once resolving it needs confirmation from outside your own systems — a bank, a processor, or another entity.
Related reading
- Financial reconciliation automation covers the full workflow this matrix sits inside.
- Financial close automation covers the close as a whole, beyond account-level matching.
- AI financial close automation goes deeper on the close in general.
- Automating legacy systems without migration covers integration when the ledger or bank feed runs on an older system.
More in Finance operations
Deal Jacket and Title/Registration Automation for Multi-Rooftop Dealer Groups
Deal jacket and title/registration automation for multi-rooftop dealer groups: a completeness checklist table, audit-gap handling and cross-store standards.
Auto DealershipsFranchise Brand-Standards Audit Documentation: Automating the Paper Trail Behind the Inspection
Franchise brand-standards audit documentation: how an agent turns photos, PDFs, forms and emailed fixes into one packet per location, ready when asked.
Multi-Unit Franchise OperatorsGroup and Folio Billing Audit: Catching the Leak Types a Normal Error Check Misses
A group and folio billing audit for hotel management companies: a leak-type table of rate code mismatches, missing closes, adjustments, orphaned charges.
Hotel Management Companies