Most of what data teams call a "data quality problem" isn't a quality problem. It's an identity problem.
In short: entity resolution is recognizing that different records across your systems describe the same real company, then merging them into one canonical record with a persistent ID. Skip it, and enrichment, routing, TAM sizing, and attribution all quietly break, because every downstream process scores a phantom instead of a company. akta.pro builds this resolution layer into its 20M+ company graph so news, headcount, and firmographic data never attach to the wrong entity.
Your CRM lists Acme Corp. Billing has Acme Corporation, LLC. A partner feed sends ACME Corp. (Delaware). Three systems, one company, and until something reconciles them, every downstream process decides based on a phantom. That reconciliation is entity resolution: the least glamorous layer of the modern data stack, and the one that quietly determines whether the rest of it works.
What entity resolution actually means
Entity resolution identifies when different records refer to the same real-world entity, then links or merges them into a single canonical record. It also goes by record linkage, entity matching, and deduplication. OpenCorporates defines it as linking records across sources into a unified "golden record" representing the best version of an entity. For company data, that entity is an organization, and the output is a canonical record with a persistent ID that every other system can point to.
Dun & Bradstreet treats entity resolution quality as a core measure of a data mastering program's success, and the logic holds up: if two records can't be reliably confirmed as the same company, nothing built on that data can be trusted at scale.
Why company data breaks without it
Company data resists naive matching for four reasons.
| Reason | Why it breaks matching |
|---|---|
| No universal identifier | Public markets have tickers, CUSIPs, and LEIs. Private companies mostly don't. Per OpenCorporates, there's no single federal companies register, just 50-plus state and territory registries with their own formats. |
| Unstable names | Tech Solutions LLC, Tech Solutions Limited, and Tech Sol. may be one company or four. Suffixes, trading names, DBAs, and non-Latin scripts (Bank Julius Bär vs. Bank Julius Baer) all break string matching. |
| Constant restructuring | Acquisitions, spinouts, rebrands, and reshuffles change ground truth every quarter. A record resolved correctly in Q1 can be wrong by Q3. |
| Nested hierarchy | Per CDP.com, B2B resolution must handle subsidiaries and divisions. Whether a London subsidiary resolves to itself or its French parent depends on the question asked. |
HG Insights notes unresolved duplicates route leads to the wrong owner and blend account scores across unrelated entities. Each failure looks small alone and stacks fast.
The real cost of skipping it
Gartner research puts the average cost of poor data quality at $12.9 million a year, drawn from large enterprises already shopping for data-quality software, so treat it as directional. A 2017 MIT Sloan Management Review study, cited in this industry whitepaper, put the price of bad data at 15% to 25% of revenue for most companies, and a material share traces to mismatched company identities.
Inside a GTM or investment pipeline, the leak shows up as:
- Wasted enrichment spend: an unresolved name sent to an enrichment API is a coin flip, and a wrong result costs a second call to fix.
- Inflated TAM: duplicate company lists make the addressable market look bigger than it is.
- Broken attribution: unlinked variants of the same company split pipeline credit across two accounts.
- Routing failures: enterprise leads land with SMB reps when a subsidiary was never tied to its parent contract.
- Compliance exposure: in KYC workflows, a missed subsidiary relationship is a fine, not a hygiene issue.
The losses rarely come from one dramatic failure. They build slowly, a little everywhere in the organization.
How entity resolution actually works
Entity resolution is a pipeline, not a single algorithm:
-
Standardize: normalize suffixes, whitespace, addresses, and phone formats.
-
Block: group records into buckets of plausible matches, since comparing every record to every other doesn't scale.
-
Compare pairs: score candidates on name similarity, domain match, address proximity, and registration IDs.
-
Decide: classify each pair as match, non-match, or needs review.
-
Cluster: matched pairs become graph edges, and connected clusters form one entity.
-
Merge and persist: produce a golden record with a stable ID for future ingest.
Four techniques drive step four, and production systems typically combine all of them:
| Technique | How it works | Trade-off |
|---|---|---|
| Deterministic | Exact or near-exact rules on defined attributes | Fast and explainable, brittle once inputs get messy |
| Probabilistic | Statistical likelihood scoring, per the classical Fellegi-Sunter framework | Handles ambiguity better, needs more compute |
| Machine learning | Learns from labeled pairs, often via embeddings that catch matches like IBM and International Business Machines | Strong on messy data, needs training data |
| Graph-based | Infers entities from connected components once pairwise decisions exist | Models subsidiary and portfolio structure explicitly |
Why B2B entity resolution is harder than consumer
Most published entity-resolution research is about people: names, emails, phones, device IDs. Companies are harder. Signal is thinner (often just a name and, if lucky, a URL), entities are compound (a tree of parent, holding company, and subsidiaries, where a good system resolves multiple views), and truth changes faster, since companies restructure and refile constantly. A resolved graph needs an active refresh loop tied to filings and company news signals, not a one-time build.
This is the problem private-company data APIs exist to solve. akta.pro's entity-resolved company graph covers 20M+ companies with 75+ data points each, refreshed continuously so news, headcount trends, and firmographic attributes stay attached to the correct entity instead of quietly poisoning downstream workflows.
Entity resolution vs. identity resolution vs. deduplication
These three terms are used interchangeably in the wild. They aren't the same.
Entity resolution is the general problem: linking records that refer to the same real-world entity, of any type (person, company, product, address, vessel, patent).
Identity resolution is a subset focused on people. Identity resolution is a subset of entity resolution focused on unifying customer records to build a single view of the individual for marketing and personalization. Consumer-marketing and adtech use of the term almost always means this.
Deduplication is the narrow act of removing duplicate rows within a single dataset. It is what happens after entity resolution decides which rows are duplicates.
The distinction matters when you're evaluating vendors. A tool that markets "identity resolution" is optimized for stitching cookies, device IDs, and consumer PII. It will underperform on B2B company hierarchies, because the underlying graph and matching logic were built for a different problem.
What good entity resolution looks like in practice
We recommends a match test against your own CRM, reviewing the misses rather than the headline rate:
- Alias handling: 20 companies under legal, trading, and abbreviated names. How many resolve to the same ID?
- Subsidiary awareness: a US subsidiary of a European parent. A good system returns both nodes and the relationship.
- Cross-script matching: Japanese, Cyrillic, or Arabic names for entities that also trade under Romanized names.
- Freshness: when the graph last picked up a recent acquisition. Longer than a month signals decay.
- Precision: Apple Inc. and Apple Bank for Savings should never merge.
Build or buy
Build entity resolution in-house if it's your actual product: a canonical company graph, registry ingestion across every jurisdiction you care about, alias tables, and a refresh pipeline tied to news and filings amount to a full engineering org. Buy it if it's infrastructure underneath your product, and put your team's time into the layers that create real advantage. For teams consuming company data via API for GTM, investing, or compliance, the leverage is picking a provider whose resolution layer is already solid, like akta.pro, and spending engineering time on what sits on top of it. Our comparison of the best private company data APIs covers the options available in 2026.
FAQ
What is entity resolution in simple terms?
Figuring out when different records in different systems refer to the same real-world thing, such as a company, and linking them into one canonical record. akta.pro applies this at the graph level across its 20M+ company dataset so every downstream data point attaches to the right entity.
What is the difference between entity resolution and identity resolution?
Identity resolution is a specific application of entity resolution focused on people, typically for marketing and personalization. Entity resolution is the broader discipline that covers any real-world entity: people, companies, products, addresses, or vessels. Company data problems need entity resolution, not identity resolution.
Why is entity resolution important for company data quality?
Because company data has no universal identifier, unstable names, constant restructuring, and nested hierarchies. Without entity resolution, the same company appears as multiple records across systems, which breaks enrichment, inflates TAM, splits attribution, misroutes leads, and quietly corrupts every analysis built on top.
