HG Subsidiary Handling

Stop parent-versus-subsidiary mix-ups from producing confident data about the wrong company.

When to use

• A workflow takes a domain or company name and the resolved entity might be a subsidiary, a site or a group holding.
• A list of accounts may contain several members of the same corporate family.
• A user asks "who owns X", "what does X own" or wants group-level figures.

Tools you'll touch

• company_firmographic: company_level, corporate_parent_id, global_hq_id. Cost: 0.1 per company.
• company_hierarchy: the ownership tree. Cost: 0.1 per node returned. Cached 30 days.
• search_companies: pick the parent directly with firmographics.company_level. Cost: 1 per 100 companies returned.

The failure mode

A user asks about Acme Corp. The workflow passes acme.com, which resolves to a 300-person regional subsidiary rather than the brand. Every downstream call (installs, spend, AI spend) returns subsidiary-scale data, and the output looks confident and is wrong. The cause is domain resolution, not the id: HG ids are hexadecimal; leading zeros may be omitted, so 31- and 32-character forms are the same company. Length says nothing about hierarchy.

The levels

company_level	What It Is	Default Treatment
Group HQ	Ultimate parent; global_hq_* fields are absent	Use for group-level questions
Corporate Parent	Brand-level company (may sit under a Group HQ)	Default target when the user names a brand
Domestic Parent	Country-level parent, often a legal or regional shell	Move up unless the country entity was asked for
Subsidiary	Owned entity	Move up unless the user named it
Site	A location of an entity	Move up

global_hq_id always points to the ultimate parent. A brand owned by a larger group points at the group, so following it turns a brand question into a group answer. For brand level use corporate_parent_id.

Decision flow

input domain or name
  → resolve (company_firmographic by domain; search_companies if name only)
  → read company_level
     Group HQ or Corporate Parent
       → proceed. If the user asked about the whole group and global_hq_id is present, re-query on global_hq_id.
     Subsidiary, Site or Domestic Parent
       → did the user name this entity specifically (its own domain or legal name)?
          YES → keep it; say it's a subsidiary of <corporate_parent_name>.
          NO  → re-query company_firmographic with hg_ids:[corporate_parent_id].
                Group-level question → use global_hq_id instead.
       → chain unclear (no corporate_parent_id, or the parent is itself a shell)?
          → company_hierarchy mode:"parents" with hg_id; pick the nearest Corporate Parent node.

When is it the brand? Default to the brand-level entity the user named:

• "Research Acme" → Acme's Corporate Parent, not its ultimate group.
• "Research the Acme group" or "total spend across the group" → Group HQ.
• "Research acme-labs.com" (a subsidiary's own domain) → that subsidiary.
• A CSV of domains → resolve each, apply the flow, and log every switch.

Picking the parent with search_companies

When you only have a name, filter to the level you want instead of ranking candidates by size:

{
  "company_identifiers": {"name": "acme"},
  "firmographics": {
    "company_level": "CORPORATE_PARENT",
    "country_codes": [{"ids": ["US"], "inclusion_method": "ANY_PRESENT"}]
  },
  "limit": 10
}

Filter values are CORPORATE_PARENT, GLOBAL_HEADQUARTER, DOMESTIC_PARENT, ALL_ENTITIES; output records label levels as in the table above. Name search is a token-substring match, so enrich the candidates with company_firmographic before choosing. To dedupe a list of accounts, keep one entity per corporate_parent_id (or per global_hq_id for group-level lists).

Using company_hierarchy

• The domain is read literally, not as a brand alias: a holding company's colloquial domain may belong to an unrelated subsidiary, and the tool returns that tree with no error. Resolve first and pass hg_id.
• "Who owns X?" → mode:"parents": the chain from the matched node up to the Group HQ, usually a few nodes. already_at_ghq:true means X is the Group HQ.
• "What does X own?" → mode:"children" (default, depth:1 = direct children). Large parents can return 100 to 330+ nodes, and every node costs 0.1: set depth deliberately and trim columns with selected_fields.
• Sister companies → mode:"parents" to find the parent, then mode:"children" on it.
• depth is applied before filters. With country_codes, naics_codes or industry_names, pass depth:5 or more, or deeper matches are cut before the filter runs.
• Dedupe nodes by id. The tree can contain duplicates, and each one is billed.
• There's no server-side level filter: filter returned nodes on company_level.
• hierarchy:null → read no_match_reason (no record, or every node pruned by filters).

Logging the choice

Log every resolution decision in the run output, not only in the deliverable:

[hg-subsidiary-handling] acme.com resolved to Acme Services Ltd (Subsidiary, ~300 employees). User named the brand → switched to corporate_parent_id: Acme Corp (Corporate Parent). Group HQ Acme Holdings not used (no group-level question).

"Why does the spend look low?" then answers itself.

Common pitfalls

1. Skipping the company_level check after a domain lookup. That's the whole failure mode.
2. Jumping to global_hq_id for a brand question. You get the whole group. Use corporate_parent_id.
3. Moving up when the user named the subsidiary. Read the intent.
4. Passing an unresolved brand domain to company_hierarchy. It's literal. Use hg_id.
5. Filtering a hierarchy at the default depth. Depth runs first; use depth:5+ with filters.
6. Skipping the log line. The next person debugging "wrong company" has no trail.

Reference

• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/company-hierarchy
• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/company-firmographic
• Full docs for LLMs: https://phoenix.hginsights.com/docs/llms-full.txt
• Related skills: hg-mcp-calling-rules, hg-firmographic, hg-search-companies