Matching Supplier Names — Which Method Works Best?
What is this about?
When our system reads a document (like an invoice) using AI, it picks up a supplier or
customer or product name written on the paper — for example "Coupling 1/50" (a garbled
reading of the real product "Cuplock 1.5 mtr") or "KRISHNA SCAFF" (a name cut short). Our
software then has to figure out: which supplier or product already saved in our database
does this match?
There are several known methods (algorithms) other companies use to do this kind of
matching. We currently use one method. This report tests our current method against 5
other well-known methods, using our real supplier data (not made-up test data), to see
if we should switch to something better.
How we tested it
- We used the real list of suppliers already saved in our system (22 real companies).
- We made 14 realistic test searches — the kind of messy input we actually get from
scanned documents: spelling mistakes, cut-off names, extra words like "Pvt Ltd" or "Trading Co.",
words in the wrong order, extra spaces, capital/small letter mix-ups, and scanner
mistakes (like reading "O" as "0").
- For each test search, every method tried to guess the correct supplier out of all 22.
- We checked: did it guess correctly? Was the correct answer at least in the top 5 guesses
(since our system shows the reviewer 5 options to choose from, not just 1)?
Results — how each method scored
Out of 14 test searches, how many did each method get right first try, and how many did it
at least get into the top 5?
| Method |
Got it right (1st try) |
Got it in top 5 |
Overall Score |
| Our current method |
14 out of 14 |
14 out of 14 |
Best |
| A similar variant of our current method |
14 out of 14 |
14 out of 14 |
Best (tied) |
| Word-overlap matching |
14 out of 14 |
14 out of 14 |
Best (tied) |
| Name-similarity scoring (good for typos in names) |
13 out of 14 |
14 out of 14 |
Very good |
| Simple keyword search (like Ctrl+F) |
13 out of 14 |
14 out of 14 |
Very good |
| Combined scoring (mixing a few methods together) |
13 out of 14 |
14 out of 14 |
Very good |
| Removing "Pvt Ltd" etc. before comparing |
13 out of 14 |
13 out of 14 |
Good |
| Spelling-distance counting (counts letter changes) |
12 out of 14 |
12 out of 14 |
Okay |
| Sound-alike matching (matches names that sound similar when spoken) |
11 out of 14 |
12 out of 14 |
Weaker |
| Search-engine style keyword search |
10 out of 14 |
11 out of 14 |
Weakest |
What we learned about each method, in plain terms
Spelling-distance counting — counts how many letters you'd need to change to turn one
name into another. Good at catching typos, but gets confused if two words are just
swapped around (e.g. "Scaffolding Siyaram" vs "Siyaram Scaffolding" — same words, different
order — this method ranked the correct answer almost at the bottom).
Sound-alike matching — groups names that sound similar when spoken out loud (like how
"Smith" and "Smyth" sound the same). Problem: it's too broad — lots of unrelated company
names ended up sounding "the same" to this method, so it gave confusing, noisy results.
Name-similarity scoring — built especially for matching people/company names, gives
extra credit when the beginning of two names matches. Performed very well, second only to
our current method. Its only miss was, again, the word-order-swapped case.
Our current method (word/text similarity) — the clear winner, tied for 1st place with 2
close variants. It handled typos, cut-off names, extra words, capital letters, and even
scanner mistakes correctly every single time. It's also the only method here that can be
looked up quickly even if we have thousands or millions of suppliers later — the other
good-performing methods would get noticeably slower as the supplier list grows.
Search-engine style keyword search — works by breaking a name into dictionary "root
words" and matching those. This performed the worst. The problem: it doesn't
understand typos at all — if a name has even one letter wrong, it often finds zero
matches. It also badly failed on short/cut-off names.
Simple keyword search (like Ctrl+F) — just checks if parts of the name appear inside
the stored name. Did surprisingly well on our test, but it has a real weak spot: if a name
is badly misspelled (not just one letter, but garbled), this method can completely miss it,
since it only looks for exact word pieces.
The one case nothing could solve
Every method — including our current best one — struggled with one specific situation:
we have two branches of the same company saved as two different suppliers:
- "Shanti Scaffolding & Shuttering - Delhi"
- "Shanti Scaffolding & Shuttering - Harayana"
These two names are almost identical on purpose (same parent company, different city). No
text-matching method can reliably tell these apart just by comparing spelling — they're
too similar to each other by design.
The real fix for this isn't a smarter spelling-matching method at all. Every Indian
business has a unique tax ID number (called a GSTIN) — like a fingerprint, no two
companies share one, even different branches of the same company. If we can read the
GSTIN off the document and match it directly against our database (instead of just
matching the name), we can tell the two branches apart with certainty. This was already
suggested separately and is still the best next step — not covered by this report's tests.
A harder real case: "Coupling 1/50"
We also tested a tougher, real situation — a scanned document read the product name as
"Coupling 1/50", when the real saved product is "Cuplock 1.5 mtr". This is harder than the
supplier examples above because the words don't share any letters in common — "Coupling"
and "Cuplock" are just two different trade words for a similar scaffolding part, and
"1/50" vs "1.5" is a number written two different ways. Nothing to spell-match against —
you need to recognize it's "close enough," not just count matching letters.
We tried all 10 methods again on this one case, checking where each one ranked the correct
product ("Cuplock 1.5 mtr") out of 97 real products:
| Method |
Got it right? |
Note |
| Our current method |
Yes — ranked #1 |
But its confidence score was too low — see below |
| A similar variant of our current method |
Yes — ranked #1 |
Same low-confidence issue |
| Spelling-distance counting |
Yes — ranked #1 |
Clear, confident win |
| Name-similarity scoring |
No — ranked #6 |
Got confused by unrelated names starting with similar letters |
| Word-overlap matching |
No — ranked #67 (basically last) |
No shared whole words at all, so it saw nothing in common |
| Removing extra words + spelling-distance counting |
Yes — ranked #1 |
Same clean win as spelling-distance counting |
| Combined scoring |
Yes — ranked #1 |
But only barely ahead of a wrong answer |
| Sound-alike matching |
Yes — ranked #1 |
But tied with 4 other unrelated products, so not a clean answer |
| Search-engine style keyword search |
No — ranked #67 |
No matching root words |
| Simple keyword search |
No — ranked #67 |
No matching text pieces at all |
The important discovery
Our current method still picked the right answer first — but its confidence score for that
correct answer was 0.25. Our system only shows a match to a reviewer if the confidence
score is above 0.3. That means, in real use, this correct match would have been thrown
away and never shown to anyone — the reviewer would have seen no suggestion at all, even
though our own system technically knew the right answer.
Spelling-distance counting, on the other hand, scored this same correct answer at a
confident 0.40 — comfortably clear of the cutoff problem.
Bottom line
We don't need to change our current matching method — it already performs the best (or
tied for best) on real data, and it's also the one built to stay fast as our supplier list
grows. Switching to any of the other well-performing methods would not improve accuracy,
and would likely make searches slower over time as more suppliers get added.
The one real improvement worth making is adding the tax-ID (GSTIN) check mentioned above,
since that solves the one case that spelling-matching alone can never fully solve.
One honest caveat: we only tested against 22 real suppliers and 14 test searches. That's
real data, not guesswork, but it's a small sample. It would be good to re-run this same test
against a bigger customer's supplier list later to double-check these results hold up at scale.
Matching Supplier Names — Which Method Works Best?
What is this about?
When our system reads a document (like an invoice) using AI, it picks up a supplier or
customer or product name written on the paper — for example "Coupling 1/50" (a garbled
reading of the real product "Cuplock 1.5 mtr") or "KRISHNA SCAFF" (a name cut short). Our
software then has to figure out: which supplier or product already saved in our database
does this match?
There are several known methods (algorithms) other companies use to do this kind of
matching. We currently use one method. This report tests our current method against 5
other well-known methods, using our real supplier data (not made-up test data), to see
if we should switch to something better.
How we tested it
scanned documents: spelling mistakes, cut-off names, extra words like "Pvt Ltd" or "Trading Co.",
words in the wrong order, extra spaces, capital/small letter mix-ups, and scanner
mistakes (like reading "O" as "0").
(since our system shows the reviewer 5 options to choose from, not just 1)?
Results — how each method scored
Out of 14 test searches, how many did each method get right first try, and how many did it
at least get into the top 5?
What we learned about each method, in plain terms
Spelling-distance counting — counts how many letters you'd need to change to turn one
name into another. Good at catching typos, but gets confused if two words are just
swapped around (e.g. "Scaffolding Siyaram" vs "Siyaram Scaffolding" — same words, different
order — this method ranked the correct answer almost at the bottom).
Sound-alike matching — groups names that sound similar when spoken out loud (like how
"Smith" and "Smyth" sound the same). Problem: it's too broad — lots of unrelated company
names ended up sounding "the same" to this method, so it gave confusing, noisy results.
Name-similarity scoring — built especially for matching people/company names, gives
extra credit when the beginning of two names matches. Performed very well, second only to
our current method. Its only miss was, again, the word-order-swapped case.
Our current method (word/text similarity) — the clear winner, tied for 1st place with 2
close variants. It handled typos, cut-off names, extra words, capital letters, and even
scanner mistakes correctly every single time. It's also the only method here that can be
looked up quickly even if we have thousands or millions of suppliers later — the other
good-performing methods would get noticeably slower as the supplier list grows.
Search-engine style keyword search — works by breaking a name into dictionary "root
words" and matching those. This performed the worst. The problem: it doesn't
understand typos at all — if a name has even one letter wrong, it often finds zero
matches. It also badly failed on short/cut-off names.
Simple keyword search (like Ctrl+F) — just checks if parts of the name appear inside
the stored name. Did surprisingly well on our test, but it has a real weak spot: if a name
is badly misspelled (not just one letter, but garbled), this method can completely miss it,
since it only looks for exact word pieces.
The one case nothing could solve
Every method — including our current best one — struggled with one specific situation:
we have two branches of the same company saved as two different suppliers:
These two names are almost identical on purpose (same parent company, different city). No
text-matching method can reliably tell these apart just by comparing spelling — they're
too similar to each other by design.
The real fix for this isn't a smarter spelling-matching method at all. Every Indian
business has a unique tax ID number (called a GSTIN) — like a fingerprint, no two
companies share one, even different branches of the same company. If we can read the
GSTIN off the document and match it directly against our database (instead of just
matching the name), we can tell the two branches apart with certainty. This was already
suggested separately and is still the best next step — not covered by this report's tests.
A harder real case: "Coupling 1/50"
We also tested a tougher, real situation — a scanned document read the product name as
"Coupling 1/50", when the real saved product is "Cuplock 1.5 mtr". This is harder than the
supplier examples above because the words don't share any letters in common — "Coupling"
and "Cuplock" are just two different trade words for a similar scaffolding part, and
"1/50" vs "1.5" is a number written two different ways. Nothing to spell-match against —
you need to recognize it's "close enough," not just count matching letters.
We tried all 10 methods again on this one case, checking where each one ranked the correct
product ("Cuplock 1.5 mtr") out of 97 real products:
The important discovery
Our current method still picked the right answer first — but its confidence score for that
correct answer was 0.25. Our system only shows a match to a reviewer if the confidence
score is above 0.3. That means, in real use, this correct match would have been thrown
away and never shown to anyone — the reviewer would have seen no suggestion at all, even
though our own system technically knew the right answer.
Spelling-distance counting, on the other hand, scored this same correct answer at a
confident 0.40 — comfortably clear of the cutoff problem.
Bottom line
We don't need to change our current matching method — it already performs the best (or
tied for best) on real data, and it's also the one built to stay fast as our supplier list
grows. Switching to any of the other well-performing methods would not improve accuracy,
and would likely make searches slower over time as more suppliers get added.
The one real improvement worth making is adding the tax-ID (GSTIN) check mentioned above,
since that solves the one case that spelling-matching alone can never fully solve.
One honest caveat: we only tested against 22 real suppliers and 14 test searches. That's
real data, not guesswork, but it's a small sample. It would be good to re-run this same test
against a bigger customer's supplier list later to double-check these results hold up at scale.