Entity resolution explained for business data

Entity resolution is the process of identifying which records in different systems, or even within the same system, describe the same real-world thing, such as a customer, an account, or a supplier, and treating them as one entity instead of several.

Why the same customer has five names

A single customer can exist as "Acme Corp" in the CRM, "Acme Corporation LLC" in the billing system, "ACME" in a support ticket, and a row with a typo in a spreadsheet a sales rep keeps on the side. None of these systems were built to agree with each other. Each one has its own idea of a unique key, and often no key at all beyond a free-text name field typed by a different person on a different day.

For the wider context, see our knowledge graph glossary of 40 terms.

The causes are ordinary, not exotic. Sales reps and support agents type names by hand, and hand-typed data drifts. Systems get adopted at different times with no shared identifier carried over. Companies merge, rename, or restructure into subsidiaries that keep operating under the old name in some records and the new one in others. A billing system might key on a legal entity while a CRM keys on a brand name that has three legal entities behind it. None of this is a data entry failure so much as a structural reality of running more than one system.

Deterministic matching

Deterministic matching links two records when they share an exact identifier: the same email address, the same tax ID, the same account number. It is fast, cheap to compute, and produces very few false positives, because an exact match on a strong identifier is rarely a coincidence.

Its limit is coverage. Deterministic matching only works when a shared, reliable key actually exists across the systems being compared, and in practice that key is often missing, inconsistent in format, or simply never captured in one of the systems. A CRM record with no billing ID and a billing record with no CRM ID cannot be joined deterministically no matter how confident anyone is that they refer to the same account.

Probabilistic and fuzzy matching

Probabilistic, or fuzzy, matching compares records on multiple partial signals, name similarity, address similarity, phone number, domain, industry, and combines them into a confidence score rather than requiring one field to match exactly. "Acme Corp" and "Acme Corporation LLC" at the same street address, with the same domain in an email field, score as a likely match even though no single field matches character for character.

This approach recovers the matches deterministic linking misses, but it introduces judgment: a threshold has to be set for how confident a match needs to be before two records are merged, and that threshold trades off false merges (two different companies treated as one) against missed merges (the same company left split across records). Getting this threshold wrong in either direction has real consequences, which is why fuzzy matching is usually paired with a review step for borderline cases rather than run fully automatically on every match.

Survivorship and the golden record

Once two or more records are identified as the same entity, something has to decide which values survive into the combined record, this is survivorship. If the CRM says a customer's status is "active" and the billing system says "past due," survivorship rules decide which field wins, or whether both are kept with a note about which system supplied which value. Common survivorship rules favor the most recently updated system, the system considered the source of truth for a given field, or the most complete record.

The result of applying survivorship consistently is a golden record: one record per real-world entity that downstream reports and questions can rely on as the answer, rather than each system's partial and sometimes contradictory version. A golden record is not necessarily more accurate on every single field, it is the agreed, documented resolution of the conflicts that existed across systems.

What breaks when entity resolution is skipped

Unresolved duplicates do not fail loudly, they fail by quietly distorting numbers that look plausible. If "Acme Corp" and "Acme Corporation LLC" are counted as two separate customers, revenue reported per customer looks smaller than it is, and the customer count is inflated. If a churn signal is calculated per account and one customer's activity is split across two account records, both records can look like they are declining even though the combined account is stable, which produces a false churn signal that no one asked to see.

The same distortion shows up in vendor spend, where a supplier billed under three different names across two years can look like three small vendors instead of one large one, hiding a case for consolidation or renegotiation. None of these errors trigger an alert. They sit inside dashboards and reports as numbers that are simply wrong, and they are usually only found when someone manually reconciles a total against a source system and the totals do not match.

Entity resolution in a warehouse MDM project

A traditional approach to this problem is a master data management, or MDM, project built on top of a data warehouse. A data team defines a golden record schema, writes matching and survivorship rules as part of the ETL pipeline, and periodically reprocesses records as new source data lands. This can produce high-quality results, but it is a real engineering project: someone has to model the entities in advance, write and test the matching logic for every pair of source systems, and maintain that logic as source systems change their own fields and formats over time.

MDM projects also tend to be centralized around a small data team, which becomes a bottleneck when a new source system, a spreadsheet, or an acquired subsidiary needs to be added. Each new source generally means new matching rules and a new round of testing before it can be trusted in the golden record.

Entity resolution in a knowledge graph

Inside a knowledge graph, entity resolution works as a standing layer that runs as new sources are connected rather than as a discrete project with a defined end date. Records from each source system arrive as nodes, and resolution logic determines whether a new node should be merged with an existing entity node or created as a new one, then the resulting entity's edges connect it to all the other systems where it appears, without work happens once and holds as new sources are added.

This does not eliminate the hard part of the problem, matching still requires the same deterministic and fuzzy techniques and still needs sensible thresholds, but it removes the need to redesign a schema and rebuild pipelines every time a new source system is connected. The concepts glossary has the short definition if you need it for an internal document. See how it works for how this plays out when a new system is added to an existing graph.

Comparison: manual dedupe vs. warehouse MDM vs. knowledge-graph resolution

Aspect	Manual dedupe	Warehouse MDM project	Knowledge-graph entity resolution
Setup effort	Low to start, high in accumulated hours	High, a defined project with schema and rule design	Moderate, resolution logic exists before a new source connects
Ongoing maintenance	Constant, redone by hand each time	Rules maintained by a data team as sources change	Runs continuously as sources are added or updated
Handles new systems	Poorly, each new source restarts manual work	Requires new rules and testing per source	New source becomes new nodes resolved against existing entities
Auditability	Weak, decisions live in someone's memory or a spreadsheet tab	Strong if documented, rules are explicit code	Strong, each match traceable to the records that produced it
Who does the work	Whoever noticed the duplicate	Data engineering or a dedicated MDM team	The platform maintaining the graph, with review for edge cases
Speed to first result	Immediate but narrow	Weeks to months before rules are trusted	Minutes to connect a source, ongoing resolution after that

Where SIGNLD fits

SIGNLD resolves entities across the systems it connects as part of maintaining its private knowledge graph, so a customer, account, or supplier that appears in a CRM, a billing system, and a spreadsheet is treated as one entity rather than three. Connections are read-only, and SIGNLD supports 800+ integrations with spreadsheets treated as first-class sources, not an afterthought bolted onto a warehouse. A company can connect its first system in about 15 minutes and get its first answer in minutes, without a prior modeling project to define entities in advance. When a resolved entity feeds into an answer, SIGNLD returns it as a Decision Brief: the finding, evidence links back to the specific source records involved, a confidence score, and a recommended action, so anyone reviewing the answer can see exactly which records were merged and why.

Key takeaways

A single customer can exist as \"Acme Corp\" in the CRM, \"Acme Corporation LLC\" in the billing system, \"ACME\" in a support ticket, and a row with a typo in a spreadsheet a sales rep keeps on the side.
Probabilistic, or fuzzy, matching compares records on multiple partial signals, name similarity, address similarity, phone number, domain, industry, and combines them into a confidence score rather than requiring one field to match exactly.
Unresolved duplicates do not fail loudly, they fail by quietly distorting numbers that look plausible.
Inside a knowledge graph, entity resolution works as a standing layer that runs as new sources are connected rather than as a discrete project with a defined end date.
Deterministic matches on strong shared identifiers can be automated with very low risk.

FAQ

What is the difference between entity resolution and deduplication?

Deduplication usually refers to removing exact or near-exact duplicate rows within a single dataset. Entity resolution is broader: it matches records that describe the same real-world entity across different systems, even when the records look quite different from each other, and it produces a combined golden record rather than simply deleting rows.

Can entity resolution be fully automated?

Deterministic matches on strong shared identifiers can be automated with very low risk. Fuzzy matches on partial signals carry a real risk of false merges, so most working systems automate the high-confidence matches and route lower-confidence matches to a review step rather than merging everything automatically.

How does entity resolution affect churn or revenue reporting?

If the same customer or account is split across unresolved duplicate records, revenue and customer counts can be misstated, and behavior that looks like decline in one fragment of a split record can generate a false churn signal, since the platform never sees the customer's full, combined activity.

Does entity resolution require a data warehouse?

No. It requires records from more than one system and matching logic to compare them. A warehouse is one place to run that matching, but it can also run inside a knowledge graph or a dedicated MDM tool without a warehouse as a prerequisite.

How do mergers and subsidiaries complicate entity resolution?

A merger or acquisition often means two companies' customer, vendor, or account records need to be resolved against each other for the first time, frequently with no shared identifier at all, and subsidiaries can appear as separate legal entities in billing while a CRM tracks the parent brand, so resolution has to decide at what level the entity should be defined for a given question.

Try SIGNLD free to see how your customer and account records resolve across the systems you already run, or see how it works.

Entity resolution explained: why the same customer appears five times

In this article