What Is MDM? Master Data Management Explained
MDM (Master Data Management) is the set of processes, rules and technology that keeps a company's CRM, ERP and other systems working from consistent data about customers, products, suppliers and other key objects. Its result is a trusted "golden" record of each object, linked to the matching records in every system.
What is master data?
Master data is the set of reference records about the business objects that every operation points to: customers, products, suppliers, warehouses, employees and financial hierarchies. It answers "who" and "what", while transactional data records the event: who bought what, when and for how much.
| Data type | Examples | What an error causes |
|---|---|---|
| Master data: business objects | Counterparty, product, warehouse, department | The error spreads to every operation and report that uses the object |
| Transactional data: events | Order, invoice, shipment, payment | Usually affects one operation |
| Reference values: standard lists | Currencies, countries, units of measure | Data is hard to compare across systems |
That is why one wrong record can affect more than one wrong transaction. When a customer exists twice, their deal history, receivables and sales volume are split, and the account manager and the finance team see different numbers for the same company.
What is a golden record? A counterparty example
A golden record is the agreed version of an object, assembled from several sources under approved rules. It doesn't have to copy any existing record: each attribute can come from the source the company trusts most for that field.
A hypothetical example. One company appears differently in three systems:
| Attribute | What the systems hold | Golden record |
|---|---|---|
| Name | CRM: "Agrozakhid"; accounting: Agro-Zakhid LLC; Excel: "Agro Zakhid" | Agro-Zakhid LLC (from accounting) |
| EDRPOU code | CRM and Excel: empty; accounting: present | Code from accounting |
| Legal address | CRM: old; accounting: current; Excel: empty | Address from accounting |
| Contact person | CRM: current; accounting: empty; Excel: old | Contact from CRM |
The selection rules here are simple: legal details come from accounting and contacts from CRM. In a real project they are agreed field by field, and disputed cases go to a data steward, the person who decides whether two records really are one company. Source records don't disappear: they keep their local codes and link to a shared MDM identifier.
Why a company registration code is not always enough
For Ukrainian legal entities, EDRPOU, the company registration code, is the natural matching key. Still, matching rules can't rely on it alone, because there are exceptions.
- Sole proprietors. They have no EDRPOU code and are identified by a 10-digit individual taxpayer number. That number is personal data, so the field needs its own access rights and shouldn't appear in every report.
- Separate divisions. A branch may have its own code or be identified through the legal entity's code and an internal division number. Decide up front whether it is a separate object or part of the parent record.
- Multiple sites of one company. In distribution, one legal entity can have many delivery addresses. The code is the same, but for logistics they are different objects.
- A valid format doesn't mean a valid code. EDRPOU has eight digits, the last being a check digit. This catches typos but doesn't show that the company exists and is active. For that you need a check against an external registry, for example through a YouControl and CRM integration.
- Records without a code, and non-residents. Old files and foreign counterparties have to be matched on normalized name, address, phone or the local tax number, which means fuzzy matching with human review.
Errors are costly here: wrongly merging two companies is harder to fix than a missed duplicate. So in Progresia projects we first test matching rules in a pilot and automate only reliable matches. Everything else goes to the steward's queue.
Four MDM styles: where the master record lives
The MDM style determines where the golden record is stored and whether corrections go back to operational systems. The four common styles differ in exactly this, although vendors draw the boundaries slightly differently.
| Style | How it works | When it fits, and limits |
|---|---|---|
| Registry | Stores key mappings between systems and leaves sources unchanged | Quickly links data for reporting and search, but source errors remain |
| Consolidation | Copies data to a central store, cleans it and builds a master for analytics | The main goal is reporting, but operational systems receive no corrections |
| Coexistence | Builds the master centrally and syncs it back to sources | CRM and ERP need corrected data, so exchange directions and conflict resolution must be agreed |
| Centralized | Records are created and changed only in MDM, and other systems subscribe to it | The strictest control over a data domain, but also the biggest process change for the business |
You don't have to choose a style once and for all. A company can use coexistence for counterparties and a registry for locations, or start with a lighter style and move to a heavier one later. To see how technology maps to these styles, read MDM on Microsoft: Dataverse, Fabric, Purview or a dedicated platform.
How MDM differs from CRM, ERP and a data warehouse
MDM replaces none of these systems. Each manages data for its own purpose, while MDM makes sure the objects they share stay aligned.
| System | Its job | What it doesn't do in place of MDM |
|---|---|---|
| CRM | Sales, service, customer work | Doesn't reconcile its customers with records in ERP or Excel |
| ERP / accounting | Finance, warehouse, production | Maintains its own master files, however good they are |
| Data warehouse and BI | Analytics and reporting | Shows discrepancies but doesn't decide which value is right |
| Data catalog | Describes what data exists and where | Doesn't build golden records by itself |
| One-off deduplication | Removes existing duplicates | Doesn't stop new duplicates appearing tomorrow |
When you need MDM, and when you don't
A separate MDM layer pays off when shared objects live in at least two systems and discrepancies already cost money or time.
- Reports don't match. Sales and finance show different numbers for one customer because they group different records.
- Reconciliation has become a job. Someone regularly matches master files by hand in Excel.
- One product has several codes. ERP, the website and suppliers use their own item codes with no reliable mapping.
- A new source has appeared. A merger, a new legal entity or an online store has added another database with its own codes.
- You are planning a migration or AI. Moving poor data or connecting assistants to it multiplies existing problems.
MDM is probably unnecessary in these cases:
- You effectively have one system. If duplicates exist only in one CRM, start with the built-in tools. In Dataverse those are duplicate detection rules and record merging for accounts, contacts and leads. We cover database completeness in our article on CRM data quality.
- Master files are few and rarely change. A data owner and a written procedure will do.
- Nobody can make the decisions. Technology won't work without data owners and stewards. Appoint people first.
Why MDM matters if you are planning AI
An AI assistant answers from the data it can access. If a customer exists in three records, the answer to "how much did they buy this year" depends on which record it finds. In February 2025, Gartner predicted that through 2026 organizations will abandon 60% of AI projects unsupported by AI-ready data. The same release says 63% of organizations either lack the right data management practices for AI or are unsure whether they have them.
This is a forecast, not a measured outcome. MDM covers only part of the task: consistent master data. Good answers also require connected sources and correctly configured access, so see also our article on Copilot security and confidential data.
Where to start: three practical steps
Pick the one domain where discrepancies cost the most
This is usually counterparties or products. Start with all master data at once and the project will drag on before it shows any result.
Measure the problem
How many records each system holds, what share lacks key fields, how many likely duplicates there are. These numbers become the baseline to compare against after the pilot.
Appoint a data owner and test the rules in a pilot
Someone has to decide which value is right. Only then is it worth scaling to new domains.
Progresia goes through this path with clients during MDM implementation on Microsoft: an audit of one domain, matching rules, a pilot on real data and, based on the audit, an honest answer on whether you need a separate MDM layer or better rules and integrations will do.
Frequently asked questions
What is MDM in simple terms?
It is a way to make all of a company's systems hold the same facts about a customer, product or supplier. MDM finds records of the same object, builds a trusted version and keeps it current under agreed rules.
How is Master Data Management different from Mobile Device Management?
They are different fields that share an abbreviation. Master Data Management governs business data records. Mobile Device Management governs corporate devices: the settings, apps and security of phones and laptops.
What is a golden record?
It is the agreed master version of an object, built from records in different systems. Each field comes from the source most reliable for it under approved rules, and a data steward resolves disputed cases.
Does MDM replace CRM or ERP?
No. CRM and ERP still run sales, finance and warehousing. MDM links their records of shared objects and manages master values. Whether corrections flow back into those systems depends on the chosen style.
Who owns master data in a company?
A business data owner sets the rules for their domain, such as a commercial director for customers. A data steward handles disputed matches day to day. IT is responsible for the platform and integrations, not for which value is right.