What is company enrichment data?

Company enrichment data is context added to an account from a company domain, company name, or LinkedIn company URL. It can include company identity fields, location, country, a short description, and firmographic data.

What identifiers can be used for company enrichment?

Company enrichment can resolve a company record from a domain, company name, or LinkedIn company URL. A registrable company domain is usually the cleanest identifier for account matching and deduplication.

Which company enrichment fields are useful for routing and segmentation?

Company domain, country, location, industry, employee range, employee count, and selected funding or revenue fields can support defined routing, reporting, and segmentation workflows. Each field should have an owner, destination, decision, and update rule before it drives automation.

How should company domains be normalized in a CRM?

Store the registrable company domain in a consistent format and use it for matching. Keep raw submitted values separately when useful, but avoid domain variants that differ only by protocol, path, subdomain, capitalization, or trailing punctuation.

How should parent companies, subsidiaries, and brand domains be handled?

Define what an account represents in your CRM and document how related entities connect. Keep approved alternate domains where relationships are known, preserve separate profiles where appropriate, and send uncertain matches to review rather than merging automatically.

Company Enrichment Data: Turn Domains Into GTM Context

Company enrichment data turns an account identifier into context your GTM team can use. Start with the company domain when you have it, resolve the account record, then apply the returned fields to routing, segmentation, research, and ongoing account data quality.

What company enrichment data includes

Company enrichment data is the context added to an account from a company domain, company name, or LinkedIn company URL.

The core company record gives you a usable identity and basic context:

company: The company name.
company_domain: The company’s registrable domain.
linkedin_url: The company’s own LinkedIn page.
location: The location as published.
country: A country derived from the location.
headline: A short company description.

These fields help you answer basic operational questions. Is this form submission associated with an existing account? Does the account belong in a particular territory? Is the company record clear enough for a seller to begin research?

Company data enrichment can also return firmographics alongside a company row:

industry
employeeCount
employeeRange
foundedYear
logoUrl
revenueAnnualUsd
fundingTotalUsd
latestFundingRound
monthlyVisits

Firmographic data is useful when it supports a decision. Industry and employee range can support firmographic segmentation. Location and country can support geographic ownership. Funding and revenue context can help a researcher understand the account’s current shape before an outreach sequence or account review.

The distinction matters. A company name and domain help identify an account. Firmographics help classify it. A headline helps a human understand it. You should not use every field in the same way.

For example, a routing rule may need country, company domain, and a selected segment. A research queue may benefit from headline, industry, employee range, founded year, funding context, and web-traffic context. Those are different workflows with different data requirements.

Enrichments returns these company fields when you resolve a domain, name, or LinkedIn URL. The firmographic fields ride along on company rows at no extra charge. You still need to decide which fields belong in your CRM, which should remain in an enrichment output, and which should drive automation.

Begin with the company identifier you can trust

A registrable company domain is usually the cleanest identifier for account matching and deduplication.

Domains are more stable than display names in many CRM workflows. A company may appear under a legal name, a shortened brand name, or a product name. Those values may be entered differently by sales, marketing, partners, and form-fill contacts. A normalized registrable domain gives you a more consistent key for matching those records.

Use the domain to anchor account enrichment when you can. Store a normalized version in a dedicated account property, then use that property for matching before you create a new account.

A company name is still useful when a domain is missing. It is also useful in account lists assembled from event registrations, manual research, or partner data. But company names need more review before they become matching keys.

Define how you handle common name variations:

Legal suffixes and entity labels.
Brand names versus corporate names.
Punctuation and spacing differences.
Abbreviations and alternate spellings.
Regional business names.

A LinkedIn company URL is also a useful identifier. It can be more specific than a company name when the account has a distinctive company page. Store it as a separate identifier rather than treating it as a replacement for the domain. A LinkedIn URL can help resolve a company record, but it should be normalized and checked for relevance to the account you intend to update.

Not every domain maps cleanly to one CRM account. Account enrichment needs explicit handling for the cases where identity is ambiguous.

Parent companies and subsidiaries

A parent company may own several operating subsidiaries, each with its own domain, market, geography, and sales motion. Do not automatically collapse every related domain into the parent account.

Decide what an account represents in your CRM:

A legal entity.
A buying group.
An operating company.
A regional business unit.
A brand.

Then document how related entities should connect. You may maintain a parent account relationship while preserving a separate domain and firmographic profile for each subsidiary. That keeps routing and reporting aligned with the account model your team actually uses.

Brand domains and regional entities

A company can operate product or campaign domains that are not its main corporate domain. A contact may submit a form using an address from a brand domain while the active opportunity belongs to the parent company. A regional entity may use a country-specific domain even when its parent has a global domain.

Treat those cases as matching decisions, not automatic merges. Keep a controlled list of approved alternate domains when the relationship is known. Route uncertain matches to review rather than attaching a contact to the first account that looks similar.

Outdated domains

Domains change after rebrands, acquisitions, or website migrations. A stale domain may still exist on an old account record, in a form history, or in an imported list.

Keep the historical value if it helps explain prior activity, but distinguish it from the current company domain. When a record resolves to a new domain, review whether it is the same company, a successor entity, or a different account that inherited a brand or web property.

Do not use an email domain alone as proof of account ownership when the domain belongs to a shared service, a subsidiary, or a brand. Match rules should allow ambiguous records to remain unassigned until they are reviewed.

Select fields based on a defined account workflow

Request company fields only when a defined account workflow has a use for them.

The easiest way to create a cluttered CRM is to import every available field because it might become useful later. The better approach is to map each field to an owner, a destination, a decision, and an update rule before you run company enrichment.

Start with the workflow. Then choose the fields.

Fields for filtering and automation

Filtering fields are structured values that support reports, lists, routing rules, and account assignment. They need consistent formats and clear ownership.

Common examples include:

company_domain for account matching, deduplication, and inbound-contact association.
country for territory assignment and regional reporting.
location when routing requires more detail than country.
industry for firmographic segmentation.
employeeRange or employeeCount for account tiers and research queues.
foundedYear when company maturity is relevant to your qualification model.
latestFundingRound, fundingTotalUsd, or revenueAnnualUsd when your team has a documented process for using those values.

Do not make a field part of an automation merely because it appears structured. A territory rule based on country requires a fallback for blank or unclear locations. A segment based on industry requires a controlled set of values that your reporting can support. A tier based on employee range needs an owner who can explain what happens when the value changes.

Fields for seller and researcher context

Descriptive fields help a person understand an account. They may be useful in an account brief without belonging in a routing rule.

These often include:

headline for a short description of the company.
linkedin_url for direct access to the company’s published profile.
logoUrl for record presentation where your CRM supports it.
monthlyVisits as a research input.
Funding, revenue, and founding context for account preparation.

Keep descriptive fields near the workflow where they are consumed. A seller may benefit from them in an account view. A researcher may need them in an exported queue. A routing engine usually does not.

This separation prevents a common account data quality problem: using human-readable context as if it were a stable classification field.

Before adding a field, write down:

Who owns the property definition.
Which workflow reads it.
Whether it is filterable, descriptive, or both.
When it can overwrite an existing value.
What happens when enrichment returns no value.
How ambiguous values are handled.

If you cannot answer those questions, keep the field out of the automation path for now.

Normalize company data before writing it to the CRM

Normalize company data before it reaches reporting or automation.

Enrichment can resolve useful company context, but your CRM needs consistent values to make that context operational. Normalization is the layer between a returned record and a property that drives territory rules, account lists, or dashboards.

Start with domains. Store the registrable company domain in a consistent format. Do not allow the same account to accumulate variants that differ only by protocol, path, subdomain, capitalization, or trailing punctuation. Keep raw submitted values separately when they are useful for investigation, but use the normalized domain for matching.

Apply the same discipline to company names. Maintain a canonical account name for your CRM. Preserve alternate names or source values when needed, but avoid treating each variation as a new account.

Countries and industries need special care because they often become reporting dimensions. Use one approved value set for each field. Do not mix country names, abbreviations, and regional labels in the same property. Do not let free-text industry labels become the source for automated segmentation without a mapping process.

Employee-range values also need a defined interpretation. If you use employeeRange for segmentation, store the returned range consistently and document how your team groups it. Do not combine employee count and employee range in one property. They answer related but different questions.

Define overwrite rules before enrichment runs

An overwrite rule should protect curated data while allowing stale or blank values to improve.

A practical policy often looks like this:

Fill blank account properties from enrichment.
Update values that are explicitly marked stale or no longer trusted.
Preserve values maintained by an approved account owner unless there is a review process.
Do not overwrite a parent or subsidiary relationship from a domain match alone.
Store the enrichment timestamp or source state where your CRM supports it.
Send conflicting identity fields to review instead of silently replacing them.

These rules should apply field by field. You may be comfortable updating a blank LinkedIn URL automatically while requiring review before changing a company name or account parent relationship.

Keep account and contact data separate

Company-level data and contact-level employer data are related, but they are not the same thing.

A contact record may have a current employer name and company domain. An account record represents the company entity your CRM has chosen to manage. If you copy contact employer data directly into account properties without matching rules, you can attach contacts to the wrong account or overwrite curated account context.

Use the contact’s employer domain as an input to account matching. Then associate the contact with an existing account only after your domain and ambiguity rules have run. Keep the company record as the source of company-level fields such as industry, employee range, funding context, and location.

Use enriched account context in GTM operations

Use enriched account context to make account decisions more consistent, not to replace judgment.

Territory and ownership decisions often begin with location and account identity. A normalized company domain can help match an inbound contact to an existing account. Country and location can then support geographic assignment, provided your routing rules define how to handle incomplete or ambiguous records.

Company attributes can also support account prioritization. Build segments around the firmographic data that matters to your motion. For example, you may create research queues using industry and employee range, then give sellers headline, LinkedIn URL, and funding context for account preparation.

The value is not in creating the largest possible list. It is in creating a list where each account has enough consistent context for the next action.

Company domain enrichment is especially useful for inbound operations:

Capture the domain or business email domain from a form submission.
Normalize it before matching.
Look for an existing account using the normalized company domain and approved alternate domains.
Resolve missing company context when the account is new or incomplete.
Apply routing rules only after identity and territory fields are usable.
Send uncertain matches to a review queue.

This process helps prevent duplicate account creation while giving the receiving team a clearer account record.

For account planning, separate the operational view from the research view. The operational view should contain the fields required for ownership, segmentation, and reporting. The research view can include company description, LinkedIn URL, industry, employee context, founding year, funding context, revenue context, and web-traffic context.

Enrichments supports company searches as well as company enrichment. Search is useful when you are finding companies that fit a description or firmographic filter. Enrichment is useful when you already have identifiers, such as domains, names, or LinkedIn URLs, and need to resolve the account context around them. The documentation covers the available API and workflow surfaces.

Keep company data useful after the first enrichment

Company data stays useful when you refresh it in response to real account events and review what did not match.

A CRM enrichment project often begins with a backlog of incomplete accounts. That is a valid starting point, but it should not be the end of the process. Company records change. Domains change after rebrands. New qualification workflows create demand for fields that were not previously collected. Accounts that return to an active pipeline may need a current review.

Define refresh triggers based on your operating process:

An account becomes active again after a period without engagement.
A new contact arrives with a domain that does not match the account’s stored domain.
A seller flags an account as renamed, acquired, or reorganized.
A new territory or segmentation workflow requires missing company context.
A record has blank or stale fields that are needed for an active workflow.

Enrichment is live, so the same company request can legitimately return different data at a later time. Treat a refresh as a new observation, not proof that a previous value was wrong. Your overwrite rules should determine whether the new value fills a blank, updates a stale property, or enters a review queue.

Review unmatched and ambiguous records regularly. They are useful feedback on your data collection process.

Look for patterns such as:

Forms that do not collect a usable business domain.
Imported company names with inconsistent formatting.
Brand domains that are missing from your approved domain list.
Regional entities being merged into global parent accounts.
Old domains remaining in active account records.
Contacts associated with accounts through weak name matches.

Use those patterns to improve identifier collection, normalization, and routing rules. This is how account enrichment becomes an account data quality practice rather than a periodic cleanup task.

The goal is a CRM where company identifiers are reliable enough to match, firmographic data is structured enough to use, and descriptive context is available when a person needs it. That requires ongoing ownership. It also requires restraint: only automate decisions that your identifiers and normalized fields can actually support.