01
Short answer
Master data breaks when systems can create entities without matching them and no steward owns uncertain cases. Keep it usable with written match rules, reversible merges, a staffed exception queue, and measures tied to downstream reconciliation work.
Master data programs often begin with a cleanup. Customers get deduplicated, a golden record is declared, the project closes. Then someone keys a rush order directly into the operational system on a Tuesday, and the next duplicate is born. Eighteen months later the count of "active customers" differs between finance and sales by several hundred, and nobody can say which number is right without a reconciliation effort nobody has budgeted.
The cleanup was never the hard part. Maintenance is. Master data stays usable in exactly the organizations that fund the maintenance, and nowhere else.
02
Where the duplicates come from
Side doors, mostly. Any system that can create an entity without matching it against the golden record is a future duplicate. The rush order is the classic case: the warehouse needs to ship today, the customer service rep cannot find the matching customer record, a new one gets created with a slightly different spelling, and now the same customer exists twice with different payment terms.
Mergers and reorganizations do similar damage at scale. Two suppliers merge; procurement now has one vendor in the payables system and two in the master, with contracts split across all three. Channel-specific catalogs grow their own identifiers because the e-commerce team cannot wait for the central process. Each of these is a reasonable local decision that quietly violates the model.
Then there is hierarchy drift. Finance restructures the product hierarchy for reporting while planning keeps the operational one, because their requirements genuinely differ. Now every cross-functional report needs a mapping between the two, and the mapping lives in an analyst's spreadsheet, and the analyst has a phone number that will eventually stop working.
03
What a golden record actually is
A golden record is the single version of an entity that systems agree to reference, produced by matching rules and surviving rules that someone wrote down and can explain.
The matching rules decide when two records describe the same real-world thing. The surviving rules decide which source wins for each attribute when they disagree. Both sets of rules need review when the business changes, because a rule tuned for domestic customers will mishandle a merger of two international subsidiaries.
Three design questions deserve real attention before any tooling:
Which system is authoritative for which attribute? One system per attribute, named in writing. When sales owns the address and logistics also owns the address, you do not have a golden record, you have an argument that has not started yet.
What happens in the gray zone of match confidence? High-confidence matches merge automatically, low-confidence ones go to a steward, and the middle band is a decision to be made deliberately. Teams that let the middle band auto-merge spend years finding the casualties.
How do downstream systems reference the record? By a durable identifier they cannot overwrite, keeping their own extensions separately. The moment a consuming system edits the shared record to suit itself, the record stops being shared.
04
The exception queue is the product
After go-live, master data lives or dies in the exception queue: the gray-zone matches, the attribute disputes, the hierarchy changes. That queue needs stewards with the authority to decide and a record of what they decided. Give the queue to everyone and it becomes no one's, which is the default outcome and the reason most programs decay.
The rhythm that holds is unglamorous. Stewards work the queue daily. Mergers, new channels, and reorganizations trigger a matching review rather than an assumption that the rules still fit. Once a quarter, someone reviews duplicate rate, exception backlog and age, and match precision with the operating owners, and the rules get tuned.
None of this requires exotic technology. It requires that someone's job description contains the phrase "works the master data exception queue" and that the person has the standing to resolve disputes.
05
Measuring whether it worked
Measure master data by its effect on the surrounding work, not by a purity score. Duplicate rate at each entry point. Exception backlog and, more revealing, its age distribution. Match precision, sampled by the stewards. And the reconciliation effort in downstream reporting, because when master data works, cross-functional reports stop needing a mapping spreadsheet to agree.
Zero duplicates is the wrong target; the business will not pay for it, and it should not. The right target is a duplicate rate that is known, trending down, and cheap to fix when it ticks up.
The Compass Group program on this site is a worked example: master data workflows with quality rules and reconciliation, so corrections traveled a governed path instead of whatever came before, and the finance team's reporting cycles shortened accordingly.
06
Start with one entity and one costly error
Choose the entity whose duplicates cause the most visible operating cost. For a distributor, that may be customers split across credit limits; for a manufacturer, materials that appear under several identifiers; for a retailer, products that cannot be matched across channels. Name the error in money or hours before choosing software.
Map every place that entity can be created or changed. The list often includes the central application, imports, mobile forms, acquisitions, partner feeds, and spreadsheets used during exceptions. Closing only the main entry screen leaves the side doors untouched. Each entry point needs a match check, a response when the match is uncertain, and an owner who can change the source process.
Use a small sample of real duplicates to write the first matching rules. Exact identifiers can auto-match. Stable combinations such as tax ID and legal name can match above a strict threshold. Addresses, phone numbers, and trading names usually need weights and a review band. Keep the explanation for every proposed merge so a steward can see which fields drove it.
Run the rules against historical data without changing production. Measure false merges separately from missed duplicates; the first can combine two customers and damage access or credit, while the second preserves an existing problem. Business owners must decide the acceptable balance. A vendor score cannot make that policy choice.
Release through one entry point and one consuming workflow. Watch the exception volume, time to decision, and downstream correction effort for several weeks. Expand only when stewards can keep the queue current. If review demand grows faster than capacity, tighten automatic matching or remove a noisy source before adding another domain.
07
Make every merge reversible
An approved merge needs the surviving identifier, retired identifiers, field-level choices, reason, steward, and time. Downstream systems need a published mapping from old identifiers to the surviving one so open orders, history, and reports remain traceable.
Unmerge is a production operation, not a database repair. Define who can request it, which downstream systems must be corrected, and how the change is tested before any automatic merge goes live. Seed a mistaken merge during release testing and make the team restore both entities.
History also protects the matching rules. When stewards reverse a merge, capture the feature combination that caused it. Add that case to the rule test set so the next change proves it will not repeat the error. The same feedback works for missed duplicates found during reconciliation.
08
Assign authority, not just responsibility
Stewards need permission to settle disputes between systems. If finance owns the legal customer name and sales owns the trading name, the rule should preserve both with clear use rather than force one team to win every disagreement. Hierarchies need the same treatment: legal ownership, reporting roll-up, and sales territory can be different relationships.
Publish response times for the exception queue based on operating risk. An uncertain customer match blocking an order needs an answer in minutes; a hierarchy correction for next month’s report can wait. Age bands show whether staffing and rules fit the work better than one average queue time.
09
Related
Where to read next on the same subject.