When two systems disagree about a customer, check both the integration and the rule it implements. A perfectly delivered update can still be wrong if nobody decided which system was allowed to change that field.
Ownership is a field level decision
The instinct is to nominate a system of record for each entity: the CRM owns customers, the ERP owns products. It is tidy and it is usually wrong, because ownership is not uniform across a record.
Accounting legitimately owns the billing address, the payment terms and the tax registration. The operational system legitimately owns the service address, the access notes and the site contact. Marketing legitimately owns the communication preferences. All three are writing to what a person would call the customer record.
Build a matrix. Rows are fields, columns are systems, and each row names the authority for that value and its receivers. Review the matrix when workflows change. It establishes the intended direction of updates but does not eliminate mapping, identity or delivery defects.
Where two systems genuinely both need to write a field, that is a design smell worth examining. Usually it means the field is actually two fields with the same name.
Tag your own writes
The second classic failure is the loop. System A updates a record, the integration writes it to B, B emits a change event, the integration writes it back to A, and the two systems update each other indefinitely.
A source marker, dedicated integration identity or provider supported correlation identifier can help identify echoed writes. Compare the fields and operation involved rather than ignoring every event from that identity: the receiving system may also add a legitimate calculated value that needs to travel back.
Without it, loops usually surface as a mysterious spike in API usage rather than as an obvious error, which makes them slow to diagnose.
Identity resolution needs a review path
Systems that were never designed to share data rarely share a key. Matching customers between them means rules, and rules produce ambiguity.
Use a shared immutable identifier where one exists. Email addresses and phone numbers can change or be shared; a company domain identifies neither an individual nor necessarily a single account. Treat those values as matching evidence with explicit limits, not guaranteed identity.
For a verified match, attach the external identifier. For an ambiguous match, hold the linking operation for review rather than silently merging or creating another active customer. Two contacts at the same company with different names are not necessarily the same person.
Merging is easy and unmerging is close to impossible, which is the argument for caution.
Transformation is where quiet corruption starts
Field mapping seems trivial until it is not.
Units. One system holds weight in kilograms and the other in pounds, and nothing in either schema says so.
Dates and time zones. One stores local time with no offset, another stores UTC. A booking that moves by an hour twice a year is the result.
Enumerations. Status values rarely map one to one. Decide what happens to an unknown value: it should raise rather than default silently to the first option in the list.
Precision. Currency held as a float somewhere will eventually produce a penny difference that finance spends a day chasing.
Write the mappings down and test them, including the edge values.
Event driven where possible, polling where not
Where the source emits change events, consume them: verified, deduplicated on the event identifier, and processed idempotently.
Where it does not, poll incrementally with a high water mark so each run reads only what changed since the last successful one. Store the checkpoint with the processed data so an interruption resumes rather than restarts.
Full table comparisons on a schedule are a last resort. They work, they are expensive, and they scale badly.
Reconciliation is not optional
Integrations decay. A field is added at one end, a permission changes, a provider revises an API, a certificate expires. Most of these do not produce a clear error.
A scheduled comparison that reports records present in one system and missing in the other, run whether or not anyone is worried, is the only reliable defence. Put the output somewhere a person reads.
The order of work
Inventory the systems and fields. Build the ownership matrix. Define identity resolution with its confidence levels and review path. Write and test the transformations. Then build the sync. Then build the reconciliation.
That sequence turns hidden assumptions into decisions the operators can inspect.
A field can change authority at a business milestone
Consider a draft order whose delivery instructions come from a customer portal. Before release, the customer may edit them. After dispatch has begun, a change may need approval because a warehouse document or carrier request already exists. A permanent rule saying the portal owns the field is insufficient.
Record the transition in the ownership matrix: which state permits direct editing, which state creates a proposed change and who can approve it. The integration should carry the order version with the proposal. If fulfilment advances while approval is pending, recheck whether the proposed change is still possible.
Keep the original value, accepted replacement and reason in the business history. That lets a dispatcher explain why a screen differs from a printed document without treating one as random corruption. It also gives reconciliation enough context to distinguish an expected historical difference from an unresolved update.
Test the transition using two sessions. Let the portal submit a change while dispatch releases the order. The system must choose a documented outcome, such as holding the change for review, rather than depending on whichever HTTP request finishes last. Ownership is therefore a rule about both the field and the workflow state, not just an arrow between two boxes.