Preserve jurisdiction context
Keep the country and identifier type with every submitted value instead of treating numbers as globally unique.
CROSS-BORDER ENTITY RESOLUTION
Company entity resolution across countries and systems.
Resolve company identities across countries using legal names, VAT numbers, EINs and registration details. Separate subsidiaries, brands and duplicate records.
START WITHCompany name or identifier + jurisdictionREVIEWCanonical local entity + source context
Design the control around your systems and policy.Define countries, inputs, match rules, exceptions, evidence and delivery before integration.
Reviewed
THE PRACTICAL ANSWER
What is company entity resolution?
Company entity resolution determines whether names and identifiers in different records refer to the same legal business. Use the registration country and typed identifiers together, then compare names and addresses as supporting evidence. VATFind returns company-record context for that process. Keep subsidiaries, parents and trading brands distinct, even when they share a website or a familiar group name.
- A multinational supplier or customer dataset contains inconsistent local identifiers.
- Group brands and local subsidiaries are being confused in CRM, ERP or onboarding systems.
- Data operations need country-aware matching before consolidation or enrichment.
THE WORKFLOW
Resolve the entity before joining records
Resolve the local company
Match the name and available identifiers against the relevant country records.
Standardise core fields
Return a resolved legal name, registration number, tax ID, address and source context.
Separate entities from groups
Keep the local contracting company distinct from its brand, branch, parent or wider corporate group.
WHAT VATFIND DOES
VATFind verifies which legal company is associated with the VAT number or EIN.
VATFind takes the submitted identifier and country, matches it to a source-labelled company record, and returns the legal name, registration number, address, company context, source and retrieval time. The workflow receives an explicit match, discrepancy, ambiguity, no-match or unavailable state instead of a generic pass/fail answer.
Evidence meaning: a verified association means the submitted VAT number or EIN is linked to the returned company record. It is not, by itself, confirmation of current tax-registration status, tax compliance or approval of the wider transaction.
For API checks, use vat_number outside the US and tax_identifier for US EINs. Optional fields can be absent when a source does not provide them.
- 01Jurisdiction-specific entity
- The legal company resolved within the correct registration country.
- 02Local identifiers
- Tax and registration identifiers labelled by type rather than merged into one field.
- 03Canonical legal name
- A consistent source-reported name for downstream systems.
- 04Address and legal form
- Local context for disambiguating similar companies.
- 05Source provenance
- The country source and retrieval context attached to the match.
CHOOSE THE RIGHT APPROACH
Choose an identifier for the job it can support
Company registration number
Use it with the issuing jurisdiction to distinguish a local registered entity. Preserve leading zeros and formatting rules.
VAT number or EIN
Keep the tax identifier type and country. Compare its company association without treating it as a universal group identifier.
Enterprise company key
Maintain your own durable cross-system key. VATFind company IDs belong to their workspace and environment, not a universal master-data namespace.
CONTROL OWNERSHIP
Give each team one clear responsibility.
A reliable workflow names who owns the input, who interprets the company evidence and who makes the wider decision. That separation prevents a data result from becoming an unexplained approval.
Enterprise data architecture
Define the canonical company model and global identifier strategy.
Local data stewards
Apply jurisdiction-specific source and exception knowledge.
Business-system owners
Adopt the canonical entity without losing operational context.
DECISION DESIGN
Define the evidence and action at each stage.
| Stage | Evidence to retain | Controlled action |
|---|---|---|
| Ingest | Original name, script, address, country and typed local identifiers. | Preserve the source value and jurisdiction before normalisation. |
| Resolve locally | Country-specific company record, legal form, identifiers and source. | Create the local legal entity before attaching group relationships. |
| Publish globally | Canonical ID, local identifiers, match confidence and lineage. | Distribute one entity record while retaining local names and exceptions. |
EXAMPLE WORKFLOW
A multinational customer appears under local names
A CRM lists a group brand, an ERP lists a German subsidiary and a contract repository holds documents for a UK entity. Preserve the three submitted values and resolve the local companies independently. Map documents and transactions to the correct legal entities before creating a group view. Where a relationship is not established by the available evidence, leave it unresolved rather than inferring parentage from a shared name.
See the API requests and responsesIMPLEMENTATION CHECKLIST
Company entity resolution checklist
- Model identifier type and issuing jurisdiction together.
- Retain native-script and transliterated company names where relevant.
- Separate legal entities, branches, establishments, brands and corporate groups.
- Use country-specific match thresholds and source priority.
- Create a stewardship queue for merges, splits and conflicting identifiers.
WHAT TO MEASURE
Prove the control is useful.
Track operating quality rather than claiming that a company match guarantees the downstream outcome.
- Records linked to a canonical legal entity
- False merges and unresolved duplicates
- Countries with documented source and exception rules
READ THE RESULT CORRECTLY
Cross-border matching must remain country aware.
Identifier availability, formatting, status definitions and update cadence differ by jurisdiction. A global matching workflow needs country-specific rules, confidence thresholds and exception handling rather than one universal pass or fail rule.
Review data and limitationsFREQUENTLY ASKED QUESTIONS
Entity resolution questions
Why can’t one identifier model work across every country?
Countries issue and publish different identifiers under different rules. A reliable workflow preserves the jurisdiction, identifier type and source for every result.
How should subsidiaries be handled?
Resolve the local legal entity first. Add group relationships separately so the subsidiary is not overwritten by the parent or brand name.
What causes ambiguous company matches?
Common causes include translated names, trading names, reused addresses, incomplete identifiers and multiple entities in the same corporate group.
Can this be used during data consolidation?
Yes, when the project defines supported markets, matching rules, source priority, confidence thresholds and a review process for unresolved records.
Can a website domain be used as a unique company identifier?
A domain is useful context, but one website may represent several legal companies, subsidiaries or brands. Use legal-company identifiers and jurisdiction to establish the entity behind each contract or record.
How should an LEI be used in company matching?
Where you already hold a Legal Entity Identifier, keep it as a separate typed identifier and compare its legal-entity details with the other evidence. GLEIF's public index can support that independent review. Do not assume every company has an LEI.
Sources and further reading
GLEIF: the public Global LEI Index GLEIF makes LEI records available for independent legal-entity research.