Data Crime Scene #01
When Should You Merge Two Customer Records?
A practical entity resolution example showing why records that look alike are not always the same thing.
At first glance, duplicate customer records look like one of the simpler problems in Master Data Management.
Two records have similar names. Their addresses match. Perhaps they share a company registration number. Merge them, create a golden record and move on.
Except enterprise data is rarely that cooperative.
Examine the evidence
Three customer records.
Which ones would you merge?
| Field | Record A | Record B | Record C |
|---|---|---|---|
| Company | Acme Limited | ACME Ltd | Acme Holdings Ltd |
| Location | London | London | Manchester |
| CEO | James Smith | Jim Smith | James Smith |
| Revenue | £32m | £29m | £142m |
| Status | Active | Active | Active |
| Company No. | 08124791 | 08124791 | 08124791 |
| Parent Company | Acme Group PLC | Acme Group PLC | Acme Group PLC |
A and B? All three? None of them?
The short answer
Do not merge all three records based on the information available.
Records A and B are strong duplicate candidates.
Record C should trigger further investigation.
Although all three records share the same company registration number, Record C also contains evidence suggesting it could represent a separate but related legal entity.
Matching tells you that records look alike. Entity resolution determines whether they actually represent the same thing.
Why Records A and B look like duplicates
Records A and B contain several strong matching signals.
- The company names are semantically equivalent.
- The locations match.
- James and Jim may refer to the same individual.
- The company registration numbers are identical.
If these records came from different systems, perhaps one from CRM and another from ERP, there would be a strong case for treating them as representations of the same business entity.
But even here, the system should be able to explain why it believes they match. A confidence score alone is not particularly useful if nobody can see what produced it.
Then Record C changes the problem
Record C shares one of the strongest identifiers in the dataset, but several other attributes conflict.
Different legal name Acme Holdings Ltd instead of Acme Limited.
Different location Manchester instead of London.
Different revenue £142m instead of approximately £30m.
Could Acme Holdings be a parent or related company rather than a duplicate?
Could the registration number on Record C simply be wrong?
Could one system contain historical data, or could enrichment data have been associated with the wrong entity?
What should you trust when customer records disagree?
There is rarely one universal attribute that should always win.
Why duplicate matching and entity resolution are not the same thing
Duplicate matching often works by comparing fields and assigning weights or confidence scores.
Company name similarity: 92%
Address similarity: 95%
Registration number: Exact match
CEO similarity: 90%
This is useful, but confidence scoring alone can still produce the wrong answer.
Graph context changes the meaning
Acme Holdings Ltd
↓ owns
Acme Limited
The records may be highly related without representing the same entity. This is why entity resolution needs context, not just similarity.
The CluedIn approach
How would CluedIn approach this problem?
Step 1
Bring the records together without losing their provenance
Source records are ingested and mapped into CluedIn while retaining information about where each piece of data originated. Conflicting values remain visible rather than being immediately flattened away.
Step 2
Standardise the evidence
Obvious variations such as Acme Limited and ACME Ltd can be normalised so superficial formatting differences do not distort the matching process.
Step 3
Identify likely duplicate candidates
CluedIn can combine matching rules, similarity scoring, source trust and relationship context to identify likely duplicates.
A ↔ B
Registration number: exact
Company name: very strong
Location: exact
Executive: strong
Overall confidence: very high
Registration number: exact
Company name: very strong
Location: exact
Executive: strong
Overall confidence: very high
Step 4
Investigate conflicting evidence instead of hiding it
Record C shares a strong identifier but conflicts on legal name, location and revenue. That should trigger investigation rather than an automatic merge.
External enrichment, for example from authoritative company registries, can help determine whether the identifier is correct or attached to the wrong entity.
Step 5
Look around the record, not just at the record
This is where a graph-native approach becomes particularly useful.
Acme Group PLC
↓ owns
Acme Holdings Ltd
↓ owns
Acme Limited
The similarities were real because the businesses are related. But related does not mean identical.
A row can tell you:
“Acme Holdings has company number 08124791.”
A graph can tell you:
“Acme Holdings appears to own the company that actually has company number 08124791.”
Step 6
Decide what should happen next
Records A + B
Recommended action: Merge
- Very strong name similarity
- Same legal identifier
- Same location
- Probable executive-name variation
- No contradictory relationship evidence
Record C
Recommended action: Do not merge
- Different legal entity name
- Different location
- Materially different revenue
- Potential parent-child relationship
- Identifier requires investigation
Where should an AI agent be allowed to act?
Finding the correct answer is only half the problem. The next question is whether an AI agent should be allowed to act on it automatically.
| Situation | Possible action |
|---|---|
| Extremely high confidence, low-risk standardisation | Automate |
| High-confidence duplicate with no material dependencies | Merge according to policy |
| Strong match but downstream dependencies exist | Recommend and request review |
| Contradictory evidence | Escalate |
| Legal, compliance or high-impact issue | Require human approval |
The goal is not to have AI make every decision. It is to stop humans having to make every obvious decision while ensuring they remain involved where judgement and risk require it.
Create the golden record without losing the history
Once A and B have been resolved as duplicate representations of the same organisation, a trusted golden record can be created.
Golden record
ACME LIMITED
Legal name: Acme Limited
Trading variation: ACME Ltd
Company number: 08124791
CEO: James Smith
Location: London
Status: Active
The underlying evidence does not need to disappear. Users should still be able to understand which source records contributed to the entity, where values came from, what changed and why a decision was made.
Acme Holdings Ltd remains a separate entity, with its relationship to Acme Limited preserved.
Final verdict
Should Records A, B and C be merged?
A and B: strong duplicate candidates.
C: do not merge until the contradictory evidence has been resolved.
Similarity is evidence. Context makes the decision.
Enterprise entity resolution is not simply a search for records that look alike. It is a process for establishing identity.
That means understanding not only the attributes attached to a record, but also where those values came from, how entities relate to one another and what consequences a merge might have elsewhere.
As AI agents take on more responsibility for enterprise data operations, this distinction becomes even more important.
The challenge is no longer simply:
“Can AI find a duplicate?”
The more useful question is:
“Can it gather enough evidence to know when it is safe to act?”
Frequently asked questions
Entity resolution FAQs
What is the difference between data matching and entity resolution?
Data matching measures whether records appear similar according to attributes such as names, addresses or identifiers. Entity resolution goes further by determining whether multiple records represent the same real-world entity using wider evidence such as relationships, provenance, source trust and context.
Should an exact company registration number always cause records to be merged?
No. A legal identifier is strong evidence, but the value itself may be incorrect, stale or associated with the wrong record. Strong contradictory evidence should be investigated before an irreversible merge.
What causes false-positive duplicate matches?
Common causes include related companies with similar names, shared addresses, common executives, parent-subsidiary structures, outdated records, incorrect identifiers and insufficient relationship context.
How can a knowledge graph improve entity resolution?
A graph represents relationships as well as attributes. This helps distinguish between records that describe the same entity and entities that are merely closely related.
Can AI automatically merge customer records?
Yes, in appropriate scenarios, but automatic merging should be controlled by confidence, risk and governance policies. Low-confidence or high-impact decisions should remain reviewable, explainable and subject to human approval.
What is a golden record?
A golden record is the mastered representation of an entity created from relevant source records according to defined matching and survivorship logic. A useful golden record should retain provenance and explainability so users can understand how it was created.
Continue exploring
Explore graph-native Agentic Master Data Management
Learn how CluedIn combines entity resolution, golden records, graph context, data quality and governed AI agents to continuously maintain trusted enterprise data.
| Explore the CluedIn platform |