Fuzzy String Matching for Company Names: 9 Rules

Your CRM holds two records for the same company and the matcher cannot see it. It also holds two records for genuinely different companies that the matcher swears are identical. Both failures trace back to the same root cause, and it is not your data.

Fuzzy string matching for company names is usually treated as a library call: import a scorer, pick a number, ship it. That approach fails in a specific and measurable way. We scored 16 company-name pairs with RapidFuzz 3.14.5 and jellyfish 1.2.1, verifying each entity against the Global Legal Entity Identifier Foundation register. Nine of those pairs are legally distinct companies. After normalisation, all nine scored a perfect 100 on token_set_ratio.

In Validity’s 2025 survey of 602 CRM users and stakeholders, 76% said less than half of their organisation’s CRM data is accurate and complete. Name matching is where a large share of that inaccuracy is manufactured, one confident wrong merge at a time.

Why fuzzy string matching breaks on company names

Fuzzy string matching breaks on company names because the standard algorithms were built for surnames and typographical errors, not multi-token legal entities. This is not a criticism of the algorithms. It is a mismatch between what they were designed to measure and what a CRM asks them to decide.

Where the standard algorithms came from

Soundex was patented in 1918. Robert C. Russell’s patent, titled simply “Index”, describes grouping names “phonetically rather than according to the alphabetical construction of the names” so that variant spellings of a person’s name sit together in a card index. Jaro-Winkler came later and carries the same DNA: Winkler’s 1990 paper for the Fellegi-Sunter model tuned its prefix weighting on “typographical variation in strings such as first name or surname”, for the Post Enumeration Survey of the 1990 US census. Levenshtein distance, published in 1965, was not about names at all; it described error-correcting codes for binary sequences.

So the three metrics every tutorial reaches for were calibrated on human names and transmission errors. A company name is a different object. It is several tokens long, it carries a jurisdiction-specific legal form, and the tokens that distinguish two real entities are frequently the most ordinary words on the page.

The four ways company names differ

Company-name variation clusters into four kinds, and each one defeats a different metric. Confusing them is why single-metric matching plateaus. Getting the score right is only half the job; something downstream still has to decide which account a record belongs to, and which account a lead actually belongs to is a separate decision with its own tie-breakers.

That last row is the expensive one. The difference between a parent and a separately incorporated division is often a single word, which is exactly where edit distance is smallest and the commercial consequence is largest. Name is also simply a poor identifier compared with the fields that identify a company more reliably than its name, which is why mature matchers treat the name as one signal rather than the deciding one.

Normalise company names before you score them

To normalise a company name, apply a fixed, ordered set of rules before any similarity score is calculated. Order is not a stylistic choice here. Strip legal forms before punctuation and Ltd. keeps its full stop, so it never matches the token Ltd and the rule silently does nothing.

The nine-rule normalisation pipeline

This is the pipeline we used for every measurement in this article. We publish it as CNN-1.0 so it can be cited and reproduced rather than paraphrased.

Rule 9 is the one most implementations omit, and it is the one that prevents the pipeline from doing harm. Holdings, Group, Partners, Ventures, Labs, International, Technologies and Solutions all look like noise and none of them are: they routinely mark a distinct registered entity. Rule 9 also protects purely numeric and single-letter tokens.

Legal forms and entity tokens by jurisdiction

Rule 8 needs a token list, and most articles hand-wave it as “strip LLC, Inc, Corp, Ltd”. That covers one country. The authoritative source is ISO 20275, published by GLEIF as the Entity Legal Forms Code List, version 1.6 of February 2026, which catalogues more than 3,600 legal forms across more than 200 jurisdictions and is released under CC0.

GLEIF tells you which forms exist. It does not tell you whether stripping one is safe. That judgment is the column below.

Name standardisation is the first step of any wider hygiene programme, and it belongs alongside the deduplication and validation work that a CRM data cleansing programme sequences around it. It is also worth checking whether you need to derive the canonical name at all, because an enrichment provider can often hand you the registered legal name directly, which changes normalisation from a guess into a lookup.

Where normalisation goes too far

Aggressive normalisation is the most common way teams make matching worse while believing they improved it. Treat “Global”, “Media” or “Holdings” as noise and Liberty Global Ltd. collapses onto Liberty Global Holdings Ltd. Those are two distinct registered entities with different LEIs in different jurisdictions. The pipeline did not find a match; it created one.

Which similarity metric to use on company names

String similarity metrics score how close two names are, and each one is blind to a different kind of company-name difference. Choosing between them is the actual engineering decision, and it is not the same as choosing a number.

Edit distance, and a correction worth knowing

Edit distance counts the single-character operations needed to turn one string into another. It handles typos and truncation well and token reordering badly. One detail trips up most write-ups: fuzz.ratio is not Levenshtein. The RapidFuzz documentation defines it as “the normalized Indel similarity”, which permits insertions and deletions but not substitutions. Levenshtein allows substitution, so the two disagree on exactly the single-character swaps that separate similar company names.

Token metrics

Token metrics split the name into words and compare the sets, which is why they beat edit distance on reordering. Deutsche Bank AG against “Bank, Deutsche (AG)” scores 62 on fuzz.ratio and 100 on token_sort_ratio. That gain is real. The cost arrives with token_set_ratio, which the same documentation describes as comparing “the words in the strings based on unique and common words between them”. Because it discounts the words that are not shared, an added division token becomes nearly free, and the metric reports a perfect match between a parent and its own subsidiary.

Phonetic and prefix metrics

Soundex and Metaphone reduce a string to a phonetic key, which is useful for blocking and unreliable for scoring multi-token company names in mixed languages. Jaro-Winkler weights early characters heavily, which flatters any pair sharing a first word. Every company in a corporate family shares its first word.

The decision framework is short. Use token_sort_ratio as the default company-name scorer. Use fuzz.ratio as a second opinion when token counts match. Use Jaro-Winkler to rank candidates you have already blocked, never as the accept signal. Avoid token_set_ratio for any automatic merge. Reach for an alias table, not a metric, when acronyms and rebrands appear.

Worth saying plainly: a name that should never have reached the matcher is not a matching problem. Free-text junk, test records and personal email domains are cheaper to reject at capture, which is what a validation gate ahead of the matcher is for.

Cut the comparison count with blocking

Blocking groups records into candidate buckets so the matcher compares thousands of pairs instead of billions. Without it, comparison count grows quadratically and any real CRM becomes uncomputable.

Splink, the record-linkage library published by UK Ministry of Justice Analytical Services, puts the consequence in plain numbers: a dataset of one million records generates around 500 billion pairwise comparisons, and the overwhelming majority cannot possibly be matches.

Blocking keys that work for company names

Good keys are cheap, stable and available on both sides. The first token of the normalised name works well because normalisation has already removed the articles and punctuation that would otherwise scatter it. Email domain, country and the first four characters of the normalised name are all serviceable. Phonetic keys are reasonable here, where a false grouping costs compute rather than correctness.

Blocking is where recall dies

A true pair split across two blocks is never compared, so no threshold can recover it. Block on country and every cross-border duplicate survives forever. This is the failure mode worth testing deliberately: take pairs you know are matches, run the blocking step alone, and count how many end up in different buckets. Blocking also sets the latency budget, which matters because inbound records are usually on a clock that the routing layer’s speed-to-lead targets already define.

How to set and defend a match threshold

To set a match threshold, score a labelled sample of your own pairs and read precision and recall at each cutoff. Copying a number from an article, including this one, produces a threshold you cannot defend when someone asks why a deal landed on the wrong rep.

Label a stratified sample

Take roughly 300 candidate pairs, drawn deliberately across the score range rather than randomly, since a random draw from a real CRM is almost all obvious non-matches. Mark each pair same entity or different entity using a registry rather than intuition. The GLEIF LEI register is free, and two distinct LEIs settle the question.

Read the trade-off, then choose

Precision is the share of accepted pairs that are genuinely the same entity. Recall is the share of true pairs you accepted. Raising the cutoff buys precision and loses recall, and there is no setting that gives you both. What the curve tells you is where the cost changes character.

Pick the cutoff by asking which error you can afford. A wrong merge destroys history and is expensive to unwind; a missed match leaves a duplicate that someone will notice later. Most teams discover their auto-merge bar sits higher than they assumed. The same discipline applies to any scoring cutoff you have to justify, which is the argument behind choosing a cutoff you can defend to a sales leader.

Seed bands you are meant to replace

If you need somewhere to start before the sample is labelled, begin at 92 for auto-accept on token_sort_ratio over CNN-1.0 names, 80 to 92 for the review queue and below 80 for reject. Treat those as placeholders with no evidential weight. They are a starting point for calibration, not a result.

Budget about two hours for a first calibration pass, most of it hand-labelling. That estimate covers one pass over one pair of lists, not a production deployment with monitoring and re-training.

False positives: high scores, different companies

A false positive is a pair that scores above your threshold but belongs to two different legal entities. This is the part of company-name matching that thin write-ups raise and then abandon, so here is the measured version.

Every score below comes from RapidFuzz 3.14.5 and jellyfish 1.2.1 over CNN-1.0-normalised names. Every “different entity” pair was confirmed as two separately registered entities in the GLEIF LEI register. One row, marked as such, is a synthetic export artefact rather than an observed record.

High score, different company

Read the token_set_ratio column again. All nine legally distinct pairs reach 100.0 after normalisation. Fourteen of the sixteen pairs reach 100.0, and only five of those fourteen are actually the same entity. On this set, accepting everything that scores 100 on token_set_ratio would have been correct 5 times out of 14.

Two rows are unwinnable by any string method. Apex Tool Group’s US and Australian entities normalise to the identical string, and “Bank of China Limited” resolves to three separately registered entities with byte-identical legal names in Australia, France and Panama. When two different companies share a name exactly, no threshold and no metric can help. Only a second field can.

Low score, same company

The mirror case gets almost no coverage and costs just as much. IBM against its own registered name scores 17.6, and no amount of tuning fixes it. Meta Platforms scores 18.2 against Facebook, and normalisation makes it worse, because “Inc.” was the only token the two names shared. SEC filings record the former name as “Facebook Inc” until 27 October 2021, which is the fix: acronyms and rebrands need an alias table, maintained by hand, checked before scoring.

The guardrails that catch both

Guardrails are token-level rules that run after scoring and override it. Four earn their keep: reject when numeric tokens disagree, reject when geographic tokens disagree, reject when two candidates carry distinct LEIs, and demote to review when the only difference is a protected descriptor such as Holdings or Energy. Guardrails work where thresholds cannot, because they inspect which token differs rather than how much. What happens to a confirmed duplicate afterwards, including which record survives, is governed by the merge rules that decide which record wins. Subsidiary and post-acquisition ownership policy is a separate decision from matching, and it belongs with your account hierarchy rules.

One honest limit on the numbers above: 16 pairs chosen to be adversarial is a demonstration, not a benchmark. The pairs are published so the result can be reproduced, and the precision figure describes this set only.

Frequently Asked Questions