Untangling One Company Into a Correct Account Tree

You have one company. It shows up as a handful of conflicting records: a rebranded name in the CRM, an old legal name in billing, three subsidiaries your enrichment vendor added, and a trade name someone typed in by hand. This guide is for RevOps, data stewards, and anyone answerable for how the records got cleaned. It carries one real tangle from raw duplicates to a finished parent-child tree, with the counts, the forks, and one reversed wrong turn, so you can follow the same path on your own case.

The hard part is not the easy duplicates. Deterministic rules handle the easy 80% of duplicates; the remaining 20% is where a rebrand, an acquisition, three subsidiaries, and a DBA all collide, and where a single wrong merge quietly destroys history you can never get back. This guide shows how to decide merge, link, or keep-separate at each of those forks on evidence, not on name similarity.

The tangle I am working, record by record

I am resolving one company that appears as eight records across three systems. The company rebranded, acquired a smaller firm, operates three subsidiaries, and trades under a DBA. Here is the raw inventory I pulled in step one, before any decision.

Three facts decide almost everything in this table. Records A, B, C, and D share one EIN, so they are one legal entity wearing four names. Records E, F, and G carry their own EINs and LEIs, so they are distinct entities that must be linked, not fused. Record H shares a brand word but nothing else, and it is a coincidental name collision I keep separate.

Why name similarity is the signal that lies

Name similarity is the most available signal and the least trustworthy; it is high for both true duplicates and unrelated firms, so it can never clear the merge bar on its own. The hard keys are domain, legal entity identifier, and tax ID. Everything else is a hint.

Here is the trap that caught me on record H. Northwind Logistics scored a high name-similarity match against Northwind Analytics. If I had trusted the score I would have fused two unrelated companies. The EIN told the truth: 55-5 against 11-1. Different legal entities, no relationship, keep separate.

The published benchmark below shows why your safest key is also your blindest. Read the recall column, not just the precision column.

The lesson is structural. Your cleanest signal silently leaves most duplicates un-merged, and the leftovers are precisely the rebrands, DBAs, and acquisitions that need a human. Name plus zip code looks productive at 68.9% recall but carries a 15.3% false-positive rate, which is how unrelated firms get fused. I use domain and EIN to confirm, and I treat every name-only match as a question, not an answer.

The one safeguard you build before touching anything

Export a full, frozen copy of every candidate record before you merge, because the undo you are imagining does not exist. Native rollback is largely absent across the tools you will use, and the window to notice a mistake is short while the consequences surface late.

The specifics are worth stating plainly. HubSpot provides no native undo for merged companies; once merged, the process is irreversible. In Salesforce, after a merge the deleted record is gone permanently. HubSpot does retain a breadcrumb through its Merged Record Ids property and property history, and a third-party reconstruction exists, but with a sharp caveat: due to API limitations, unmerging creates a new record with a new record ID rather than restoring the original, with original read-only fields like Create Date preserved in a separate property group.

That caveat matters more than it first appears. Even a "successful" reconstruction hands you a new record ID, so every downstream foreign key that pointed at the original is now dangling. The pre-merge export is the only artifact that lets you rebuild the exact prior state. On my tangle I exported all eight records, their related contacts, and their billing links to a dated sheet before I merged a single pair. I needed it later.

Merge, link, or keep-separate: the discriminators

Decide on hard keys, not on resemblance. A shared EIN or domain with a different trade name means merge or alias; a distinct legal entity more than 50% owned means link; a coincidental name with different keys means keep separate. The EIN is the discriminator that name and domain cannot provide.

Start with the DBA, because it masquerades as both a duplicate and a subsidiary. A DBA, also called an assumed, fictitious, or trade name, can operate using an EIN but does not own one independently; it lets a company conduct business under a name other than its legal name. You use the same EIN for a business and all its DBAs, because an EIN is tied to the legal entity, not to individual trade names. So record D, NDS Insights, sharing EIN 11-1, is an alias to collapse onto the master. It is never a child node to link.

For true separate entities in one family, the link evidence is the LEI Level-2 relationship. Legal entities report their direct accounting consolidating parent and their ultimate accounting consolidating parent. The parent test is explicit: the parent owns more than 50% of the legal entity, consolidates accounts, and is not restricted from reporting by legal obstacles. Records E, F, and G each have their own EIN and a Level-2 relationship pointing at the master's legal entity, so they link as children. Note the limit: GLEIF reports accounting consolidation, not every ownership nuance, so it confirms the relationships it covers and is silent on the rest.

This is the fork most generic merge posts skip. They tell you to merge duplicates and stop. The real work is telling an alias (collapse), a subsidiary (link), and a coincidence (keep separate) apart, and the only reliable way to do it is the legal-entity key.

If you need a person who has run a Salesforce-to-billing cleanup end to end, describing the job in plain English and getting back the people who have done it is the shortest path. That is what Refolk is for.

Classify the corporate event on primary evidence only

Assert a rebrand, acquisition, or divestiture only from a registry filing, an LEI Level-2 relationship, or a press release. A 301 redirect and a logo change are marketing artifacts, not legal evidence, and reading them as ownership is the most common way this step goes wrong.

On my tangle, the acquired firm Harbor Metrics had 301-redirected its old domain onto the Northwind domain. That redirect is suggestive, and it is exactly the move an acquirer makes: acquirers routinely use a 301 redirect to migrate an acquired domain to a parent or sister domain, and 301s are permanent. But the same redirect is a staple of pure link-building, so it does not establish ownership. The transferable principle from engineering says it cleanly: browser-controlled redirect data does not grant access by itself.

So I did not classify Harbor Metrics as acquired on the redirect. I found the press release and the LEI Level-2 relationship, which needs consolidated accounts verifying the link. With that primary evidence in hand, E linked as a child. Had I stopped at the redirect, I might have linked a company Northwind merely partnered with, or worse, fused it.

The procedure, step by step

Work the nine steps below in order, with the one documented exception that teams who already know an acquisition happened sometimes classify events before bucketing pairs. Each step names who does it, roughly how long it takes, and what done looks like.

On execution, a few tool facts constrain you. Salesforce merges a maximum of three accounts at a time, so my four-record cluster (A, B, C, D) took two passes. The master's record ID is retained after merge, which is why choosing it is a one-way door. And vanilla Salesforce keeps exactly one surviving value per conflicting field; a second phone number or a real-but-not-chosen value is simply lost.

Field survivorship is where I nearly erred. Defaulting to the first record open can overwrite good data with stale data, because the primary wins conflicts. Record A had the new brand name but a stale address; record C had the current billing address. I set survivorship field by field on recency rather than taking A wholesale, then committed.

The master-ID choice and the cross-system repoint

Choose the master, then make every other system point at it, because the master's ID becomes the one surviving key and billing will not follow on its own. This is the step that, skipped, leaves a clean CRM sitting on top of a broken billing ledger.

Because the deleted record IDs for B, C, and D vanished at merge, any system still referencing them now dangles. The billing reconciliation is explicit: identify the customer accounts linked to the merged CRM records and replace the old CRM ID with the CRM ID of the master account, so all existing and future records sync to the correct account. I repointed the billing record that had been keyed to C's old CRM ID over to A, then re-ran the sync.

Here is where I made and reversed the wrong turn. In my first pass I merged B into C instead of into A, making the old legal-name billing record the master because it looked more complete. That buried the new brand under the old name and left A's richer CRM history orphaned. Because I had the pre-merge export from step one, I restored all four records, chose A as master deliberately, and redid the cluster. Without the export, that mistake would have been permanent, and I would have discovered it weeks later when an invoice went out under the dead name.

Build the hierarchy so roll-up and subsidiary history both survive

Link distinct entities with the Parent Account lookup and custom ultimate-parent fields, and mirror the tree in billing, because the roll-up view is not a merge side effect. It is something you build.

The native field is thin. In Salesforce the Parent Account field is a lookup pointing to another account; it establishes the parent-child relationship that builds the Account Hierarchy view, but it is a lookup, not a formula, so it does not roll up data or enforce ownership logic. Worse, Salesforce cannot tell you from a standard field whether an account has children, and finding the ultimate parent three levels up needs custom configuration or a separate query. So teams add custom Ultimate Parent Name, Ultimate Parent ID, and Hierarchy Level fields, keyed on a stable external ID like DUNS. A traversal formula typically climbs about ten levels before hitting recursion limits, which is ample for most trees.

For my tangle, A became the ultimate parent, and E, F, and G each got A's record ID in their Parent Account and Ultimate Parent ID fields, with Hierarchy Level set to 2. The billing side needs its own parallel tree: activate the Customer Hierarchy feature, assign the parent account in the billing system, and sync so both parent and child CRM IDs resolve correctly. Each subsidiary keeps its own contracts and history; the roll-up is simply the traversable parent chain, not a fusion of data.

How this goes wrong: the failure modes to watch

Most wrong trees come from a short list of recurring mistakes, each of which looks like success at the moment you make it. Here is what each one looks like, and the check that catches it.

• Name-only match. Two unrelated firms share a common name and score high on similarity. It looks like a strong duplicate. Check EIN, domain, or LEI before merging; name alone never clears the bar. This is the check that saved record H.
• Merging a parent into a subsidiary. Firmographics overlap, so it looks like a clean duplicate. They are distinct entities. Check for differing EINs or LEIs and link them in a hierarchy instead of fusing.
• Wrong master chosen. The surviving record looks complete, but because the primary wins conflicts, defaulting to the first record open overwrites good data with stale data. Check field recency and set survivorship field by field before committing.
• Silent chain merge. Treating "A matches B, B matches C" as transitive. One false-positive link can silently merge unrelated entities, chaining hundreds of records together, so actively check every cross-group merge rather than accepting the chain.
• No rollback artifact. The merge appears to work, but no export exists and the undo window has closed. Confirm a frozen export exists before any destructive action.
• Redirect read as acquisition. An old domain 301s to a new one, so you infer ownership. It may be link-building. Require a filing, press release, or LEI Level-2 relationship.
• Cross-system drift. The CRM is clean but billing still points at the deleted ID, so invoices fork. Check that every billing CRM ID was repointed to the master and the sync re-ran.
• Stale ultimate-parent fields. Custom hierarchy fields go stale after reparenting events. Recompute on save so the roll-up stays correct.

Verify the result and keep it current

Before you call the job done, reconcile counts against the pre-merge export and confirm every subsidiary's history and contracts still resolve. The tree is correct only when the roll-up renders and nothing downstream is pointing at a dead ID.

Keeping the tree current is a staffing question as much as a technical one. In Refolk's index, the people who should own this are scarce and unevenly placed. US Revenue Operations Managers number 1,099 against 221 in the UK, nearly five to one; and within the US, the dedicated data-quality bench outnumbers RevOps almost two to one.

The practical implication: the people who own the CRM (often marketing ops) are frequently not the people best equipped to own entity resolution (the data-quality bench). When you assign this work, assign it to someone who can read a legal-entity key, not just someone with admin rights. Re-run the inventory step after any acquisition or rebrand, because that is when the next tangle starts, and recompute the ultimate-parent chain so the roll-up you just built does not quietly go stale.