Think Build Implement Repeat
Data & Scraping

One Version of the Customer, Across Five Systems

Last updated:

The symptom

The same customer exists in the CRM, the accounting system and the operational system, with three slightly different names, two addresses and no way to tell they are the same organisation.

Every cross-system report then requires manual reconciliation, and every automation has to guess.

Four steps that fix most of it

  1. Choose an owner per entity. One system owns customers, one owns products, one owns suppliers. Others read.
  2. Create a stable internal identifier that never changes even when names and addresses do.
  3. Map every other system to it, storing the identifier alongside their own.
  4. Decide who may create a new record, and enforce it. Uncontrolled creation is where duplicates come from.
The stable identifier is the piece people skip. Matching on name and address works until a company rebrands or moves, at which point your history splits in two.

Duplicates need a decision, not just an algorithm

Matching is straightforward. Deciding what happens when two records disagree is not: which address survives, whose history is kept, who is told, and how it is reversed if wrong.

Agree those rules with the business before building anything, and keep the merge reversible.

Products are harder than customers

  • Variants and pack sizes that are the same product to a customer and different to a warehouse
  • Supplier codes that differ from your own
  • Descriptions that change while the product does not
  • Products replaced by successors that must inherit history

Start with customers, where the rules are clearer, and apply what you learn to products afterwards.

Enforce at the point of creation

The cheapest duplicate is the one never created. A creation flow that searches for existing matches before allowing a new record prevents most of the problem permanently.

It also makes the initial clean-up worth doing, because it will not simply regrow within a year.

Keep it proportionate

Full master data management is an enterprise discipline with tooling and governance. For a smaller business, the four steps above plus a monthly duplicate report is enough and is sustainable.

Frequently asked questions

Which system should own the customer record?

Usually the one where customers are first created in the normal course of business, which is often the CRM for prospects and the operational system for active customers. Pick one and make the other read.

How do we clean up existing duplicates?

Fuzzy match, review the middle band by hand, merge with a reversible audit trail, and fix creation at the same time so the problem does not return.

What does this cost?

A matching and mapping exercise with creation controls typically £10,000–£30,000 depending on the number of systems and how messy the starting point is.

Do we need a dedicated MDM tool?

Not at small scale. The discipline matters far more than the tooling, and a tool without agreed ownership rules solves nothing.

Keep reading

Same customer in three systems, three different ways?

Tell us which systems hold customer records. We will suggest the owner, the identifier and how to stop duplicates being created.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

Web ScrapingData Science