Anyone who runs financial reconciliations knows the routine. A tolerance is too tight, breaks are piling up, so you widen it. You rerun, and the break count drops from 40 to 9. It looks like a clean win.
But the count does not tell you which rows actually moved. You cleared some rounding noise, but did you also swallow a real discrepancy that was sitting just inside your new tolerance? You will not know until it resurfaces weeks later as a loss or an audit question.
The hidden risk in every reconciliation rule change
Reconciliation compares two systems that should agree: orders against settlements, a ledger against a custodian feed, a book against a counterparty statement. Making them agree means writing rules, key mappings, tolerances, exclusions, precision settings.
Those rules never stay right. New counterparties send different files. Feeds change formats. What counted as noise yesterday matters today. Every change means editing the matching logic, and every edit is made blind. There is no safe way to see what a rule change does before you are committed to it.
Why reconciliation rules are never done
The same reconciliation software, reconciliation rules, and break management workflows that keep daily ops running also need constant tuning. Financial reconciliation teams widen tolerances, remap keys, and add exclusions as formats drift. Without reconciliation automation that can show its work, each change is a guess.
Software solved this problem decades ago
Developers do not edit live code and hope. They branch off the current state, make the change in isolation, read the diff, and merge when they are ready. Nothing goes live by accident.
Reconciliation never got the equivalent. Until now.
Branching and data diffs, applied to reconciliation
MatchStrat brings the branch-and-merge model to reconciliation:
- Branch a live reconciliation and edit the rules in a private sandbox. The live process keeps running untouched.
- Freeze the data so any change in the output came from your rule edit and nothing else.
- Diff the outcomes, not the config. See row by row what moved: newly matched, newly broken, resolution flipped. In our tolerance example: 31 rows correctly cleared, 1 real break caught before it shipped.
- Merge or abandon. If it is good, publish it. If not, throw the branch away. Nothing lost, full history kept.
Reconciliation that can show its work
Because every branch, rule version, and diff is recorded, the audit trail comes for free. When a controller or auditor asks why a number moved, the answer is the diff, not a reconstruction from memory. Reconciliation is a control function, and one that can prove what it did is worth more than one that can only insist it did.
Read the full white paper
Tuning reconciliation rules should run on evidence, not hope. Our white paper, Version Control for Reconciliation, walks through the full model: branching, data diffs, and how teams adopt it alongside their existing process.
Frequently Asked Questions
What is version control for reconciliation?
Version control for reconciliation applies the branch-and-merge model from software development to reconciliation rules. Instead of editing matching logic directly on a live process, you branch it, make changes in a sandbox, review a diff of the results, and merge only when you are confident. It brings the same safety software teams have had for decades to financial reconciliation.
How do you test a reconciliation rule change before it goes live?
You create a branch of the reconciliation, which freezes the underlying data so nothing else can shift, then edit the rules in isolation. Running the branch produces a full set of results you can compare against the original, row by row, so you see exactly what the change did before publishing it. If the change is not right, you abandon the branch and nothing is affected.
What is a data diff in reconciliation?
A data diff compares the results of two reconciliation runs and sorts every row that changed into clear categories: newly matched, newly broken, resolution flipped, and so on. Unlike a summary break count, it shows which rows moved and why, so a real discrepancy cannot hide behind an improved total. It is the difference between describing a change and measuring it.
Why do reconciliation rules need constant tuning?
Reconciliations depend on rules, key mappings, tolerances, exclusions, precision settings, that reflect how two systems format and report data. As counterparties, feeds, and data formats change, those rules drift out of date and produce false breaks. Regular tuning keeps the process accurate, but without a way to test changes safely, teams often tune too conservatively to avoid breaking something.
Does reconciliation version control help with audit and compliance?
Yes. Because every branch, rule version, and diff is recorded, you get an automatic audit trail of what changed, what it did to the numbers, and when. When a controller or auditor asks why a figure moved between periods, the answer is the diff itself rather than a reconstruction from memory, which makes reconciliation a control that can prove its work.