Reconciliation

What it contains

Reconciliation is done per data object rather than in aggregate. For each object there are usually three layers of evidence. Counts: how many records were in scope, how many loaded, how many were rejected and why. Control totals: the sum of key numeric fields — balances, order values, quantities — compared between source and target. Sampling: a defined number of records compared field by field, chosen to cover normal cases and known awkward ones.

Two supporting elements make the numbers usable. A tolerance, stating what difference is acceptable and on what basis — some differences are legitimate, such as records deliberately excluded from scope. And an exceptions list, itemising every discrepancy with a cause and a disposition. A reconciliation report with a variance and no explanation of the variance is not evidence of anything.

How it is used

Reconciliation runs after every dry run and again after the live load. Its first use is diagnostic: comparing counts and totals across successive dry runs shows whether mapping and transformation fixes are working. Its second use is acceptance — the evidence a business owner signs against before the new system is opened. That sign-off record is a specific tab in the migration tracker because it is what the go/no-go meeting asks for.

During cutover the reconciliation step is a timed task on the runbook with an owner, a duration and a decision attached. It is also one of the few places where the runbook has a genuine branch: if reconciliation fails outside tolerance, the sequence either pauses, proceeds with a recorded exception, or triggers rollback. Which of those applies is a decision somebody has to be authorised to make at the time.

Reconciliation also continues into the first days of live running, where operational reports are compared against expected values and the finance position is checked against the legacy close.

Where it goes wrong

The most common problem is tolerances agreed after the numbers are known. When a variance appears at three in the morning and no one wrote down what was acceptable, the tolerance becomes whatever the team can defend at that moment.

The second is reconciling counts only. Record counts match while values are wrong, because a transformation defect affected a field rather than a row. Control totals on the fields that matter commercially catch what counts miss.

The third is sampling that avoids difficulty. Samples drawn at random from the bulk of clean records confirm what was never in doubt. Deliberately including the edge cases — records with unusual characters, historic accounts, partially completed transactions — is where sampling earns its place.

The fourth is a reconciliation with no named acceptor. The report is produced, circulated, and nobody formally accepts it, so when a discrepancy surfaces in week three of hypercare there is no record of what was known and agreed at the time.

Related terms

Data migration is the load that reconciliation tests. Control total is the summed value compared between systems. Tolerance is the agreed acceptable variance. Exception is a discrepancy recorded with a cause and a disposition. Sign-off is the named acceptance of the reconciliation result, usually a go/no-go criterion.

Glossary · All 36 templates