The situation
A building-products group sold through a network of trade accounts, and each of its systems knew those accounts differently. The CRM held a trading name entered in a hurry by a salesperson. The ERP held the registered legal entity used for delivery. Finance held its own spelling of the name and a billing address that had not been updated since the account opened. Each system had been right on the day someone typed it in, and each had drifted since. Ask a simple question, such as how much a given account was worth, and the answer depended on which screen you looked at.
The group had already tried the tempting shortcuts. Someone had picked one system as the winner and copied its values everywhere, which overwrote a correct phone number in one system with a stale one from another. Someone else had tried matching accounts by name, which quietly fused two unrelated businesses that happened to trade under similar names. Both attempts made the drift worse rather than better, and both were quietly abandoned.
What we built
The problem was never that the data was bad. It was that there had never been one place that decided who a given customer actually was, so we built that place in the data platform rather than inside any one operating system.
Matching started from the strongest identifiers available, such as a registered business number or a billing account, and fell back to weaker signals only under rules the business could inspect and approve. For every attribute, we agreed survivorship rules with the business: the most recently verified address won, the legal name came from the system that issued invoices, contact details came from the system that took the calls. No single system had to be right about everything, because each field’s winner was chosen deliberately rather than inherited by accident.
Diagram: a customer record in the CRM and a customer record in the ERP both connect to a match and survivorship engine inside the data platform. The engine applies matching rules to decide which system wins each field, producing one golden record. Agreed values sync back to both source systems, so the CRM and ERP end up in agreement, and the golden record feeds business intelligence reporting.
Records for the same account arrived from every system, matched on the agreed keys, and resolved field by field into one golden record in the platform. That record then synced back out, so the CRM, the ERP and finance all read the same name, address and history because they were all reading from the same resolved record.
The engineering here was the easy part. Agreeing which system won which field was a set of business decisions, not a technical one, and getting the sales, finance and operations teams to settle those calls and stand behind them took longer than building the pipeline that enforced them.
The outcome
Revenue, exposure and account history stopped depending on which screen someone had open. When someone asked what an account was worth, there was one answer, and it was the same answer in the CRM, the ERP and finance. The rules the business agreed are still the ones the platform enforces, and the client’s own data team owns the survivorship rules going forward.