Key takeaway
A health score is only as good as the account it describes. When a subsidiary sits under the wrong parent, usage from one business unit inflates another, support tickets disappear into a sibling record, and the renewal date belongs to a contract nobody mapped.
Hierarchy errors change the numbers
A health score is only as good as the account it describes. When a subsidiary sits under the wrong parent, usage from one business unit inflates another, support tickets disappear into a sibling record, and the renewal date belongs to a contract nobody mapped.
These errors rarely announce themselves. They surface as a surprising classification, an executive question that cannot be answered, or a renewal review where two teams bring different contract values. Hierarchy hygiene is the unglamorous work that keeps those conversations short.
Define parent, child, and contract boundaries
Write down what each level means. A parent is the legal entity that signs, a child is an operating unit that uses the product, and a contract is the commercial instrument that carries the terms. A single customer can have several contracts across several children, and the model must allow that without duplicating the parent.
Ambiguity appears when the commercial parent and the support parent differ. Name the primary reporting relationship and record the secondary one as a reference. Every report then states which hierarchy it uses, so a dashboard and a renewal forecast are not silently comparing different structures.
Resolve duplicates and merges
Duplicates accumulate through imports, acquisitions, and sales teams creating a record before checking. The cleanup rule is to merge on a verified identifier such as a domain, a contract number, or a finance account code, never on a similar name.
Before merging, capture both records, the evidence for the match, the surviving identifier, and the owner who approved the merge. Merges that lose history create reporting gaps that are hard to explain later. Where a merge is uncertain, link the records and flag the question instead of forcing a decision.
Map contacts to the right node
Contacts inherit meaning from their account. A sponsor attached to the parent when they actually manage one child will distort stakeholder coverage for both. Use the contact's stated scope, not their seniority, to decide where they belong.
Record the contact role, the node they influence, and the date the role was confirmed. When a contact changes teams, the old relationship stays visible as history while the active mapping updates. Coverage reports should count active, confirmed contacts rather than every address in the database.
Check rollup math before the review
Two business days before a health review, run a rollup check comparing child sums to parent totals for seats, usage, tickets, and recurring revenue. Differences are expected only where the model intentionally excludes a segment, and those exclusions must be documented.
The check is also a chance to catch double counting. A child attached to two parents will appear twice in a portfolio view. The report should show the parent once and the child once, with a note explaining the relationship rather than an unexplained inflated total. Where a difference cannot be explained, the review treats the affected accounts as unverified until the model is corrected.
Record hierarchy changes with dates
Hierarchy changes are events: an acquisition closes, a business unit is renamed, a contract is novated. Each change carries an effective date, a reason, the source document, and the person who approved it. Retroactive changes need extra care because they alter historical reporting.
Where a restatement is unavoidable, keep the prior structure available for comparison. A chart that jumps because the hierarchy changed is not a customer trend, and presenting it as one damages trust in every number that follows.
Handle the acquisition exception
Acquisitions create temporary ambiguity. The acquired company may keep its own contract, systems, and support process for a transition period. The register should model both structures and mark the transition end date rather than forcing an immediate merge.
During the transition, reports label the affected accounts and state which structure applies. The CSM and the commercial owner agree who communicates with the acquired team. Without that agreement, the customer receives duplicate outreach from two parts of the same company.
Assign ownership for hierarchy maintenance
Hierarchy work needs a named owner in revenue operations and a partner in customer success. The owner maintains the model, reviews change requests, and runs the quarterly audit. The CS partner confirms that the structure matches how accounts are actually managed.
Change requests follow a simple path: request, evidence, impact on reporting, approval, effective date. Small teams can run this in a shared queue. The point is not ceremony; it is that a change to a parent record can alter every downstream report.
Reconcile the model with finance
Finance holds the legal entity list, contract values, and billing relationships. Customer success holds usage, contacts, and support history. A quarterly reconciliation prevents the common split where the CRM hierarchy follows sales territory and the billing hierarchy follows legal structure.
Record the differences rather than forcing one model to win. A territory view is useful for coverage, a legal view is necessary for renewals and revenue reporting. The reconciliation confirms that each report names the structure it uses and that account identifiers map between them.
Publish a quarterly hierarchy audit
Once a quarter, sample twenty accounts and verify parent, children, contracts, contacts, and ownership. Record the error rate, the types of error found, and the fixes applied. Share the summary with sales, finance, and customer success so the cost of bad data is visible.
Use the audit to improve the intake rules rather than only cleaning the current records. If most errors enter through a particular import, fix the import. If they enter through manual creation, simplify the form or add a duplicate check at the point of entry.
Common questions
What defines a parent account?
The legal entity that signs the contract. Children are operating units that use the product, and contracts are recorded separately so multiple agreements can sit under one parent.
How should duplicates be merged?
Only on a verified identifier such as a domain, contract number, or finance code, with the evidence and approving owner recorded. Uncertain matches are linked and flagged, not forced.
Why do rollups disagree with child totals?
Usually because a segment is excluded or a child is attached to more than one parent. The exclusion or relationship must be documented before the report is used.
Who owns hierarchy maintenance?
Revenue operations maintains the model, with a customer success partner confirming that it matches how accounts are managed.
Sources and context
Sources provide public context. Their inclusion does not imply endorsement of this site or a guaranteed business result.
Apply this to your customer journey
Define a support role with visible boundaries.
Bring one recurring workflow. We will help map the approved inputs, review owner, evidence, and escalation points.
Book a free consultation