The Company Match-Key Reference: What Each Identifier Resolves

This is the row-per-identifier reference for deciding which field to match two company records on when you are deduping accounts or joining records across systems. It is written for recruiting and revenue operations, data stewards, and anyone who has to answer for how the merge was made. Jump to the key you are holding, read what it proves and where it lies, and leave with a verdict.

Other guides in this library cover the refresh cycle, untangling a corporate family, and reaching a merge verdict. This one is narrower and more useful mid-task: it defines the match keys themselves so you can answer "can I trust a shared domain here?" without reading a whole playbook first.

Which field should I trust as the company match key?

Trust a government-issued primary identifier first, then a global entity identifier, then a tax registration, and only then a verified web asset. The order is registration number, LEI, VAT number, verified domain, with legal name used only after normalization and never alone.

The reasoning is stability. A registration number, once assigned on incorporation, stays with the entity for its entire life, through every name change, share issue, rebrand, and restructure. That permanence is exactly what you want in a match key: two records that carry the same registration number are the same legal entity, full stop. Everything below it trades away some of that permanence for either broader coverage or easier collection.

The trap is that the strongest key is the one nobody types correctly. Registration numbers survive every rebrand, yet the common failure is purely clerical: a spreadsheet drops the leading zero and the lookup returns nothing. Get the normalization right and this ladder holds. Skip it and even your best key fails silently.

What each identifier proves and how it misleads

Each candidate key answers a different question. A domain answers "does this org have a web presence?" A registration number answers "is this the same legal entity?" Confusing the two is the root of most bad merges. The table below is the fast lookup.

Read each row against your own record pair. A registration number proves a legal entity in one jurisdiction and is the strongest single key you can hold; it lies only when a clerk stripped a leading zero or when you compare numbers across two different national registries. An LEI proves a global legal entity but only for the minority of firms that enrolled. A VAT number proves a tax registration that was live when you checked, nothing more; it can be deregistered, so treat validity as a snapshot.

A domain proves a web presence and never an entity. There is no regulation that forces a domain to match the company name, so one firm often runs many domains and unrelated firms share free-provider domains. A legal name does identify the entity but is spelling-volatile: the same firm appears as "Vouch," "Vouch Inc.," and "Vouch Insurance," so it needs normalization before it can join anything.

Two keys deserve a note by exclusion. A trading or DBA name has no legal standing on a contract, so never promote it above the registered name. External CRM, billing, and ERP IDs are stable inside one system and meaningless across systems, so they are join keys within a stack, not entity-resolution keys between stacks.

Domain as a key: where it over-matches and under-matches

A domain fails in both directions from the same root cause: it is a marketing and web asset with no legal tie to an entity. That single fact produces two opposite errors, so a domain is safe only after filtering and only as a secondary key.

Over-match (false merge) is triggered by free and shared providers. Free providers are shared by millions of unrelated individuals, so the domain reveals nothing about a company, and mapping them creates fake "companies" that corrupt deduplication, segmentation, and account-based targeting. A single Gmail pseudo-account can absorb thousands of unrelated contacts. The fix is upstream: filter every domain against a freemail and disposable list before you map anything.

Under-match (false split) is triggered by one company owning many domains. Big companies own dozens of domains - regional sites, product domains, typo-catchers - that might all map to one parent or to different sub-brands. Left alone, acme.com and acme.co.uk log as two accounts. The fix is a domain-to-parent alias table you inspect whenever a regional or product TLD appears.

There is a subtler over-match inside the provider question. Do not merge across providers: a Microsoft account might own both hotmail and outlook addresses, but treating all Microsoft domains as interchangeable creates false merges on legacy accounts that were never linked. Custom-domain corporate mail behaves differently from consumer mail; only consumer gmail rows need dot and plus normalization, while Google Workspace on a custom domain behaves like corporate mail.

LEI as a key: reach, renewal, and where it stops

The LEI is a 20-character alphanumeric code based on ISO 17442, carrying Level 1 "business card" data and Level 2 relationship and parent data. It is genuinely global and free to query, which makes it a strong high-confidence key where it exists. Its ceiling is structural, not adoption-lag: it was designed for financial-market counterparties, not general firmographics.

Read the renewal rate as the coverage warning it is. With 43.4 percent of records lapsed and no LEI at all for non-financial SMEs, matching only on LEI silently discards the majority of a typical B2B account base. Renewal also varies sharply by jurisdiction, from Japan at 89.3 percent down through Finland, India, Germany, and Saudi Arabia, so the LEI you find on a Japanese counterparty is far more likely to be current than one on a firm in a low-renewal market.

The practical rule: use the LEI as a top-tier deterministic key when a record carries one, and fall back to the registration number for non-enrolled entities. Treat it as authoritative-when-present, never as universal. Two operational limits matter if you query the index yourself: the Global LEI Index is published CC0 public domain, and a single API run paginates to a ceiling of 10,000 records, so plan bulk pulls around that.

Registration and tax numbers: normalize before you match

Government identifiers are your strongest keys, but they are worthless until normalized, and normalization is where most of the value is won or lost. A registration number is a string, not a number, and a VAT number is a country-prefixed pattern, not a bare integer. Treat them otherwise and the join breaks before it starts.

For UK company numbers, leading zeros are sometimes omitted, so 00644831 appears as 644831. To normalize, pad with zeros to eight characters and upper-case any letters. This is not cosmetic: the Companies House API returns no match for 48839 but does for 00048839. The failure origin is almost always a spreadsheet or manual entry stripping the zero at the moment the identifier enters the system as a number. Prefixes also encode entity type - SC for Scotland, NI for Northern Ireland, OC for LLPs, FC for overseas - so preserve them exactly.

For VAT numbers, the two-letter country prefix is mandatory and the format is country-specific. Normalize the input into a canonical internal representation, then run country-specific format rules so obvious bad values fail immediately. Some formats resist pattern validation: Romanian VAT is 2 to 10 digits after RO, so length alone cannot confirm it. Note two jurisdictional shifts: GB VAT numbers left VIES after Brexit, and Northern Ireland goods use the XI prefix under the Windsor Framework.

Cross-source reconciliation is hard for a predictable reason: leading zeros may be stripped or added, prefixes may be included or omitted, and dashes, spaces, and slashes appear or disappear depending on the system that processed the number. Canonicalize every source to one representation before you compare, and keep the format check separate from the live check. A number can be perfectly formatted and still not exist.

Deterministic first, probabilistic second

Run exact keys before fuzzy keys, always. A mature setup uses both in sequence: deterministic matching compares normalized field values for an identical result - same registration number, same account number - and is fast with almost no false positives, but it is brittle to a single typo or "Inc." versus "Incorporated." That brittleness is measurable.

Deterministic-only is a real miss, not a rounding error, because one "Inc." versus "Incorporated" breaks the join. So after the exact pass, score the remainder probabilistically on name, address, and domain combinations. But probabilistic matching without properly tuned thresholds can merge two different firms into one record, so route mid-band scores to human review and tighten the threshold when the cost of a wrong merge is high.

Some keys are useful in the fuzzy pass but unsafe as a sole key: directors, ultimate beneficial owners, industry codes, and website domains are helpful for probabilistic scoring but too volatile to rely on alone. Keep them as corroborating signals, never as the deciding one.

Deterministic keys tell you who is certainly the same. Probabilistic keys tell you who is probably the same. Never let the second speak alone.

There is a genuine order disagreement in the field: some tooling presents name-similarity clustering as the first pass, while master-data-management and CRM sources put deterministic exact keys first and fuzzy second. For account deduplication I favor exact-first, because your strongest keys are the government identifiers and clustering on names before you have exhausted those invites avoidable false merges.

The people who own this decision are scarce, which is worth naming because it shapes who actually tunes your keys.

In Refolk's index of professional profiles, US RevOps profiles outnumber UK ones 374 to 46, an 8.1x gap, and master-data-management skills trail Salesforce administration 1.71-to-1 in the US. The specialist who tunes match keys is far rarer than the CRM admin who inherits the duplicates, so if you need to hire or borrow that skill, expect a thin market and search precisely.

The procedure: from raw keys to merged accounts

Work in this order. Each step has one owner and one definition of done, so you can hand it off cleanly and audit it later.

The corporate-family step is the one teams skip and regret. For subsidiaries, decide a consistent rule - map to the operating brand or roll up to the parent - apply it everywhere, and document the decision. Without a written rule, two stewards resolve the same family two ways and you rebuild the duplicates you just merged.

How this goes wrong: failure modes and false positives

Most bad merges trace to a small set of repeatable errors. Each one below pairs the false positive it produces with the local check that catches it, so you can screen a record pair before you commit the merge.

• Free or shared email domain treated as a company key. A Gmail mega-account absorbs thousands of unrelated contacts. Check: run every domain against a freemail and disposable list before mapping.
• One-company-many-domains under-match. acme.com and acme.co.uk log as two separate accounts. Check: maintain a domain-to-parent alias table and inspect regional and product TLDs.
• Registration number with stripped leading zeros. 48839 fails lookup while the entity exists as 00048839. Check: zero-pad to fixed length and store as text, never numeric.
• VAT validity read as identity proof. A structurally correct DE123456789 is assumed to be a real, current registration. Check: separate the format check from the VIES lookup, and treat VIES validity as point-in-time.
• Legal-name exact-match. "Vouch Inc." and "Vouch Insurance" split into two, or two accelerator "Alpha" companies merge into one. Check: normalize suffixes, then require a second corroborating key.
• LEI treated as universal. Matching only on LEI silently drops the roughly 43 percent lapsed and every non-financial SME without one. Check: fall back to the registration number for non-enrolled entities.
• Cross-provider email merge. Legacy hotmail and outlook accounts merge as one. Check: never treat one provider's domains as interchangeable.
• Probabilistic threshold set too loose. Two different firms with similar names and addresses merge. Check: route mid-band scores to human review and tighten the threshold for high-cost merges.

The pattern across these is that every fast key has a cheap way to fail. The registration number fails clerically, the domain fails structurally in two directions, the VAT number fails when a snapshot is read as permanent, and the name fails on spelling. Naming the failure before the merge is worth more than any single key.

Verify before you call the merge done

Run this before you commit a merge or sign off a batch. Every item is a check you can either pass or fail, not a topic to think about.

Keeping the reference current

Match keys decay because entities change, so the work is never finished at the batch level. Companies rebrand and get acquired all the time, and a name that was right last year may be wrong now, so re-enrich on a schedule rather than treating a clean merge as permanent.

Three things to re-check on a cadence. First, LEI status, because renewal is annual and a key that resolved last quarter may now sit in the lapsed 43 percent; re-query the GLEIF index and demote lapsed LEIs to the fallback registration number. Second, VAT validity, because a registration can be deregistered; a point-in-time VIES pass expires. Third, the domain-to-parent alias table, because acquisitions add and retire domains constantly.

When you need to bring in the scarce skill to run or audit this, search precisely rather than broadly. Refolk lets you ask for exactly the profile you need in plain English, which matters when the specialist pool is as thin as the 46 UK RevOps profiles in its index suggest. Naming the role, the skill, and the market in one query - master-data-management specialists with entity-resolution experience, or RevOps leaders who own CRM data quality - returns the people who tune keys, not the admins who inherit the mess. That precision is the difference between a match-key policy someone maintains and one that quietly rots.