UNECE Rec 20 Unit Codes Explained

Unit fields are one of the quietest failure modes in product data: a supplier writes “ea”, a second writes “each”, a third writes “pc”, and an automated matcher sees three pack configurations instead of one. UNECE Rec 20 unit codes collapse those variants into a single canonical token — MTR for metre, KGM for kilogram, EA for each — so your PIM, ERP, and enrichment pipeline can compare, convert, and validate without re-parsing free text. Claro normalizes and validates unit codes as part of building a trusted canonical product record, so the problem is fixed once at ingestion and stays fixed across every channel and supplier feed.

Definition

UNECE Recommendation 20 (Rec 20) is the United Nations Economic Commission for Europe standard formally titled Codes for Units of Measure Used in International Trade. It assigns a short alphanumeric code — typically up to three characters — to each unit of measure a product or shipment might be expressed in:

Each code also carries a common name, a description, and a symbol. The recommendation is widely embedded in cross-border trade and electronic data interchange and is the unit vocabulary GS1 references for attributes in the Global Data Synchronisation Network (GDSN). Rec 20 is paired in practice with UNECE Rec 21 — codes for passengers, cargo types, packaging materials — for the packaging side of the same problem.

Why UNECE Rec 20 unit codes matter for product data

Units are a silent failure mode in matching, deduplication, and enrichment. Without a normalized code, automated systems cannot tell whether two records describe the same selling unit or two genuinely different pack configurations. That ambiguity creates duplicates, misprices, and listing rejections across the full data supply chain.

Consider an MRO distributor consolidating two acquired catalogs: one lists a lubricant as sold per “QT”, another per “quart”, and a third feed expresses the same SKU in litres. Without a normalized Rec 20 code, a matcher sees three distinct configurations and either creates duplicate records or merges products that are genuinely different sizes. Mapping every value to a Rec 20 code — QT for US quart, LTR for litre — lets the matcher compare like with like and lets enrichment correctly compute price-per-unit.

The same problem appears across industries. A CPG vendor syndicating to a grocery marketplace must report net content in a unit the retailer’s schema accepts; a mismatch between GRM and “g” can block a listing at the data pool. A furniture seller importing from multiple factories receives dimensions in millimetres, centimetres, and inches, and only a normalized unit lets a single facet filter (“width under 60 cm”) work across the whole assortment. In industrial distribution, cable sold per metre versus per foot, or fasteners sold per 100 versus per box, drives real pricing errors when units are not canonicalized first.

Units also matter for AI search and generative engines. When a shopper asks for “the 5-litre can,” the model can only answer confidently if your catalog carries a structured, comparable quantity and unit, not a string buried in a description. Clean Rec 20 codes feed the structured product attributes that machines cite.

Before and after: messy units vs. trusted units

How Claro applies Rec 20 during enrichment

Claro maps incoming free-text unit values from every supplier feed to their canonical Rec 20 codes as part of attribute normalization. The validated code is stored alongside the human-readable label in the canonical product record. When a new feed arrives with a different unit spelling or a different measurement system, Claro converts and validates before the record reaches your PIM or ERP, so schema drift in unit fields does not accumulate silently over time. Validation failures surface as flagged attributes with confidence scores, giving your team a clear remediation queue rather than a silent data quality problem.

This matters especially for teams running multiple supplier onboardings simultaneously or managing catalogs that span both metric and imperial supplier bases. Unit normalization is one of the most reliable, lowest-risk enrichment steps — because the mapping from “quart” to QT is deterministic, it carries a high confidence score by default and rarely requires human review.

Related

FAQ

What does UNECE Rec 20 stand for? +

It stands for United Nations Economic Commission for Europe Recommendation No. 20, formally titled Codes for Units of Measure Used in International Trade. It is the maintained list of standard codes that name units of measure unambiguously for trade and data exchange.

What format do UNECE Rec 20 unit codes use? +

Each unit has a common code of up to three alphanumeric characters — MTR for metre, KGM for kilogram, LTR for litre, GRM for gram, EA for each. The standard also records each code’s name, description, and, where applicable, its relationship to a base SI unit.

How is Rec 20 different from a unit of measure? +

Unit of measure is the general concept (length, weight, volume, count). Rec 20 is a specific controlled vocabulary that assigns one canonical code to each unit, so different spellings and languages for the same unit all resolve to one value your systems can compare and convert.

Where are UNECE Rec 20 codes used in product data? +

They appear in EDI messages, customs and trade documents, and GS1 GDSN attributes such as net content and packaging measurements. Many PIM and ERP systems use them as the backing code list for unit fields so data stays interoperable across trading partners.

Is EA a valid Rec 20 unit code? +

Yes. EA denotes ‘each’, the unit used for items counted individually rather than measured by weight, volume, or length. It is one of the most common codes in retail and distribution catalogs because so many products are simply sold per piece.

How does Claro handle unit normalization during enrichment? +

Claro maps incoming free-text unit values from every supplier feed to their canonical Rec 20 codes as part of attribute normalization. The validated code is stored alongside the human-readable label in the canonical product record, so price-per-unit calculations, deduplication, and downstream channel exports all read from one trusted, machine-comparable field.