Quick quiz. Are these the same company: “International Business Machines Corporation,” “IBM Corp.”, “I.B.M.”, and “ibm”?
You answered instantly. Your database can’t. To exact string comparison those are four unrelated values. And that gap between human-obvious and machine-impossible is where deduplication fails, enrichment misses, and the same account ends up with four owners.
Fuzzy matching is how machines close that gap. Here’s how it works on company names specifically (the hardest common case), a Python starting point you can copy, and the ceiling where string similarity stops working.
What is fuzzy matching?
Fuzzy matching decides whether two strings refer to the same thing by scoring their similarity instead of demanding equality. “Acme Ltd” and “ACME Limited” fail an exact match but score high on fuzzy similarity, so a matching pipeline treats them as the same company.
Company names need it more than almost any other data type. The same legal entity shows up under endless legitimate variants: legal suffixes, abbreviations, punctuation, trade names, typos, and translations.
📌 TL;DR: normalize hard first, score similarity with a token method plus an edit-distance method, send the awkward middle scores to human review, and resolve survivors to website domains before merging anything. Name similarity finds candidates. Domains confirm identity.
Why are company names so hard to match?
Company names are hard to match because one entity legitimately appears under many names, and different entities share similar ones. Six everyday failure modes:
- Suffix noise. Inc, LLC, GmbH, S.A., Pty Ltd: legally meaningful, matching-hostile.
- Abbreviation drift. “General Electric” vs “GE”; “Hewlett-Packard” vs “HP”.
- Punctuation and casing. “E*TRADE”, “iRobot”, “3M”: normalization landmines.
- Trade vs legal names. The brand everyone types vs the entity in the registry.
- Similar names, different companies. Every “Apex,” “Summit,” and “Phoenix” in existence. This is fuzzy matching’s false-positive minefield.
- International variants. Transliterations and translated legal forms of the same multinational.
Notice the two failure directions. Missing a true match (four IBM records) and inventing a false one (merging two different Apexes). Every design choice below trades one risk against the other.
How does a company-name matching pipeline work?
A serious pipeline runs three stages: normalize, score, decide. And the first stage does more work than the algorithms get credit for:
- Normalize. Lowercase everything, strip punctuation and accents, remove or expand legal suffixes from a maintained list, collapse whitespace. “ACME Ltd.” and “acme limited” both become “acme” before any algorithm runs. Half of real-world match failures die right here, for free. (The same discipline shows up in data normalization generally; names are just its messiest case.)
- Score similarity. Compare normalized names with one or more algorithms (next section) and produce a similarity score per candidate pair.
- Decide with thresholds. High score: auto-match. Low: no match. The awkward middle: human review queue. Pretending the middle doesn’t exist is how auto-merge disasters happen.
💡 Normalize first: before comparing algorithms, spend your effort on the suffix list. A maintained set of legal-form tokens (inc, llc, gmbh, sarl, pty, oy, ab...) removed at normalization time beats a fancier algorithm run on raw strings. Boring wins here.
Which algorithms should you know?
Five families cover the field. Each thinks differently, and each has a blind spot:
| Algorithm | How it thinks | Good for | Weak against |
|---|---|---|---|
| Levenshtein | Counts character edits between strings | Typos, small variations | Abbreviations, word reordering |
| Jaro-Winkler | Similarity weighted toward matching prefixes | Short names, common-prefix variants | Long multi-word names |
| Token set/sort | Compares words regardless of order | “Bank of America” vs “America Bank of” | Single-word names |
| TF-IDF + cosine | Weights rare words heavily, ignores common ones | Large-scale many-to-many matching | Needs a corpus; setup cost |
| Phonetic (Soundex etc.) | Matches names that sound alike | Transcribed or misheard names | Everything else; use as a supplement |
Edit distance (the count of single-character changes needed to turn one string into another) is formalized in Levenshtein distance, and the sound-alike idea goes back to Soundex, patented a century ago. So none of this is new. What’s new is how cheap it is to run at scale.
The practical answer for company names: normalize hard, then combine a token-based method with an edit-distance method and take the stronger signal. And test on YOUR data, because algorithm rankings shift with the shape of the names you actually hold.
A Python starting point you can copy
Want to try this on your own list today? Two small libraries get you surprisingly far: cleanco strips legal suffixes, and thefuzz scores similarity:
from cleanco import basename
from thefuzz import fuzz
a = basename("ACME Ltd.").lower() # "acme"
b = basename("Acme Limited").lower() # "acme"
score = fuzz.token_set_ratio(a, b) # 100
edit = fuzz.ratio(a, b) # exact-ish comparison
if score >= 90:
print("auto-match candidate")
elif score >= 70:
print("send to review queue")Three honest notes on that snippet. It’s fine for lists in the thousands; for many-to-many matching at scale, move to a TF-IDF approach or RapidFuzz, which runs the same scores much faster. The thresholds (90 and 70) are illustrations, so tune them on a labeled sample of your own pairs. And keep the review queue. No threshold makes it unnecessary.
The ceiling: where fuzzy matching stops working
Here’s the truth from the trenches: no similarity score can tell you that “Apex Solutions” in your CRM and “Apex Solutions” in your import file are DIFFERENT companies in different states. The strings are identical. The entities aren’t. String similarity has hit its ceiling, because similarity can’t resolve identity.
Identity needs an identifier, and for companies the most practical one is the website domain. Two records that resolve to apexsolutions.com are the same company, whatever the name columns say. Records resolving to different domains are different companies, however similar the names. That’s why mature pipelines end with name-to-domain resolution as the tiebreaker. Full disclosure: doing that in bulk is exactly what Company URL Finder sells, so weigh the suggestion with that in mind. The architecture stands on its own either way.
→ The working pipeline: normalize → fuzzy score → resolve survivors to domains → merge on domain, not name.
Downstream, that domain-anchored matching is what makes account enrichment and deduplication trustworthy. It’s the whole reason this problem is worth solving properly.
How do you pick the thresholds?
Pick thresholds by labeling a sample of real pairs and measuring, never by feel. The process takes an afternoon:
- Pull 200 to 300 candidate pairs from your own data, across the score range. Not just the easy ones.
- Label them by hand. Same company, different company, or genuinely unsure. The unsure ones are data too.
- Plot scores against labels. You’ll see a band where the two classes overlap. That band IS your review queue, whatever its edges turn out to be.
- Set the auto-match line where false merges drop to near zero in your sample, and accept that it costs you some missed matches. That trade is correct, because a false merge hurts more.
And revisit the lines quarterly. New data sources bring new name shapes, and a threshold tuned on last year’s imports slowly drifts off target. Ten minutes of spot-checking per quarter keeps it honest.
Common mistakes (I’ve made most of them)
- Merging on name alone. The Apex disaster. Always confirm with an identifier before an irreversible merge.
- One global threshold. Short names need stricter cutoffs than long ones; a 90 on “Ace” means far less than a 90 on “Ace Industrial Group”.
- Skipping normalization. Running algorithms on raw strings makes every score noisier and every threshold a guess.
- No review queue. Forcing every pair into match/no-match converts your middle scores into silent errors, in both directions.
- Testing on toy data. Clean sample lists flatter every algorithm. Benchmark on a labeled slice of your real, ugly data.
🧠 False-merge warning: a missed match costs you a duplicate. A false merge costs you two companies' histories tangled into one record, and un-merging is miserable everywhere. When in doubt, DON'T auto-merge. Queue it.
The merge I still apologize for
My worst variant cluster, from my Hamburg CRM-cleanup days, was one client company under seven spellings. Two with typos, one with the old legal form, and one creative entry that was just the founder’s last name. Fuzzy matching caught six of the seven, and I felt very clever.
Then I auto-merged two logistics companies with near-identical names from neighboring cities. Different owners, different deals, one record. It took a week to untangle the activity history, and a rep lost notes she’d trusted us with. That’s the day the review queue and the domain tiebreaker became permanent policy.
Six good matches don’t pay for one bad merge. Design for the bad one.
How we know this (and what to double-check)
This guide comes from hands-on account-layer cleanups plus the standard literature on record linkage. Honest limits: I’ve quoted no accuracy percentages because they’d be fiction. Match performance depends entirely on the shape of YOUR names, your suffix list, and your thresholds. Label a few hundred real pairs from your own data and measure there before trusting any setup, including one built from this article.
Frequently asked questions
What is fuzzy name matching?
Fuzzy name matching is a similarity-based comparison that treats two non-identical strings as the same entity when they score above a threshold. Matching “Acme Ltd” with “ACME Limited” despite different spellings is the classic case.
What is a fuzzy matching example?
Matching “Jonson & Sons Inc.” with “Johnson and Sons”. Normalization strips the suffix and punctuation, then an edit-distance algorithm scores the remaining difference (one missing letter) as high similarity and flags the pair as the same company.
How do you match company names?
Normalize both lists first (casing, punctuation, legal suffixes), score candidate pairs with a token-based plus an edit-distance algorithm, auto-match high scores, queue the middle for review, and confirm identity with an external key like the website domain before merging.
Can ChatGPT do fuzzy matching?
For a handful of names, yes, a large language model judges “same company?” pairs quite well. For thousands of rows it gets slow, costly, and inconsistent, and you can’t tune a threshold. Use deterministic fuzzy scoring for the bulk work, and consider an LLM only for the review queue.
What is another word for fuzzy matching?
Approximate string matching is the formal computer-science term. In data work you’ll also hear record linkage, data matching, entity resolution, and similarity matching, each emphasizing a slightly different slice of the same problem.
How accurate is fuzzy matching for company names?
With strong normalization and tuned thresholds, it resolves most everyday variants. But it fundamentally cannot distinguish different companies with similar names. For those, you need an identifier check, and resolving names to website domains is the practical tiebreaker that closes the gap.
It’s time to make your database answer the quiz
Run one query this week: group your accounts by normalized name (lowercased, suffixes stripped) and count the groups with more than one record. That’s your duplicate backlog, sized in thirty minutes.
Then resolve those groups to domains before you merge anything. Merging on names alone is how the Apex disaster happens.
You’ve got this. Tell me in the comments the worst name-variant cluster you’ve found. My record is seven spellings, two of them creative.
