What Is Master Data Management (MDM)? Master Data, Golden Records and the 4 Implementation Styles
In short
Master data management (MDM) is the discipline of creating and maintaining a single, trustworthy version of the data that describes a company's core entities: customers, suppliers, products, materials, locations and assets. The goal is that every system in the organization works from the same information, with no duplicates and no competing versions.
There are four implementation styles: registry, consolidation, coexistence and transaction. The first three correct the record after it has already entered a system. The fourth governs it at the moment of capture, which is where the problem actually starts.
A golden record decays for two distinct reasons: capture keeps happening without governance across multiple systems, and many of the checks that made the record trustworthy have an expiry date.
What is master data management (MDM)?
Master data management (MDM) is the discipline of creating and maintaining a single, trustworthy version of the data that describes a company's core entities: customers, suppliers, products, materials, locations and assets. Its purpose is to make sure every system in the organization works from the same information, without duplicates or conflicting versions.
That definition is the easy part. What almost no one explains is that there are four distinct ways to implement it, and the difference between them decides whether the project fixes the problem or merely documents it.
What is master data?
Master data is the information describing the entities your business uses over and over, across several systems at once. A supplier shows up in procurement, in accounts payable, in the ERP and in your tax filings. A material shows up in engineering, in production, in inventory and in the commercial catalog. This information changes rarely, gets read constantly, and when it is wrong the error spreads.
It helps to separate it from the other data types it lives alongside:
Data type | What it records | Example |
Master | The entities of the business | The supplier, the material, the customer |
Transactional | The events of the business | The purchase order, the invoice, the shipment |
Reference | The permitted values | Country codes, currencies, units of measure |
Metadata | Data about the data | Field definitions, lineage, business rules |
A purchase order is transactional data that points to a supplier (master), is denominated in USD (reference) and carries with it the definition of what each field means (metadata). If the supplier is duplicated, so is the order.
The master data domains
The literature usually lists four domains. In the day-to-day operation of an industrial or consumer goods company, there are at least six:
Supplier: tax identity, banking details, contacts, commercial terms
Material: SKU, technical specifications, unit of measure, classification
Customer: tax identity, commercial hierarchy, credit terms
Location: plants, warehouses, distribution centers, points of sale
Asset: equipment, vehicle fleet, spare parts
Employee: identity, org structure, roles and permissions
Each domain has its own owners, its own rules and its own target systems. An MDM that solves only one of them is a project, not a capability.
Why master data management matters
The symptoms of not having it are remarkably consistent, and they surface in different domains.
A duplicated material creates artificial scarcity. The same component exists under two part numbers because two plants created it with different naming conventions. Consolidated inventory shows adequate coverage, but each plant sees only its half and both place emergency orders. The cost is not the data entry error, it is the working capital tied up in the same product counted twice.
An outdated location catalog stops the operation. Tax and logistics systems validate against official catalogs that change over time. A postal code, a product classification code or a vehicle attribute that fell out of sync triggers rejections at the moment documents are issued, not six months later. The catalog of drivers, vehicles and locations is master data, even though almost no organization administers it that way.
A supplier onboarded without screening becomes a compliance problem. When a supplier turns up on a denylist, the documents it issued can lose their validity for whoever received them. The damage is not discovered at onboarding. It is discovered once invoices have been booked and payments executed.
All three cases share the same shape: the error entered at the moment of capture and surfaced much later, in a different system, under a different owner.
How to implement MDM: the phases of a project
With variations by vendor and scope, every MDM project runs through the same stages:
Identify the critical entities. Which data deserves to be governed as master data. Not all of it does.
Define the data model. Which attributes make up each entity, which are mandatory, and how they relate to one another.
Set the governance rules. Who can create, who can modify, who approves, and against what criteria.
Matching and deduplication. Establishing that two separate records describe the same real-world entity.
Build the golden record. The version the organization accepts as true.
Distribution. How that record reaches the systems that consume it.
The question that decides whether the project succeeds is not on this list. It is where step 3 happens.
Types of MDM: the 4 implementation styles
This is the part most guides skip, and the most useful part for making a decision. The industry recognizes four MDM implementation styles, distinguished by where the master record lives and who has the authority to write it.
Registry. The MDM does not store the record. It builds a cross-reference index identifying which records in which systems describe the same entity, and assigns them a global identifier. Source systems remain the authority. It is the fastest and cheapest style to implement, and the one that changes the least. It tells you how many duplicates you have. It does not stop you producing them.
Consolidation. The MDM does store a consolidated version, assembled from source systems through cleansing, matching and merging. That golden record lives in the hub and feeds analytics and reporting. It never goes back to the source systems, which keep operating on their data exactly as it was. This is the most common style in projects that originate in the data team, and it produces the most uncomfortable paradox: the report is clean and the operation is still dirty.
Coexistence. Same as above, except the hub publishes corrections back to the source systems. The master record exists on both sides and synchronizes bidirectionally. It is a genuine step forward, and also where operational complexity appears: if two systems can write the same entity, conflicts have to be resolved permanently. Reltio describes this style as consolidation with loopback features to the sources, which requires those sources to have cleansing capabilities of their own.
Transaction or centralized. The master record is born inside the hub. Users author it there, under the hub's rules, and the hub writes it out to the target systems once approved. The other systems stop being sources and become subscribers. This style offers the most control and demands the most in design, because it means moving a business process, not just a data flow.
Style | Where the record is corrected | What it demands | When it fits |
Registry | Nowhere, it is only identified | Low effort | Initial diagnosis |
Consolidation | Afterwards, in the hub | Moderate effort | Analytics and reporting |
Coexistence | Afterwards, with loopback to source | High and continuous effort | Transition toward stronger governance |
Transaction | Beforehand, at the moment of capture | Process redesign | Critical and regulated entities |
The first three styles correct. The fourth prevents. Most organizations evolve between styles as their data governance matures, and that is reasonable. The problem is settling indefinitely into the second one, convinced that having the golden record on a dashboard is the same as having it in the operation.
What is a golden record, and why does it decay?
A golden record is the version of an entity the organization accepts as true and that every other system should reference. When it is built through consolidation, it is a photograph that starts aging the instant it is taken. For two distinct reasons, and the second one is almost never discussed.
Capture keeps happening without governance. As long as entities are created across twelve systems under twelve different criteria, the hub will be deduplicating whatever the operation produces every week, forever. It is perpetual work by design.
The record's validity has an expiry date. This is the critical point. Many of the checks that make a master record trustworthy are not permanent. A denylist screening is valid on the day it ran, and the list changes afterward. A tax standing that is current today may not be current next quarter. A correct record stops being correct without anyone touching it.
An MDM that only deduplicates has no way of detecting that. No matching algorithm will reveal that a perfectly unique, perfectly clean supplier stopped being trustworthy yesterday. Detecting it requires the MDM to re-run the check and act on the result, and that is no longer a repository capability. It is a process capability.
MDM and business process: governing data at the point of capture
In the market, MDM and business process management are sold separately. You buy an MDM platform for the golden record, you buy a workflow engine or a portal for the approvals, and then you pay an integrator to connect them. The usual result is a middle layer nobody fully controls and that becomes expensive to change.
The alternative is for the engine that governs the record to be the same engine that executes the process producing it. In practice, that means four things.
The process is designed, not coded. The onboarding flow is built visually on BPMN notation: who captures, who reviews, who approves, what happens on rejection. Changing the flow does not require a development cycle.
Validations operate at three levels. Declarative rules for the simple cases, such as a tax identifier format or a conditional mandatory field. Scripts for what will not fit in a rule, such as showing only a given country's banks when the supplier is based there. And external service calls for what lives outside the organization, such as denylist screening.
It is worth separating two kinds of validation that rarely get distinguished. An informational validation flags the record and lets it through, for someone to review later. A blocking validation stops the process. With denylist screening the validation is blocking: if the result is positive, the record does not advance and is never written to the target system. There is no record to clean up later, and no invoice that turns into a liability months down the line.
Capture is assisted by automation. The documents supporting the request are processed to extract their fields automatically, so the user confirms instead of transcribing. A tax certificate or an identity document in PDF fills the form with no manual entry. This matters more than it appears: manual capture is precisely where the duplicates and spelling variants are born that the rest of the industry then tries to repair with fuzzy matching. Removing transcription removes the cause, not the symptom.
The write reaches the target system. Once approved, the record is written directly into the ERP, the commercial system or wherever it belongs, with no technology middleman in between. The record does not sit waiting for someone to replicate it.
There is a less obvious benefit to this model, and it is speed. Validation rules change: official catalogs get updated, regulatory obligations shift, internal policies are adjusted. A model where changing one rule means weeks of development cannot keep up with that pace. When the process is edited visually, the distance between a regulatory change and its reflection in production is measured in days.
Applying MDM to suppliers, materials, customers and other domains
One risk of explaining this model through a single example is that it looks like a solution for one specific team. It is not. The clearest way to see it is to place three different entities side by side and watch what repeats.
Supplier | Material | Customer | |
Who requests it | Procurement | Engineering or product | Sales |
What gets validated | Tax identity, denylists, banking details | Technical spec, classification, unit of measure | Tax identity, credit capacity |
Who approves | Procurement, tax, compliance | Engineering, quality, costing | Sales, credit and collections |
Where it gets written | ERP, supplier module | ERP, materials module | ERP and commercial system |
All four rows change completely from one column to the next. And yet the mechanism operating them is identical in all three cases: a form that surfaces the fields that apply in context, a set of validations that run before the record is allowed to advance, a review and approval path with named owners, an auditable log of every step, and a write to the target system only once the process has finished.
Put differently: what gets built once is the engine. What gets configured per entity is the process running on top of it. Onboarding a new domain does not mean buying another product or standing up another project from scratch, it means designing a different flow on the same foundation.
That is the practical difference between a master data platform and a tool that solves a single domain. The second one forces you to repeat the investment every time the business needs to govern something new.
How to measure an MDM project: KPIs and metrics
Generic objectives are useless for steering a project. These metrics are not:
Time to onboard an entity. From request to record available in the target system.
Share of records requiring rework. How many bounce back to the requester for incomplete or incorrect information.
Validation coverage. Not how many records passed, but what share of the universe went through each rule. A 99% pass rate at 40% coverage means nothing.
Volume processed with full traceability. How many executions carry an auditable log end to end.
Compliance block rate. How many requests were stopped, and for what reason.
Time from a rule change to production. The metric the traditional model never reports, because it never measured it.
MDM and AI-ready data
An agent querying the supplier catalog inherits every duplicate in it. A demand model trained on misclassified materials learns the wrong classification. AI does not fix master data: it amplifies it.
Gartner estimated in February 2025 that through 2026 organizations would abandon 60% of AI projects not supported by data prepared for that use. In the same research, 63% of the organizations surveyed either lacked the data management practices AI requires or were unsure whether they had them.
The relevant point is that clean data and AI-ready data are not the same thing. The latter requires lineage, agreed definitions of business terms and continuous maintenance, not a cleanup exercise ahead of a project launch. A master record governed at the moment of its creation already satisfies a good part of those conditions by construction.
Case study: supplier onboarding from months to minutes
A global food company ran supplier onboarding on email, paper and photocopies. The process took weeks and in some cases up to two months, with no traceability and no systematic screening: a supplier on a denylist could be onboarded without passing any check at all.
Arkon Data implemented the full process on its platform, with dynamic forms, automated denylist screening before a record could advance, approval flows visible to procurement, tax and compliance, and direct writes into the client's Oracle Cloud environment. That direct write removed the dependency on the technology integrator that previously sat in the middle.
Results to date:
Registration time cut from months to minutes, subject to the approvals in the process
More than 18,000 monthly executions with full traceability
7 operating organizations across 4 languages, with 2,800 users
Bulk onboarding of 1,200 suppliers in Brazil against a regulatory deadline the previous global consultancy would not commit to
Teams in marketing, financial planning and master data now consuming the information directly from the platform
Supplier onboarding is where the model was proven at the largest scale. The same architecture runs today across materials, spare parts and finished goods.
Frequently asked questions about master data management
1. What is the difference between MDM and a data warehouse?
A data warehouse stores data so you can analyze it. An MDM defines which version of an entity is correct and distributes it to operational systems. The warehouse answers what happened; the MDM answers who the supplier is.
2. Are MDM and data governance the same thing?
No. Data governance sets policies, roles and accountability across all of an organization's data. MDM is the concrete implementation of that governance over master entities.
3. What is a golden record?
It is the version of an entity that the organization accepts as true and that every other system should use as its reference.
4. How long does an MDM implementation take?
It depends on the style and the scope. A registry can be running in weeks. A centralized authoring model over one critical entity is usually measured in months, because it means redesigning the business process that produces the record.
5. Can you do MDM without replacing the ERP?
Yes. In the centralized authoring style the ERP remains the target system; what changes is that it receives records already validated and approved instead of direct data entry.
6. What is the difference between an MDM and a supplier portal?
A supplier portal solves document collection for one domain. An MDM with a process engine governs any master entity and writes the result into the operational systems. The portal is a use case; the MDM is the capability.
From diagnosis to execution
The question worth answering before choosing a platform is where each master entity is captured today and who actually approves it. The answer almost always involves more teams than the project had accounted for.
At Arkon Data we do not just hand over the platform. Our process engineers work with your teams to map the real onboarding flow for each entity, including the rules that today live only in the head of whoever applies them, and translate it into an executable process. If your organization already has that mapping, we start from there. If it does not, which is the common case, that is the first part of the work.
Let's set up a short conversation, no obligation, to review how your master data is entering the business today.