Automated reconciliation software for banks

How a match rate is manufactured

Widen the value date window to five days, set the amount tolerance to one percent and normalize references aggressively, and almost anything will match something. The break count drops, the dashboard turns green, and the differences that mattered are now inside the tolerance where nobody will ever look at them again.

The honest way to read a match rate is together with three other numbers: how much of the match came from the exact pass rather than the tolerance pass, what value sits inside the tolerances, and how old the oldest unresolved item is.

Auto-match is fine. Auto-close is where banks get hurt

Automatically pairing two records that agree under an approved rule is exactly what the software is for. Automatically closing an item that does not agree, because it is small or old or awkward, is a write-off, and a write-off is a decision that needs a person, a reason code and an approver.

BankAutomation draws that line in the product. Matching is automatic. Closing an unmatched item is an action, taken by a named user, approved by a second one where the amount or type requires it, with the reason attached to the item forever.

What actually raises a real match rate

1. 01Reference normalization that understands payment references rather than stripping characters at random.
2. 02A value date window set per account, because a correspondent in a different time zone is not the same case as an internal transfer.
3. 03Fee and charge handling, so deducted amounts stop presenting as amount mismatches every single day.
4. 04Duplicate detection on the ledger side, so a re-presented payment does not consume the wrong statement line.
5. 05Feeding resolved breaks back into rules, so a difference you explained once stops arriving as a surprise.

The two pass matcher, and why order matters

On payment accounts the residue has its own shape: ACH returns, returned Fedwire and FedNow payments and rejected instructions. Those are tied back to the original payment and worked by rail with payment exception management software, in the same queue as every other break.

Running tolerance first is a common and damaging shortcut. It produces a higher headline match rate and a lower quality result, because a pair that would have matched exactly can be consumed by a looser rule against the wrong counterpart. Order is not a preference here, it is a correctness requirement.

Grouped and split matches, where the volume hides

Two structural cases account for a surprising share of unmatched items and neither is a tolerance question. A batched posting is one entry on one side and many items on the other. A split settlement is one instructed item settled in parts. If the matcher can only pair one to one, both arrive as breaks every single day, and widening a tolerance makes the population worse rather than better because it starts consuming the wrong counterparts.

The handling that works is explicit many to one and one to many matching, with every leg consumed by the match recorded against it so the audit trail shows which items formed the group. A residual left over from a split should stay open against the original reference rather than being absorbed, because that residual is the outstanding exposure.

Re-running a reconciliation without rewriting history

Reconciliations get re-run. A statement is redelivered, a ledger export was incomplete, a rule was corrected. What must not happen is that the re-run silently replaces the earlier result, because somebody may already have worked items from it and an auditor may later ask what was known on the day.

• A re-run is a new run with its own timestamp, not an overwrite of the previous one.
• Actions taken on items from the earlier run survive and are carried forward, with their actor and reason intact.
• The rule version that produced each match is recorded on the match, so an old result stays explainable under an old rule.
• A redelivered file is detected as a redelivery rather than ingested as new activity, which is the same duplicate detection that stops a statement being loaded twice.

Straight through processing, honestly defined

Straight through processing is often quoted as a percentage without saying what it counts. Two definitions are in common use and they can differ by twenty points on the same data: the proportion of items that matched without human intervention, and the proportion of items that reached a final state without human intervention. The second is the meaningful one, because an item that matched automatically and then required a person to release it did not go straight through anything. When comparing tools or reporting internally, state which definition is in use, once, and then keep using it.

See both numbers move

The resolver reports exact matches and tolerance matches separately, on purpose. Change a tolerance and watch which number moves. If only the tolerance number is moving, you did not improve the reconciliation, you improved the report about it. Vault, ATM, Fed cash order and carrier shipment accounts run on the same matcher, and that workload has its own page on cash reconciliation software.

Questions about automated reconciliation software