Company Data Enrichment: From Domain to Useful Record

One of the worst failure modes in company data enrichment is not an empty field, but every field filled for the wrong entity. A domain is not a company. It is a pointer that might resolve to a parent holding group, an operating subsidiary, a regional legal entity or an acquired brand that kept its old website. The useful record is the one where you know which of those the fields describe, when each value was observed, and what to do when the match cannot be made with confidence.

That framing changes the workflow. Instead of asking "how many fields can I fill from a domain," you ask three questions in order: which entity did I actually match, how fresh is each value, and what happens to the inputs that did not resolve. This article works through all three with a synthetic example you can copy into your own operations.

Entity resolution comes before field filling

Enrichment providers, including enrichment built into a CRM like HubSpot, have to resolve an input to a candidate in a company graph before returning attributes, and a common default is to pick the strongest single match. This is reasonable default behavior, but it hides a decision your team needs to make explicitly: when a domain belongs to a corporate family, do you want the parent's attributes or the operating entity's?

The difference is not academic. Employee count, funding stage, technology stack and hiring signals can differ by an order of magnitude between a holding group and the subsidiary you actually sell to. If your data enrichment pipeline silently writes parent-level firmographics onto a subsidiary record, your segmentation, routing and scoring all inherit the error, and each downstream system amplifies it.

A practical policy has three parts:

1. Decide per field which entity level is authoritative. Revenue and funding often belong to the parent; headcount, tech stack and hiring usually belong to the operating entity.
2. Store the parent-child relationship as its own field, not as a footnote in a notes column.
3. Never let a parent match overwrite operating-entity values without a flag showing the substitution happened.

Illustrative example: three domains, one corporate family

Everything in this section is synthetic. Suppose your dataset contains three domains that all belong to a fictional logistics group:

• vantorrafreight.com, the main operating business, Vantorra Freight LLC
• loadpath.io, an acquired routing-software brand that kept its own site, Loadpath Inc.
• vantorra.de, a German entity where two plausible candidates exist: Vantorra Analytics GmbH and a dormant holding registration

Here is what a disciplined enrichment pass produces. Note that unresolved does not mean empty; it means deliberately not written.

Two things matter in this table. First, Loadpath stays a child record with its own headcount. If the pipeline had merged it into Vantorra Group, a rep working the 20-50 employee software segment would never see it, and a rep working the group account would carry a misleading tech-stack signal. Second, vantorra.de gets no fields at all. A record that says "we could not decide" is more valuable than one that guesses, because the review queue is a finite, workable list while silent errors are not.

Why dated ranges beat undated counts

An employee number without a date is a rumor. "Employee range 200-500, observed 2025-08" tells you three things: the band for segmentation, the observation date for freshness checks, and an implicit expiry. If your policy says headcount older than two quarters must be re-verified before it drives routing, the date makes that policy enforceable. An undated "347 employees" cannot support any of it, and the false precision of an exact count invites people to trust it more than any external source deserves.

The same logic applies to funding stage, office locations and technology detections. Each field on the record should carry its own observation date, because fields decay at different rates. A reasonable policy might expire hiring signals within weeks while trusting a legal entity name for years; pick windows that match your market.

This is where a field-level ledger earns its keep. The W3C PROV-O model formalizes the idea by distinguishing the entity described, the activity that produced a value, and the agent responsible (W3C PROV-O). You do not need a standards implementation to benefit; a ledger with field, value, source type, observation date and matched entity ID captures the operational core. See the data provenance glossary entry for how this fits into a broader data layer.

A quick freshness worksheet

These windows are suggested operating policy, not something any product enforces automatically. Tune them to how fast your market moves.

Handling the unresolved bucket

Illustrative example: run 1,000 domains through resolution and you might see 780 resolve cleanly to a single operating entity, 140 resolve to a parent that needs child mapping, and 80 remain unresolved. That is 780 + 140 + 80 = 1,000, and the honest read is that 22 percent of the batch needs a decision, not a write.

The 140 parent-matches are the sneaky ones. They look like successes because fields came back. Your pipeline should tag them, apply the per-field authority policy from earlier, and only then let them flow into segmentation. The 80 unresolved domains go to a review queue ranked by potential value, so a human spends ten minutes on the accounts that matter and archives the rest.

An agentic approach helps here because resolution, multi-source verification and re-checks can run as a standing process rather than a quarterly project. AstroFabric's waterfall enrichment agents sequence sources, attach observation dates and route low-confidence matches for review instead of forcing a write, and the resulting records land in your CRM and sheets rather than a separate dashboard. The prospecting data infrastructure page covers how resolved records feed targeting downstream.

Tradeoffs and failure modes

Strict resolution costs coverage. Requiring high-confidence single-entity matches means more records land in the review queue. That is usually the right trade for routing and scoring, but for broad market-sizing work a looser threshold with a confidence flag can be acceptable. Decide per use case, not globally.

Parent-level rollups can be correct. If you sell enterprise agreements negotiated at the group level, the parent is your account and subsidiaries are contacts of context. The failure mode is not choosing one level; it is letting the enrichment provider choose silently.

Merges are hard to reverse. If you merge a subsidiary record into a parent in your CRM and later discover they should have been separate, reconstruction is painful and often lossy. Prefer relationship links over merges until the family structure is confirmed.

Review queues rot. An unresolved bucket nobody works becomes a graveyard. Cap its size, rank by account value, and set an expiry after which unworked items are archived with a reason code.

FAQs

Why does enrichment sometimes return the parent company instead of the one I searched? Providers typically resolve a domain to the highest-confidence entity in their graph, and for corporate families that can be the parent rather than the unit you meant. If you target operating units, add explicit parent-child mapping and a per-field authority rule so parent values never silently replace subsidiary values.

Should I store an exact employee count or a range? Store the range with its observation date. Ranges reflect the real precision of external sources, and the date makes freshness policies enforceable. An undated exact count looks authoritative and misleads everyone who reads it later.

What should happen to domains that cannot be matched to a single company? Route them to a ranked review queue with candidate entities and the failure reason attached. Writing a low-confidence guess is cheaper in the moment and far more expensive to unwind than a short human review.

Next step

Take ten company records your team relied on this week and check three things: which entity level the fields describe, whether each key field carries a date, and whether any of them were silent parent substitutions. If you want resolution, dated enrichment and review routing running as a standing process instead of a manual audit, start with AstroFabric and point the agents at one segment first.

Sources

• HubSpot data enrichment
• W3C PROV-O