Entity resolution: how to tell when two records are the same customer

Your CRM says "ACME Industries". Your ERP says "Acme Inds. Pvt. Ltd.". Your billing system says "Acme Industries Private Limited" at an old address. A person can see these are one company in a second. A computer cannot, unless someone teaches it how.

That teaching is entity resolution. It sits underneath every attempt to get one customer list, one supplier list or one product catalogue. This guide explains how it works, step by step, with a demo you can try.

What entity resolution means

An entity is a real thing: a customer, a supplier, a product, a person. A record is what a system writes down about it. Entity resolution finds all the records that point to the same entity and links them, so the company sees one thing instead of many.

You may also see it called record linkage, deduplication or matching. They describe the same idea at different scales.

Why it is hard

• Spelling and shortcuts. "Pvt Ltd", "Private Limited" and "P. Ltd." are the same thing.
• Missing fields. One system has the tax ID, another does not.
• Old data. A company moves, a person changes phone number.
• Look-alikes. Two different companies can share a name in different cities.
• Scale. Comparing every record with every other record grows very fast. A million records means hundreds of billions of possible pairs.

How it works, in six steps

1. Clean. Put every record in the same shape: upper or lower case, standard abbreviations, address parts split out, ID numbers checked for the right format.
2. Group. Only compare records that share something, such as the same PIN code or the same first letters of a name. This step, called blocking, cuts billions of pairs down to a manageable number.
3. Compare. For each pair, check each field. Exact for IDs, "how similar" for names and addresses.
4. Score. Add up the evidence. A matching tax ID counts for far more than a matching city.
5. Decide. High scores match automatically. Low scores do not. The middle goes to a person to approve.
6. Merge. Build one record, choose which value wins for each field, and keep a link to every source record.

Try it: score a pair

The weights here are an example to show the idea, not a standard. Real systems learn or tune weights from your own data.

Rules or probabilities?

There are two main ways to decide a match, and most real systems use both.

A useful detail for Indian data

For Indian companies, the GSTIN is a strong identifier. It is 15 characters long, starts with a two-digit state code, and carries the business's 10-character PAN inside it. So two GSTINs from different states can still point to the same legal entity, through the shared PAN. A good matching setup uses that, instead of treating each GSTIN as a separate company.

Which value wins after a merge

Once records are matched, the merged record needs one value for each field. The rules that pick it are called survivorship rules. Common ones are simple:

• Most trusted source wins. The tax ID comes from the system that checked it against the GST portal.
• Most recent wins. The address comes from whichever system was updated last.
• Most complete wins. The record with a full address beats one with only a city.
• A person decides. For fields that matter, such as credit limits, a steward picks.

Write these rules down per field, and keep every source value. If a rule turns out to be wrong, you can rebuild the merged record without going back to the source systems.

How to know it is working

Track three simple things each month: how many records were matched automatically, how many went to a person, and how many merges were later undone. A rising undo count means the auto-match bar is too low. A growing review queue means it is too high, or the source data needs cleaning first.

Why a person stays in the loop

A wrong merge is worse than a missed one. Joining two different companies can send an invoice to the wrong customer or mix up their credit limits. So the uncertain middle should go to someone who knows the business, with the evidence laid out. Their decision is logged, and the system learns from it.

Every merge should also be reversible and traceable. An audit trail that shows who approved which match, and why, is what lets you undo a mistake months later.

Where it pays off

• One customer view for master data management.
• Breaking data silos between teams and acquired companies.
• Privacy requests, where you must find every copy of one person's data.
• Supplier risk, where one supplier trades under several names.

Where Samvrik fits

Smelter does entity resolution inside your own environment. It cleans and matches records across your systems, auto-matches the clear cases, sends unclear ones to a person with the evidence, and keeps a link from every merged value to its source. See how Smelter works.

Common questions