One Customer, Five Systems: What Master Data Management Actually Has to Solve

A customer appears in the billing system as “Acme Corp Ltd,” in the CRM as “ACME Corporation,” in the support tool under a contact’s personal email, in the ERP under a legal entity name nobody recognizes, and in a spreadsheet the sales team maintains. None of those records is wrong. Each is correct for the system that created it, and every one of them was entered by someone doing their job properly. Master data management is what an organization does about that, and most of the difficulty has nothing to do with the matching algorithm.

Product behavior cited below follows AWS Entity Resolution documentation as checked in September 2026; the concepts are not specific to that product.

What counts as master data

Master data is the set of entities that several systems all need to refer to and that exist independently of any transaction: customers, products, suppliers, employees, locations, accounts. Two distinctions keep the scope honest.

• Not transactional data. An order is an event with a timestamp; a customer is a thing that persists and changes slowly. Orders need master data to point at, which is why master data problems surface as broken joins in reporting.
• Not reference data. Country codes, currency codes, and status values are shared lists with external or agreed definitions. They need governance too, and it is much simpler: agree the list, distribute it, version it. Master data has the harder property that the same real-world thing arrives under different descriptions.

A large part of the problem is one missing thing: a shared identifier. Where systems already share one — a national company number, an internal employee ID issued at hire — the matching work below mostly disappears, because deciding which records describe the same entity is a join.

What does not disappear is everything after identification. Two systems using the same customer ID can still hold different addresses, disagree about whether the account is active, and each believe they own the right to change it. Which value wins, who may change it, how a change propagates, and what evidence exists for a past state are questions about attribute authority and lifecycle, not about identity. That is the part of mastering a shared key leaves untouched — and the rest of this article.

Matching: two approaches, two ways to be wrong

Deciding which records refer to the same real-world entity is entity resolution, and tools approach it in two ways that are worth understanding as different risk profiles rather than as old and new. AWS Entity Resolution offers “rule-based matching, machine learning-based matching (ML matching), and data service provider-led matching,” and normalizes inputs first — “removing special characters and extra spaces, and formatting text to lowercase.”

Rule-based matching produces groups you can explain: each match group carries “the rule number used to generate that match,” and the documentation notes that the number can “demonstrate the precision of each match group such that rule one is more precise than rule two.” Machine learning matching produces groups with “a confidence score in each group,” on a scale of “0.0–1.0, which indicates the precision of the match.” The practical difference is what happens when someone disputes a match. A rule can be read aloud in a meeting; a confidence score of 0.83 cannot be, by itself. What explains a decision is the evidence behind it — the fields compared and how each counted — together with the rule definition or model version that produced it, and whether a tool exposes that varies by model and product rather than by the label “machine learning.”

Both approaches fail in two directions, and the costs are not symmetric.

	Over-merging (false positive)	Under-merging (false negative)
What happens	Two different entities become one record	One entity stays split across several records
How it shows up	A customer sees another customer’s data; invoices go to the wrong company; a person’s history is polluted	Duplicate outreach, understated customer value, a support agent missing half the history
How hard to undo	Hard — the merged record has been read, copied, and acted on, and the original boundary may no longer be recorded	The link is simple to fix — merge them when noticed — but what was done on the split history is not undone: offers sent twice, decisions taken on an understated value, support given without the full record

That asymmetry should inform the threshold, weighed per use case: the cost of each error and of the review queue that sits between them. Where a wrong merge exposes one party’s data to another, the matching policy should be conservative and the uncertain cases should go to a person, not to a default. Uniqueness as a quality dimension “measures the number of duplicates,” and a program measured only on that number will push toward over-merging, because duplicates are the visible failure and wrong merges are not.

Merging is where the real argument starts

Once two records are judged to be the same entity, something has to decide what the combined record says. The billing system has one address, the CRM another, and both were updated this month. The rules that settle this are survivorship rules, and they are business decisions wearing technical clothing.

Four bases are commonly used, and the choice differs per field rather than per record.

• Source authority. The billing address comes from billing, the support contact from the support tool. This is usually the best answer, and it requires someone to state which system is authoritative for which field — a decision nobody makes until forced.
• Recency. The most recently updated value wins. Simple, and wrong whenever a system touches records without anyone verifying them — a nightly sync can make a stale system look like the freshest one.
• Completeness. The most populated value wins. Useful for filling gaps, dangerous when it prefers a long wrong value over a short right one.
• Verification status. A value someone confirmed beats one nobody has. The strongest basis where it exists, and it requires capturing that a verification happened.

Because these are business decisions, they need the same treatment as any other: a named owner per field, the rule written down where the next person will read it, and the reasoning recorded. A survivorship rule buried in a mapping tool is a decision the organization has made and cannot find.

What a golden record is and is not

The merged result is usually called a golden record, and the name does most of the damage in these programs. It suggests a true version that existed all along and was recovered. What it actually is: the output of matching decisions and survivorship rules, assembled by a process, correct to the extent that those rules were right.

Two consequences follow from taking the name less literally. It has a grain and a definition like any other dataset — one row per what, exactly, and under whose rules — which belongs in a written definition rather than in tribal knowledge. And it does not make the source records wrong. The billing system still needs its own address for its own purpose, and an MDM program that treats source records as errors to be corrected will be resisted by every team that depends on them.

Four ways to implement it

Implementations differ mainly in where the mastered record lives and who is allowed to write it, and the styles form a spectrum from least to most invasive.

Style	What it does	What it asks of the organization
Registry	Stores only the links between source records and a shared identifier. Sources keep their data and their authority	Least. Nothing changes in source systems, and consumers must join through the registry to get a unified view
Consolidation	Copies source records into a hub and builds a merged version there for analytics and reporting	A pipeline and survivorship rules. The hub is read-only, so operational systems stay as they are
Coexistence	Builds the merged version in a hub and pushes agreed values back to source systems	Agreement on which fields flow back, and conflict handling when a source changes a value it received
Centralized	The hub is where master records are created and edited; sources subscribe	The most — applications must be changed to write through the hub, and the hub becomes a system of record with the availability requirements that implies

The choice is usually settled by how much change the organization can absorb rather than by which is architecturally cleanest. A registry that people actually use beats a centralized hub that three teams are still refusing to integrate with two years in. It is also reasonable to differ by domain: products centralized because one team owns them, customers consolidated because five systems create them and none will give that up.

Design for being wrong

Every matching system makes mistakes, so the question is not whether a wrong merge will happen but whether it can be undone when it does. Three design choices decide that, and all three are cheap before the fact and costly or impossible afterwards, depending on what was kept.

• Never destroy the source records. A merge should create a link, not overwrite the inputs. If the original records are gone, an unmerge is a reconstruction rather than a reversal — and the same holds one level down: a fact table that stored only the merged master identifier cannot be split back unless each fact kept its source identity, which is exactly what keys are for.
• Record why each match was made. The rule number or confidence score that produced a group, kept with the group along with the rule definition or model version and the inputs as compared, is what lets someone review a disputed merge instead of arguing about it. It is also what makes a threshold change reviewable in retrospect.
• Keep the decision log. Manual merges and unmerges are decisions by people and belong in an audit log, both because they will be questioned and because a re-run of the matching process must apply the decisions currently in force rather than silently undo them — which means each decision carries who made it, what it covers, from when, and what supersedes it.

Downstream, an unmerge is a change to data consumers have already used — the customer count moves, the revenue per customer moves — which makes it a correction that is also a restatement, and worth announcing as one. Lineage gives the recorded candidates for who needs to hear it, not the whole list.

Starting without boiling the ocean

MDM programs more often founder on the scope they take on than on the matching technique. The version that works starts with one entity type, the two or three systems that matter most for it, and one consuming use case that will notice if it is wrong — a customer count that finance argues about, a supplier list that procurement cannot reconcile.

Three things make that first slice worth the effort. A stated authority per field, so survivorship is a decision rather than a default. A contract for the mastered output, so consumers know what one row means and what may change. And a periodic reconciliation against the sources, because it checks that every source record arrived. It does not check that records were grouped correctly — two rows that an approved case says are one customer can both be loaded, linked to different master IDs, and pass every count. Matching quality needs its own evidence: a set of approved match and non-match cases, a representative labeled sample, and a comparison of group counts and unmatched rates between runs, where a change is a signal to investigate rather than proof of an error and a previously linked pair is not automatically right.

References: AWS Entity Resolution User Guide, What is AWS Entity Resolution?; GOV.UK, Meet the data quality dimensions. Checked September 2026.