The same customer existed three times. In the CRM it was "Northwind Trading Co." with one identifier. In the ERP it was "Northwind Trading Company" with another. In the billing platform it was a third record, keyed differently again, created the day someone needed to send an invoice and couldn't find the first two. Then a payment arrived, and no one could say with certainty which of the three accounts it belonged to. Receivables aged against a customer that, depending on which system you asked, either owed nothing or owed twice.
Moving the data between those systems was never the hard part. Connectors are a solved problem; you can sync fields all day. The hard part is that the three systems do not agree on what a customer is. The CRM's "customer" is a sales relationship. The ERP's is an account that carries a balance. The billing system's is a payer with terms. They share a name and almost nothing else, and the integration that assumes they are the same object inherits every place they differ.
So we stopped treating the customer as one thing that travels between systems, and started treating it as several things that have to be reconciled by an explicit map.
Identity is the thing that doesn't transfer
You can copy a name, an address, a tax ID. What you cannot copy is identity — the guarantee that the Northwind in this system is the same Northwind in that one. Identity is a decision, not a data element. Someone has to own the rule that says these two records are the same legal entity and that one is the master, or the systems will quietly disagree and each will be internally correct. There is no field for "this is definitely the same company as the one over there." That has to be governed.
This is why field-level syncing fails so gracefully that no one notices until close. Each system keeps its own version, the sync papers over the differences, and the seam holds right up until a number has to be the same on both sides — a balance, a payment, a credit memo — and suddenly the three Northwinds matter very much.
What the seam needs to hold
An integration across systems that each have their own notion of a customer needs more than a pipe. It needs a small amount of governance, applied deliberately:
- One source of truth per entity. Exactly one system owns the master record for a customer. The others receive and reference it; they do not invent their own.
- A stable key that survives. The master carries an identifier that never changes, so every system can point at the same entity even as names and addresses drift.
- An explicit translation table. The map between this system's ID and that one's is a first-class artifact, owned and versioned — not a lookup someone holds in their head.
- Survivorship rules. When two records collide, a stated rule decides which value wins. Without it, the most recent careless edit wins by default.
- Change that propagates. A merge or a correction in the master flows outward on purpose, so the systems converge instead of drifting further apart.
None of this is glamorous, and that is part of why it gets skipped. Master data governance has no demo. It shows up only as the absence of a problem — the payment that lands on the right account, the receivable that ages against a real entity, the report that does not have to footnote which Northwind it counted.
Where the value actually leaks
Get the seam wrong and the cost does not stay contained at the seam. It travels. Receivables age against duplicates and overstate exposure. Revenue posts to the wrong entity and the segment report misleads. The close inherits an ambiguity it cannot resolve, because by the time the number reaches the ledger, the question of which customer it belonged to is three systems upstream and no longer answerable. The leak is small at the source and expensive everywhere it flows, which is the worst shape a problem can take: cheap to cause, costly to find.
It connects directly to the rest of this series. A posting only reconciles if it lands against the right account, and "the right account" depends on resolving the identity here. And an integration is only safe to rerun when each record has a stable key on both sides — which is the same governed identity, seen from the integration's angle.
It ties back to the ledger
The books are clean at the entity level because someone decided, early and explicitly, which system owns the customer and how everyone else refers to it. One customer, owned once, mapped on purpose everywhere else. It is unglamorous work that never makes a status highlight, and it is the reason a payment knows where to land and a receivable ages against something real. Two systems, one customer — but only if you make them agree on which one.