Entity resolution is the work of recognizing that a CRM account, an accounting debtor, a support organization and a billing customer are the same real-world company – and giving that company one identity your queries and AI agents can rely on. This post explains why it quietly breaks analytics and agents, the three matching strategies, and a practical version you can build in an afternoon.
Ask your systems how many customers you have. Your CRM says 1,850. Your accounting package says 1,410. Your support desk says 2,300, because every contact opened their own organization.
None of them are lying. They just don’t agree on what a customer is, because each system created its own record with its own ID the day someone typed the name in – slightly differently each time.
ACME BV in the CRM. Acme Belgium in the ledger. acme.be in the support desk. One company, three spellings, four IDs, zero connections between them.
For years this was an annoyance analysts worked around. With AI agents querying your data directly, it graduates from annoyance to the quiet reason answers come back wrong – which is why entity resolution earned its own check in our agent-ready data checklist. This post is the full explanation.
What entity resolution actually is
Entity resolution is matching records across systems to the real-world things they describe – companies, people, products – and assigning each thing one durable identity. The output is unglamorous: a mapping that says CRM account 0043921, debtor D-11208, support org_77 and billing cus_9x2 are all ACME BV, entity 00017.
That mapping is sometimes called a golden record or master data. The name matters less than the property: every query about ACME can now join through one ID instead of guessing at four.
Why it breaks more than it used to
Three escalating consequences.
First, counting goes wrong. Revenue per customer, churn rate, customer lifetime value – every per-customer metric is silently distorted when one customer is counted as three. The distortion isn’t random either; your biggest accounts have the most duplicate records, because more people touched them.
Second, cross-system questions become unanswerable. “Which customers with overdue invoices have an open support ticket?” requires joining accounting to support – and without a mapping, there is nothing to join on. The question isn’t hard; it’s impossible.
Third – the new one – AI agents guess. A human analyst rebuilt the ACME mapping once, in their head, and reused it for years. An agent rebuilds it per question, from name similarity, and differently each time. Same question Monday and Thursday, different customer set, both delivered with confidence. We covered why agents can’t compensate for missing structure in the context layer post; entity resolution is the sharpest case of it.
The three matching strategies
1. Deterministic: shared keys
The best matches use keys that already identify the entity in the real world. For European B2B data this is a genuine advantage: VAT numbers and company registration numbers are unique, verifiable, and present in most accounting systems. Email domains work as a second key for the long tail.
Deterministic matching is cheap, explainable and rarely wrong. Always start here – in B2B, it typically resolves the majority of records on its own.
2. Probabilistic: fuzzy matching for the rest
What’s left matches on similarity: normalized names, addresses, phone numbers, scored and thresholded. This is where “ACME BV” meets “Acme Belgium”. The trade-off is real: loosen the threshold and you merge two different companies; tighten it and duplicates survive. Neither error is free, so ambiguous pairs should land in a review queue, not get auto-merged.
You don’t need to invent this. Splink, the UK Ministry of Justice’s open-source library, does probabilistic linkage at serious scale – around a million records in a minute on a laptop – and is a better afternoon than writing your own name normalizer.
3. The mapping table: where results live
Whatever strategy produced the match, the output belongs in one place: a cross-reference table in your warehouse – entity ID, source system, source ID, match method, confidence. Every downstream query and every agent joins through it. If the mapping lives in a notebook on someone’s laptop, it isn’t entity resolution yet – it’s a one-time analysis that will go stale.
How to build it in an afternoon
- Get the sources into one queryable place. Matching across systems needs the systems side by side – this is why entity resolution gets dramatically easier once a warehouse exists.
- Run the deterministic pass. Match on VAT number, registration number, email domain. In most B2B datasets this resolves well over half the records with near-zero risk.
- Fuzzy-match the remainder, with a threshold that auto-accepts only high-confidence pairs and queues the rest for a human – reviewing 80 ambiguous pairs is an hour, not a project.
- Publish the cross-reference table and rewrite your two most-used customer queries to join through it. The before/after on “how many customers do we have” is your proof of value.
The failure modes to expect
Honesty about the ongoing part: entity resolution is maintenance, not a project. Corporate structures will test your definition of “one entity” – is a subsidiary its own customer or part of the parent? (Decide once, write it down.) Companies rename, merge and get acquired, so yesterday’s correct mapping goes stale. And new records arrive daily, which means the matching pass needs to run on a schedule, not once.
None of this is a reason to skip it. It’s a reason to build the small version that runs weekly instead of the perfect version that runs never.
Where Peliqan fits
The pattern needs three things Peliqan happens to be. Sources side by side: 300+ connectors syncing into a built-in warehouse, so matching runs against systems in one place.
A place to run the matching as SQL or Python transformations on a schedule, not once. And a cross-reference table every downstream consumer can join through.
That last consumer includes AI: agents querying over MCP use the same mapping table, so “everything about ACME” means the same thing on Monday and Thursday.
Resolved entities are also what make data activation trustworthy – syncing a customer health score back to the CRM only helps if the score was computed about the right customer.
The judgment calls – subsidiary rules, match thresholds, the review queue – stay yours. The platform makes them a join and a schedule instead of a project.
If you want to see your own duplicate count, book a demo: connect your CRM and accounting system, run the deterministic pass on VAT numbers, and watch how far apart your customer counts really are. Most teams guess wrong by half.
