Entity resolution is the process of determining whether records in different datasets refer to the same real-world entity. It is a foundational requirement for cross-system analysis because a supplier, customer, product or location may have different names and identifiers in different applications.
The objective is not to merge every similar-looking record. It is to establish defensible relationships, preserve uncertainty and avoid treating an unverified match as fact.
Why identity becomes a business problem
A supplier may appear in a procurement system under one account number, in finance under another, and in a contract repository under its legal name. A customer may use multiple delivery addresses. A product may have an internal SKU, a vendor code and a legacy code.
If the records are not linked, the organisation may undercount spend, miss repeated delivery failures or incorrectly split one customer’s history. If unrelated records are merged, the analysis may be even more dangerous.
How matching approaches differ
| Method | Strength | Limitation |
|---|---|---|
| Exact identifier | Highly reliable when the identifier is authoritative and correctly scoped | Fails when identifiers are missing or differ |
| Rule-based matching | Transparent and repeatable | Rules may not cover variations and exceptions |
| Fuzzy matching | Finds candidates despite spelling or formatting differences | Can match unrelated names |
| Multi-attribute matching | Uses several fields such as address, tax ID and contact data | Attributes may be stale or contradictory |
| Human-reviewed mapping | Uses domain knowledge for ambiguous cases | Requires time and consistent governance |
In practice, a robust process often combines these approaches. Strong identifiers can establish a relationship; weaker evidence can create a candidate for review; contradictory evidence should block an automatic merge.
A safer entity-resolution workflow
- Start Records from multiple sources
- Normalise formats and identifiers
- Generate candidate relationships
- Evaluate supporting and conflicting evidence
- Risk-appropriate confidence?
- High Accept under approved policy.
- Medium / ambiguous Send to human review.
- Low / contradictory Keep separate or reject.
- Record the decision and its provenance
- Outcome Monitor changes and re-evaluate
A low-risk exploratory analysis may tolerate more candidate links than a payment approval or compliance investigation.
The confidence threshold should depend on the use case. A low-risk exploratory analysis may tolerate more candidate links than a payment approval or compliance investigation. Confidence should not be treated as a universal percentage that means the same thing in every context.
False positives and false negatives
A false positive links two different entities. A false negative leaves two records separate even though they refer to the same entity.
| Error | Potential consequence | Suitable control |
|---|---|---|
| False positive | Two suppliers’ spend is combined | Strong identifier checks, contradiction rules and review |
| False negative | One supplier’s spend is fragmented | Candidate generation, unmatched-record review and periodic checks |
| Stale relationship | Historical link no longer reflects a merger or account change | Effective dates and revalidation |
| Ambiguous group relationship | Parent company and legal subsidiary are treated as identical | Explicit relationship types, not just a single merged identity |
The model should preserve distinctions such as “same legal entity”, “same corporate group”, “same trading name” and “same product family”. These relationships are not interchangeable.
Why entity resolution needs governance
Every accepted relationship should have a basis: identifiers used, evidence considered, confidence or decision status, effective time, reviewer if applicable, and a way to correct the relationship. Downstream answers should be able to show whether a total relies on an accepted match or an unresolved candidate.
Qwry.AI’s platform describes relationship discovery and cross-source context as part of its source-to-answer workflow. For a real use case, the relationship rules and review thresholds should be validated against representative records before relying on the result for decisions.
Next step: Select one entity type and sample real mismatches. Label true matches, false matches and unresolved cases with a domain expert. Use those examples to establish and validate matching and review rules.
FAQ
Frequently asked questions.
They overlap but are not identical. Entity resolution links records that may represent the same entity. Master data management also covers ownership, authoritative records, lifecycle processes and the governance of core entities.
Some low-risk, high-confidence relationships may be accepted under approved rules. Ambiguous, contradictory or high-impact matches should be escalated according to policy.
There is no universal threshold. Set it based on the cost of false positives and false negatives, test it on labelled examples, and monitor outcomes after deployment.
Not by default. They may be related but legally distinct. Preserve the relationship type and aggregate only when the business question requires group-level reporting.