Table of Contents
- Why does one customer end up as seven entities in four systems?
- What parent-child hierarchy survives an acquisition?
- How do you separate the global account from the local buying entity?
- How should attribution work across North America, EMEA and APAC?
- How do you manage duplicates at entity scale?
- What happens to search visibility when brands consolidate?
- What does group board reporting need?
- How should a migration be sequenced?
- Where this model does not fit
- Frequently Asked Questions
Need help with B2B Marketing?
Let the smarketers’ team drive your pipeline with data-led campaigns and AI-powered growth strategies.
Ask a group CRO how much revenue their largest customer represents and you will often get three answers, depending on who runs the report. Multi-entity businesses need a parent-child account hierarchy in which the global account is the reporting unit and the local legal entity is the transacting unit. Collapsing those two into one record is the most common cause of group-level revenue reporting nobody trusts.
We ran a consolidation for a manufacturing group with operations across North America, EMEA and APAC where the same customer existed as 34 separate account records. Deduplication was the easy part. Agreeing which entity owned the relationship took six weeks and three escalations.
Why does one customer end up as seven entities in four systems?
Because the structure grows from decisions nobody made together. An acquisition brings its own CRM. A regional subsidiary buys separately for tax reasons. A partner registers a deal under a different legal name. A local team creates a record because it cannot see the one that exists.
STAT
The average B2B buying decision now involves 13 internal stakeholders and 9 external influencers, and procurement is a decision-maker in 53% of business buying cycles. Source: Forrester, State of Business Buying, January 2026.
Those stakeholders are often spread across the customer’s own legal entities, so the fragmentation exists on both sides. Your seven records may map to their four purchasing entities, and neither structure matches the other.
What parent-child hierarchy survives an acquisition?
A three-level model handles almost every real case. More levels look tidy on a diagram and collapse the first time someone maintains them.
| Level | What it represents | What it owns | Who maintains it |
|---|---|---|---|
| Group | The ultimate parent, the reporting unit | Group revenue, relationship strategy, contract framework | Central RevOps |
| Legal entity | The party that signs and pays | Deals, invoices, contracts, tax identifiers | Regional operations |
| Site or division | Where the work happens | Activities, contacts, delivery records | Account owner |
Two rules make it durable. A deal always attaches to a legal entity, never the group, because the group cannot sign anything. And the group record carries no transactional data of its own; it aggregates. Break either rule and double counting appears inside a quarter.
Record the relationship type on the link rather than assuming ownership. Wholly owned subsidiary, majority holding, joint venture and franchise behave differently in reporting and in contract terms, and one generic parent link cannot express that.
How do you separate the global account from the local buying entity?
By deciding, per account, which holds the relationship strategy and which holds the commercial terms. Write it into a field rather than leaving it to convention.
| Question | Global account holds it | Local entity holds it |
|---|---|---|
| Who signs the contract | No | Yes |
| Who sets pricing framework | Usually | Applies within it |
| Who owns the relationship plan | Yes | Contributes |
| Whose revenue does finance recognise | Aggregated view | Recognised here |
| Who is measured on the number | Group and local, differently | Local |
That final row causes most of the trouble. If two people are paid on the same revenue with no defined split, the hierarchy becomes a commission dispute rather than a data model. Agree the credit rule before migration, not after.
How should attribution work across North America, EMEA and APAC?
Region is a property of the transacting entity, not of the marketing activity. That single decision resolves most cross-region reporting arguments.
A campaign run centrally can generate a deal signed by an EMEA entity while the influencing contacts sit in North America. If attribution follows the campaign’s region, the report tells EMEA it produced nothing. If it follows the entity, revenue lands where it is recognised and influence shows as a separate cross-region flag on the deal.
Report that flag as its own number. In group businesses it is usually larger than anyone expects, and it is the evidence that justifies central programme spend against regional budgets.
PROOF POINT
On an enterprise HubSpot migration for Botsync, we consolidated fragmented account records into a single parent-child hierarchy before any reporting was rebuilt, so that group and entity numbers reconciled from day one. [FIELD: number of duplicate account records merged and the change in group revenue reporting accuracy after consolidation]
How do you manage duplicates at entity scale?
Standard fuzzy matching fails here, because two records with the same name may be different legal entities that must stay separate. The logic has to tell a duplicate from a sibling.
| Signal | Duplicate | Sibling entity |
|---|---|---|
| Same registration or tax identifier | Yes, merge | Not applicable |
| Same name, different registered address | Investigate | Usually a sibling |
| Same domain, different country | Investigate | Often a sibling |
| Same name, same address, different owner | Merge after ownership check | No |
| Different name, same registration number | Merge | No |
The reliable key is a registration or tax identifier, which means adding it as a field and populating it during migration. Name and domain matching alone merges records that should never be merged, and unmerging is far harder than merging in most systems. Our HubSpot implementation projects treat identifier capture as a prerequisite, not an enhancement.
KEY TAKEAWAY
Match on registration identifiers, not on names. Two subsidiaries can share a name, an address and a website while being separate contracting parties, and merging them destroys the contract history of both.
What happens to search visibility when brands consolidate?
An acquisition ends with a decision to retire or keep the acquired brand, and that has consequences beyond the CRM. Retiring a brand removes an entity search and answer engines have already learned, along with the third-party references attached to it.
STAT
Roughly 84% of AI citations come from earned media and third-party sources. Source: MozCon, 2026. Median enterprise B2B brands appear in just 3% of relevant AI Overviews. Source: Walker Sands B2B AI Search Visibility Benchmark, 828 companies across 14 industries and 45 million queries, published June 2026.
Because so much visibility rests on third-party mentions, consolidation destroys the ones tied to the retired name unless they are updated. Before retiring a brand, list every directory, review platform, association listing and trade reference carrying it, and plan the update inside the migration rather than as a marketing task afterwards. Redirects handle your own pages. They do nothing for a listing on someone else’s site.
What does group board reporting need?
Four views, kept separate rather than merged into one dashboard that answers none of the questions properly.
| View | Question it answers | Grouped by |
|---|---|---|
| Group revenue | How large is this customer to us | Ultimate parent |
| Recognised revenue | What can finance reconcile | Transacting entity |
| Cross-region influence | What did central programmes contribute | Deal flag, reported alone |
| Pipeline by entity | Is this one large opportunity or several | Entity, with parent visible |
The third view is never added to the first two. The fourth stops a single group pursuit being read as several small unrelated deals.
How should a migration be sequenced?
Order matters more than speed. Each step depends on the one before it.
- Agree the hierarchy definition and the credit rule with finance and sales leadership, in writing.
- Capture registration or tax identifiers for the top accounts covering most of the revenue.
- Build the hierarchy on those accounts first and validate the totals against the finance ledger.
- Migrate open deals, attaching each to a legal entity rather than to a group record.
- Migrate closed history without attempting to correct it retrospectively.
- Rebuild reporting last, only after the totals reconcile.
Step five is where projects overrun. Historical records were created under different rules and cannot be made consistent with the new model at reasonable cost. Migrate them, label the pre-migration period, and report across the boundary with a stated caveat. Retrofitting five years of inconsistent history is how a twelve-week martech integration becomes a nine-month one.
Where this model does not fit
It is unnecessary below a certain complexity. A business with one operating company and a few overseas offices does not need three levels, and imposing them creates maintenance work without improving any report.
It assumes someone owns the hierarchy centrally. Where each region administers its own CRM configuration, the model degrades within two quarters as maintenance rules drift apart.
It cannot resolve genuine commercial ambiguity. If two regions both legitimately own a relationship, the data model can only reflect the decision the business makes. Pretending a hierarchy will settle a territorial dispute just moves the argument into the CRM.
Finally, this is an operating structure, not a growth mechanism. It makes group numbers trustworthy. Whether that changes any decision depends on what the board does next.
Frequently Asked Questions
How should a holding company structure its CRM?
Use a three-level hierarchy where the group record is the reporting unit, the legal entity is the transacting unit that owns deals and contracts, and the site or division holds activity and contacts. Record the relationship type on each link, because subsidiaries, joint ventures and franchises behave differently in both reporting and contracts.
How do you merge CRMs after an acquisition?
Sequence it. Agree the hierarchy and revenue credit rules in writing first, capture registration identifiers for the accounts covering most revenue, build and validate the hierarchy on those, then migrate open deals before closed history. Rebuild reporting last, once entity totals reconcile against the finance ledger.
Should a deal be attached to the group or the local entity?
Always the legal entity, because the group cannot sign a contract. The group record should aggregate rather than hold transactional data of its own. Attaching deals at group level produces double counting the moment the same opportunity is also recorded locally, and it breaks reconciliation with finance.
How do you avoid merging subsidiaries that share a name?
Match on registration or tax identifiers rather than on company name or domain. Two subsidiaries can share a name, an address and a website while remaining separate contracting parties. Populate the identifier field during migration, and treat name-only matches as candidates for investigation rather than automatic merges.
How should revenue be attributed across regions?
Treat region as a property of the transacting entity rather than of the campaign. Revenue lands where it is recognised, and cross-region influence is captured as a separate flag on the deal and reported as its own figure. Never add influenced revenue to recognised revenue in the same total.
What happens to SEO when an acquired brand is retired?
You lose the third-party references attached to the old name unless you update them. Research presented at MozCon in 2026 found roughly 84% of AI citations come from earned and third-party sources, so directory entries, association listings and trade coverage need an update plan. Redirects only fix pages you control.
Enoch Pakanati
CEO





