Skip to main content

Master Data Management (MDM)

Master Data Management (MDM) is the set of organizational, process and technical measures that keep a company's master data — customers, suppliers, items, accounts, employees — consistent and quality-assured across every system that touches it. It is the least glamorous discipline in enterprise software and one of the highest-leverage, because almost every downstream failure traces back to a record that was wrong in two places.

What counts as master data

Master data describes the entities a business transacts with or about, and it persists: a customer exists before and after any given order. Transaction data — orders, invoices, postings — records events and references master data. The distinction matters because the two have different lifecycles and different failure modes. A wrong invoice is one wrong document; a wrong item master is every document that references it, forever.

The usual domains are customer, vendor, item or material, chart of accounts, and employee. Manufacturers add bills of materials and routings; distributors add pricing and product hierarchies; project businesses add project and resource structures.

The golden record and how it is built

MDM's core artifact is the golden record: one authoritative version of each object that other systems reference. Building it involves data modeling (what fields exist, which are mandatory), duplicate detection (fuzzy matching on names and addresses), validation rules, survivorship logic (which source wins per field), approval workflow, and an audit trail of changes.

The technical work is well understood. What fails is governance: nobody is accountable for approving a new vendor, so sales creates one to get an order through, and the duplicate that results is the sixth record for a company that appears under six spellings. A single source of truth is a governance outcome that tooling supports, not a product you install.

What it costs when it is missing

Duplicate customers split credit limits and hide true exposure. Inconsistent part numbers produce double ordering and wrong stock valuation. Stale vendor banking details are a payment-fraud vector. Reporting becomes an argument about whose numbers are right rather than a discussion of what they mean.

The same problem now bites in a newer place: AI features in ERP — forecasting, document coding, anomaly detection — read master data as ground truth. Poor master data does not make them fail visibly. It makes them confidently wrong, which takes longer to notice.

Where it sits technically

Three patterns are common. The ERP-as-master approach makes the ERP authoritative and pushes changes outward — simplest, and adequate for most midsize companies. The registry approach leaves records in their source systems and maintains a cross-reference index. The central hub approach holds the golden record in dedicated MDM software that feeds everything else, including the ERP.

All three depend on the integration layer working reliably, which is why MDM discussions quickly become integration platform discussions, and why clean master data upstream is the precondition for trustworthy data warehouse and analytics output downstream.

Related topics

Frequently asked questions

Do we need a dedicated MDM tool?

Below roughly three systems holding overlapping records, usually not — the ERP can be the master and integrations can push from it. Dedicated tooling starts earning its keep when several systems legitimately create records, when survivorship rules get complicated, or when data stewards need a workflow rather than a spreadsheet. Buying the tool first and defining ownership later is the standard way to end up with expensive shelfware.

What is a golden record exactly?

The authoritative version of one master-data object, assembled from the best available field values across sources according to explicit survivorship rules. It is not necessarily any single source record: the address might come from the ERP, the industry code from the CRM, the tax ID from the billing system. What makes it golden is that the rules are written down and applied consistently.

Who should own master data?

A business function, not IT. The people who suffer from a wrong customer record are the people who should approve changes to it — typically finance for vendors and customers, engineering or operations for items. IT owns the mechanism; the business owns the content. Projects that invert this produce technically clean data that describes the business inaccurately.

How does MDM relate to an ERP migration?

It is the part of the migration that determines whether the new system starts clean or inherits the old mess. Deduplication and standardization are far cheaper before load than after, and a migration is the one moment when the business will tolerate the disruption of cleanup. Skipping it to hit a go-live date is a decision that gets paid for later, with interest.