The buyer reordered 480 units of a floor cleaner to top the warehouse back up to its target, signed off the purchase order without a second look, and a week later eleven and a half thousand units arrived on the dock. No fat finger, no rogue spreadsheet. The item had been created with a conversion factor of 1, the reorder was calculated in each and placed in cases, and a factor of 1 let 480 each pass straight through as 480 cases. The case was a 24-pack. The data did the multiplying.
Unit of measure is the master data domain people assume is trivial because the code list is short. Each, case, box, pallet, kilogram, litre. A dozen entries, done in an afternoon. That afternoon is the easy half, and finishing it feels like finishing the job, which is exactly why this domain keeps wrecking purchase orders long after everyone has stopped thinking about it.
It is two things wearing one name
A unit of measure record looks like one thing and behaves like two. The first is the code itself: a controlled value that says case or pallet or kg, shared across the whole catalog, the same for every product. That part is reference data, and it governs the way any reference list does: one authorized set, one owner, change control in front of it.
The second is the conversion factor, and it does not belong to the list at all. It belongs to the item. A case of gloves is 24 each; a case of cleaner is also called a case and holds a different number entirely. The word case is shared. The multiplier behind it is not. So the factor lives on the product record, set once per item per alternate unit, and that is the half almost everyone forgets to govern. They lock down the code list, feel finished, and leave the multipliers to whoever happens to be creating the item that day.
That split is the whole problem in one sentence. The part that is easy to govern barely causes errors. The part that causes the errors is the part nobody treats as master data.
Where the conversions break
None of these throw an error. They are valid records doing exactly what the data tells them to. That is what makes them expensive: they surface as a delivery, an invoice dispute, or a stock count that will not reconcile, weeks after the record that caused them was created.
The default nobody changed
A new item is created and the conversion factor defaults to 1. The order unit and stock unit are different, but the multiplier says they are the same. Every reorder is now off by exactly the factor it should have carried, and nothing flags it because 1 is a perfectly valid number.
Two codes for one unit
EA and EACH both exist in the list, or PC and PCS and UN. Half the catalog references one, half the other, and a report that groups by unit splits a single product line into three. Worse, a downstream system maps only one of them, so the others fail validation on import.
The unit with no factor
A vendor sells in drums, the warehouse stocks in litres, and nobody recorded how many litres are in a drum. The unit is in the list, the item references it, and the conversion that turns a purchase into stock simply does not exist. The receipt posts in drums and the rollup is meaningless.
The silent rounding
A reorder works out to 2.4 cases, the system rounds to 2, and over a year of weekly orders the stock quietly drifts below where the min-max math thinks it is. Each rounding is invisible. The shortfall that builds from them is not, but by then it looks like theft or shrinkage.
The fractional each
You cannot ship half a glove, but the item allows decimal quantities, so a botched conversion leaves 1,200.5 units on hand. The half unit can never be picked, so the location never reconciles to zero, and someone spends an afternoon every quarter hunting a discrepancy that lives in the data, not the shelf.
The first one is the worst because a factor of 1 is indistinguishable from a factor that was set on purpose. There is no null to catch, no blank to validate against. The only defense is a rule that says a factor of 1 is illegal when the two units are not the same code, enforced when the item is saved rather than discovered when the truck pulls in.
Catch-weight breaks the model on purpose
Some items refuse to hold still. A case of cheese is sold by the case but priced by the kilogram, and no two cases weigh the same. A side of beef, a coil of cable, a drum of resin filled to a line rather than a count. These are catch-weight items, and a conversion factor is the wrong tool for them, because a factor assumes one case is always the same weight, which is the one thing a catch-weight item is not.
Force them into a fixed multiplier and the invoice disagrees with the scale on every shipment. A better number will not save you here, because the data needs a different shape. Catch-weight items carry a captured weight per delivery, not a constant stored once on the item. The point is to recognize, while you are still modelling the domain, that one factor cannot describe them, before someone enters an average weight and calls it done.
Govern the list once, the factors per item
The code list is the easy half, so do it properly and stop touching it. One authorized set of unit codes, a single owner, and an approval step in front of any addition, so the day someone wants a second code for each they have to argue for it instead of just typing it. If you can, align the codes to the UN/CEFACT Recommendation 20 standard rather than inventing your own, because the systems you integrate with already speak it, and a shared vocabulary is one less mapping table to maintain.
The factors are the half that needs the real rules, and they belong to the product record. Validate them where the item is created, not in a report that runs after the damage. Every alternate unit needs a factor. A factor of 1 is rejected unless the units are genuinely identical. Decimal quantities are blocked on units that cannot be split, so nobody can leave half an each on hand. A unit that appears on an item with no path back to the stock unit fails the save. These are data-quality rules, and unit of measure is the domain where catching the bad value at entry, rather than at the loading dock, pays for the whole governance effort by itself.
If you are coming off MDS, this is the kind of thing the constrained domains never fully enforced. The unit list was a domain-based attribute, but the conversion factors lived in attributes nobody validated against each other, so the rules above were tribal knowledge held by whoever set up the items. Carrying that into a new system is a chance to make the rules explicit instead of remembered, and it is far cheaper to write them down now than to keep paying for the orders that get them wrong.
Common questions
What is unit of measure master data?
Two things under one name. A controlled list of unit codes (each, case, pallet, kilogram) that products reference, and the conversion factors that link those units for a given item. The list is reference data shared across the catalog. The factors are per-item, because one case holds a different number of one product than another.
Why does a bad unit of measure cause over-ordering?
A reorder is calculated in the stock unit and placed in the order unit, and the conversion factor translates between them. If the factor is missing, wrong, or left at 1, the quantity passes through unchanged in the wrong unit. A reorder of 480 each against a factor of 1 becomes 480 cases, which is 11,520 units delivered.
How do catch-weight items break the model?
They are sold by count but priced by weight, and the weight of a unit is not fixed. A conversion factor assumes one case is always the same number of kilograms, which is exactly what a catch-weight item is not. They need a captured weight per delivery, not a multiplier stored once on the item.
Where should conversion factors be governed?
On the product record, validated when the item is created. The code list is governed centrally as reference data with one owner and an approval step. The factors belong to the item, because they vary by item, and they need a rule: every alternate unit has a factor, the factor is not 1 unless the units are the same.
Catch the bad factor before the truck does
Primentra keeps the unit code list as governed reference data with an approval step in front of every change, and holds the conversion factors on the product record where validation rules can reject a factor of 1, a missing path back to the stock unit, or a decimal on a unit that cannot be split. It runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial runs against your real catalog, which is long enough to find the items whose factors were never right.