Resolving a Tangled Corporate Family Into One Clean Account Tree

You have a scattered pile of account records for one enterprise: duplicates, partial names, a purchased parent link that smells wrong, and a handful of records with no parent at all. This guide is for RevOps, revenue operations, and the data steward answerable for how the tree was built. It carries one corporate family from that tangle to a verified parent-child tree, with the real sources checked, the intermediate counts, and the wrong turns left in.

I will use a US-registered enterprise as the worked example throughout because that is the case with the richest public evidence. The method transfers to any jurisdiction; the sources change, the ranking does not.

Decide which tree you are building before you touch a source

There is no single correct hierarchy for a company. The same records legitimately produce two different ultimate parents, so the first decision is which question you are answering.

A finance or liability hierarchy prioritizes the ultimate legal parent: who pays the debts. A sales hierarchy prioritizes the effective sales parent: can the parent force the child to buy. These are different trees over identical records, and if you skip this decision you will resolve the wrong question and only notice when territories come out unbalanced.

The reason the trees diverge is provider basis, not provider quality. D&B builds on ownership above 50 percent. GLEIF builds on accounting consolidation, where the ultimate parent is the highest-level legal entity that prepares consolidated financial accounts within the group. A "conflict" between them is frequently two correct answers to different definitions.

For the worked example I am building a sales hierarchy, because the downstream consumer is territory routing. That choice means when a legally correct parent has no purchasing control over a child, I will not let it sit at the top of that arm.

The sources, in the order I actually consult them

Consult public linkage sources in a fixed order and stop climbing the cost ladder as soon as a higher-provenance source answers the question. The order below runs from most authoritative and free to weak or paid.

Exhibit 21 is the attachment to a Form 10-K that lists subsidiaries of the registrant, the state or jurisdiction of incorporation, and the names under which they do business, per 17 CFR 229.601. It is the strongest single source for a US parent, with one large caveat covered in the failure-modes section: immaterial subsidiaries can be omitted under Item 601(21)(ii) of Regulation S-K.

OpenCorporates treats each linkage as a provenanced claim. A subsidiary statement may have been parsed from an SEC filing, or a user may have asserted one company is a parent of another. Its control statements derive primarily from the UK Companies House People of Significant Control dataset, and its subsidiary relationships derive from SEC archives. That provenance is exactly what lets you rank one claim above another.

GLEIF and OpenCorporates published the first open-source file linking OpenCorporates records to the LEI, which means you can cross-walk a registry entity to its consolidation-based parent without paying a vendor. GLEIF Level 2 collection principles were set in March 2016 and data collection began in May 2017, so coverage is deep but not universal; a parent without an LEI will simply be absent.

Identifiers are not interchangeable across providers

The three ultimate-parent identifiers mean specific, different things, and their definitions shift by provider. Get this wrong and you will merge two trees that were never the same.

The global ultimate D-U-N-S belongs to a business's worldwide ultimate parent. The domestic ultimate D-U-N-S belongs to the highest-level family member within a specific country. The parent or HQ D-U-N-S belongs to a business's immediate headquarters or parent. A subject may be its own domestic ultimate, and a subject may be its own global ultimate, which is common for standalone entities.

Notice the empty cell. GLEIF has no domestic-ultimate concept. If your CRM has a domestic-ultimate field, it can only be populated from an ownership-basis source, and you cannot backfill it from LEI data. Recording which basis each value came from is not bookkeeping; it is what keeps the tree interpretable a year later.

The worked example, tangled to clean

Start from the pile and drive it to a tree in nine steps. Each step below has a done condition so you can tell when to move on.

Here is how those steps actually played out on the example pile.

Step 1, profiling. The pile came in at 47 records for what I believed was one enterprise. Profiling every source object for row counts, null rates per field, and distinct value counts is the move that surfaces unused fields and inconsistent formats. Distinct names came back at 31, which already told me roughly a third of the pile was duplication.

Step 2, natural key and de-dup. No clean external ID existed, so I constructed one from normalized legal name plus jurisdiction code. That collapsed the 47 records to 29 real entities. This is the point where you either establish a natural key or accept that every later join is guesswork.

Step 3, authoritative links. The registrant filed a Form 10-K, so Exhibit 21 was the first pull. It named 22 of my 29 entities as subsidiaries with jurisdictions. Seven were not in the exhibit. Rather than call those seven orphans, I cross-ran OpenCorporates and GLEIF Level 2. OpenCorporates placed four of the seven via SEC-derived subsidiary statements. GLEIF placed one more. That left two genuinely unplaced.

The first wrong turn. One of the two remaining unplaced records shared the parent's email domain, so my initial instinct was to link it on domain alone. That would have been a domain false positive. The shared domain turned out to be a shared-service center using the group domain without being owned by the group in the sales sense. Domain is a weak signal that breaks on exactly this pattern, so I held the link until a registry or LEI source corroborated it. None did. It stayed an orphan pending a dated corporate event.

Step 4, assigning the tree. Walking each arm to domestic then global ultimate is mechanical once the links are sourced, provided you stick to the definitions for the tree you chose in the first section.

When a purchased link disagrees with the registry

Resolve conflicts by provenance rank, and record which source won. No single canonical tie-break procedure is published, so the governing principle is field-level source of truth: document, per field, which system originates the data and which conditions allow it to be overwritten.

On the example, a purchased feed placed one mid-tier entity directly under the global ultimate, skipping an intermediate holding company. Exhibit 21 and the OpenCorporates relationship both showed the intermediate holding company as the direct parent. This is the disagreement the whole method is built to handle.

The rule I apply, and the one I recommend you assert in your own governance doc:

Applying it, the registry filing and the relationship file both outrank the purchased feed. The intermediate holding company won as direct parent. I logged the purchased feed as the losing source with a note that it had flattened the chain, which is a known behavior of sales-oriented feeds. The reason logging matters: the next steward who sees the purchased feed will otherwise re-open the same fight.

A conflict between two providers is usually two correct answers to different definitions, so rank the sources rather than counting them.

This is the stage where the search cost is highest, because you are reconstructing a chain by hand across three sources per entity. When the family is large or the entities span jurisdictions, Refolk removes the part where you first have to find and identify every entity and the people who own its data, so the manual work narrows to adjudicating the links you actually have.

How this goes wrong

Most of the value in a hierarchy standard is knowing how it fails. Each failure below states what the signal looks like when it lies, and how to catch it.

• The Exhibit 21 completeness illusion. The subsidiary list looks authoritative, but it legally omits immaterial subsidiaries. A real subsidiary reads as an orphan. The lie: absence interpreted as "no link." Check: cross-run OpenCorporates and GLEIF before declaring any orphan final.
• Building the wrong tree entirely. Using a finance or liability ultimate for sales territory. The lie: a legally correct parent that has no purchasing control over the child. Check: ask "if I sell to the parent, can they force the child to buy," and if not, do not seat that parent atop a sales arm.
• Stale ultimate after M&A. The ultimate-parent field no longer matches the actual top of the chain after an acquisition or reorg. The lie: a confident field that is quietly out of date. Check: re-verify against a dated registry or news event, never against the CRM's own field.
• A reparent that looks fixed but is not. The hierarchy looks right in the UI while downstream data says something different, misrouting leads and misassigning territories for weeks. The lie: the UI view. Check: query the stored ultimate-parent field directly.
• Circular reference runaway. A's parent is B and B's parent is A. Adding one link creates infinite recursion until the query hits MAXRECURSION or tempdb fills. The lie: a link that seems harmless in isolation. Check: a recursion cap plus a visited-node set in the cycle-detection query.
• The domain false positive. A shared domain across a rebrand or a shared-service center implies a link that ownership disproves. This is the wrong turn I took above. Check: require registry or LEI corroboration before committing any domain-only link.
• An auto-link committed without review. A confidence score is trusted blindly and written straight to the CRM. Check: enforce the approval gate so confidence and risk are evaluated and an approver signs off before anything is written.

The stakes on getting this wrong are not abstract. Forrester found data inaccuracies can increase sales cycle length by 15 to 20 percent, and Gartner estimates poor data quality costs organizations an average of 12.9 million dollars per year. A mis-parented enterprise account routes to the wrong team on both counts.

The approval gate and who staffs it

Never write an inferred parent without a named human approving it, with the reason recorded. Published stewardship workflows are explicit: an issue is detected, a change is recommended, confidence and risk are evaluated, an approver reviews and approves or rejects, and only then is the change written to the CRM.

The governance layer that supports this needs role-based access, field-level controls, approval permissions, audit logs, recommendation history, visible confidence scores, and approval statuses with rejection reasons and a full approval history. In plain terms: route every change through one approval path with a named approver and a documented reason.

That approver is usually a scarce specialist, which raises the stakes on documentation.

In Refolk's index the top employers for data-steward and master-data titles include JPMorganChase, Siemens, Citi, and UnitedHealth Group, which tells you where the specialists cluster if you need to hire one. Because the role is thin, the approval statuses, rejection reasons, and full history are the assets that outlast any single steward. Build the audit trail as though the person who made every decision will be gone in a year, because eventually they will be.

Load, verify, and keep it current

Load the tree in two passes, verify against stored fields not the UI, and re-verify on corporate events rather than on a decay percentage.

Self-referencing hierarchies create a chicken-and-egg problem: a child cannot point at a parent that has not loaded yet. Load all accounts first without the parent reference, then run a second pass to populate it. Keep automations controlled during the load; a 200,000-record load with automations active fires 200,000 automations and can hit governor limits. Both migration guides and hierarchy-tool vendors disagree on whether de-dup or enrichment comes first, but they agree the parent-reference load is a separate second pass.

For re-verification, anchor to events, not a number. Nobody publishes a decay rate specific to hierarchy fields; that is not established. The defensible bound is general firmographic decay, measured at 2.1 percent per month, roughly 22.5 percent annualized, up to 30 to 40 percent per year in high-mobility sectors like technology and financial services. What actually breaks a hierarchy is M&A, spin-offs, reorganizations, and rebrands, so make the corporate event your trigger and the percentage merely your reminder that fields go stale.

Run a quarterly audit of unused fields, inactive workflows, and orphaned records, because without scheduled cleanup, CRM technical debt becomes a migration project within three years. Standing detection reports should include accounts in hierarchy-eligible industries without parent relationships, an alert when a hierarchy exceeds five levels, and child accounts with no ultimate-parent reference populated.

The tree you finish with is only as trustworthy as the provenance behind it. When someone challenges a parent link six months from now, the answer is not "the CRM says so"; it is the source that won, the source that lost, and the approver who signed. That record, more than the tree itself, is the deliverable.

entity: <child legal name + jurisdiction code>
direct_parent: <parent legal name>
tree_type: sales | liability
winning_source: SEC Exhibit 21 | GLEIF L2 | OpenCorporates | domain
losing_source: <source that disagreed, or none>
reason_won: <one line, e.g. registry outranks purchased feed>
approver: <named steward>
approved_on: <date>