EA vs PCE vs C62: Common Unit Code Mistakes in BMEcat and EDI

Why unit codes cause rejections

Unit codes are a three-character field. They seem simple. But incorrect unit codes are one of the top five reasons BMEcat files get rejected by data pools, and one of the top three causes of EDI message failures.

The problem is that humans read "KG" and understand kilogram. Machines read "KG" and return "unknown unit code." The UN/CEFACT Rec 20 standard defines specific three-character codes that do not always match common abbreviations. When your PIM or ERP exports non-standard codes, every downstream system that validates against Rec 20 will reject the data.

Run your file through the unit code validator to catch these errors before submission. Here are the most common mistakes and their fixes.

Mistake 1: The "piece" problem

This is the single most common unit code error in product data. Three codes compete for "piece" or "each":

The fix: Use C62 for all "each/piece" situations unless your trading partner explicitly requires a different code. C62 is accepted by ETIM BMEcat, ECLASS BMEcat, all major European data pools, and EN 16931 e-invoicing.

In a BMEcat file:

<!-- Wrong -->
<ORDER_UNIT>EA</ORDER_UNIT>
<ORDER_UNIT>STK</ORDER_UNIT>

<!-- Right -->
<ORDER_UNIT>C62</ORDER_UNIT>

Mistake 2: Common abbreviations that are not Rec 20 codes

Human-readable abbreviations do not map to Rec 20 codes. Here is the full list of common errors:

Every one of these will fail Rec 20 validation. The correct codes are standardized and non-obvious. MTR for metre makes some sense. MMT for millimetre is less intuitive. KGM for kilogram is not what anyone would guess.

After updating your unit codes, validate them against Rec 20 to confirm every code is recognized.

Mistake 3: Electrical units

Electrical product data uses unit codes for feature values. The wrong code in a feature unit means the technical data is ambiguous.

Note that some codes happen to match their common abbreviations (OHM, KHZ). This is coincidental. Always verify against the Rec 20 list rather than assuming.

Mistake 4: Cross-section and area codes

Cable and wire products use conductor cross-section values measured in square millimetres. The unit code for this is not intuitive.

<!-- Wrong -->
<FUNIT>MM2</FUNIT>
<FUNIT>QMM</FUNIT>
<FUNIT>mm²</FUNIT>

<!-- Right -->
<FUNIT>MMK</FUNIT>

MMK is the Rec 20 code for "square millimetre." This is the code you need for conductor cross-section in cable products, busbar dimensions, and any other area measurement in square millimetres.

For square metres (floor area, surface coverage), use MTK. For square centimetres, use CMK.

Mistake 5: Temperature codes

Temperature units have specific Rec 20 codes that are often confused:

CEL for Celsius is not obvious. If your product data includes operating temperature ranges, make sure the unit is CEL, not "C" or "degC" or any other variant.

Mistake 6: Packaging unit confusion

Products sold in packaging (boxes, cartons, pallets) use packaging-level Rec 20 codes. These interact with the BMEcat ORDER_UNIT and CONTENT_UNIT fields.

A common error: using BX as the ORDER_UNIT but not setting CONTENT_UNIT and NO_CU_PER_OU correctly. If ORDER_UNIT is BX (box) and the box contains 100 cable ties, then CONTENT_UNIT should be C62 and NO_CU_PER_OU should be 100.

<!-- Correct: box of 100 pieces -->
<ORDER_UNIT>BX</ORDER_UNIT>
<CONTENT_UNIT>C62</CONTENT_UNIT>
<NO_CU_PER_OU>100</NO_CU_PER_OU>

The German VEG/DE rules specifically check that when ORDER_UNIT equals CONTENT_UNIT, NO_CU_PER_OU must be 1. If they are the same unit, the ratio is 1:1 by definition.

Mistake 7: Missing unit code entirely

Some BMEcat exports leave ORDER_UNIT or CONTENT_UNIT empty. In the ETIM guideline, these are mandatory fields. An empty ORDER_UNIT means the receiving system does not know how to process orders for that product.

The fix depends on how the product is sold:

• Individual items: C62
• By length (cable, conduit): MTR
• By weight (bulk materials): KGM
• By volume (liquids, gases): LTR
• As sets (kits, assemblies): SET

Worked example: fixing a cable catalog

An electrical cable manufacturer exports 800 products to a German data pool. The data pool rejects the file with 1,600 unit code errors.

Analysis:

• 800 products with ORDER_UNIT = "M" (should be MTR)
• 800 products with FUNIT = "MM2" on conductor cross-section (should be MMK)

The fix is a mapping table applied to the export:

After applying the mapping, validate the unit codes to confirm all codes are valid Rec 20 entries. The re-exported file passes with zero unit code errors.

Prevention

The best approach is to configure your PIM or ERP export to use correct Rec 20 codes from the start. Build a unit code mapping table and apply it at export time. Test every export against a Rec 20 validator before sending to trading partners.

If you inherit data with wrong unit codes, build the mapping once and apply it across all future exports. The number of distinct unit codes in a typical electrical product catalog is small (usually under 20). Mapping them correctly once eliminates the error category permanently.