2026-07-22

Where reconciliation breaks before you automate it

Most reconciliation automation projects start with a tool decision — which platform, which vendor, which integration — before anyone has written down exactly where the current process actually breaks. That order produces expensive automation of the wrong step.

The teams that get a working fix on the first attempt tend to do the diagnostic work first: map where today's process actually fails, then automate that specific break. This is a practical checklist for that first step.

Why automating the wrong break point wastes a build cycle

A reconciliation process usually has one or two genuine failure points and a long tail of things that already work fine. If the build targets the long tail — automating matches that were never the problem — the actual bottleneck is still there after go-live, just now wrapped in a more expensive system.

The fix is to name the break points before scoping anything, the same way you'd map a workflow before deciding what to build: find the friction first, then match the fix to it.

A checklist for finding where reconciliation actually breaks

Break type	Symptom	Example
Data-quality break	Same real-world entity, represented differently across systems	"Acme Corp" in one feed, "ACME CORPORATION LLC" in another — an exact-match rule fails here even though a human reads it instantly as the same counterparty
Timing break	Two systems agree eventually, but disagree at the moment you check	A trade books in system A at T+0 and doesn't land in system B until T+1 — every day-of check flags a "break" that resolves itself by morning
Coverage break	A whole category of transaction has no defined matching rule yet	A new product type or a new counterparty format nobody's written a rule for — these don't fail loudly, they just silently pile up in an exceptions queue
Volume break	Rules that worked at low volume start producing false positives at scale	A matching rule tuned by hand for 200 trades a day starts misfiring at 20,000, because edge cases that were rare become routine

Each of these needs a different fix. A data-quality break usually needs fuzzy or rule-based normalization before matching, not a stricter exact-match rule. A timing break often needs a re-run window, not more automation. Conflating the four is the most common reason a reconciliation build under-delivers.

The difference between a data-quality break and a process break

It's worth separating these two explicitly, because they get treated the same way and shouldn't be:

A data-quality break is a matching problem — the same fact is recorded two different ways, and the logic needs to handle that (this is where something like fuzzy matching, a normalization step, or a reference-data cleanup earns its cost).
A process break is a workflow problem — the data matches fine, but the *step* that should catch a real exception is missing, understaffed, or dependent on one person's manual review.

Automating a data-quality break with better matching logic helps. Automating a process break the same way just moves the bottleneck to wherever the exceptions get dumped instead.

What to map before you scope a fix

Before writing a requirements doc or briefing a vendor, get clear answers to:

What percentage of items match cleanly today, without any manual touch?
Of the ones that don't match, how many fall into each break type above?
Which specific exceptions currently require one named person's judgment call?
What would "good enough" automated coverage look like — 90% auto-matched with a clean exceptions queue, or something closer to 99%?

Ops teams that can answer these before scoping a build consistently end up automating the actual bottleneck, not the easiest-to-automate step that happened to be top of mind.

If your team is scoping a reconciliation fix and wants a second set of eyes on where the real break points are before you commit to a build, book a call — we're happy to talk through where the diagnosis-first approach applies to your specific process.