The API returned 200, but records diverged: reconciling business integrations
Detect missing and inconsistent CRM and ERP records with field ownership, stable identifiers, comparable snapshots, version checks and safe repair workflows.
Contents
The logs show no errors: API requests succeeded and the queue drained. Yet an order exists in the CRM and is missing from the ERP, while a report displays yesterday’s status. Transport metrics describe requests moving between systems. A separate business-record reconciliation process is needed to verify the outcome.
Assign ownership at field level
One system does not necessarily own an entire record. The CRM might own customer contact details while the ERP owns shipment status. Document the owner, business key, transformation rules and acceptable propagation delay for each significant field.
Map external IDs to a stable internal key. Account for merged duplicates, deletion and recreation. Matching names or row positions creates false equivalence.
Normalize representations before comparing them: time zones, empty values, case where irrelevant, monetary precision and collection ordering. Reconciliation and the integration contract should share these rules.
Compare a meaningful slice
If the CRM changes while the ERP export is running, different values do not necessarily indicate a lost event. Establish a comparison boundary, object versions and an allowed lag.
Use consistent snapshots or agreed watermarks where available. Otherwise, select records that have remained unchanged longer than the allowed delay, recheck candidates and preserve the versions observed in both reads. A timestamp from one machine does not prove ordering across systems.
For large datasets, partition by stable key and period. Partition checksums can narrow the search but require identical canonicalization and cannot replace record-level investigation.
Classify differences before repairing them
| Difference | Investigation question |
|---|---|
| Missing record | Was its event lost, delayed or rejected? |
| Older version | Is work queued, and is the lag still acceptable? |
| Different fields | Which system owns the value, and do transformations match? |
| Extra record | Was there duplication, deletion or a selection-scope change? |
Record the reconciliation run ID, object key, versions, difference class and a reference to the originating event. Avoid copying full personal records into diagnostic logs when identifiers are sufficient.
Reconciliation complements infrastructure observability. A healthy HTTP success chart can coexist with a growing number of inconsistent orders.
Repair through the normal write path
Do not turn reconciliation into a nightly script that blindly overwrites the receiving database. Produce a repair plan containing the object, observed version, expected version and reason. Run it without applying changes first and review the scope.
Check the version again before applying the repair. If a user has already changed the record, the old plan should stop or require investigation. Reprocessing must be idempotent and must not trigger duplicate shipments or notifications.
Where possible, replay the originating event through its standard handler. A transactional outbox helps preserve events, but that log does not remove the need to verify the final state. Structural changes need a separate database schema migration plan.
Define when a run is complete
Measure differences by age, entity and cause, the remaining unexamined data, and the share of successful repairs. Track whether a repaired problem reappears.
A run is complete when all planned partitions have been checked, candidates have been rechecked and unresolved cases have assigned owners. Start with one critical flow, such as order-to-shipment, and exercise event loss, duplication, concurrent updates and an unavailable source. The integration then has a measurable business outcome alongside its request-success counter.
