This Bytechap analysis examines the hard version of company entity matching: two records contain names, but no reliable registration number, address, website, or ownership data. A model must decide whether spelling, punctuation, legal suffixes, abbreviations, and word order describe the same organization or two genuinely different companies.
Normalize before asking an LLM
The first stage should be deterministic. Convert case consistently, normalize Unicode, remove punctuation where appropriate, standardize whitespace, and map common legal forms such as N.V., Ltd., GmbH, and Inc. into known tokens. This makes easy pairs cheap to resolve and prevents the language model from spending time on formatting noise.
Generate candidates, then judge
Comparing every company against every other company does not scale. A blocking or retrieval stage should first produce a small candidate set using character n-grams, token similarity, phonetic keys, or embeddings. An LLM can then examine only ambiguous pairs and return a decision with a reason and confidence score.
Names alone impose a hard ceiling
An LLM may recognize that legal suffixes are optional or that abbreviations expand to the same words, but it cannot invent missing evidence. Similar subsidiaries can share almost identical names, while unrelated businesses can use the same trading name in different countries. A safe system needs an “uncertain” outcome instead of forcing every pair into match or non-match.
Evaluation must reflect business cost
Accuracy alone hides the difference between a false merge and a missed match. Merging two companies can contaminate financial, compliance, or customer records; failing to merge duplicates may be less destructive but still expensive. Thresholds should therefore be calibrated separately for automatic matching, human review, and automatic rejection.
The strongest design is hybrid
A practical pipeline combines deterministic normalization, fast candidate retrieval, conventional similarity features, and an LLM only for the ambiguous middle. Every decision should retain the original strings, intermediate scores, model version, prompt version, and reviewer corrections so the system can be audited and improved over time.