Master Data
Master data is the shared, slowly changing core entities such as customers, products, and suppliers that multiple systems must agree on.
Definition
Master data describes the core business entities used across systems: customers, products, suppliers, employees, locations, and charts of accounts. It is relatively stable, shared by many processes, and requires a governed golden record so that different applications do not create conflicting versions of the same entity.
Context and scope
Operational systems often create their own customer or product records, then disagree on identifiers, names, and status. Master data management resolves those conflicts and provides a trusted reference for transactions and analytics.
Common misconceptions
- Master data is any important table, including transactions and events.
- A single database can serve as master data without stewardship or matching rules.
Anti-patterns
- Letting every application create customers independently and merging them only in reports.
- Overwriting source attributes in the golden record without preserving provenance.
Related concepts
Related examples
Authoritative source
How it works
Master data management identifies entities across sources, matches records that refer to the same real-world object, merges them under survivorship rules, and assigns a durable identifier. A central hub may own the golden record and publish it to consumers, or a registry may keep source systems authoritative and provide cross-references. Stewards resolve exceptions that automated matching cannot.
The work is partly technical and mostly organizational. Matching needs deterministic keys and fuzzy rules for names and addresses. Survivorship needs a policy for which source wins for each attribute. Consumers need a way to map local IDs to the master ID without breaking existing transactions.
When to use it
Invest in master data when multiple systems must report on the same customers or products, when duplication causes billing or compliance errors, or when a merger creates overlapping entities. Start with one domain and a clear business case. A full enterprise program before any delivery usually stalls.
Trade-offs
A central hub improves consistency but adds latency, coupling, and a new failure domain. A registry preserves source autonomy but leaves some inconsistency in place. Matching produces false positives and false negatives, so manual stewardship is unavoidable. Governance boards can also slow routine changes if they review too much.
Example and misconception
A bank has the same customer in retail, cards, and wealth systems under three spellings and two dates of birth. MDM matches them with a shared national ID where available and fuzzy name plus address otherwise, assigns a party ID, and keeps source-system keys in a cross-reference table. Reports can now count one customer once, while each system retains its operational record.
The misconception is that master data is a one-time cleanup. New customers, mergers, and address changes continually create duplicates, so matching and stewardship must run continuously.