Master data: who owns the customer record

The question sounds technical and is not. When the CRM, the finance system and the operational system each hold a customer, the problem is not synchronization — it is that nobody has decided which one is right, and each has a reasonable claim.

Name the authoritative source per entity, not per system

For each significant entity — customer, supplier, product, employee, site, asset — one system is authoritative. Everything else holds a copy, and copies are read-only with respect to the fields the master owns.

This is per entity, not per system. A finance system might be authoritative for a supplier and hold a downstream copy of a customer. That is normal and workable, as long as it is explicit.

Ownership is a business role

Someone in the business owns the definition and the quality of each entity. They decide what constitutes a duplicate, what the mandatory fields are, and what happens when two functions disagree.

IT can build the checks, run the matching and enforce the flow. It cannot decide whether a subsidiary is a separate customer or a location on the parent — and where IT is left to decide, the answer will satisfy nobody and be reopened in a year.

Fix the creation process before cleaning the data

Most duplicates come from a creation flow with no check: two spellings of the same company name, a new record created because searching was slower than adding, an import that matched on nothing.

Cleaning without fixing the cause produces a clean set that degrades immediately. Fix creation first — a search-before-create step, a small number of mandatory fields, and a validation against an external reference where one exists.

Decide what a duplicate actually is

Harder than it sounds and unavoidable. Is a division a separate customer? Are two sites of the same company one record or two? Is a person who is both an employee and a contractor one record?

There is no universally right answer. There is a right answer for your business, and it has to be written down, because every matching rule and every report depends on it.

Handle conflicts with a rule, not a meeting

When the master and a downstream system disagree, something has to resolve it. Common approaches: the master always wins, the most recent change wins, or a person adjudicates for specific fields.

Whichever you choose, apply it consistently and log what was overwritten. Unlogged overwrites produce the situation where a correction disappears overnight and nobody can explain why.

Start narrow

A full master data program is a long project with a poor completion record. Starting with one entity — usually the one causing the most arguments — produces a working pattern in a fraction of the time, and the second entity reuses most of it.

The test for whether it worked: two people in different functions look up the same customer and see the same thing, and both know which system to change if it is wrong.