Finance counts 41,000 customers. Sales counts 38,000. Nobody can account for the gap, and when somebody finally exports both lists and lines them up, the same company turns up four times: once as Ltd, once as Limited, once with a trailing space nobody can see, and once spelled the way a salesperson typed it at a conference in 2019.
Master data management is the work of fixing that and then keeping it fixed. Master data is the set of core business entities that show up everywhere: customers, products, suppliers, employees, sites, cost centres. MDM is the practice of agreeing one definition and one authoritative record for each of them, putting a name against that record, and holding the line while a dozen systems quietly pull it apart again.
We build data foundations for clients at Shipshape Data, and master data is where a surprising number of AI projects run aground. Not on the modelling. On the fact that nobody in the room could say with confidence how many customers the business actually had. This guide covers what master data is, how a golden record gets built, the four ways MDM gets implemented, why matching records is harder than it looks, and what all of it changes once AI sits on top.
Why the same customer exists five times
Nobody sets out to fragment their own data. It accumulates, one reasonable decision at a time. The sales team buys a CRM because the old one was slow. Finance keeps its own customer list because the CRM does not hold the fields an accountant needs. An acquisition arrives with a complete second set of records for companies you were already selling to. Somebody in operations builds a spreadsheet as a stopgap in 2021 and four years later it is load-bearing.
Each of those decisions made sense on the day. Together they produce a business where the answer to a simple question depends on who you ask.
Every system thinks it is in charge
The deeper issue is that most systems are built on the assumption that they own the record. Your CRM believes it holds the customer. So does your billing platform, your support desk and your ERP. None of them is wrong exactly, they each hold a version, and each version is shaped by what that particular system needed to know. Sales cares about the account. Finance cares about the legal entity that pays the invoice. Support cares about the site where the engineer turns up. Three genuinely different things wearing the same word, and calling all of them "the customer" is how the confusion starts.
Left alone, the versions drift. An address gets updated in one place and not the others. A company rebrands and three systems catch it while two do not. This is closely related to how data silos form, though it is a distinct problem: silos are about data being unreachable, master data is about the same entity being described differently everywhere you can reach.
The cost lands on somebody else's desk
The people who create the fragmentation are rarely the people who pay for it. Finance spends the last week of every month reconciling. Marketing pays to post the same brochure to one company three times. A salesperson walks into a meeting unaware that the account is in dispute with support, because the two systems do not agree on which record is which.
Ask three systems how many customers you have and you get three numbers. The gap between them is not a rounding error, it is the cost of never having decided who owns the answer.
What counts as master data
Not everything needs this treatment, and treating everything as master data is a reliable way to stall the whole programme. It helps to separate three kinds of data that behave very differently.
Master, transactional and reference
Master data describes the things your business deals with. A customer. A product. A supplier. It changes slowly, it gets referenced by enormous numbers of transactions, and it exists in more than one system. That last point is what makes it a problem worth solving.
Transactional data records events. An order, a payment, a support ticket, a shipment. There is a lot of it, it is written once and rarely edited, and it points at master data rather than duplicating it. You do not run MDM on transactions. You run it on the things transactions refer to.
Reference data is the smaller supporting vocabulary: country codes, currencies, units of measure, your own status values. It causes its own particular headaches, usually when two systems use the same code to mean different things, or when somebody adds a status value in one place and the reports downstream silently stop balancing.
A practical test
When a client asks whether something should be treated as master data, we ask three questions. Is it referred to by lots of transactions? Does it change slowly? Does it exist in more than one system? Three yeses and it belongs in scope. One yes and it almost certainly does not, whatever anyone's instinct says.
Start narrow. A programme that begins with customer and product, done properly, tends to succeed. A programme that begins with a plan to master eleven domains at once tends to still be in design workshops a year later.
The golden record, and why it is harder than it sounds
The golden record is the single trusted version of an entity, assembled from every system that holds a piece of it. One customer, one record, everything downstream agreeing on what it says. The phrase makes it sound like a filing exercise. It is not, because building one forces you to answer a question the business has usually avoided: when two systems disagree, which one is right?
Deciding which value wins
The rules that settle this are called survivorship rules, and writing them is where the real work sits. They are decided field by field rather than record by record, because different systems are trustworthy about different things. Your billing platform probably holds the most reliable registered address, since invoices bounce when it is wrong and somebody fixes it fast. Your CRM probably holds the best phone number, because a salesperson rang it last week. The ERP holds the credit terms. Nobody's system is authoritative for everything, and pretending otherwise produces a golden record that is confidently wrong in a handful of fields.
Some rules are simpler. Most recently updated wins. Most complete wins. A named system always wins for a named field. All are defensible and all are wrong sometimes, which is why the rules need an owner who can adjudicate what they do not cover.
The record nobody wants to own
Here is the part that sinks programmes. Survivorship rules are a business decision the technical team cannot make on its own, and the moment you ask "whose version of the customer address is the real one" you are asking two departments to agree that one of them has been maintaining a worse copy. That conversation needs somebody senior enough to close it. Without that, the rules get deferred, the build stalls, and the project quietly becomes a data warehouse with ambitions.
Four ways to actually implement MDM
There is more than one shape this can take, and the right one depends on how much control you have over the source systems and how much disruption the business will tolerate. Most vendors will present their preferred style as the mature choice. Treat that with some suspicion.
Registry
The registry style leaves every source system exactly where it is and builds an index on top. The hub stores the identifiers and the matching logic, works out that customer 4471 in the CRM and account 90233 in billing are the same company, and can assemble a golden record on request without ever writing back. It is the least invasive option and by far the quickest to stand up. The trade is that the underlying systems stay messy. You have built a very good map of the duplication rather than removing it.
Consolidation
Consolidation copies master data out of the sources into a central hub, cleans and merges it there, and uses the result for reporting and analytics. The sources keep operating unchanged. It is a common first move because it delivers a trustworthy customer list without asking anyone to change how they work. It does nothing for the operational problem, though. The salesperson is still looking at the duplicate.
Centralised authoring
In a centralised model the hub becomes the place master data is created and edited, and it pushes changes out to the systems that consume it. This is the version that genuinely fixes the problem, and it is also the one that asks the most of everyone, because it changes daily habits across several teams and usually needs integration work in systems that were never designed to take an external feed. Done well it ends the argument permanently. Done under-resourced it produces a hub that half the business bypasses.
Coexistence
Coexistence sits in the middle. Data is still authored in the source systems, but changes flow into the hub, get mastered there, and flow back out so the sources are corrected. Nobody has to abandon the tool they know, and the records still converge. It is the most common landing spot in practice, and it is also the most demanding to run, because bidirectional sync between systems that update at different speeds creates conflicts that somebody has to resolve. If you want to compare what the platforms in this space actually do, our review of master data governance solutions goes tool by tool.
Matching: the part everyone underestimates
Every style above rests on one capability: deciding whether two records describe the same thing. This sounds mechanical and is not.
Deterministic matching compares fields exactly, or nearly exactly. Same company registration number, same email, same postcode and surname. Where you have a reliable identifier it is fast, explainable and correct, and you should use it. The catch is that reliable identifiers are rarer than anyone expects, because the field exists in the schema and is empty in a third of the rows.
Probabilistic matching scores similarity across several fields and merges above a threshold. It copes with the abbreviations, the typos, the trailing whitespace and the person who entered "Acme Holdings" where another system has "ACME Hldgs Ltd". It also introduces a dial that somebody has to set, and setting it is a genuine trade-off rather than an optimisation.
False merges are worse than false splits
Turn the threshold up and you get false splits: the same customer surviving as two records, which is the problem you started with, only now with a project behind it. Turn it down and you get false merges, two genuinely different companies collapsed into one. Both are errors. They are not equally bad.
A false split is embarrassing and easy to correct. A false merge blends two companies' contacts, orders and credit history into a single record, and unpicking it afterwards is genuinely difficult, because you have thrown away the information that told you which row came from where. Anyone who has tried to reverse one at scale learns to hold the threshold conservative and route the uncertain cases to a person. Which means budgeting for that person. A stewardship queue with nobody working it is just a list of problems with a nicer interface.
Matching quality depends on the inputs, so an engine pointed at fields that were never validated on entry will underperform no matter how good the algorithm is. That makes basic data quality work a prerequisite rather than a parallel workstream.
Governance is what stops it decaying
MDM projects have a characteristic failure mode. The clean-up succeeds, the golden records get built, everyone is pleased, and eighteen months later the duplicates are back. Nothing went wrong technically. What went wrong is that the project ended and no one inherited it.
The fix is unglamorous and mostly about people. Someone owns each master data domain, with the authority to settle definition disputes rather than escalate them into a committee. Stewards handle the day-to-day: working the match queue, approving new records, rejecting the ones that do not meet standard. Definitions get written down somewhere findable, because a customer definition that lives in one person's head leaves when they do.
Then the rules get enforced where data is created, not audited after the fact. A required field that is genuinely required. A dropdown where free text invites five spellings. A duplicate check that runs when a salesperson creates an account, not in a monthly report. This is the same discipline that data governance applies more broadly, and MDM is where governance stops being paperwork and starts being visibly worth it. Tracing where a mastered value came from, through data lineage, is what answers the inevitable question of why the hub disagrees with the system somebody is looking at.
What changes when AI sits on top
All of this mattered before anyone put a model on it. It matters more now, and in a way that catches teams out.
Ask an AI assistant how much you sell to Acme and it has to know what Acme is. If your data holds four Acme records, the honest answers are four different numbers, and what you get instead is one number, delivered fluently, with no indication that it covers a quarter of the relationship. A person looking at a report notices the total seems low and goes digging. A language model does not. It answers the question it was asked against the records it was given, and the confidence of the response is unrelated to whether the entity resolution underneath was correct.
This is why master data tends to surface early in AI work, often as a surprise. A retrieval system pulling context about a supplier needs to pull all of it, not the two-thirds sitting under one of three IDs. And any model trained on entity-level features inherits the duplication as signal: a customer split across three records looks like three smaller customers, which quietly distorts segmentation and churn prediction in ways that are difficult to detect from the output.
None of this requires finishing a multi-year MDM programme before touching AI. It does mean knowing which entities your AI use case depends on, and being honest about whether those are mastered yet.
Where to start
Pick one domain, and pick the one causing visible pain rather than the one that looks tidiest to model. Usually that is customer, occasionally product, and if a specific reconciliation is eating somebody's week every month then that is your answer already.
Profile what you have before designing anything: how many records, how much overlap, how bad the duplication really is. That number is almost always worse than the estimate, and having it in hand turns a governance conversation from opinion into arithmetic. Then agree the definition, write the survivorship rules with the business in the room, choose the lightest implementation style that solves the actual problem, and name the owner before you build rather than after.
Master data is the least exciting part of a data foundation and one of the most load-bearing. If you are weighing up an MDM programme, or you have AI plans that assume a single view of the customer you are not sure you have, talk to us. We would rather help you scope it honestly now than watch a model confidently report on a quarter of a customer.