UOM (unit of measure)
UOM (unit of measure) is the unit a product is counted, measured, priced, or sold in: each, case, foot, pound, milliliter. In distributor catalogs one SKU usually carries several UOMs at once: a stocking UOM, a selling UOM, and a pricing UOM can all differ on the same record, alongside units attached to physical attributes like length and weight. A bolt stocked in EA can sell as a box of 50 and be priced per hundred.
What UOM actually means in a product record
UOM answers one question: this number, in what? A 2 means nothing until you know whether it is 2 each, 2 cases, 2 inches, or 2 pounds.
Distributor records rarely carry a single UOM. One fastener SKU carries several at once, and they are not interchangeable:
| UOM slot | Question it answers | Code as it appears on a 3/8-16 x 2" Grade 8 hex bolt |
|---|---|---|
| Base / stocking UOM | How does inventory count it? | EA |
| Selling UOM | What goes in the cart? | BX (box of 50) |
| Pricing UOM | Price per what? | C (per 100) |
| Ordering UOM | How does the vendor ship it? | CS (5 boxes = 250 EA) |
| Dimension UOM | Unit for length, thread, drive size | INH (inches) |
| Weight UOM | Unit for ship weight | LBR (pounds) |
That last column is itself a mix, and the mix is the problem. EA, CS, INH, and LBR are UN/ECE Recommendation 20 codes, the list GDSN and EDI traffic expect. C is not: it is trade shorthand for per hundred that people type by habit, and the Rec 20 code is CEN. BX is Rec 20, but the box size it implies is not.
Two other defects show up immediately. The UOM field is blank, or it holds free text — in, inch, inches, IN., " — instead of a code from any controlled list at all. Both arrive the same way: an attribute typed by hand during new item setup, or a vendor spreadsheet loaded without unit validation. The value passes every check the system has, because the system was never told what unit that field is supposed to hold.
Where mixed units silently corrupt the catalog
UOM errors do not throw exceptions. They produce plausible output that is wrong, which is why they survive for years.
- Facets collapse or fragment. A "Length" facet fed by
2,2 in,50.8, and50.8mmrenders four buckets for one physical size. Filter on 2 to 4 inches and half the matching SKUs disappear. - Sorts lie. Sort a bore-diameter list numerically and a 300 mm bore lands above a 12 in bore, because the sort compares 300 to 12. The 12 in bore is 304.8 mm, the larger part, and it is now on the wrong end of the list.
- Pricing and margin drift. A price loaded per hundred and displayed per each is off by 100x. Priced per foot and sold per box of 100 ft is off by 100 too, and usually is not caught.
- Feeds reject or mislead. Google Shopping's
unit_pricing_measureandunit_pricing_base_measureneed real units. Amazon flat files have their own unit columns per template. A blank UOM becomes a disapproval or a nonsense per-unit price on the listing. - Freight math breaks. Dimensional weight computed from a number whose unit is assumed rather than stored is a quote you cannot defend.
- AI answers inherit the error. When an assistant is asked for a UL listed 600V connector that accepts 12 AWG, it reads whatever unit string is on the PDP or in the structured data. Garbage units produce a confident wrong answer with your brand on it.
What normalized UOM looks like
Normalized UOM is not one unit across the catalog. It is one declared unit per attribute, applied consistently, with the raw value and the unit code stored apart.
A normalized record has four properties:
- A canonical unit declared per attribute, not per catalog. Thread pitch and drive size may stay imperial on a US fastener line because that is the standard the part is made to; net weight may be KGM everywhere for customs and GDSN. The rule lives on the attribute.
- Value and unit in separate fields.
50.8in one column,MMTin another. A single string column is how the problem started. - Conversion factors stored, never implied. Each-per-box, boxes-per-case, feet-per-reel: these belong on the record. Implied factors are the reason a 250-count case ships as 50.
- A display value alongside the canonical one. Buyers search for a 3/8 in bolt, not a 9.525 mm bolt. Canonical storage and buyer-facing display are different jobs.
Here is bore diameter, an attribute whose declared canonical unit is MMT:
| Source value | Parsed | Canonical (MMT) | Display |
|---|---|---|---|
1/2 in. | 0.5 + INH | 12.7 | 1/2 in |
.500" | 0.5 + INH | 12.7 | 1/2 in |
12.7 | 12.7 + null | flag for review | — |
13mm | 13 + MMT | 13 | 13 mm |
Row three is the one that matters. A bare number with no unit is not convertible. Guessing it is how a 12.7 mm hole becomes a 12.7 in hole. It gets routed to a human or left empty, and validation rules enforce that every dimensional value carries a unit code from the controlled list.
Why this is a completion problem, not a storage problem
Any modern PIM models units, measurement families, and conversion; the fields exist. Anglera works alongside Akeneo, Salsify, Syndigo, inriver, and Pimberly.
The gap is upstream: across tens of thousands of SKUs from hundreds of vendors, those fields sit half empty and half free text, and filling them means reading spec sheets and vendor PDFs attribute by attribute. Where the source is ambiguous, the SKU comes back flagged instead of guessed.
Frequently asked questions
What is the difference between selling UOM and pricing UOM?
Selling UOM is what a buyer can actually add to the cart, such as BX for a box of 50 bolts. Pricing UOM is the basis your price is quoted on, such as CEN for per hundred. They are frequently different, and the conversion factor between them has to be stored on the record. When it is implied, the PDP shows a price 100x off or the order ships the wrong quantity.
What is a conversion factor and where should it live?
A conversion factor is the number that turns one UOM into another for a specific SKU: 50 each per box, 5 boxes per case, 250 ft per reel. It belongs in a stored field on the record, not in a spreadsheet, a pricing rule, or someone's head. Factors vary by SKU even inside one category, so a global rule cannot cover them. An implied factor is how a 250-count case ships as 50.
What UOM code list should I standardize on?
UN/ECE Recommendation 20 is the practical default: EA for each, CS for case, FOT for foot, INH for inch, KGM for kilogram, LBR for pound, CEN for per hundred. GDSN and most EDI traffic expect it, so standardizing there means you are not translating at every hand-off. Trade shorthand like C for per hundred, or a bare inch mark, should be mapped into Rec 20 on ingest rather than stored as-is.
How does UOM affect a Google Shopping feed?
Google uses unit_pricing_measure and unit_pricing_base_measure to show a comparable per-unit price, and both need a real value plus a supported unit. A blank or free-text unit gets the item disapproved or produces a misleading per-unit price on the listing. Amazon flat files have their own unit columns per category template, so the same underlying UOM has to map cleanly into several different destination formats.
Why do UOM errors break AI shopping answers?
An assistant answering "what 600V connector takes 12 AWG" reads your PDP text and structured data as-is. It has no way to know your Length field is inches when the value says 50.8. It will not flag the mismatch, it will just answer confidently and wrong, or skip your product because the filter did not match. Clean unit codes in the structured data are what make you eligible for the answer.