If you are searching for how to translate UN/CEFACT Recommendation 20 codes, how to translate unit-of-measure codes in international trade, how to translate UN/CEFACT Recommendation 21 package codes, or how to preserve units, package types and trade-data meaning across languages, the safest rule is to separate human-language labels from coded data. Translate the unit or package description where needed; preserve the official code exactly.
This matters in invoices, customs declarations, purchase orders, shipping instructions, electronic data interchange, logistics labels, warehouse systems, product master data, freight documents, procurement systems, trade statistics and cross-border APIs. A translation can look professional and still be operationally wrong if a kilogram code becomes a translated abbreviation, if “piece” is confused with package count, if a carton is translated as a crate, if a container is treated as packaging material, or if quantity and unit separate during spreadsheet or EDI processing.
This guide explains how to translate around UN/CEFACT Recommendation 20 and Recommendation 21 safely. It covers the difference between a unit name and unit code, quantity and package count, package type and packaging material, coded trade data and visible labels, and the quality controls needed in CSV, XML, JSON, EDI and multilingual documents. The page owns this narrow coded-trade-data search intent beneath the wider eduKateSG translation architecture; it does not replace existing articles about physical unit conversion, GS1 identifiers, customs classifications or general technical translation.
1. What UN/CEFACT Recommendation 20 does
Recommendation 20 provides standardized alphabetic and alphanumeric codes for units of measure used in international trade and related economic, scientific and technological activities. The list covers quantities such as length, area, volume, mass, time and many other measurement concepts. Its purpose is interoperability: different trading partners and systems can exchange the same unit without relying on local abbreviations.
2. What UN/CEFACT Recommendation 21 does
Recommendation 21 provides coded representations for package type names and related trade concepts such as cargo and packaging. These codes help trading partners exchange information about how goods are presented, packed or grouped. Translation should make the package description understandable while leaving the official package code unchanged.
3. Codes are not translated abbreviations
A standardized code exists precisely so the underlying concept can remain stable across languages. Do not replace a Recommendation 20 common code with initials derived from the target-language unit name. Do not replace a Recommendation 21 package code with a local warehouse abbreviation. The visible label can change; the coded value should not.
4. Unit name, symbol and common code are different things
A measurement concept can have a full unit name, a scientific symbol and a trade-data common code. These are not always identical strings. Translators should preserve each field according to its function. The unit name can be localized, the scientific symbol follows measurement conventions, and the common code follows UN/CEFACT reference data.
5. A code does not perform a unit conversion
Changing language is different from converting metres to feet or kilograms to pounds. Recommendation 20 identifies the unit; it does not authorize changing the quantity into another unit system. If a target document requires conversion, that is a separate numerical transformation with its own formula, precision and rounding controls.
6. Quantity and unit must stay attached
The number 500 means very different things when paired with kilograms, litres, pieces, metres or hours. Translation workflows that move labels between columns can preserve every number and every unit code yet attach them incorrectly. Quality assurance must therefore check quantity-unit relationships, not just token accuracy.
7. Unit-of-measure codes belong in structured fields
In an ideal trade-data system, quantity and unit are stored separately, such as quantity equals 12.5 and unitCode equals a Recommendation 20 value. The interface can display a localized unit name while the backend retains the canonical code. This separation prevents translators from editing machine-facing values accidentally.
8. Three-character codes can be alphabetic or alphanumeric
Recommendation 20 includes three-character alphabetic and alphanumeric common codes. A code that contains digits should not be interpreted as a quantity. It is still an identifier. Likewise, a code made of letters should not be expanded as though it were a natural-language acronym unless the standard defines that meaning.
9. Unit symbols need scientific discipline
Symbols such as kg, m, s and other scientific notations are governed by measurement conventions, including capitalization and spacing. A translator should not localize case or punctuation to make a symbol look more natural. A change from one case to another can represent a different symbol or become non-standard.
10. “Piece” is a unit concept, not automatically a package
A commercial quantity can be expressed as pieces while the same goods are packed in cartons, boxes, pallets or another package type. Recommendation 20 quantity units and Recommendation 21 package types answer different questions. Translating both as “units” can make a shipment ambiguous.
11. Package type is different from packaging material
A box is a form or type of package; cardboard is a material. A drum can be made from steel, plastic or another material. Recommendation 21 historically covers coded representations across package and packaging concepts, so translation should keep form and material separate when the data model does.
12. Package is different from cargo type
Cargo type describes the nature or handling form of the cargo, while package type describes how the goods are packed. Bulk liquid, containerized cargo and packaged goods can involve different coding layers. Do not translate a cargo category as though it were the package itself.
13. A freight container is not just another carton
International trade uses several layers of containment: the product, its immediate packaging, cases or cartons, pallets and freight containers. Recommendation 21 explicitly distinguishes package concepts from transport equipment in its rules. Translators should not collapse a shipping container into a package-material description.
14. Pallets require context
A pallet can function as transport equipment or as part of a logistics-unit configuration depending on the data model. In some trade messages, the package code describes the goods’ presentation; in GS1 systems, an SSCC can identify the palletized logistics unit. Preserve the source schema rather than assuming one universal meaning.
15. Recommendation 20 does not replace SI
The International System of Units defines scientific measurement units and symbols. Recommendation 20 provides trade-oriented code elements for representing units in data exchange. The two systems interact but are not the same document or purpose. Translate technical explanations without claiming that every UN/CEFACT code is itself an SI symbol.
16. Recommendation 20 can include non-SI trade units
International trade uses units beyond the core SI set, including counts, commercial measures and domain-specific units. A target-language document should preserve the exact unit identified by the source rather than normalizing everything into SI unless the project explicitly requires conversion.
17. Count units are not all interchangeable
Piece, pair, dozen, hundred and other count concepts describe different quantities. Translating all of them as “unit” can alter the number represented. If a source says one dozen, the semantic quantity is twelve items. Preserve the coded unit and translate the display label precisely.
18. Mass and weight terminology needs domain awareness
Commercial documents often use weight in everyday language where scientific writing might distinguish mass. Recommendation 20 names and codes should be interpreted according to the reference list and source business context. Do not rewrite a trade field into a physics lesson, but do not change the identified unit either.
19. Volume and capacity can be context-sensitive
Litres, cubic metres and other units can describe volume or capacity. Product, freight and customs systems may have specific fields for gross volume, net volume or package capacity. Translate the field label and unit independently so the measurement property stays clear.
20. Area units must stay with the property they measure
Square metres can describe floor area, fabric area, land area or surface area. The unit code alone does not explain the business property. Translation should preserve field names such as net area, gross area or covered area while keeping the unit code unchanged.
21. Time units are not timestamps
Hours, minutes and seconds are units of duration. A timestamp such as an ISO 8601 date-time identifies a point or interval on a time scale. Do not confuse Recommendation 20 time-unit codes with timezone or timestamp identifiers already covered elsewhere in the Translate family.
22. Rate units combine quantity relationships
Some business measurements represent one quantity per another, such as mass per volume or currency per quantity. Translation must preserve numerator, denominator and order. Converting “per” into a vague relational phrase can reverse or obscure the rate.
23. Compound units need structural protection
A compound measurement can combine units through multiplication, division or powers. In human-readable labels, punctuation and superscripts can vary by style, but the machine code and mathematical relationship must remain intact. Do not translate operators as words inside a coded field.
24. Decimal separators belong to number formatting, not the unit code
A target locale may display 1.5 as 1,5. That is a formatting decision for the quantity. The Recommendation 20 unit code does not change. Keep numeric localization and unit-code preservation as separate transformations, then round-trip the displayed number to ensure its value survived.
25. Thousands separators can corrupt trade quantities
A comma or period can mean grouping or decimal separation depending on locale. When a quantity is paired with a unit code in CSV or spreadsheet files, incorrect parsing can multiply or divide the apparent value by a thousand. Test localized values programmatically rather than relying only on visual review.
26. Rounding is not a translation choice
Commercial quantities may have contractual or regulatory precision. A translator should not round 12.499 kilograms to 12.5 because the target language usually uses fewer decimals. Any rounding rule must come from the business specification, not from prose style.
27. Net, gross and tare quantities are different
Shipping and customs records often distinguish net mass, gross mass and tare. The same unit can appear in all three fields. Translation must preserve which property each quantity describes. A perfectly preserved kilogram code is useless if gross mass is relabelled as net mass.
28. Package count is different from item quantity
A shipment may contain 1000 pieces packed into 50 cartons. Piece count and package count are both correct but represent different levels. Translate field labels such as number of packages, quantity and quantity per package precisely, and keep each with its intended code.
29. Inner and outer packaging can coexist
Goods can be packed into bottles, grouped into cartons, loaded onto pallets and placed in containers. A multilingual product or logistics record may therefore contain several packaging levels. Do not choose one familiar package word for all levels. Preserve hierarchy and package count at each layer.
30. “Box,” “case,” “carton” and “crate” are not safe synonyms
Everyday language often overlaps these words, but logistics systems distinguish package forms because dimensions, handling and regulatory meaning can differ. A translator should follow the standardized package description and approved company glossary instead of choosing the most natural general word.
31. Bags, sacks and pouches need controlled terminology
Flexible packaging terms vary widely across languages and industries. Grain sacks, retail bags, sealed pouches and bulk bags are not necessarily the same package type. Preserve the source package code and use the code list definition to choose the target label.
32. Drums, barrels and casks need domain context
Liquid, chemical and food industries use container terms that can be culturally familiar but technically distinct. Do not substitute a local traditional vessel word merely because it sounds natural. Translate against the coded package type and the product context.
33. Bottles, jars and cans should not be normalized casually
Retail packaging can appear visually similar while differing in closure, material or form. Package codes and master data exist so systems do not depend entirely on prose. Keep the code stable and translate the label without collapsing distinct forms.
34. Dangerous-goods packaging adds another standards layer
Transport of dangerous goods can involve UN packaging codes and regulatory requirements beyond Recommendation 21. Similar words do not make the code systems interchangeable. Translation should identify which standard the source uses and preserve every regulated code exactly.
35. Recommendation 21 package codes are not GS1 identifiers
A package-type code describes a packaging form; a GS1 identifier such as SSCC identifies a specific logistics unit. One carton type can be used for many different logistics units. Keep descriptive package coding separate from identity coding.
36. Package codes are not HS commodity codes
HS and related customs codes classify goods for customs purposes. Recommendation 21 describes packaging and cargo presentation. A carton containing shoes remains a carton regardless of the commodity classification of the shoes. Translation should not infer one code system from the other.
37. Unit codes are not customs quantity codes unless the schema says so
Customs systems can require supplementary quantity units or national code lists that map to international standards. Do not assume every customs quantity field accepts the full Recommendation 20 list. Preserve the source schema and use authorized mappings.
38. EDI messages require structural translation discipline
UN/EDIFACT and other EDI formats carry coded data in defined segments and data elements. A translator should not translate raw syntax or code values as prose. Localize human-readable descriptions in documentation or interface layers while leaving message structure and code fields intact.
39. XML should keep unit and package codes in controlled elements
XML trade documents can store quantities, unitCode attributes and package codes separately. Translate element content only when the schema marks it as human-language text. Do not translate element names, namespace prefixes, code-list identifiers or controlled values.
40. JSON APIs need stable code values
A modern trade API might send quantity, unitCode, packageTypeCode and localizedDescription as separate fields. The localized interface can render kilogram or carton in the target language while the code remains canonical. Contract tests should confirm that changing locale does not change code values.
41. CSV exports are a common failure point
CSV workflows combine weak typing with locale-sensitive numbers. A decimal comma can collide with a comma delimiter, while translators can sort only one column and detach unit codes from quantities. Use quoting, explicit import schemas and stable row identifiers.
42. Spreadsheets can auto-correct codes
Short alphanumeric codes can be interpreted as dates, formulas or scientific notation by spreadsheet software. Protect code columns as text before opening the file. After saving, compare literal source and target codes rather than assuming the visible cells are unchanged.
43. Product master data should separate selling unit and physical unit
A product can be sold by piece while measured by weight, length or volume. It can also be packed into cases. Multilingual commerce systems should keep selling unit, measurement unit and packaging type as separate fields. Translating all of them as unit can cause ordering errors.
44. Purchase-order quantities need contract integrity
If a purchase order specifies 500 kilograms, changing the unit label to pounds without converting the number changes the contract. Likewise, converting the number without preserving agreed precision can create discrepancies. Translation should normally preserve the contractual quantity and code unless conversion is explicitly part of the project.
45. Invoice quantities must reconcile with prices
A unit price is meaningful only with its pricing unit. Ten dollars per kilogram is different from ten dollars per piece. Translation workflows should validate quantity, unit, unit price and total together. A correct code attached to the wrong price basis can create financial errors.
46. Warehouse labels need human and machine agreement
A printed label may display a localized package name while a barcode or QR payload contains coded data. The two representations must describe the same packaging and quantity. Regenerate labels from structured master data rather than retyping codes into translated artwork.
47. Procurement catalogues can contain several unit concepts
A catalogue may specify order unit, issue unit, package size, minimum order quantity and conversion factors between them. Translation should preserve each concept. A buyer ordering one case should not accidentally receive one piece because both fields were rendered with one generic word.
48. Unit conversion factors are data, not translation memory
Systems may store that one case contains 24 bottles or one roll contains 100 metres. Those relationships can change by product. Do not reuse a conversion factor from a similar item because the text looks familiar. Keep factors attached to the product master and validate them numerically.
49. Package count can be zero, one or many for valid reasons
Bulk cargo may not be represented as ordinary packages, while consolidated shipments can contain many package units. Translation should not “correct” unusual counts without understanding the trade model. A zero or blank package count can carry specific meaning in a message specification.
50. “Not applicable” and “not specified” are different states
Trade-data code lists can contain values representing absence, unknown status or special cases. Translators should preserve the distinction. Not applicable means the concept does not apply; not specified can mean the information is unavailable. Collapsing both into “none” destroys data quality.
51. Versioning matters for code lists
UNECE publishes revisions and updated annexes for Recommendation 20, including updated common-code lists. Systems should record which code-list version they use. Translation teams should not mix a current label with an obsolete or vendor-specific code without documenting the mapping.
52. Vendor code lists can differ from UN/CEFACT
ERP, marketplace and logistics platforms often maintain proprietary unit or package abbreviations. A value such as EA, PCS, BX or CTN may have platform-specific meaning or mapping. Do not claim that every familiar abbreviation is a UN/CEFACT code. Verify the namespace first.
53. Crosswalks require explicit governance
When a company maps internal UOM and package codes to UN/CEFACT values, one internal code may not have a perfect international equivalent. The crosswalk is a data-governance artifact, not a translation dictionary. Record exceptions and do not invent equivalence because the words look similar.
54. Translation memories must protect codes and quantities
Trade documents repeat boilerplate, but quantities and codes change frequently. A high translation-memory match can carry an old unit or package type into a new shipment. Mark these values as variables or locked tokens and compare the final target with current source data.
55. Machine translation should not normalize technical codes
A language model may expand abbreviations, change case or substitute a familiar localized unit. That is useful in prose but dangerous in coded fields. Protect Recommendation 20 and 21 values before machine translation, then restore them from the data layer.
56. Generative AI should not guess an unknown package code
A code can look similar to a common warehouse abbreviation without being the same standard. If the namespace or version is unknown, preserve the source and investigate. A plausible guessed expansion can misdescribe physical packaging and affect handling, customs or purchasing.
57. OCR is risky for short alphanumeric codes
Scanned trade documents can confuse O with 0, I with 1, B with 8 and similar characters. Because many codes are short, one OCR error can create another plausible-looking token. Validate against the authoritative code list and source business data rather than correcting by eye.
58. Worked example: 500 pieces in 25 cartons
A purchase order contains 500 pieces of a product packed into 25 cartons. The target translates “piece” and “carton” for readers but keeps the Recommendation 20 unit code and Recommendation 21 package code in their respective fields. It does not replace piece count with carton count or treat the carton as the commercial measurement unit.
59. Worked example: 1.5 metric tonnes in bulk
A commodity shipment is measured by mass and transported as bulk cargo. The translated document preserves the mass value and unit code, while the cargo or package field indicates the appropriate bulk presentation. The absence of cartons is not a missing translation; it reflects the physical logistics.
60. Worked example: one case contains twelve bottles
A catalogue sells by case but describes inner bottles. The target language displays both levels: one case equals twelve bottles. The order unit, inner-package type and conversion factor remain separate. A buyer can therefore understand the packaging without changing the ERP’s canonical codes.
61. Worked example: spreadsheet turns code into a date
An alphanumeric code imported into a spreadsheet is autoformatted as a date-like value. The translator never edits the cell, but the export now contains a different string. The prevention is to import coded columns as text, not to rely on manual visual checks after damage occurs.
62. Search intent: “translate unit code”
The user may want to know what a Recommendation 20 common code means, how to display the unit in another language or whether the quantity should be converted. Identify the code first, translate the unit name, and explain that conversion is a separate numerical task.
63. Search intent: “translate package code”
First identify whether the token belongs to UN/CEFACT Recommendation 21, a carrier code list, a dangerous-goods code, GS1 data or an internal warehouse system. Then translate the package description while preserving the official code. Namespace identification comes before linguistic expansion.
64. Search intent: “UN/CEFACT unit code vs package code”
Recommendation 20 answers how quantity is measured; Recommendation 21 answers how goods or cargo are packaged or presented. One shipment can use both at once. Translating both as “unit code” hides the distinction. Keep quantity measurement and packaging structure separate.
65. A practical translation workflow for Rec 20 and Rec 21
Identify the code-list namespace and version. Extract quantity, unit code, package count, package code, cargo type, packaging material and related descriptions into separate fields. Lock machine-facing codes and numeric values. Translate human-readable labels with a controlled glossary. Reassemble by stable key, then validate quantities, unit relationships, package hierarchy, code membership, version and final document rendering.
66. Reference route: UNECE UN/CEFACT code-list recommendations
UNECE publishes the official UN/CEFACT code-list recommendations. Recommendation 20 provides standardized codes for units of measure used in international trade, while Recommendation 21 provides coded representations for package types and related cargo or packaging concepts. Use the maintained source and the version specified by the trading system rather than a copied vendor list.
67. Connection to existing eduKateSG specialist owners
This page intentionally does not duplicate the existing Translate owners for physical unit concepts, GS1 logistics identifiers, ISO 6346 container numbers, HS and HTS commodity codes or UN/LOCODE. Those pages own identity, classification or measurement topics at other layers. This article owns one narrower problem: preserving UN/CEFACT unit and package code meaning in multilingual trade data.
68. Connection to the master translation architecture
The article sits beneath the Master Art of Translation — Technical Translation System. Vocabulary work connects to the protected Vocabulary Learning Hub because terms such as unit, piece, package, case, carton and container are ordinary words that become tightly controlled in trade-data systems.
69. Final rule: translate the label, preserve the coded trade fact
UN/CEFACT Recommendation 20 and 21 translation succeeds when people can read unit and package descriptions in their language while machines still receive the same coded measurement and packaging facts. Preserve code, quantity, hierarchy, version and schema relationships; translate the human-facing label; keep conversion separate from translation; and validate the final output as structured trade data, not only as prose.