Entity Resolution: 7 Steps to Match Records Across Business Systems

Entity resolution determines whether records in separate datasets refer to the same real-world person, company, product, or location. It goes beyond exact matching because systems may store names, addresses, identifiers, and formats differently. A reliable entity resolution process helps teams reduce duplicate records and build a more complete view, while keeping uncertain matches visible for review.

This guide explains the matching workflow, common methods, accuracy tradeoffs, privacy controls, and how to plan a safe deployment.

Why exact matching is not enough

Two systems may contain “Northwind Parts LLC” and “Northwind Parts, L.L.C.” as the same supplier. A customer could appear under a former surname, a shortened name, or a different email address. Product catalogs may use local part numbers that map to one manufacturer item. Entity resolution uses multiple attributes and relationships to decide whether two records likely represent one entity.

The task is related to identity resolution, but the terms are not always interchangeable. In identity proofing, a service tries to distinguish an applicant within a specific population and may verify evidence. Broader entity resolution can link records about organizations, products, and other entities without claiming that a person has been verified. NIST defines identity resolution as collecting information to distinguish an individual within the served population; see its identity resolution glossary and digital identity guidance.

How an entity resolution workflow works

1. Define the entity and purpose. Decide whether the system matches people, businesses, products, or locations, and what business action depends on the result.
2. Prepare the data. Normalize casing, punctuation, addresses, phone formats, and identifiers while preserving original values.
3. Generate candidate pairs. Use blocking rules to compare plausible records instead of every record with every other record.
4. Score evidence. Compare exact identifiers, names, dates, addresses, and other fields with weights that reflect reliability.
5. Set thresholds. Automatically merge only high-confidence pairs, reject clear non-matches, and route ambiguous cases for review.
6. Create a durable identity record. Preserve links to source records, match rationale, and versioned decisions.
7. Monitor and correct. Track false matches, missed matches, review outcomes, and downstream effects.

Matching methods

Deterministic rules

Deterministic matching applies explicit rules, such as matching on a unique tax identifier or a combination of postal address and account number. It is easy to explain and works well when source data contains stable identifiers. However, strict rules can miss true matches when a value is absent or entered incorrectly.

Probabilistic matching

Probabilistic methods assign weights to agreements and disagreements across attributes. A rare surname plus a matching date of birth may provide stronger evidence than a common surname alone. The system produces a score, and the business sets thresholds for automatic decisions and human review.

Machine learning can support candidate ranking or learn from past match decisions. It should not become a black box that silently merges records. Keep explainable evidence, test the model on representative data, and monitor performance when source systems or populations change.

Data preparation and identifiers

Normalize values carefully. Removing punctuation may help compare company names, but stripping meaningful characters from product codes can create false matches. Standardize address components using a documented process, keep language and locale in mind, and avoid changing the source record itself. A separate normalized field makes the transformation reversible.

Use trusted identifiers when available, but verify their scope. An identifier may be unique only within one system, country, or account. Do not assume that similar identifiers point to the same entity. A master data management approach can help set ownership and a stable reference for shared entities.

Accuracy, review, and explainability

Measure precision and recall separately. Precision asks how many automatic matches are correct; recall asks how many true matches the process finds. A false positive can combine two customers or suppliers that should remain separate. A false negative can leave the same entity duplicated. The acceptable balance depends on the action: a marketing report may tolerate more uncertainty than a credit or eligibility decision.

Maintain a review queue for cases near the thresholds. Give reviewers source values, score reasons, provenance, and a way to reverse a decision. A reviewer should not need to inspect dozens of irrelevant fields. Use sampled audits on auto-matches and non-matches to detect drift.

Keep a survivorship policy for the combined view. When two records disagree on a field, decide whether to prefer a designated source, keep both values with provenance, or request human review. Do not overwrite source systems without an approved process.

Privacy and fairness considerations

Collect only the attributes needed to resolve records for the stated purpose. Sensitive personal data can improve match rates while increasing privacy risk. Restrict access to raw attributes, encrypt transfers and storage, set retention rules, and document how a person can challenge an incorrect association where applicable.

Test matching quality across languages, transliteration, name conventions, and data quality differences between regions or groups. A system can produce uneven error rates if some records have richer identifiers than others. For high-impact use cases, require human verification and a clear explanation before an automated match affects a person’s access or treatment.

How to choose entity resolution software

• Connector and batch capabilities for relevant sources.
• Configurable rules, probabilistic scoring, and explainable results.
• Human review queues and reversible merge decisions.
• Lineage, audit history, and model or rule versioning.
• Privacy, retention, and access controls.
• Monitoring for match rates, exceptions, drift, and source quality.

Run a pilot with labeled examples and real edge cases. Include records that should match, records that look similar but should not, and cases with missing fields. Compare the tool’s results to expert review before connecting automated merges to operational workflows.

Conclusion

Entity resolution can create a more consistent view of customers, suppliers, products, and other records. The safest approach combines careful normalization, evidence-based matching, confidence thresholds, human review, and visible provenance. Start with one well-defined business use case and measure the impact before expanding to more data.

How to set thresholds with evidence

Do not choose match thresholds from intuition alone. Build a labeled sample that reflects the records and errors in your sources. Include clear matches, clear non-matches, and ambiguous pairs. Have experienced reviewers label the sample independently, then discuss disagreements so the ground truth is consistent enough to test against.

Run the candidate rules on that sample and calculate precision and recall at different thresholds. A strict threshold may create fewer false merges but leave more duplicates unresolved. A permissive threshold may improve coverage while increasing the chance of joining two distinct people or businesses. Choose based on the consequence of each type of error, not on a single score that hides the tradeoff.

Keep a review band between automatic match and automatic non-match decisions. For instance, a high-confidence pair may link automatically, a middle range may need review, and a low score may remain separate. Exact cutoffs depend on the data and use case. Reassess them when you add a new source, change normalization logic, or observe a shift in source quality.

Manage clusters and merge history

Pairwise matches can create larger groups of linked records. If record A matches B and B matches C, the system may infer that A and C represent the same entity even when their own evidence is weak. Use clustering rules that prevent one bad pair from collapsing many distinct people into one profile. Make the cluster’s evidence inspectable and allow a reviewer to split a group.

Prefer a canonical entity identifier that points back to all source records rather than deleting duplicates. Store merge and unmerge events with the actor, timestamp, reason, and rule or model version. If a user challenges a match, the organization needs to trace the association and correct affected downstream systems. A reversible link is safer than destructive record consolidation.

Test downstream impact before automating

Entity resolution often feeds CRM, fraud review, reporting, billing, or customer support workflows. Before automatic updates, run the system in shadow mode and compare its decisions with current operations. Identify which actions are safe to automate and which require a second control. A reporting dashboard might tolerate a small number of unresolved cases, while a payment or eligibility decision may require stricter evidence.

Monitor matched-record counts, reviewer agreement, false-match investigations, split requests, and changes after source updates. Track both benefits and harm: fewer duplicate accounts are useful, but an incorrect merge can expose one person’s data to another or misroute a case. Create an incident procedure for discovering a false match, including which linked systems must be corrected.

Build a human review process

Reviewers need focused evidence, not a raw database dump. Present normalized and original values side by side, explain which fields agreed or differed, and show the confidence reason in plain language. Provide “match,” “not a match,” and “need more information” outcomes. Capture reviewer feedback as training or tuning data only after checking its quality and retention implications.

Set service targets for the review queue and route high-impact cases to trained staff. Sample completed reviews for quality, and maintain guidance for edge cases such as shared household addresses, subsidiaries, common names, business name changes, and transliteration. A clear process reduces the chance that two reviewers interpret the same evidence differently.

Governance for a long-lived entity record

Assign an owner for each entity domain and define which system wins when source records conflict. Let authorized stewards correct a canonical view while preserving source lineage. Review access to attributes according to sensitivity, and make deletion requests propagate through derived records when required. Retain only attributes that support a documented purpose.

Finally, explain matching limits to users. A resolved entity is a data association, not necessarily proof of identity or intent. Make that distinction clear wherever the result could affect an individual. Strong governance lets the organization benefit from connected records without treating a probability score as certainty.