How to Match Multilingual Supplier Catalogs Without Losing Product Identity

Three supplier rows can describe one bolt in three languages and still be a trap. The text similarity between Hex bolt M8x40 zinc plated and Hex bolt M8x45 zinc plated is higher than between the English and German versions of the correct match. A matcher driven by string or embedding similarity will rank the wrong pair first. This playbook shows how to separate language work (translation, abbreviation expansion) from identity work (attribute comparison and approval), using one fastener as the worked example.

Input and audience

• Input: two or more supplier files for overlapping product ranges, in different languages or abbreviation styles, with no shared GTIN or with an unreliable MPN. See how to match supplier products without a GTIN for the identifier-first part of the workflow.
• Audience: catalog and product-data managers at distributors, and the engineers or buyers who sign off on technical equivalence.
• Output: a reviewed match table where each pair is approved, rejected or needs review, with the evidence for every identity-defining attribute.

The worked example

One physical item (an M8 hexagon bolt, 40 mm long, zinc plated) arrives from three suppliers. Two more rows look similar but are different products.

row_id,supplier,language_hint,supplier_sku,description
A1,SupplierA,en,A-10240,Hex bolt M8x40 zinc plated
B1,SupplierB,de,B-77310,Sechskantschraube M8x40 verzinkt
C1,SupplierC,abbrev,C-0042,6KT SCR M8X40 ZN
A2,SupplierA,en,A-10245,Hex bolt M8x45 zinc plated
B2,SupplierB,de,B-77315,Sechskantschraube DIN 933 M8x40 verzinkt
B3,SupplierB,de,B-77316,Sechskantschraube DIN 931 M8x40 verzinkt

Illustrative / synthetic source file.

Step by step

1. 1
   Keep the raw string and tag its language

   Store the description exactly as received, with supplier, row and file reference. Tag the language or abbreviation style per supplier, not per row, so the tagging rule is reproducible. Never overwrite the raw text with a translation. See data provenance for why the original string must survive.

2. 2
   Extract candidate attributes, not conclusions

   Parse each description into candidates: product type, thread size, nominal length, finish, standard, property class. Mark each candidate as stated (the text says it), inferred (a rule or dictionary supplied it) or absent. For example, Sechskantschraube yields product type “hexagon head screw or bolt” as inferred from a dictionary, and 6KT is read as an abbreviation of the German “Sechskant” (hexagon) only because the sibling rows use that word; flag this reading for review rather than hard-coding it.

3. 3
   Normalize into one schema with units and standards

   Map candidates into the target fields of your schema. For fasteners, the hex bolt attribute template lists the fields that matter: thread size and series, length, grade or property class, finish and the dimensional standard. Normalize M8x40 to thread M8, length 40 mm; normalize decimal commas and units before comparison. The general method is in map supplier attributes to your schema.

4. 4
   Declare which attributes define identity

   Before comparing any pair, decide which attributes must be equal for two rows to be the same product. For a hex bolt these are at least: thread size, nominal length, product form (full or partial thread, which the dimensional standard normally decides), property class or material, and finish or coating. Anything not on that list is informational. Write the list down so reviewers and matchers share it.

5. 5
   Compare attributes pair by pair and record each verdict

   For each candidate pair, record per attribute: equal, different, or unresolved (one side is absent or ambiguous). A single different on an identity attribute rejects the pair. A single unresolved caps the pair at needs review. Only a pair with every identity attribute equal can be approved, and only with evidence for each.

6. 6
   Route unresolved attributes to a named review reason

   Do not collapse unresolved into a low score. Give each one a reason code (for example finish_ambiguous, property_class_missing, standard_missing) so the fix is targeted: ask the supplier, read a datasheet, or let a technical reviewer decide.

7. 7
   Approve identity separately from translation

   Store the translated text and the identity decision as separate things. A good translation is not a match. A match is a reviewed decision that cites attribute evidence. See variant vs duplicate vs replacement for the relationship types to record when a pair is close but not identical.

Raw to canonical

Standards: do not merge full-thread and partial-thread bolts

DIN 933 describes the fully threaded hexagon screw (“thread up to the head”) and DIN 931 the partially threaded hexagon bolt. Both DIN documents are withdrawn and the content now lives in ISO standards: DIN 933 is listed as replaced by ISO 4017 (hexagon head screws, product grades A and B), and DIN 931 is listed by DIN Media as withdrawn and replaced by DIN EN ISO 4014 (hexagon head bolts, product grades A and B). Suppliers still print the old DIN numbers.

What this means for matching:

• DIN 933 M8x40 and DIN 931 M8x40 share thread and length but differ in thread coverage. They are different products for matching purposes, and B2 versus B3 above must not auto-merge.
• A row with no standard stated (A1, B1, C1) is compatible with either form until evidence says otherwise. That is an unresolved standard, not a free pass.
• A DIN-numbered row and an ISO-numbered row of the same form are candidates for equivalence, but the standards are not guaranteed to be identical in every dimension. One distributor page notes changed wrench widths for some sizes between DIN 931 and ISO 4014 (see the Böllhoff catalog note, a vendor description rather than the standard text). Record equivalence as a reviewed relationship, not as an automatic synonym.

Validations

Run these checks on the normalized table before any pair is approved.

Reviewed output

row_id,thread,length_mm,product_type,finish_raw,finish_canonical,standard_stated,property_class,form_known
A1,M8,40,hexagon head screw or bolt,zinc plated,zinc plated (spec unknown),,,no
B1,M8,40,hexagon head screw or bolt,verzinkt,zinc plated (spec unknown),,,no
C1,M8,40,hexagon head screw or bolt,ZN,UNRESOLVED,,,no
A2,M8,45,hexagon head screw or bolt,zinc plated,zinc plated (spec unknown),,,no
B2,M8,40,hexagon head screw or bolt,verzinkt,zinc plated (spec unknown),DIN 933,,yes (full thread)
B3,M8,40,hexagon head screw or bolt,verzinkt,zinc plated (spec unknown),DIN 931,,yes (partial thread)

Illustrative / synthetic mapped file.

pair,decision,reason
A1-B1,needs_review,"thread and length equal; finish equal by reading; standard, property class and coating spec absent on both"
A1-C1,needs_review,"finish_ambiguous (ZN); standard and property class absent"
B1-C1,needs_review,"finish_ambiguous (ZN); standard and property class absent"
A1-A2,rejected,"length 40 vs 45 mm"
B2-B3,rejected,"DIN 933 (full thread) vs DIN 931 (partial thread)"
A1-B2,needs_review,"A1 has no stated standard; B2 is full thread; cannot confirm form of A1"

Illustrative / synthetic decisions. Note that no pair is approved: with property class and coating specification absent on every row, the honest outcome is a short, specific review queue rather than a confident merge.

Unresolved attributes and how to close them

Exceptions and review conditions

Send a pair to a human reviewer when any of these hold:

• An identity attribute is unresolved on either side.
• Two different standards are stated, even if one is the legacy DIN and the other the ISO successor (record the relationship, do not merge silently).
• A numeric attribute differs by a small amount that could be a typo, such as M8x40 against M8x4O.
• The abbreviation reading rests on one supplier’s convention only.
• The pair would merge two SKUs with different pack sizes (see same MPN, different pack sizes).

Checklist and artifact

• Raw description stored unmodified beside every translation
• Each candidate attribute marked stated / inferred / absent
• Identity-defining attributes written down per category
• Thread size and length compared as numbers, never as text similarity
• Standard and thread coverage compared; legacy DIN vs ISO relationships recorded as reviewed equivalences
• Ambiguous tokens (such as ZN) carried as unresolved with a reason code
• No pair approved on translation alone
• Evidence reference stored for each approved attribute

The artifact is a pair decision table like the second CSV above, with an evidence column added.

Related Claro workflow

Claro’s catalog matching uses the same separation: it extracts attributes from supplier descriptions, compares them with the evidence attached, and routes pairs with unresolved identity attributes to review instead of auto-approving them. You can run the playbook above in a spreadsheet first; the point of tooling is to repeat it across thousands of rows and keep the decisions reversible.

Related

FAQ