How to Fix a Broken Account Hierarchy in Your CRM

What actually breaks in an account hierarchy?

Four failure patterns cover almost everything: orphans, false parents, missing middles, and duplicated branches. Each one distorts a different report, which is why the symptom rarely points at the cause.

Orphans are accounts with no parent that should have one. A regional subsidiary created by a rep who did not check the hierarchy, now sitting at the top level as though it were an independent company. This is the most common failure and the easiest to fix.

False parents are the opposite. Somebody set a parent based on a name match rather than an ownership relationship, so two unrelated companies with similar names are joined. These are rare and expensive, because they silently combine revenue that belongs to different customers.

Missing middles happen when a hierarchy skips a level. A location reports directly to the global parent, bypassing the regional buying entity that actually holds the contract. Roll-ups still work, but any report at the buying entity level understates the relationship.

Duplicated branches come from acquisitions and rebrands. The acquired company keeps its old account, a new account gets created under the acquirer, and both stay active with revenue split across them. Retention reporting reads this as a churn plus a new logo.

Why does hierarchy matter for revenue reporting?

Because retention math operates on the customer, and the customer is a hierarchy rather than an account record. Get the structure wrong and every retention number is wrong by an amount nobody can estimate.

Consider a customer with four subsidiaries. One subsidiary cancels, the other three expand. At the correct parent level, this is a contraction inside a net expansion, and the reconciling waterfall shows it precisely: beginning ARR, churned customer ARR, churned product ARR, product decrease ARR, new customer ARR, new product ARR, increased product ARR, and ending ARR. Every movement lands in the right bucket and the ending balance becomes next month's beginning balance.

With a broken hierarchy, that same month reads as a full customer churn plus three unrelated expansions. Gross retention drops, the customer count changes, and the churn analysis chases a customer who never actually left.

The distortion runs the other way too. Territory credit depends on knowing which entity a deal belongs to, and coverage reporting on a named account list depends on the list resolving to the same set of records the sales team is working. When those disagree, pipeline coverage for the enterprise segment is measuring a different population than the one the enterprise team owns.

How do you decide what the parent should be?

Structure the hierarchy around who signs the contract, not around who owns the shares. Legal ownership answers a question your revenue reports are not asking. The buying entity model wins for most software companies because it matches how the money moves. A conglomerate where each division runs its own procurement, signs its own contracts, and holds its own budget contains several customers, and treating it as one customer produces retention numbers that describe nobody.

Set a three-level standard and enforce it. Global parent for the organization, buying entity for the contracting party, and operating location where the product gets used. Deeper structures look precise on a whiteboard and get abandoned in practice, because every additional level adds work to every record a rep creates.

Write the tiebreaker rule down. When a division's buying behavior is unclear, default to whichever level appears on the invoice. That rule is unambiguous, checkable by anyone, and settles most arguments before they start.

What order do you fix the hierarchy in?

Work top down by revenue, not alphabetically or by record age. Fixing the largest customer structures corrects most of the reporting distortion.

Start by listing accounts with revenue, sorted descending, and mark each with its current parent. Work down until the accounts get small enough that a hierarchy error changes nothing, which usually happens faster than expected.

Then run this sequence for each customer.

First, find every related account. Search by domain root, by billing address, and by contact email domain. Domain search catches the most, since subsidiaries usually keep a shared email domain even when the account names look unrelated.

Second, resolve duplicates before setting parents. Merging after the hierarchy is built means redoing the hierarchy. Duplicate accounts inside one branch also distort the roll-up in a way that is hard to spot, because the totals still look plausible.

Third, set the parent field from the bottom up. Assign locations to buying entities, then buying entities to the global parent. Working downward from the top creates orphan gaps in the middle that nobody notices until a report breaks.

Fourth, reassign ownership last. Hierarchy changes often change who should own the account, and doing both at once makes it impossible to tell which change caused a reporting shift.

Snapshot revenue by top-level account before you start. When somebody asks why a customer's revenue doubled, that file is the answer.

How do you keep hierarchy accurate afterward?

Restrict the parent field and audit orphans monthly. A hierarchy maintained by whoever happens to create a record decays back to its starting state.

Lock write access on the parent account field to RevOps and a short list of named admins. Reps request a hierarchy change through the same path they use for any other account request. This slows down a handful of edits per month and prevents dozens of errors.

Require a hierarchy decision at account creation for any account above a revenue or employee threshold. The creating user picks a parent or explicitly marks the account as independent. The explicit choice matters, because it distinguishes an account that has no parent from an account nobody checked.

Run a monthly orphan report. Top-level accounts with revenue, no children, and a domain that matches an existing hierarchy. That query finds most new breakage in a single pass.

How does hierarchy affect forecasting?

It changes the unit of analysis, which changes every rate you calculate from history. Win rates, deal sizes, and cycle lengths all shift when the same records get grouped differently.

Segment definitions usually key off account attributes such as employee count or revenue band, and those attributes live on the parent. A subsidiary sitting as its own top-level account gets classified as mid-market when the relationship is enterprise. The deal then enters your history under the wrong segment, and every enterprise conversion rate carries mid-market deals inside it.

Expansion analysis suffers the same way. A deal that is genuinely an expansion into an existing customer looks like new business when the entities are unlinked, which inflates new logo counts and understates expansion revenue. Since forecast approaches often treat new business and expansion as separate motions with different conversion behavior, misclassification here degrades the model rather than just the report.

Fix the hierarchy before you tune the model. Cleaner segmentation improves forecast accuracy more reliably than adjusting stage probabilities, and it is the kind of correction that holds for years rather than needing a quarterly revisit.