The Company Identifier Reference: Which Key Resolves One Entity

You have the same company arriving from two sources - one calls it by its domain, one by a legal name, one carries a registry number you cannot place. This reference is for the person answerable for the merge: recruiting operations, revenue operations, or whoever owns the account master. It catalogues each company identifier as a row, tells you what it proves, ranks it by stability and coverage, and names the exact way it produces false merges and missed matches. Jump to the identifier you are holding, read its failure mode, and leave.

What each identifier proves, and what it is

An identifier is a value attached to a company record that is supposed to point at one real-world entity. The problem is that some point at exactly one entity forever, and some point at a moving target or at several entities at once. The whole job of matching records is knowing which is which before you commit a merge.

Here is the working set, from most durable to most volatile:

• LEI (Legal Entity Identifier) - a unique 20-character alphanumeric code defined by ISO 17442. Proves global entity identity. Every LEI represents one entity and only one.
• Company registration number - the number a registry assigns on incorporation. Proves the entity exists in that registry's jurisdiction. In the UK it stays with the business for life regardless of name changes, relocations, or ownership transfers.
• Legal name - the registered, official name on filings and contracts. Proves contract standing.
• DBA (doing business as) / trade name - a public-facing alias different from the legal registered name. Proves nothing about identity on its own; one entity can hold several.
• Domain - the DNS name a company uses on the web. Proves a web presence, not an entity. Shared and reassigned freely.
• Ticker / CIK - the exchange symbol or SEC filer index number. Ticker proves a listing at a point in time; CIK proves a filer.
• Proprietary vendor key - an internal identifier minted by a data provider. Proves only that the vendor believes two rows are the same, on evidence you cannot inspect.

The mistake that drives most bad merges is treating a code-shaped value as if the shape guarantees uniqueness. A NAICS industry code looks structured, but it is self-assigned and can be changed at any time. A ticker looks like a key, but it gets recycled. Shape is not scope.

Stability versus uniqueness scope

Stability answers "does this value stay with the entity for its life?" Uniqueness scope answers "within what boundary is this value guaranteed to point at one entity?" You need both to decide whether a key can be joined deterministically. The table below ranks the primary identifiers on exactly these two axes.

Two rows deserve emphasis. The LEI is the only row that is both durable and globally unique, which is why it anchors any serious matching chain when it is present. The US state entity number is durable but scoped to a single state, which is the single most common source of confident-looking false merges in US data.

The active LEI population surpassed 3 million in early 2026, which sounds large until you compare it to the number of companies with a domain, which is effectively all of them. Stability and coverage pull in opposite directions, and that tension is the reason no single key resolves everyone.

Legal name, DBA, and registration number across jurisdictions

The legal name carries contract standing; the DBA does not; the registration number is durable but jurisdiction-scoped. The legal name on a contract is the registered, official name of the corporation taking part, and when both parties sign it becomes legally binding. A DBA is a name under which a business operates that is different from its legal registered name, and a business can run several trade names targeting different markets or product lines. So a DBA match tells you a brand overlaps, not that two records are the same legal entity.

Numbers are where jurisdiction bites hardest. The UK relies on a Companies House registration number that is national and permanent. Australia uses an ABN and ACN. Switzerland's UID is a rare universal join key, used across the commercial register, VAT, social insurance, customs, and statistics, which makes it the single reliable key for Swiss company data.

The United States is the trap. There is no federal company register, so there is no national company number. Companies receive a state-issued entity or file number from the state where they incorporated, and formats differ from state to state. The consequences are measurable.

Read that first row again. A bare US registration number is not a key - it is a partial value that resolves to one entity only after you attach the state. Illinois even encodes the entity type in the prefix, so parsing rules differ registry to registry. Treating "US company number" as a single concept is a category error, and it silently manufactures false merges every time two unrelated firms in different states share a value.

The deterministic ceiling and the fallback chain

Single-identifier deterministic matching tops out at a widely cited 70 to 80 percent accuracy, so a fallback chain is mandatory. Deterministic matching, at its simplest, is a database join on trusted ID columns. It yields the highest confidence precisely because it makes no assumptions - two records match when they share a trusted key or they do not. That strength is also its ceiling: the approach breaks down when data is not clean or when the identifying field is missing, which rules out large slices of real data.

Note where that 70 to 80 percent figure comes from. It is a practitioner estimate repeated across identity-resolution vendors, not a peer-reviewed constant. Use it as a planning band, not a guarantee. The point stands either way: one key is never enough, so you chain from the most stable available key down to fuzzy scoring on the remainder.

Practitioners disagree on order. Some argue deterministic-first, then probabilistic. Others argue both must run together, because a single source contains both clean-ID records and dirty ones, so you cannot cleanly separate the passes. Either way, the sequence of trust is the same: start on the value with the narrowest guarantee of pointing at one entity, and only widen to guesses once the certain matches are committed.

One key is never enough; you chain from the most stable value down to a scored guess on what is left.

The specialism to run this well is genuinely scarce. In Refolk's index, only 6 US and 3 UK data-engineering or data-quality profiles explicitly list an entity-resolution skill. Most operations teams are improvising this without a named specialist, which is exactly why a per-identifier reference like this one earns its place open on a second monitor.

The procedure: matching two sources safely

Work from stability to coverage, commit only what is trusted, and preserve everything you touch. This is the sequence I run to merge two company sources without generating false merges.

Step 4 is the one most teams skip and most regret. Domain matching only works on exact matches of the domain string, so if one source stores "www.example.com" and the other stores "example.com", they are left as duplicates. Canonicalization is cheap insurance against a whole class of missed matches.

How this goes wrong: false merges and missed matches

Every identifier lies in a specific, repeatable way. The table of failure modes below is the most useful part of this reference: it names the failure, whether it produces a false positive (a wrong merge) or a false negative (a missed match), and the check that catches it.

• Domain shared across unrelated entities. False positive. Two schools on the same email provider get merged into one company. Check: require domain plus one corroborating stable key before merge.
• Domain normalization gap. False negative. "www.example.com" and "example.com" left as duplicates. Check: canonicalize protocol, "www", and casing before comparison.
• Registry number collision across states. False positive. The same number belongs to two unrelated firms in different states and gets merged. Check: always pair the number with its issuing jurisdiction.
• EIN treated as proof of identity. False positive. An EIN accepted as a unique registration key. Check: the EIN is tax-only and not publicly verifiable, so it never keys identity.
• Ticker reuse or recycling. False positive. A post-delisting ticker matched to the prior issuer's history. Check: resolve to CIK or LEI and time-bound the match.
• Industry code as a match key. Either. A self-reported, changeable NAICS code drives a merge or splits one. Check: use it only as a weak probabilistic signal, never a key.
• Legal name versus DBA confusion. False positive. A DBA matched to the wrong legal entity. Check: resolve the DBA back to the registered legal name first.
• Auto-merging medium-confidence pairs. False positive. A fuzzy score treated as certainty. Check: route to a review queue and preserve originals.

The ticker trap is time-shaped

Tickers deserve their own note because their failure is not about scope but about time. The symbol "EAGL" was the ticker for four different SPACs that IPO'd in 2011, 2013, 2015, and 2018. On the TSX, a discontinued ticker can be applied for by another company but cannot be reused for 53 weeks. So a ticker match is only valid within a window. Any historical merge on ticker alone silently blends unrelated issuers, and no amount of string cleaning fixes it - you have to resolve the ticker to a durable filer identity like a CIK or LEI and bound the match to the period the symbol was in force.

Self-reported fields feel structured but behave like free text

Any company may assign any NAICS or SIC code to itself at any time, and change it at any time, with no prerequisite and no central approver. The primary source to confirm an industry code is typically the company itself. That is the definition of a label wearing the costume of a code. It carries the false confidence of structure with the volatility of a free-text field, which is exactly why it belongs in probabilistic scoring and never in a deterministic key.

Coverage is jurisdiction-dependent, so re-check the fill rate

Do not assume the LEI or a registry number is present just because it is the best key - coverage moves with regulation and must be measured per source. Regulation manufactures LEI coverage in bursts. In 2025 more than 355,000 new LEIs were issued, taking the active population past 2.93 million at a 13.5 percent annual growth rate, up from 11.5 percent the prior year, with a large share driven by a single national mandate. The practical read: LEI fill-rate is high for EU and Indian regulated entities and sparse elsewhere. Your ranking of keys is only as good as the coverage grid from step 1, and that grid changes over time.

This is why the inventory step is not one-time. When a source is refreshed or a new jurisdiction enters your account universe, re-measure fill-rate per identifier before you trust your old key ranking. A chain tuned for US-heavy data will misbehave on a source dominated by EU entities where the LEI suddenly becomes the strongest available join.

The scarcity of the specialism compounds this. Refolk's index shows the supply gap between the two largest English-speaking markets for this work.

Against that thin bench, Refolk's index also shows 1,579 US Revenue Operations profiles, the core audience answerable for account merges and territory routing. The people who own the outcome vastly outnumber the people who have built the machinery, which is the structural reason this work gets improvised. When you do need to hire or borrow the machinery, Refolk surfaces the handful of people who list record linkage directly, rather than making you infer it from job titles.

Before you commit the merge

Run this checklist against every batch before it updates core records. It is the difference between a merge you can defend and one you will be unwinding later.

The identifiers themselves are stable knowledge - an LEI will always be globally unique, a US number will always need its state. What changes is coverage, and coverage is the thing you re-check. Keep the coverage grid from step 1 versioned, rerun it whenever a source changes, and let it, not habit, decide the order of your fallback chain. That single discipline keeps this reference true against your data long after any specific fill-rate number has moved.