Why Supplier Codes Never Match Your Catalog—and What Actually Fixes It

We see the same failure pattern in distributor catalogs: the supplier’s code does not equal the buyer’s SKU, a competitor uses a third code for the same item, and the manufacturer number is missing or formatted differently in every source. The first fix is usually a cross-reference spreadsheet. It works—until the next catalog arrives.

At Claro, we do not treat those code values as product identity. We treat each as a source-specific alias and use record linkage to connect it to the real product. That shift—from maintaining pairs of codes to continuously evaluating evidence—is what makes product deduplication survive supplier change.

A supplier code is local, not universal

Consider one sealed bearing sold through three channels:

All four codes can be valid without matching. A supplier code may also represent a pack, contract line, replacement item, or private-label offer rather than the manufacturer’s base product. Trying to make the strings equal solves the wrong problem.

The explicit failure mode of static mapping tables

A cross-reference table stores supplier_code → internal_sku. It does not store why the relationship was accepted, which attributes agreed, what packaging level applied, or whether the source has changed since validation.

The table starts to rot when any of these events occurs:

• a supplier replaces BRG-88421 with BRG-88421-B after a range refresh;
• a code is reused for a new pack quantity;
• an acquisition introduces a new manufacturer name and duplicate internal SKU;
• the internal catalog merges two records and retires the mapped destination;
• a monthly file silently changes units, column meanings, or leading zeros.

The worst part is silent success: the lookup still returns a destination, so the import appears automated while writing current data onto an obsolete or incorrect item.

Our approach: confidence-scored linkage

We preserve supplier codes, but we use them as one signal in a broader decision. Every proposed link is supported by evidence such as resolved manufacturer, normalized part number, description similarity, dimensions, category, unit of measure, packaging, and previously validated aliases. Conflicts on variant-defining attributes count against the match.

1. Keep the raw source and code namespace

   Store the original supplier row, supplier identity, catalog version, and import time. Never strip a leading zero or overwrite a source code in place; create normalized comparison fields alongside it.

2. Resolve candidates, not just equal strings

   Retrieve plausible internal products using strong identifiers first, then manufacturer, category, normalized text, and technical attributes. This catches changed codes without comparing every supplier row to every catalog row.

3. Score positive and negative evidence

   A normalized MPN and manufacturer agreement may be strong evidence. Conflicting voltage or pack quantity may be disqualifying evidence. Produce a calibrated confidence score and an explanation rather than a binary fuzzy-string result.

4. Apply permission bands

   Auto-link only above a high-confidence threshold, route the middle band to review, and reject weak candidates. Use the confidence-threshold playbook to set bands against labeled examples from your catalog.

5. Turn validations into durable knowledge

   Keep confirmed supplier aliases, rejected candidates, and the evidence behind each decision. When a new feed resembles a known record, that history improves retrieval and scoring without making the old answer irreversible.

6. Re-evaluate on every change

   Re-score a link when the supplier row, internal product, schema, or mapping rules change. Flag meaningful drift instead of letting a stale relationship pass because its two codes still exist.

This is how we think about “self-improving” matching: not an opaque model approving its own guesses, but a controlled system that converts reviewed decisions into reusable evidence, measures outcomes, and keeps humans in charge of uncertain cases.

What good output looks like

A production linkage result should include more than an internal SKU:

Supplier record: Supplier A / BRG-88421-B / catalog 2026-09
Canonical product: MRO-104392
Confidence: 0.987
Evidence: manufacturer resolved; MPN normalized; bore and seal agree
Conflicts: none
Decision: auto-link
Previous alias: BRG-88421

That record can be audited, re-scored, and reversed. It also distinguishes identical products from equivalents, successor items, and pack-level offers—relationships a two-column table tends to collapse.

A practical migration from mappings to linkage

Do not discard the spreadsheet. Import it as historical evidence, sample its rows, and verify them against current attributes. High-quality mappings seed the known-alias layer; stale or conflicting rows become review cases. Then run the supplier-catalog-to-inventory playbook and write confirmed links back to the ERP or PIM.

For existing duplicate internal items, follow how to deduplicate a product catalog and preserve reversible merges. Linkage decides that records describe the same product; deduplication safely resolves what happens next.

If supplier-code reconciliation is consuming every onboarding cycle, bring a real file to a Claro demo. We will evaluate the identifiers, variants, and changed codes that make the current mapping table fail—not substitute a clean sample.

FAQ