Define what agreement means

List the fields and states that must match, and identify differences that are expected. Two systems may represent the same workflow differently, so raw record equality is often the wrong test.

Choose stable identifiers for matching records. Document how deleted, merged, or archived records should appear in the comparison. If one system updates later than the other, define a reasonable observation window before treating a difference as an exception.

Classify discrepancies

Separate missing records from conflicting values, stale updates, and records that cannot be matched confidently. These categories may need different responses and different owners.

Avoid automatically repairing every mismatch in one direction. A receiving system may contain a legitimate correction that should be reviewed rather than overwritten. The ownership rules for the information should determine which repairs are safe to automate.

Turn the comparison into work

Produce a report or queue that identifies the affected records, the observed difference, and the next action. Include enough context for someone to investigate without manually querying both systems from scratch.

Record how discrepancies are resolved and look for repeated patterns. A recurring correction may point to a misunderstood field, a missing event, or an integration rule that no longer matches the business process.

Run reconciliation after changes as well as during normal operation. An integration release that appears healthy at the request level may still introduce a semantic mismatch. Independent comparison gives the team a way to notice that difference before users discover it through a broken downstream workflow.

Illustrative scenario

A practical example.

A sales application and fulfillment service disagree about whether an order shipped. Start with a stable shared identifier and compare the records at an agreed cutoff, rather than comparing changing totals from two dashboards.

Classify mismatches: missing records, stale state, different field values, or an expected delay. Each class may need a different repair. A missing order might be resent; a conflicting address may need human review. Produce a reviewable report before applying bulk corrections, and keep the evidence that explains each change. Reconciliation should also detect a failed integration that looked successful at the transport layer. A delivery acknowledgment alone does not prove that the intended business record is correct.

Put it into practice.

  • Choose shared identifiers and a consistent comparison window.
  • Distinguish expected delay from missing or conflicting information.
  • Make repair decisions reviewable and record the changes they produce.

Working through a similar decision?

Tell us about your project