Reconciliation Is a Symptom, Not a Workflow

If you have a team whose full-time job is comparing two numbers that should already match, you don't have a reconciliation problem. You have an integration problem that you've hired people to absorb.

Reconciliation is necessary in the world we actually live in. Two systems will always drift. Counterparties will always send files with small inconsistencies. Manual adjustments will always be made. The question is not whether reconciliation should exist — it's whether it should be the workflow, or the exception to it.

In most of the operations we see, reconciliation is treated as the workflow. A team pulls reports from two systems on a schedule, drops them into a workbook, runs a comparison, and hand-investigates differences. The work is methodical, valuable, and quietly expensive. It also misses things, because human reviewers are not designed to spot the one record out of fifty thousand that broke in a new way.

The shift worth making is from periodic reconciliation to continuous validation. The architecture is straightforward in principle, even when the rollout takes patience:

Pick the system of record, deliberately.For every meaningful data domain — positions, fees, accruals, customer master, vendor master — one system should be the authoritative source. Other systems can hold copies, but they cannot disagree without an explanation. “Equal authorities that drift” is the most expensive operational pattern in finance.

Define canonical keys. Loans get one identifier. Trades get one identifier. Entities get one identifier. If two systems use different keys, there is exactly one mapping table, owned by exactly one team. Most reconciliation pain is fancy key translation, performed daily, by hand.

Validate continuously, not periodically.Run the comparisons as part of the pipeline, not as a downstream task. When a record fails validation, it should raise a ticket the moment it enters the system — not at month end, when the context is gone and the original file has been overwritten.

Make exceptions first-class.Every legitimate difference between systems should be representable as a typed exception with an owner, a reason, and an expected resolution date. “The senior analyst knows why those two numbers are different” is fine until the senior analyst is on vacation. An exceptions table is the cheapest way to make that knowledge survive a long weekend.

The teams that make this transition don't fire their reconciliation analysts. They redeploy them. The work shifts from running comparisons to investigating the comparisons the system has already flagged, defining new validation rules, and improving the integrations that produced the differences in the first place.

That's a higher-leverage version of the same job. It also produces an operation where month-end is uneventful, audit questions have clean answers, and adding a new fund or product doesn't require adding a new tab to a workbook.

The right amount of reconciliation in a mature operation is not zero. It's the residue left after the integrations and validations have done their work. If your team is doing more than that, the bottleneck isn't headcount. It's architecture.