Corporate Hierarchy Data: A Buyer’s Evaluation Guide for Account Expansion

Start with the decision your data must support

Corporate hierarchy data describes relationships among companies, including parent and subsidiary connections. Buying it for enterprise account expansion requires more than confirming that a supplier can draw a large family tree. The practical question is whether the returned relationships can support the decisions your team actually makes, with enough evidence to challenge mistakes before they reach customers.

Start the evaluation with a specific decision: identify operating subsidiaries connected to existing customers that merit an account-team review. Define the countries, company types and relationship types involved. Specify whether you need direct ownership, control, an immediate parent, a global ultimate parent or a commercial grouping. Those are different requests. A supplier can answer one correctly and still fail your intended workflow.

Agree on the unit of testing. A company record is a node; a relationship between two companies is an edge; a chain of relationships is a path. Evaluate all three. Correctly identifying a German company does not establish its UK parent. Correctly identifying the direct parent does not establish the ultimate parent if an intermediate link is missing. An impressive record count cannot substitute for these distinctions.

Keep this exercise separate from configuring your CRM. The outcome is an acceptance decision about the data and its operating cost. The CRM account hierarchy guide explains implementation after acceptance. Similarly, the hierarchy definitions guide explains the relationships themselves. This evaluation asks which claims you can verify, which remain unknown and what limitations your account teams will inherit.

Build a test sample that can expose failure

Choose the sample before asking suppliers for a demonstration. Include straightforward customers, multinational groups, local private companies, recently changed groups and difficult cases with shared names or websites. Add known non-relationships: companies that look related but are not within your agreed group definition. A test containing only famous listed companies mainly demonstrates that the supplier can find familiar information.

Use two complementary sets. A representative set reflects the mix of accounts you expect to process. A challenge set concentrates on expensive mistakes: a divested subsidiary, a minority investment, a branch, an operating business beneath several holdings and two unrelated companies with similar names. Report the sets separately. Mixing them into one percentage can hide either poor everyday coverage or dangerous edge cases.

Create an independently reviewed answer file wherever evidence allows. Record the entity identifiers, relationship definition, source, observation date and effective date if available. Mark uncertain cases as unresolved rather than forcing a binary answer. The answer file is not infallible; reviewers should be able to challenge it with better evidence. Keep supplier identities hidden during adjudication when practical to reduce preference bias.

A small pilot is useful for discovering failure modes, but it does not establish a universal accuracy rate. Twenty clean results from one market tell you little about another jurisdiction or an acquisition-heavy segment. Expand the sample where the commercial risk is concentrated. Preserve the sample selection rule so procurement can distinguish a repeatable test from a set of hand-picked successes.

Require an evidence record for every material link

For each returned link, ask for stable identifiers for both entities, the relationship type, the source basis, the source date, the provider observation date and any applicable effective date. Record whether the link is reported, calculated or inferred. A provider may offer useful inferred relationships, but a buyer needs to know when an inference is being used instead of a directly supported ownership statement.

A recent delivery timestamp is not the same as recent underlying evidence. A file retrieved this morning may contain an older filing. Conversely, an older filing can still be the latest available statement. Your evaluation should distinguish the age of the evidence from the age of the delivery and explain what the source can establish. A single freshness badge hides these differences.

Test the handling of conflicts. Ask the supplier to show a case in which sources disagree, a parent changed, or an entity has several types of connection. Does the export preserve the conflict, choose a documented rule or silently flatten the result? You do not need every record to be uncomplicated. You need the system to reveal the cases that require a human decision.

Do not turn missing evidence into a negative claim. No returned parent can mean independence, unavailable coverage, an unresolved match, a depth limit or a product entitlement restriction. Those states have different consequences. Require a reason code where available and retain an explicit unknown state in your own workflow when the explanation cannot be established.

Measure verified links, errors and unresolved cases separately

Use three mutually exclusive outcomes for returned relationships: verified correct under the test definition, verified incorrect, and unresolved. The denominator for the returned-link composition is all returned links in that sample. Do not remove unresolved cases to make the report look cleaner. They consume reviewer time and may block activation even when no error has been proven.

Also measure discovery against the known reference set. If the answer file contains 80 supported relationships and the supplier returns 60 of them correctly, the observed recall against that reference set is 75 percent. That is not proof of 75 percent global coverage. It describes recovery of known relationships in the test. Report relationships outside the reference set separately until they are adjudicated.

For an illustrative returned set of 100 links, suppose 72 are verified, 8 are incorrect and 20 remain unresolved. Precision among the 80 adjudicated links is 90 percent, while only 72 percent of all returned links are currently verified. Both statements can be mathematically true. Presenting only the first hides the unresolved fifth of the workload. Neither measure establishes whether the supplier missed other relevant subsidiaries.

Make the consequence of each error visible. Linking a passive holding entity into a research list may create minor rework. Linking an unrelated company into a strategic customer group can misroute outreach or contaminate reporting. Classify severity independently from frequency. A low average error rate does not excuse a failure mode that your workflow cannot safely contain.

Compare capabilities without inventing a vendor league table

The market offers overlapping capabilities with different starting points. D&B describes corporate linkage and commercial identity capabilities. Moody’s Orbis describes company reference, financial and ownership information. Their published breadth does not establish the quality of a particular export for your chosen countries, relationships and update requirements. Test the delivered product, including entitlements, rather than the largest number on a product page.

ZoomInfo and Cognism cover sales intelligence and enrichment use cases. Demandbase describes company hierarchy and account-intelligence workflows, while 6sense documents account identification and enrichment. Those capabilities can support activation, but the evaluation still needs to establish the entity grain and meaning of the relationships returned. A sales account view and a legal ownership view may serve different purposes without either being intrinsically wrong.

Sayari describes corporate and trade networks, Exiger focuses on third-party and supply-chain risk, and Quantexa describes entity resolution and contextual relationships. These are relevant comparison points for evidence, network navigation and identity handling. They are not interchangeable substitutes for an enterprise expansion workflow. Ask which functions your team needs and which would add integration effort without helping the intended decision.

Compare evidence using the same test questions, not invented vendor scores. Can the supplier distinguish a branch from a subsidiary? Can you reproduce an immediate-parent path? Can the export explain an unresolved result? Can your team retain the evidence needed to review a decision? Current product documentation helps shape the questions; only your sample, contract and operational trial establish the answers for your purchase.

Calculate review capacity before negotiating the data price

A cheaper record is not necessarily a cheaper decision. Estimate the work required to resolve exceptions, investigate errors, operate the integration and maintain the account view. Keep subscription or usage fees separate from staff effort so the comparison remains explainable. Avoid pricing a hypothetical revenue gain into the model before the sales process has demonstrated it.

The calculator below models one narrow cost: manual review hours for a batch of returned relationships. Multiply the number of links by the share needing review, then by average minutes per review, and divide by 60. Enter your own pilot observations. The starting values are fictional and assume each flagged relationship is reviewed once. They exclude engineering, contract interpretation, repeated escalations and ongoing maintenance.

Consider 500 returned links, 20 percent needing review and 12 minutes per case. That creates 100 reviews and 20 hours of work. If the team can allocate eight hours each week, the queue represents 2.5 weeks of capacity, before new cases arrive. This is an operational planning estimate, not a promise about resolution time: some cases may depend on information that remains unavailable.

Set a queue policy alongside the acceptance threshold. High-impact contradictions should pause the affected decision. Low-priority unknowns can remain in a research backlog. Do not automatically reject a useful supplier because it exposes uncertainty honestly, or prefer one because it hides exceptions. The economically relevant question is how much trustworthy, usable coverage the team can maintain within its capacity.

Test changes as well as the first delivery

A one-time export cannot demonstrate how the service behaves when the world changes. Request an observed update example with before and after values, stable identifiers, relationship status and dates. Distinguish a completed acquisition from an announcement, a correction from a new event and a changed display name from a changed legal entity. Each should produce a different review decision.

Ask what happens to historical links when a subsidiary is divested. Current group membership should change when supported, but prior account decisions may still need their original context. A service that provides only the latest view may be adequate if you retain governed snapshots. It may be inadequate if your reporting requires historical reconstruction that neither party can supply.

Exercise the integration with duplicate deliveries, partial responses and an unavailable endpoint. Confirm pagination and depth limits so a truncated family tree cannot appear complete. Define retry behavior without assuming that every failure should trigger a new billable lookup. Test the actual export or API route you intend to use; a polished user interface does not prove an integration contract.

Keep structural updates separate from commercial actions. A confirmed ownership change can reopen an account review. It should not automatically transfer an opportunity, expose customer information to another team or declare an affiliate covered by contract. Those decisions require their own owners and evidence. The sales-trigger guide provides the subsequent review workflow once a change is established.

Write acceptance conditions that procurement can enforce

Turn the findings into an acceptance record, not an averaged score. State the supported markets, relationship types, intended uses, known exclusions, measured results and unresolved risks. Define which failures block purchase, which limit rollout and which can be managed through a documented review process. Weighting everything into one score can let strong coverage cancel out a non-negotiable evidence or usage-rights gap.

Confirm the rights required by the actual workflow with your procurement and legal owners. Internal viewing, API access, CRM storage, derived account lists, sharing across affiliated teams and redistribution can have different contractual treatment. Do not assume one entitlement includes another. Record the agreed terms rather than relying on a seller’s description of what customers usually do.

Agree on correction handling and operational responsibilities. Who receives a disputed relationship? What evidence accompanies the report? How is the correction communicated? What happens to downstream copies? A response-time commitment and a resolution-time commitment are different. Avoid interpreting a support acknowledgement as proof that the underlying data has changed.

Run a limited rollout with named owners and a reversal plan. Preserve the previous account relationships, stage proposed changes and prevent automated reassignment until the test gates pass. Compare the proposed hierarchy with the current one before activation. A reversible pilot gives both parties evidence about practical fit while reducing the cost of discovering that the initial scope was too broad.

Leave the evaluation with a decision, not a bigger spreadsheet

The final review should make one of three decisions: accept for the defined use, accept with explicit restrictions, or defer until a blocking question is resolved. Specify what the decision does not cover. A successful UK operating-company pilot does not approve every jurisdiction, ownership type or use of the same dataset. The boundary is part of the result.

Have the account team inspect a small set of proposed expansion candidates after the data review. Can they explain the entity, its group connection, the evidence date and the commercial question to investigate? If not, more hierarchy data may only produce a longer research queue. Structural credibility comes first, followed by agreement coverage, customer need and buying authority.

Use the corporate hierarchy data product page to explore the underlying capability, then bring a bounded sample to the evaluation. Follow the white-space guide only after the relevant entities and relationships have passed your acceptance rules. The goal is not the largest visible tree. It is a reliable set of decisions that your commercial team can defend, maintain and act on without confusing corporate connection with customer demand.