Guide · Master data

Master data management without an MDM platform

MDM has a price tag that starts in six figures and a reputation for multi-year programmes, which is why most mid-market businesses conclude it is not for them and carry on reconciling three customer lists by hand. Nearly all of the value is available for the cost of three decisions and an argument.

8 minute read For: the operations lead, the analyst Reviewed September 2026

The short answer

Master data is the set of entities several systems share — customers, products, suppliers, sites, employees. Managing it means deciding which system is authoritative for each attribute, how conflicts are resolved, and who resolves them. Write those three things down for your two most contested entities and you will have captured most of what an MDM platform would give you, without the platform.

Three panels — CRM, finance and support — with arrows converging on one panel headed golden record, whose four rows each carry a grey tag naming the system that field is taken from. — The golden record is not a place. It is an agreement about which system wins for which field. Illustration

What master data is, and what it is not

Master data is the nouns your business shares: customers, products, suppliers, sites, employees, cost centres. It is small, slow-moving, and joined to by everything. Transactional data is not master data, and the distinction matters because the fixes are different — an order that is wrong is an incident, a customer record that is wrong is a structural problem that produces incidents indefinitely.

Sitting alongside it is reference data: the code lists everything joins to. Country codes, order status values, product categories. Unglamorous, and behind a startling share of reports that disagree, because one system says "Cancelled", another "CANCELLED", and a third "Void".

The three decisions

1. Which system is authoritative, per attribute

Not per entity — per attribute. This is the refinement that makes the exercise tractable. The CRM is probably authoritative for a customer's contact details and account manager; the finance system for their legal name, billing address, credit limit and payment terms; the support desk for their entitlement.

Draw the grid: attributes down, systems across, one authoritative mark per row. It looks like a RACI and it works for the same reason — one owner per row, and the arguments surface immediately.

2. How conflicts are resolved

When two systems disagree about an attribute one of them does not own, the answer is usually "the authoritative one wins and the other is corrected". Write it down anyway, because the interesting cases are the ones where the non-authoritative system has better information: the account manager who updated the address in the CRM because the customer told them on the phone, while finance still holds the one on the last invoice.

The rule that survives contact: the authoritative system wins on read, and there is a defined route to get it corrected. If there is no route, people stop correcting it and start keeping their own list, which is how the fourth customer list gets created.

3. Who decides

One named person per entity. Not a committee, and not the person who runs whichever system happens to be authoritative today. This is the data owner for that entity, and if nobody will take it, that is the real finding.

Matching: the part that is genuinely hard

"Acme Ltd", "ACME Limited" and "Acme Ltd." with three account numbers are probably one customer. Probably. The matching is a real technical problem and the tools do it well, but two things are worth knowing before you start.

Merging is destructive and asymmetric. Failing to merge two records that are the same is annoying — you carry a duplicate. Merging two records that are genuinely different is a serious error that can put one customer's data in front of another and is painful to unwind. Set the threshold conservatively and review the borderline pairs by hand. On a first pass, do not auto-merge at all.

Survivorship rules are business policy. When two records merge, which values survive? Most recent? From the authoritative system? Longest string? That last one is a real default in real tools, and it will cheerfully preserve "Acme Limited (DO NOT USE - see new acct)" as the customer name. Decide the rules and write them down.

A month of work that gets you most of the way

Pick the two entities that cause the most pain. For most businesses it is customer and product. Ignore the rest for now.
List where each one lives. Expect four to eight systems including at least one spreadsheet.
Build the attribute grid and get it agreed. Half a day to draft, two weeks of other people's calendars to settle.
Fix the reference lists first. Standardise the status values, category lists and country codes across systems. It is the least interesting task on this page and it usually removes the largest number of report discrepancies.
Count your duplicates. An exact match on the business key, then a fuzzy match on name and postcode, then eyeball the top hundred pairs. Publish the number.
Agree the survivorship rules before you merge anything.

That is roughly a month of part-time effort and it addresses the reconciliation problem for the two entities that generate most of it.

When a platform is genuinely the right answer

There are cases where the manual version does not scale, and it is worth being straight about them:

Hundreds of thousands of customer records with a high rate of new creation, where duplicates form faster than people can review them.
A dozen or more systems needing continuous two-way synchronisation rather than an agreed read order.
A regulated obligation to evidence the derivation of a golden record.
An acquisition programme where a new estate arrives every year or two.

If two or more of those describe you, price the platforms. If none do, the three decisions and the reference-list clean-up will get you further than a procurement exercise, and considerably sooner.

Common questions

What is master data management?

The practice of holding one agreed version of the entities several systems share — customers, products, suppliers, sites — and keeping the copies in step. At mid-market scale it comes down to three decisions: which system is authoritative for each attribute, how conflicts are resolved, and who decides.

Do we need an MDM platform?

Usually not below about a thousand employees. A platform earns its price where duplicates form faster than people can review them, where a dozen systems need continuous two-way synchronisation, where a regulator requires evidence of how a golden record was derived, or where acquisitions bring a new estate every year or two.

What is a golden record?

The single reconciled version of an entity, assembled from the several systems that each hold part of it. Building one is a matching problem and a political problem in roughly equal measure — the matching is solvable with tooling, but agreeing whose version wins when the CRM and the finance system disagree needs a named owner.

What are survivorship rules?

The rules deciding which values survive when two records are merged — most recent, from the authoritative system, longest string, and so on. They are business policy rather than a technical setting. Longest-string is a common tool default and will happily preserve a customer name like 'Acme Limited (DO NOT USE - see new acct)'.

Where the product comes in

The register is where the authoritative decision gets recorded

Lake On Rails is not an MDM platform and does not match or merge records. What it holds is the decision: which dataset is authoritative, who owns it, what the definition is, and what changed when. That is the artefact a matching exercise needs in place before it can be executed, and the one that usually does not exist.

Request a demo See what you get

Forty-five minutes with whoever runs your reporting

We tell you honestly whether this is worth doing at all, and roughly what it would take. If the answer is not yet, you will hear that. "Not for us" is a fine outcome, and a better one than a slow maybe.

Request a demo Is it for us?