Table of Contents
The Essentials in Brief
Master data differs from transactional data in that it rarely changes yet is needed everywhere: a supplier’s name, for instance, not the individual order placed with them. Master Data Management brings this data together in one leading source, the so-called golden record, and distributes it to every connected system.What Counts as Master Data?
Classic master data domains include customer data, supplier data, employee data, location data, and product data. They differ from transactional data such as orders or invoices in that they form the stable reference framework those transactions point to. An order references a customer; if that customer’s address changes only in the CRM and not in the ERP, contradictions appear that only surface at the next delivery or invoice. The more systems a company runs, the more such reference points exist. Every discrepancy becomes more expensive as a result, because it propagates across departments before anyone notices.How Does Master Data Maintenance Work in Practice?
MDM systems consolidate data from different sources, detect duplicate records through matching rules, and merge conflicting records into a golden record. Governance rules define which system takes the lead in a conflict, for example that address changes are maintained exclusively in the CRM from now on and distributed from there. They also define who owns a record across its entire lifecycle, from creation to archiving. How that kind of consolidation works in detail is covered in the article on the Golden Record.
The governance rules themselves matter more than the software. An MDM system can detect duplicates and flag conflicts, but in the end a person has to decide which department is right when in doubt. Without that decision, open conflicts pile up in the system while data quality does not actually improve.
What Are the Advantages of an MDM System?
The immediate benefit usually shows up first in reporting: once customer data from CRM, ERP, and the support system no longer needs manual reconciliation, reports become more reliable and available faster. Well-founded decisions then rest on a data foundation that is the same across the entire company. A second effect concerns compliance: during audits or regulatory filings, companies can show exactly which data changed, when, and by whom. The article on Data Governance explains how that traceability gets organizationally secured. A third, often underrated effect concerns mergers and acquisitions. When two companies with separate customer and supplier records combine, master data matching largely determines how quickly the new organization really works as one company.Single-Domain or Multi-Domain MDM?
Single-domain MDM focuses on one type of data, usually customer or product data, and tends to roll out relatively fast. Multi-domain MDM manages several domains at once, such as customers, suppliers, and locations, through a shared data model. The advantage lies in consistent relationships between domains, for example when a supplier also acts as a customer. The downside: multi-domain projects are more complex to implement and need clear prioritization from the start on which domain goes live first.Single-Domain vs. Multi-Domain Compared
| Criterion | Single-Domain MDM | Multi-Domain MDM |
|---|---|---|
| Scope | One data type, usually customers or products | Several domains through a shared model |
| Time to value | Shorter, often three to six months | Longer, depending on number of domains |
| Strength | Faster initial payoff, lower risk | Consistent relationships across domains |
| Common pitfall | Solves only part of the problem | Launching all domains at once instead of prioritizing |
Four Implementation Styles: Where Master Data Is Actually Maintained
Whether master data management works day to day depends less on the tool than on an architectural decision. Where is a record created and changed, and where does it flow afterwards? Industry literature and analyst reports describe four styles for this. They differ mainly in how far the MDM reaches into the maintenance processes of the source systems.

| Style | Where data is maintained | Role of the MDM | Typical use |
|---|---|---|---|
| Registry | In the source systems | Links duplicates via a central index, no write-back | Quick overview while source systems stay unchanged |
| Consolidation | In the source systems | Holds a cleansed copy for analysis | Reporting and BI, often the first expansion step |
| Coexistence | Shared between MDM and source systems | Holds the golden record and distributes it back | Grown landscapes in which several systems keep maintaining data |
| Centralized | Only in the MDM | System of record, source systems receive the data | High governance demands, for example in regulated industries |
Many companies start with consolidation. It leaves the source systems untouched and still delivers clean reporting. What it does not deliver is the operational benefit, meaning fewer duplicates when new customers or suppliers are created. That only comes with coexistence or centralized maintenance. It is therefore worth fixing the target style before the project starts: a consolidation approach can later grow into coexistence, provided the data model is designed for write-back from day one.
Measuring Data Quality Instead of Just Claiming It
Without metrics, the benefit of MDM stays abstract. A few, consistently tracked figures prove their worth in practice: the duplicate rate before and after consolidation, the match rate achieved by automated matching rules, the share of mandatory fields fully populated per domain, and the time between a data change and its distribution to every connected system. These figures can be captured as a baseline before the project starts and rechecked quarterly, rather than relying on a single one-off success story. All of it serves one goal: a single source of truth that every connected system can rely on.If you exchange master data with suppliers or customers, ISO 8000-110:2021 provides a solid framework. The standard specifies how exchanged master data is checked against an agreed data specification. Quality becomes verifiable instead of a matter of negotiation. Which metrics work beyond MDM across the entire data landscape is covered in the article on data quality in the enterprise.
Maturity: Where Does Your Company Stand in Master Data Management?
Gartner describes the development of master data management in five levels, from first recognizing the problem to continuous optimization. According to the analysts, most large organizations are at Level 2 and working toward Level 3 (Gartner on master data management). In practice this usually means that individual domains already run through an MDM, while owners and leading systems have not yet been defined for every data type.

Four questions are enough for a first assessment:
- Is it documented for every master data domain which system leads?
- Is there a named person per domain who decides conflicts?
- Are duplicate rate and completeness measured regularly or only at project start?
- Are new records checked against existing data at the point of entry?
If the answer to the first two questions is no, the work should start with the organization, not with software selection. The DAMA-DMBOK offers a methodical framework for this and treats reference and master data as a knowledge area of its own within data management.
Selection Criteria and Typical Cost
Selecting a system comes down less to a feature list than to how well the software fits the existing landscape of ERP systems, CRM and PIM. Key criteria: does the system support matching rules that can be adjusted without custom code? How transparent are change logs for audits? And how flexible is the data model when a new domain needs to be added? If artificial intelligence proposes matches, can those proposals be traced and approved by people? An often-overlooked question is who inside the company maintains the governance rules once the project team has moved on. A system that turns every rule change into an IT ticket rarely stays current in practice. MDM platforms that let business departments adjust simple rules themselves lower that barrier noticeably.What does an MDM project cost?
The range is wide, because effort and data quality vary more here than with other system categories. Smaller single-domain projects with a clean data foundation often go live in three to six months. Multi-domain projects in complex, grown corporate structures typically take considerably longer, mainly due to the organizational alignment needed across business units.Common Mistakes During Implementation
The most frequent mistake is leaving MDM to the IT department alone. Without a clearly defined decision on which department has the final say when data conflicts arise, governance rules stay theoretical. A second mistake is trying to roll out every domain at once instead of starting with the domain causing the most pain. Third, ongoing maintenance after go-live is often underestimated: without a dedicated data steward continuously resolving new conflicts, data quality degrades again, as described in Data Steward: Role, Responsibilities, and Skills.MDM in Relation to PIM
MDM and PIM overlap on product data but cover different needs. A PIM system specializes in marketing product data: multilingual, with sales copy and channel-specific exports. MDM additionally covers customer, supplier, and location data, and focuses on consistency rather than marketing. Many companies run both together: PIM for go-to-market, MDM as the overarching consolidation layer. The exact boundaries, and which system typically comes first, are explained in PIM vs. MDM: Key Differences Explained.Practical Example: A Retail Company After a Merger
After two retail companies merge, it is common for two CRM and two ERP systems to keep running in parallel, because an immediate technical merger would be too risky. During this phase, an MDM system consolidates both customer databases, detects duplicates by name, address, and tax ID, and ensures that sales and finance work from the same customer list. Skip that intermediate step, and duplicate invoices to the same customer through two different legal entities become a real risk, generating complaints and rework. Experience shows that the biggest effect comes later. It arrives once governance rules take hold and the system checks new records at the point of entry, so duplicates no longer appear.Conclusion: Start With One Domain and Settle the Rules First
Master data management pays off once several systems maintain the same master data and contradictions can no longer be resolved by hand. The biggest lever is rarely the matching algorithm. What matters are the decisions made beforehand: which implementation style, which leading system and who decides in a conflict. A good starting point is the domain that causes the most friction day to day, together with a baseline for the key metrics.
VIA/MDM shows how Master Data Management Software brings customer, supplier and product data together in one shared model. How analysts assess the market is summarized in the article on the Gartner Magic Quadrant.
Frequently Asked Questions About Master Data Management
Master Data Management refers to the central management of business-critical master data, such as customer, supplier, location, and product data, across every system a company operates.
Master data such as a customer's name rarely changes and forms the stable reference framework. Transactional data such as an order documents an individual business event and references that master data.
A golden record is the consolidated data record treated as correct, created by merging conflicting information from multiple source systems according to fixed rules.
Four styles are common: registry, consolidation, coexistence and centralized maintenance. They differ in where master data is maintained and whether the MDM distributes the golden record back to the source systems.
If product data consistency for marketing and sales is all that is needed, PIM is often enough. Once customer, supplier, or location data also needs to stay consistent across multiple systems, MDM adds that as an overarching layer.
A focused single-domain project with a clean data foundation often goes live in three to six months. Multi-domain projects in complex system landscapes typically take considerably longer.



