What is master data (and why the same customer shows up three times)

Search for any customer in your CRM. If they show up two or three times —one record with the trading name, one with the legal name, one with a typo that has been there for years— you have a master data problem, even if nobody in your company uses the term. This article explains what master data is, but its real purpose is a decision that few small and mid-sized companies have ever made explicitly: when two records for the same customer, product or supplier don't match, which record wins, and who gets to decide.

The symptoms arrive before the name does

This problem almost never introduces itself as "we need to manage our master data". It shows up like this: the same supplier exists under three different names and nobody knows how much you buy from them in total. A salesperson calls a company that a colleague already spoke to last week, because each of them has it under a different record. A product has one code in the warehouse and another in the price list, and every so often someone invoices the wrong one.

None of these failures is dramatic on its own. Together, they are the reason simple questions —how much did we invoice this customer last year?— don't have simple answers.

What master data actually is

Master data is the set of records for the things your business talks about every day: customers, products, suppliers, employees; depending on the sector, also projects, case files or policies. It sits apart from transactional data —orders, invoices, movements— which is created and closed daily. An invoice is transactional data; the customer it's issued to is master data.

The distinction matters for a practical reason: everything transactional hangs off the masters. Every order points to a customer record and to product records. So an error in a master record doesn't stay put: it gets copied into every order, every invoice and every report that touches it, for years.

It's worth being clear about what this problem is not. It isn't about connecting systems or getting two applications to agree: even inside a single application you can have three records for the same customer. The problem isn't technical. It's that nobody has decided which record is the right one.

Why duplicates appear on their own

Nobody duplicates a customer on purpose. It happens because creating a new record is faster than checking whether one already exists. Because each department creates it with the details that matter to them: finance with the legal name and tax ID, sales with the name everyone actually uses. Because an old migration brought across whatever was there. Because nobody ever defined which fields are mandatory or how they should be formatted.

A duplicate isn't one person's slip: it's the natural result of not having a rule. Which is why cleaning them up without changing the rule only works for a while. You can spend a week merging records and, a few months later, the list is back where it was, because new entries keep coming in the same way.

The decision: which record wins, and who decides

Merging duplicates is the mechanical part. The hard part is two decisions that come first.

The first is which record is the reference. And it's rarely one record winning outright: the correct billing address may live in one record and the up-to-date contact person in another. The useful rule is defined field by field, not record by record: billing details are owned by whoever invoices; contact details by whoever talks to the customer. Written down that simply, on a single page, it's already more than most companies have.

The second is who decides. One owner per type of master —someone for customers, someone for products— with recognised authority. That doesn't require a committee or a new job title: it requires a name. When two records disagree, that person arbitrates; when someone creates a new entry, their rules apply. Without that name, every conflict gets resolved differently depending on who stumbles into it, or not at all.

A third, smaller decision hangs off those two: the rules for creating records. Which fields are mandatory, in what format, and the habit of searching before creating. That's what stops the work from undoing itself.

What it costs not to decide

This cost never appears in the accounts under its own name. You pay it in fragmented history: a customer of many years looks brand new because their activity is spread across three records. In commercial risk: two people on your team negotiating different terms with the same company without knowing it. In volume discounts calculated wrongly, because the real volume isn't in one place anywhere. And in the reconciliation time someone spends every time a reliable total is needed.

There's one more cost that shows up late: everything you build next sits on top of these records. A new report, an automation, an AI assistant — every one of those projects inherits the masters you have, good or bad. Sorting them out is not a glamorous project, but it's one of the few that raises the value of every project that follows.

Three questions to find out where you stand

1. Pick your best customer and search your systems: how many records do they have?
2. When two records don't match, is there someone with recognised authority to decide which one counts?
3. Are there written rules for new entries —minimum fields, format, search before you create— or does everyone do it their own way?

If the first answer is "more than one" and the other two are "no", the order matters: first the rule and the owner, then the clean-up. The other way round, the clean-up undoes itself. This is exactly the kind of disorder that surfaces early in a data & systems assessment: fixing it doesn't demand a big project, but it does demand a decision that, until now, nobody had made.