Master data sits underneath almost every enterprise transaction. Customer accounts, suppliers, products, locations, units of measure, chart-of-accounts structures and legal entities are reused across ERP, CRM, ecommerce, procurement, warehouse and analytics platforms. When those records are incomplete or inconsistent, the effects spread: orders fail, reports disagree, duplicate suppliers are paid, inventory is misclassified and teams lose confidence in business data.
Master data management (MDM) is the combination of governance, data models, quality controls, stewardship and technology used to create and maintain trusted records across an organisation. It is not simply a database-cleaning project or a software purchase. This guide explains how to establish a workable MDM operating model and when a dedicated platform is justified.
What counts as master data?
| Domain | Examples | Why it matters |
|---|---|---|
| Customer and business partner | Legal name, account hierarchy, tax identifiers, addresses, payment terms | Sales, credit, invoicing, service and compliance |
| Supplier | Supplier ID, bank details, tax status, approved categories, contacts | Procurement, payment controls and supplier risk |
| Product and item | SKU, description, unit, variant, category, dimensions | Pricing, inventory, production, fulfilment and reporting |
| Location | Legal entity, site, warehouse, branch, ship-to and bill-to | Inventory, tax, logistics and financial reporting |
| Financial reference | Chart of accounts, cost centre, department, currency, fiscal calendar | Posting, consolidation, budgeting and management reporting |
Master data is different from transactional data. A customer account is master data; an individual sales order is a transaction. The customer record may be referenced by thousands of orders, which is why changing its identity or structure needs stronger controls than editing a transaction note.
Why master data problems persist
- Decentralised creation: departments create records independently to keep work moving.
- Different definitions: CRM, ERP and analytics teams use different meanings for customer, active product, region or business unit.
- Legacy migration: duplicate and incomplete records move into a new ERP without sufficient cleansing.
- Acquisitions and expansion: acquired companies bring separate identifiers, hierarchies and data standards.
- Unclear accountability: IT is asked to fix quality problems that require commercial or finance decisions.
- Weak change control: a supplier, customer or product can be edited without approval or downstream impact analysis.
Build an MDM operating model before selecting software
1. Assign data owners and stewards
A data owner is accountable for the definition, policy and acceptable quality of a domain. A data steward manages day-to-day standards, reviews exceptions and coordinates remediation. System administrators maintain the technology but should not be expected to make business decisions about customer hierarchies, supplier status or product classification.
For example, finance may own payment terms and legal-entity attributes, procurement may own supplier qualification, product management may own product classification, and sales operations may own CRM segmentation. Assign one accountable owner for each attribute or decision to avoid conflicting approvals.
2. Define the canonical data model
Agree the key entities, required attributes, relationships, identifiers, allowed values and lifecycle states. Document how a global parent account relates to legal entities, branches, delivery locations and contacts. For products, define how SKU, variant, unit of measure, packaging and category relate. A canonical model does not mean every application must store every field; it provides a common language and mapping reference.
3. Set quality rules that can be measured
Rules should be specific and testable. Examples include mandatory legal name and country for a supplier, unique item identifiers within an agreed scope, valid units of measure, approved tax codes, consistent address formats and no active customer without an accountable owner. Define thresholds and exception routes rather than using a vague target such as “clean data”.
4. Establish create, change and retire workflows
Specify who can request a new record, who validates it, who approves sensitive changes, which systems receive the update and how a record is deactivated or merged. Supplier bank-account changes, customer credit details and product substitutions may need stronger controls than descriptive fields.
5. Monitor quality continuously
Measure completeness, uniqueness, validity, consistency, timeliness and referential integrity. Assign an owner and resolution target to each exception type. A one-time cleansing exercise will not prevent new defects unless the process that creates them is changed.
Choose the right architecture: registry, consolidation or centralised hub
There is no single MDM architecture that suits every organisation. The right design depends on how much central control is needed, how many systems create data, and how quickly updates must reach operational applications.
| Pattern | How it works | Best suited to | Main trade-off |
|---|---|---|---|
| Registry | Maintains identifiers and links to records held in source systems | Organisations that need a cross-reference and discovery layer | Source records may remain inconsistent |
| Consolidation | Combines records from multiple systems for matching, cleansing and analytics | Reporting, acquisition integration and quality improvement | Does not automatically govern operational changes at source |
| Centralised hub | Creates or approves trusted master records centrally and distributes them to connected systems | Enterprises requiring strong control over critical domains | More workflow, integration and organisational change |
| Coexistence | Allows source systems to maintain selected data while synchronising governed attributes | Large or federated organisations with legitimate local processes | Ownership and conflict rules require careful design |
MDM technology: when do you need a dedicated platform?
Many organisations can improve data quality using capabilities already present in their ERP, CRM, database, integration and governance tools. A dedicated MDM platform becomes more compelling when there are many source systems, complex hierarchies, high duplicate rates, multiple legal entities, strict approval requirements or a need to distribute governed records across the application estate.
Examples of technology approaches include:
- ERP-native governance: use the ERP’s master data workflows and validation rules where the ERP is the primary authority for the domain.
- CRM or platform-based master records: use a platform such as Dataverse where it is deliberately chosen as the authoritative source for selected entities.
- Dedicated MDM hub: centralise matching, stewardship, approval, survivorship and distribution when multiple operational systems need a shared master.
- Data governance and catalog tools: document definitions, lineage, ownership and classifications. These tools complement MDM but do not necessarily perform operational mastering by themselves.
SAP describes central governance, consolidation, duplicate matching and replication in its Master Data Governance documentation. Microsoft documents an example architecture combining Purview governance with Profisee MDM in its MDM integration guidance. These examples illustrate different product approaches, not a recommendation that every organisation needs either platform.
How to measure master data quality
| Dimension | Example measure | Business consequence |
|---|---|---|
| Completeness | Percentage of required fields populated | Missing information can block orders, onboarding or compliance checks |
| Uniqueness | Duplicate rate by domain and identifier | Duplicate customers, suppliers and products distort reporting and controls |
| Validity | Percentage of values passing defined rules | Invalid tax codes, units or account attributes create downstream errors |
| Consistency | Conflicts across systems for governed attributes | Teams act on different versions of the same business entity |
| Timeliness | Time between approved change and downstream availability | Users work with stale account, product or supplier information |
| Referential integrity | Records with valid parent and related entity links | Broken hierarchies affect consolidation and process execution |
Implementation roadmap
- Select one high-value domain. Start with customer, supplier or product data where defects have a measurable operational cost.
- Profile the current state. Count records, identify duplicates, measure missing fields and map source-system differences.
- Agree definitions and ownership. Confirm the canonical model, data owner, steward, approval rights and exception process.
- Clean and match records. Apply standardisation, matching, survivorship and manual review for ambiguous cases.
- Configure workflows and integrations. Define creation, change, approval, distribution, error handling and audit requirements.
- Pilot with real processes. Validate customer onboarding, purchase orders, product updates or other workflows end to end.
- Expand by domain and measure results. Add other domains only after ownership, quality and support responsibilities are working.
Common MDM mistakes to avoid
- Buying an MDM tool before agreeing who owns the data.
- Trying to govern every domain at once instead of proving value in one high-impact area.
- Assuming a data catalog automatically cleans or masters operational records.
- Using fuzzy matching without review thresholds and survivorship rules.
- Allowing every connected application to overwrite the same attributes.
- Ignoring local legal, tax, language and regulatory differences.
- Measuring record counts rather than the business impact of improved data quality.
Final guidance
MDM succeeds when business accountability, data definitions and technology controls work together. Start with a domain that creates visible cost or process risk, define ownership and quality rules, then choose the lightest architecture that can enforce those decisions across systems. A trusted customer, supplier or product record should be traceable, approved and consistently understood wherever it is used.
For related implementation considerations, see SeerOmega’s ERP implementation risk guide and ERP data migration checklist.
