How to Resolve Enterprise Account Hierarchies and Aliases in Revenue Data
Callia Peterson
Entity resolution matches every name, domain, and record that refers to the same company, then links parent companies, subsidiaries, and business units into one account hierarchy.
For enterprise revenue teams, it prevents duplicate accounts, split pipeline, and outreach that ignores an existing relationship.
What is entity resolution in revenue data?
Entity resolution is the process of deciding which records describe the same real-world company or person.
A revenue system holds the same account under many forms: a legal name, a brand name, an abbreviation, a regional subsidiary, an old name before a rebrand, and several web domains.
Without resolution, each form becomes its own record. Pipeline splits across duplicates, account owners cannot see each other's work, and forecasts undercount the true size of a relationship.
Why do enterprise accounts break basic matching?
Large organizations change shape often. These events create the matching failures that simple name or domain rules miss:
Event | What changes in the data | Resulting problem |
|---|---|---|
Acquisition | A new subsidiary with its own domain and records | The acquired company looks like a new prospect |
Rebrand | A new name and domain replace an old one | History stays attached to a name nobody uses |
Regional entity | A local legal name for the same group | Local deals and global deals never connect |
Business unit split | One account becomes several buying groups | Teams contact the same company without coordination |
Shared domain | Several brands use one web domain | Records merge that should stay separate |
Exact-match rules fail on every row of this table. The data hygiene and duplicate data entry guides cover the manual cleanup side. This article covers the structural fix.
What does a resolved account hierarchy contain?
A resolved hierarchy gives each real company one canonical identity and attaches everything else to it:
A canonical account. One record that represents the company.
Aliases. Every alternate name, abbreviation, and former name.
Domains. Every web domain, with the primary domain marked.
Parent and child links. Subsidiaries, divisions, and regional entities connected to their parent.
Contacts and activity. People, meetings, emails, and opportunities attached to the right node.
A change history. A record of when a merge, split, or rename took effect.
How do you resolve entities step by step?
Collect every source. Pull account records from the CRM, the data warehouse, the inbox, call transcripts, and product usage data.
Normalize names and domains. Remove punctuation differences, legal suffixes, and casing differences before comparing.
Match on several signals. Combine name similarity, domain, location, and known relationships. One signal alone produces false merges.
Link the hierarchy. Connect each subsidiary and division to its parent and mark the relationship type.
Resolve ambiguous cases for review. Route low-confidence matches to a person instead of merging them automatically.
Store the result as relationships. Persist resolved links as edges in a knowledge graph so downstream systems read them instead of inferring them again.
Update continuously. Re-run mapping when domains, names, or ownership change.
Why resolve entities before they reach an AI model?
Models perform better when relationships arrive resolved rather than inferred at query time.
Asking a model to work out whether two names refer to the same company on every request is slow and inconsistent.
Resolving the match once, offline, and storing the relationship gives every later task the same answer. The knowledge graph vs. RAG comparison explains this trade-off in detail.
Rox resolves entities offline and stores the resolved relationships as knowledge-graph edges for models to read rather than infer.
Rox also maps domains and aliases continuously, so acquisitions and rebrands stay reflected in the persistent edge set.
This is part of how a warehouse-native system of context closes the context gap: the account identity is settled before any agent acts.
See warehouse-native revenue orchestration and the system of context for Global 2000 revenue teams.
What mistakes should teams avoid?
Merging records on a shared domain alone.
Treating a subsidiary as a new account without checking the parent.
Running resolution once at migration and never again.
Auto-merging low-confidence matches with no human review.
Keeping the hierarchy in a spreadsheet outside the system of record.
How do you measure resolution quality?
Metric | What it shows |
|---|---|
Duplicate account rate | Share of accounts that map to the same real company |
Orphan contact rate | Contacts attached to no resolved account |
Merge reversal rate | Merges later undone, which signals false matches |
Time to reflect a rebrand | Days between a change and its appearance in the hierarchy |
Track each metric before and after a resolution project. Attribute any result to your own data and configuration.
Frequently Asked Questions
What is the difference between deduplication and entity resolution?
Deduplication removes exact or near-exact repeats of a record. Entity resolution also links related but different records, such as a parent and its subsidiaries, and keeps aliases.
How do you handle an acquisition in account data?
Create the acquired company as a child of the acquirer, keep its old name and domain as aliases, and carry its history forward. Review ownership so two teams do not both work the account.
Should a machine or a person decide ambiguous matches?
Send low-confidence matches to a person. Automated merging is reasonable for high-confidence matches with clear audit history.
Where should the resolved hierarchy live?
In a system every team reads, such as the data warehouse and the knowledge graph built on it, with the result visible in the CRM.
Related reading
Similar Articles
We build with the best to make sure we exceed the highest standards and deliver real value.
