Source to Target Reconciliation

What Source to Target Reconciliation Means

Source to target reconciliation is a completeness and accuracy control. It compares records, totals, or attributes after movement from one system to another so teams can confirm that the receiving system reflects the source of record and that no material data was lost, duplicated, or changed in transit.

Used well, it turns a transfer into a verifiable control point rather than a blind handoff. In reporting and risk data pipelines, that distinction matters because downstream decisions often depend on the assumption that the source and target datasets still match.

Why Reconciliation Matters in Data Flows

Reconciliation is especially important where data is transformed, aggregated, enriched, or routed through middleware before it reaches its destination. Each step can introduce mapping errors, truncation, type conversion issues, late-arriving records, or filters that change the final result without any obvious system failure.

It is also one of the few controls that can reveal silent data quality loss. A pipeline may appear healthy from an uptime perspective while still producing inaccurate outputs, which is why reconciliation is often paired with control totals, row counts, key-field checks, and exception reporting.

How Source and Target Checks Work

Reconciliation can be exact or sampled, depending on the volume and criticality of the data. Exact checks compare every record or aggregate, while sampling may be used for very large flows where the main goal is to detect anomalies quickly and direct deeper investigation.

The control usually starts with a defined comparison rule: what fields must match, what counts as material variance, and how duplicates or late updates are handled. The stronger the business impact of the data, the more precise the reconciliation rule needs to be, because vague matching criteria weaken the assurance the control is supposed to provide.

In mature environments, reconciliation is part of the reporting chain, not an afterthought. Teams expect exceptions to be logged, investigated, and resolved with a clear owner so that repeated breaks in the same transfer path become visible trends rather than isolated incidents.

What Good Reconciliation Proves

Good reconciliation proves more than that two systems exchanged information. It shows that the data retained its intended meaning across the transfer, that material exceptions can be identified, and that the organisation has evidence to support completeness and accuracy claims.

This matters in risk reporting, finance workflows, and other regulated or operationally sensitive pipelines because the control provides traceability. If numbers change unexpectedly, reconciliation creates a defensible way to pinpoint whether the issue came from extraction, transformation, transport, or loading.

It also helps separate system failure from process failure. A successful transfer is not the same as a correct transfer, and source to target reconciliation is the control that closes that gap.

Risk and Threat Considerations

When reconciliation is weak or absent, silent corruption can travel downstream and contaminate reports, dashboards, decisions, and automated workflows. The main danger is not always an obvious outage, but a believable answer built on incomplete or altered data.

Failure mechanism: A record can be dropped, duplicated, truncated, remapped, or delayed during extraction, transformation, transport, or loading, and the error may remain invisible unless the source and target are explicitly compared.

Impact: Incorrect reporting, missed anomalies, flawed risk calculations, and delayed incident detection can follow, especially where business processes assume the target system is an exact reflection of the source.

Practitioner Guidance

Why practitioners should care: Reconciliation should be treated as a control design choice, not just a technical check. The comparison method, tolerance threshold, and exception handling need to match the criticality of the data flow, otherwise the control can produce a false sense of assurance.

What to watch for: Repeated mismatches in the same fields, unexplained volume drift, missing late-arriving records, and manual overrides are all signals that the pipeline or the reconciliation logic itself may need review. If those issues recur, the underlying mapping or control assumption is usually the real problem.

Practitioner takeaway: The value of reconciliation comes from closing the loop on exceptions, not from producing a pass/fail result once in isolation.

Related resources from NHI Mgmt Group

• Why do package-lock discipline and dependency pinning matter when attackers target open-source ecosystems?
• What happens when source to target validation is missing during data movement?
• Target State Reconciliation
• Source To Target Validation