Units of Measure in Warehouse Operations, Explained
“How many do we have” seems like it should have one obvious answer, right up until an item gets bought by the pallet, stored by the case, and sold by the piece — all legitimately, all at once. Business Central handles that by giving every item exactly one true unit its inventory is actually kept in, and letting any number of other units convert to it. Most of the time that conversion is invisible. Where it isn’t set up carefully, it’s one of the quieter, more expensive mistakes a warehouse setup can make.
One base unit, and everything else converts to it
Every item has a single base unit of measure, assigned on the item card, and it defines how the item is genuinely stored in inventory — it’s the unit every quantity, cost, and valuation ultimately reduces to, no matter what unit a specific transaction happened to be entered in. Anything else — an alternate unit of measure — exists purely to make a specific business process convenient: buying on pallets, selling by the each, producing in some other batch unit entirely, while inventory itself still keeps its books in the one base unit underneath all of it.
The conversion between an alternate unit and the base unit is a single number: the Qty. per Unit of Measure field, set per alternate unit on the item. Buy in cases of 24, sell in eaches, and the case’s Qty. per Unit of Measure is simply 24 — enter one case on a purchase order and Business Central books 24 base units into inventory without anyone doing the arithmetic by hand.
A worked example — three pallets, received in two different units
Vellano Imports’ EVOO-500 is stocked, and reported on the item ledger, in eaches. It’s also set up with a pallet unit of measure carrying a Qty. per Unit of Measure of 120 — ten layers of twelve bottles. A purchase order arrives for 3 pallets. On the warehouse receipt, the receiving clerk works entirely in pallets: 3 pallets in, 3 pallets confirmed, one line. Underneath that single line, Business Central books 360 base units — 3 × 120 — into inventory, and every downstream record (the item ledger entry, the bin content, a subsequent pick) is denominated in eaches from that point forward, regardless of the fact that the receiving document itself never mentioned the number 360 anywhere. Nobody converts pallets to eaches by hand, and nobody has to remember that this particular item’s pallet holds 120 rather than the 100 a different item’s pallet might hold — the conversion factor lives once, on the item, and every transaction that references the pallet unit reads it from there.
When the produced unit and the stocked unit genuinely differ
A specific, real case worth naming: an item that’s stocked in one unit but produced in a different one entirely — the documented example is an item stocked in pieces but produced in tons. For that, Business Central supports a dedicated manufacturing batch unit of measure, used specifically during the Refresh Production Order step to calculate the correct component quantities for a production run, translating between the unit a shop floor actually produces in and the unit the finished item is stocked and sold in.
Rounding precision exists because base-unit math doesn’t round itself
Converting an alternate-unit quantity into base units is ordinary division, and ordinary division doesn’t always land on a clean number. Business Central’s own documented example is worth repeating exactly because it’s so easy to hit by accident: receive one box of six items, discover one of the six is missing, and decide to post a receipt of five out of six pieces rather than reject the whole box — that decision, worked out as a fraction of the box unit, produces a receipt of 4.99998 pieces, not a clean five. The Quantity Rounding Precision field on an item’s unit of measure exists exactly to absorb that — set it to 1, and the same scenario rounds to an honest five pieces instead of leaving an ugly, technically-correct fraction sitting in the ledger forever.
Physical dimensions turn a unit of measure into something a bin can hold
This is the part of unit-of-measure setup that reaches furthest outside the item card, because it’s the actual input directed put-away and pick’s bin-capacity checking depends on (see bin setup and bin content, explained and directed put-away and pick, explained). Each unit of measure on an item can optionally carry Height, Width, Length, and Weight — with Cubage calculated automatically from the first three — and the moment any of those fields holds a nonzero value, that measure is used across every process that involves placing the item in a bin: put-away, movement, receipt, shipment, pick, and adjustment alike. Business Central sums the physical measures of whatever’s being put away against whatever’s already sitting in a bin, and checks the total against that bin’s own capacity policy on the location card.
There’s one easy-to-miss consistency rule buried in that mechanism: the same physical measure has to use the same units across every unit of measure an item is transacted in — kilograms throughout, or pounds throughout, never a mix — because Business Central is summing raw numbers, not unit-aware quantities. Mixing kilograms on one unit of measure and pounds on another for the same item wouldn’t raise an error; it would just silently produce a capacity check that’s wrong by roughly a factor of 2.2, with nothing on screen to say so.
The silent failure this setup invites
It’s worth stating plainly, because it’s exactly the kind of gap that doesn’t announce itself: if an item is genuinely transacted in two units of measure — say, each and case — and only one of them has height, width, length, and weight filled in, the bin capacity math for whichever unit is missing that data is simply wrong. Not rejected, not flagged — just calculated against incomplete information, silently, the same way an unfilled routing-line bin code or an un-entered counting period quietly leaves a gap in whatever process depends on it. A location that’s carefully dimensioned its items in “each” but never got around to dimensioning the case unit of measure looks fully configured for directed put-away right up until the first case-quantity put-away is suggested into a bin that can’t actually hold it.
Setting a default doesn’t remove the choice, it just removes the retyping
An item can carry a separate default unit of measure for sales and for purchasing — set independently on the item card’s Invoicing and Replenishment tabs respectively — so a business that habitually sells in eaches and buys in cases doesn’t have to reselect the unit on every single order line. It remains exactly that: a default, not a restriction. Any unit of measure set up for the item is still available to choose on a specific transaction where the default isn’t what that particular order actually needs.
Translations exist because the unit label is customer-facing too
For businesses selling across languages, a unit of measure code can carry translated descriptions per language code — so a customer-facing document in one language shows “Box” and the identical underlying unit shows “Boîte” on a document generated for a different locale. It’s a small feature, but it’s a reminder that a unit of measure isn’t purely an internal inventory concept; it’s often printed straight onto a document a customer reads.
Where this goes next
The bin-capacity mechanism this article’s dimensional data feeds directly into is covered in bin setup and bin content, explained and, for the rung where it actually starts mattering operationally, directed put-away and pick, explained. For how a unit of measure and a quantity actually get encoded onto a physical label in the first place, see barcode symbologies for warehouse labels, explained.
Key terms
New to the vocabulary? Unit of measure is defined in the glossary.
Further reading — Microsoft Learn
Set Up Item Units of Measure — base and alternate units of measure, the manufacturing batch unit, rounding precision, and the physical-dimension fields described above, in full.