Master Data Management: Reducing Duplicate Customer, Product and Supplier Records
Master data management in practice: key domains, MDM styles, golden records, match and merge rules, data stewardship, and tools vs lightweight approaches.
What does master data management involve?
Master data management (MDM) means deciding which system owns each core entity (customers, products, suppliers, locations), defining rules for matching duplicates and choosing the best value for each field, assembling a trusted 'golden record', keeping systems in sync, and assigning people to resolve conflicts and maintain quality. Tools help, but ownership and rules matter more.
This guide is for operations, finance and data leads dealing with duplicate customers, inconsistent product data or conflicting supplier details. For customer data specifically, see customer data integration; for product data, product information management.
Key takeaways
- Start with the domain causing most pain.
- Name a system of record and an owner per domain.
- Validate at entry to stop new duplicates.
- Use clear match and survivorship rules.
- Review uncertain matches; never merge different people.
- Measure duplicate rates and fix rates over time.
Domains and typical problems
| Domain | Typical problems | Common system of record |
|---|---|---|
| Customers | Duplicates across CRM, ecommerce, ERP; inconsistent names and ABNs | CRM or ERP |
| Products | Different descriptions, units and attributes by channel | PIM or ERP |
| Suppliers | Duplicate supplier records, outdated bank details | ERP or accounting |
| Locations | Inconsistent addresses and site codes | ERP or operations system |
MDM styles
| Style | How it works | Fits when |
|---|---|---|
| Registry | Links records across systems without changing them | You need a single view but cannot change sources |
| Consolidation | Builds golden records for reporting | Analytics is the main goal |
| Coexistence | Golden record syncs back to systems | Sources need cleaner data |
| Centralised | Master data is created only in the hub | Strong governance; complex environments |
Matching and survivorship
Match on reliable identifiers first, such as ABN, customer number, email or SKU, then on fuzzy combinations of name, address and phone. Score matches and set thresholds: merge automatically above a high score, send the middle band to a steward, and leave low scores alone. Define survivorship rules per field, for example billing address from the ERP, marketing consent from the CRM and the most recently verified phone number. Keep a history of merges so they can be reversed.
Stewardship and prevention
- Assign a data steward per domain with time to do the work.
- Validate at entry: required fields, formats, ABN Lookup checks and duplicate warnings.
- Prevent creation of records outside the system of record.
- Report duplicate rates and open review tasks monthly.
- Respond to correction requests and keep personal information accurate (APP 10 and APP 13 where the Privacy Act applies).
Tools or lightweight approach?
A lightweight approach (systems of record, validation, scheduled duplicate detection in the warehouse, a review queue and integrations that update sources) covers many mid-sized businesses. Dedicated MDM platforms add matching engines, workflows and hierarchies for complex, multi-domain environments. Start lightweight, measure, then decide. See data engineering for growing businesses.
Hypothetical example: an industrial supplier
This example is hypothetical. An industrial supplier had customers created separately in its ecommerce site, CRM and ERP, with many duplicates. It named the ERP as the customer system of record, matched records on ABN first and then on fuzzy name and address, auto-merged high-confidence matches and sent the rest to a steward in accounts receivable. New ecommerce accounts were checked against the ERP before creation. The team reported the duplicate rate and review backlog each month.
Common mistakes
- Cleaning once without preventing new duplicates.
- Buying an MDM platform before agreeing ownership and rules.
- Auto-merging low-confidence matches.
- No history, so bad merges cannot be undone.
- Treating MDM as an IT project without business stewards.
Related guides
- CDP vs CRM for customer data tools.
- Product data architecture for ecommerce catalogues.
- Data migration for cleaning data during system changes.
- AI data entry automation for validation at capture.
Conclusion
Master data management is mostly ownership and rules: a system of record per domain, clear matching and survivorship, validation at entry and stewards who resolve conflicts. Start with the domain that hurts most, measure duplicates, and add tooling only when the lightweight approach runs out.
Struggling with duplicate records?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on data integrations and clean-up and data validation and matching automation. If it would help to plan a master data approach, we are happy to talk it through.
Common questions.
The core shared entities a business runs on, such as customers, products, suppliers, locations and employees, as opposed to transactional data like orders and invoices. Master data changes relatively slowly and is used by many systems.