A supplier appears in purchasing as “Harbour Services Ltd” and in finance as “Harbour Services Limited.” A matching service suggests that the records describe the same organisation. Linking them could improve reporting and reduce duplicate work. Merging them incorrectly could direct an invoice, restriction, or payment-related change to the wrong entity.
Master data management, or MDM, establishes governed identities and shared attributes for important business entities such as suppliers, customers, products, and locations. Production reliability depends on the decisions behind that shared view: what counts as the same entity, which attributes are authoritative, how changes propagate, and how the organisation corrects a mistaken match without losing the history needed to repair its consequences.
Define the Entity Before Resolving Its Records
Begin with the business use. Supplier reporting, invoice matching, contact management, and payment administration can involve different entities and relationships. A corporate group is not identical to each subsidiary, a trading name is not necessarily a legal entity, and a contact person is not the supplier organisation.
Document the unit being mastered and the relationships it needs. If the organisation wants group-level spending, preserve subsidiary identities and connect them to the parent rather than treating all group records as duplicates. Consolidation for reporting does not require erasing legitimate distinctions in operational records.
Separate master data from every fact associated with the entity. A supplier’s identity and approved reference attributes can be shared, while invoices remain transactions with their own histories. A single “active” flag may be inadequate if purchasing eligibility, payment hold, and marketing contact preferences describe different states.
The business-classification article examines a related problem: categories need a defined entity, purpose, and effective period. MDM benefits from that clarity before a platform begins assigning common identifiers.
Preserve Source Identities Alongside the Shared Identity
Each source system may have a valid local identifier. Retain a mapping between those identifiers and the shared entity rather than assuming every application can adopt one new key immediately. The mapping needs source context because the same identifier string can occur independently in several systems.
A shared identity does not require every attribute to live in one physical database. An architecture can link records, consolidate an analytical view, or publish governed attributes back to operational systems. The right arrangement depends on consumers, update authority, latency, and recovery requirements.
State which purpose the view serves. A supplier directory useful for analytics is not automatically authorised to change payment details in the finance system. Copying an attribute into a master record does not confer permission to use it for every downstream action.
Retain relationship and provenance information needed to reconstruct the view. W3C’s PROV data model provides concepts for describing source information, the activities that produced a result, and responsible agents. The implementation should support actual investigation rather than merely draw a lineage diagram.
Separate Candidate Matching From a Merge Decision
Matching can use exact identifiers, normalised names, addresses, other evidence, or statistical similarity. A similar name is a useful lead, but it may describe two different organisations. Shared premises, changed ownership, and recycled contact information can complicate apparently obvious matches.
A numerical match score needs a defined interpretation. It is not automatically the probability that two records describe the same entity. Evaluate the method against representative confirmed matches and non-matches, including difficult cases. Check whether scores or thresholds remain useful when sources and populations change.
Choose thresholds with the consequence in mind. A candidate link used to assist a steward may tolerate uncertainty that is unacceptable for an automatic merge. Evaluate false merges and missed matches separately. A single aggregate accuracy figure can hide rare but costly incorrect combinations.
Keep an unresolved state. The system should be able to request more evidence or retain separate records rather than force a decision merely to improve a duplicate-count metric. Record the decision and evidence when a person resolves a case so later reviewers can understand what was established.
Decide Authority at the Attribute Level
Even a correct entity match does not establish which values should survive. The delivery address, registered address, billing address, and contact address may all differ legitimately. Choosing the newest string without its purpose can produce a more recent but less appropriate value.
IBM’s survivorship documentation describes rules used to compose the master view from source records. This is a useful distinction: matching concerns common identity, while survivorship determines which information is carried forward under defined criteria.
Define those criteria using business meaning, source authority, verification, and relevant time. A recent unverified update should not automatically displace an approved value whose role requires additional confirmation. Conflicting evidence may need a review state rather than a silently chosen winner.
| Decision | Evidence or rule needed |
|---|---|
| Are these the same supplier? | Identity evidence and evaluated matching criteria |
| Which address is used? | Address purpose, source authority, and effective period |
| May an attribute change automatically? | Approved update policy and consequence assessment |
| Can a merge be undone? | Preserved source mappings, values, and decision history |
Keep policy-specific states separate where possible. Identity resolution should not silently combine consents, eligibility, restrictions, or access rights as though they were interchangeable descriptive attributes. Those states may depend on the source, relationship, purpose, and applicable requirements.
Make Synchronisation a Controlled Process
Publishing a corrected master value creates another distributed workflow. Consumers may be offline, reject the update, apply changes in a different order, or continue using a cache. The master platform’s successful write does not establish that every dependent system now agrees.
Define versions, ordering, acknowledgement, and reconciliation appropriate to the service. Repeated delivery should not repeat consequential actions. An update’s identity and intended effect need to remain recognisable across retries and replay. The retry-policy guide explains why repeat safety belongs at the action boundary.
Avoid update loops. If the platform republishes a corrected address to a source and then re-ingests that value as a new independent update, it can confuse provenance or override another authorised change. Preserve origin and version information and define how conflicting concurrent edits are resolved.
The production data-strategy article connects these expectations with consumers. A contractual freshness target should describe the relevant event and coverage, not merely how often a synchronisation job runs.
Design Unmerge and Remediation Before Automating Merges
An incorrect merge requires more than deleting one shared identifier. The platform needs to separate source records, restore or reconstruct appropriate attributes, and communicate new mappings to consumers. Some systems may already have combined histories or taken actions based on the merged identity.
Preserve enough evidence to establish which source values and relationships belonged to each entity. A merged text field that overwrites its inputs can make reversal difficult. The existence of an “unmerge” command is useful only if the data and dependent processes support the required correction.
Stibo Systems’ unmerge documentation illustrates that reverting a match is an explicit product operation with particular behaviour. Do not generalise one product’s guarantees to every platform or assume an unmerge automatically repairs external decisions.
Track affected invoices, communications, permissions, or other outcomes according to the incident. Correcting the master view is one responsibility; correcting consequences elsewhere is another. The accountability-after-failure guide provides a practical approach to scope, evidence, and owned remediation.
Give Stewards Evidence, Authority, and Capacity
Stewards need source records, relevant definitions, match evidence, and a route to obtain specialist decisions. A queue containing only two similar names and an unexplained confidence score does not support careful identity assessment. Define what they can approve and what requires escalation.
Plan for the volume and complexity of cases. Introducing a new source can create a burst of ambiguous matches. Monitor queue age, unresolved high-impact cases, and recurring causes. Increasing automation to clear the queue without evaluating false merges can simply move the problem downstream.
Assign business ownership for definitions and source authority, alongside technical ownership of matching, storage, and integration. Changes to thresholds or survivorship rules should have an evaluated release process. Decisions about disputed legal entities or controlled payment attributes should reach people with the appropriate responsibility.
The data-protection article addresses another boundary: a consolidated identity view can expose information across contexts that were previously separate. Access, permitted use, retention, and correction requirements need to follow the combined service.
Measure Improvement Beyond a Smaller Record Count
Fewer duplicate records can be useful, but deleting distinctions can also reduce that number. Measure verified matching quality, false merges, time to resolve disputes, synchronisation failures, and relevant business outcomes such as reduced invoice rework or better reporting reconciliation.
Start with a bounded domain and consumers who can test the result. Expand when the organisation can explain how identity is resolved, authority is chosen, changes propagate, and corrections reach affected systems. A trusted master view is maintained through those decisions, rather than established permanently by the first successful deduplication run.
