How Product Matching Actually Works at Scale (and Why LLMs Alone Aren't Enough)

Two suppliers send you the same hydraulic fitting. One calls it 1/2" BSP 350 bar, the other DN15 5076 psi, and your ERP already carries a third record under a different part number with the pressure rating blank. A person glances at all three and knows they’re one product. Getting software to reach that same conclusion — reliably, across hundreds of thousands of records, without merging two things that only look alike — is the actual hard problem underneath every clean catalog.

It’s called product matching, and most teams underestimate it until a bad merge corrupts a quote.

Matching is where catalog quality is won or lost. Product deduplication, enrichment, and a trusted canonical product record all depend on it: you can’t merge duplicates you haven’t matched, can’t enrich a product whose identity you haven’t resolved, and can’t trust a golden record built on the wrong join. So it’s worth understanding how matching is done well — and why the obvious modern answer, “just ask an LLM,” is only part of the picture.

Deterministic matching: rules you can trust

Deterministic matching joins records on exact agreement of identifying values. If two records share a GTIN, an MPN, or a normalized supplier SKU, they’re the same product — full stop. Where you have clean, shared identifiers, this is the strongest method you’ve got: it’s exact, explainable, and auditable. Nobody has to wonder why two records matched; they matched because the manufacturer part numbers are identical.

The catch is that weak-standard, multi-supplier catalogs rarely give you clean shared identifiers. One supplier omits the MPN. Another invents an internal SKU. A third puts the real part number inside a free-text description. Deterministic rules are precise but brittle — they match what’s clean and silently miss everything that isn’t, which in a real supplier feed is most of it.

If you need a deeper definition of the discipline behind this, start with entity resolution. Product matching is entity resolution applied to messy, overlapping product and supplier records.

Probabilistic matching: judgement under uncertainty

When identifiers don’t line up, you fall back to similarity. Probabilistic, or fuzzy, matching scores how alike two records are across multiple attributes — name, brand, dimensions, specs, units — and treats a high enough combined score as a likely match. This is what lets 1/2" BSP and DN15 resolve to the same fitting once you’ve normalized the thread standards and reconciled bar to psi.

Done seriously, this is more than string similarity. It involves normalizing units and formats first, so 350 bar and 5076 psi are comparable at all; blocking the data into candidate groups so you’re not comparing every record against every other one; weighting attributes by how identifying they are, because a brand match means less than a matching manufacturer part number; and producing a confidence score rather than a yes/no. Probabilistic matching is powerful precisely because it tolerates the mess — but it’s also where false merges happen, which is why a score alone isn’t a decision.

Why an LLM on its own isn’t the answer

Large language models are genuinely good at one slice of this: reading messy free text, pulling a likely part number out of a description, suggesting that two oddly worded rows might be related. That’s real value. But matching at catalog scale needs three things an LLM, used alone, doesn’t reliably give you.

First, it needs to be deterministic where it can be — you don’t want a probabilistic guess on records that share an exact GTIN. Second, it needs to be explainable and auditable — when a match writes back into your item master, you need to know why, not “the model thought so.” Third, it needs calibrated confidence you can threshold, so the system knows the difference between a match it should commit automatically and one a human should check.

The reliable pattern isn’t model-versus-rules. It’s a pipeline: normalize the data, apply deterministic rules where clean identifiers exist, use probabilistic scoring with LLMs helping on the messy free-text edges where they don’t, attach a confidence score and the evidence behind it to every candidate match, and route by confidence. High confidence merges automatically. The grey band goes to human review. Low confidence is rejected. That’s how you get the LLM’s flexibility without inheriting its tendency to guess.

Confidence and provenance are the whole game

A match isn’t useful until you can trust it enough to act on it. That’s why the output that matters isn’t a merged row — it’s a merged row with a confidence level and a record of why it merged. When the system writes a canonical record back into ERP or PIM, every decision carries its evidence: which identifiers agreed, which attributes were normalized, where each value came from.

That provenance is what makes a merge safe to automate and reversible if it’s ever wrong. Generating a match is easy. Generating a match you’d let touch your system of record is the hard part.

This is exactly how Claro approaches matching. We resolve product identity with deterministic checks where shared identifiers exist and probabilistic scoring where they don’t, attach a confidence score and provenance to every match, auto-merge what’s clearly the same product, and hold the uncertain cases for review instead of guessing. The result is one canonical, trusted record per real-world product — the golden record everything downstream depends on.

Before and after

Want to see product matching run on your own supplier feeds?

Bring your messiest two-supplier overlap and we’ll show you what resolves automatically, what we’d flag for review, and why.

Book a demo

Related Claro resources

FAQ

What's the difference between deterministic and probabilistic matching? +

Deterministic matching joins records on exact agreement of identifying values such as GTIN, MPN, or normalized SKU — precise and auditable, but brittle when identifiers are missing. Probabilistic matching scores similarity across attributes and treats a high enough combined score as a likely match — tolerant of messy data, but it needs a confidence threshold and review to avoid false merges.

Can't I just use an LLM to match products? +

An LLM helps with the messy free-text edges — extracting a part number from a description, flagging that two odd rows might relate. But matching at scale also needs deterministic rules where identifiers are clean, explainable and auditable decisions, and calibrated confidence you can threshold. The reliable approach combines all three rather than relying on a model’s guess.

What is a golden record in product matching? +

A golden record, or canonical record, is the single trusted version of a product, built by matching every record that describes it, reconciling their values, and attaching confidence and provenance. It’s what your ERP, PIM, search, and downstream systems read from instead of the conflicting source rows.

Claro keeps multi-supplier product and supplier data clean, matched, enriched, and validated across your existing ERP, PIM, and procurement systems. Your catalog should get smarter every day.