Unit-of-measure traps: when cases, eaches, and dozens stop agreeing

Troubleshooting · 7 min read

Few setup errors corrupt inventory as quietly as a wrong unit of measure. The documents all look reasonable — a case received, a dozen sold — while the base quantity underneath drifts further from the shelf with every transaction, until a count, a negative balance, or a reorder that makes no sense exposes it. The system is doing exactly what it was told: converting with the factors on the item. When cases, eaches, and dozens stop agreeing, the factors are where the disagreement lives, and the fix is an audit, not an adjustment.

How Business Central actually converts quantities

Every item has a base unit of measure, set on the item card. The base unit defines how the item is stored in inventory, and it is the basis for conversion to every alternate unit. Alternate units are set up on the Item Units of Measure page, reached with the Units of Measure action on the item card. Each alternate carries a Qty. per Unit of Measure: how many base units that unit contains. The base unit itself must carry the value 1. A worked example makes the arithmetic plain: with a 500 ml bottle as the base, a six-pack converts at 6 bottles and a case at 24 bottles, so an order for 5 six-packs deducts 30 bottles automatically. Get either factor wrong and the deduction is wrong by the same proportion, on every single transaction, with no error message — the math is consistent, it is just consistently wrong.

Two defaults decide which unit a document reaches for. The Sales Unit of Measure on the item's Invoicing FastTab and the Purch. Unit of Measure on the Replenishment FastTab set the usual selling and buying units, which can differ from the base and from each other. That separation is the point of the design — buy on pallets, sell in pieces — and it is also where the second trap lives, because a correct factor with the wrong default still produces wrong documents whenever staff accept the default without looking.

The three traps, and how each one lies differently

The wrong-factor trap deserves its reputation because of scale. A case received at a factor of 10 instead of 12 understates stock by two units per case, every receipt, and the sales side then depletes a quantity that was never fully there — which is how a conversion error becomes a negative-inventory problem with no receiving or selling mistake anywhere in sight. The rounding trap rides along with it. When a converted quantity lands on a fraction of a base unit — receiving five of the six pieces in a box instead of the full box posts as 4.99998 pieces — the Quantity Rounding Precision field on the Item Units of Measure page is what rounds that back to a whole five. Leave precision unset on piece-based items sold from broken packs and the fractions accumulate invisibly. Set it carelessly and a different failure appears: a rounding precision that conflicts with the calculated quantity produces posting errors, and there are quantities the standard product simply will not force to whole units without custom development, because the system protects financial accuracy over tidy numbers. Weight-based items are the extreme case, where decimal precision is not a nicety but the difference between a correct conversion and a daily drift.

Audit procedure: prove every factor against the physical pack

Run this per item, for any item whose count, cost, or reorder behaviour looks wrong — and for every new multi-unit item before its first receipt.

1. Start from the physical pack, not the screen. Count what a case, a dozen, or a pallet of this item actually contains, from the supplier packaging. This number is the specification every factor is checked against.
2. Open the item card and note the base unit. Confirm the base is the smallest unit the store actually handles — for most retail items, the individual piece. If the base is a case and the store sells singles, the setup is fighting the workflow before any factor is checked.
3. Open Units of Measure on the item and list every line: code, Qty. per Unit of Measure, and Quantity Rounding Precision. Confirm the base line carries exactly 1.
4. Verify each factor against the physical count (spec verification). Case factor must equal pieces per case, dozen must equal 12, six-pack must equal 6. Do the multiplication both ways: one case in, factor-many pieces on the shelf; factor-many pieces sold, zero remaining.
5. Check the two defaults. Sales Unit of Measure should be the unit staff sell in; Purch. Unit of Measure should be the unit on the supplier invoice. A mismatch here explains one-off document errors on an otherwise correct item.
6. Check the dimensions while the page is open. Height, width, length, and weight per unit feed bin capacity checks across put-away, receipts, shipments, picks, and adjustments, and they must use one consistent measure across all of the item's units — kilograms or pounds for weight, never a mixture.
7. Record the verified factors in a spreadsheet audit list — item, base unit, each alternate, verified factor, date checked — so the next audit diffs against a known-good state instead of starting from memory. Item master data stays clean only when someone can prove what correct looked like; attributes and units belong in their proper fields on the item, not buried in descriptions where no conversion can use them.

What success looks like: for every audited item, each Qty. per Unit of Measure equals the physical pack count, the base line is 1, rounding precision is set on items received or sold in partial packs, and both default units match how the item is actually bought and sold. A test receipt of one case increases the base quantity by exactly the verified factor — no fraction, no surprise.

Fixing setup without corrupting history

Order matters. Correct a wrong factor first, then count the item: every entry posted under the bad factor is suspect, and only a physical count re-anchors the quantity. Use the physical inventory journal to post the counted quantity, or the item journal for a single-item adjustment, and note the factor fix as the reason — otherwise the adjustment looks like shrinkage and the real cause disappears from the record. Correct a wrong default unit at any time; defaults only steer new documents, so no history moves. The base unit is the dangerous one: changing it after transactions exist can cause major inconsistencies, because all existing quantities were expressed in the old base. If a base unit is genuinely wrong, treat it as a data project, not a field edit — the safe route is a new item with the correct base, a counted transfer of stock to it, and the old item blocked once its quantity reaches zero. Where a single item is being stretched across two sizes that no one conversion can serve honestly, separate items or variants are the honest structure; a fudged factor is not.

Prevention for new items is mostly sequencing: choose the base unit deliberately as the smallest handled unit, set factors from the physical pack at setup time rather than from a catalogue description, set rounding precision wherever partial packs occur, and run the audit above before the first receipt posts. Ten minutes at setup is the whole cost. The alternative — discovering the drift at stocktake, with months of converted history to unpick — is the expensive version of the same ten minutes.

FAQ

Can the base unit just be edited when it is wrong? Not safely, once transactions exist. Existing entries are expressed in the old base, and changing the base underneath them creates inconsistencies no recount fully repairs. Migrate to a new item instead.

Why does stock show fractions like 4.99998? A partial-pack quantity was converted without a rounding precision to bring it back to a whole base unit. Set Quantity Rounding Precision on the item's units of measure — 1 for piece-based items — so converted quantities land on whole pieces.

The factor is right but documents still come out wrong. What else? Check the defaults. A correct case factor with the purchase default set to eaches (or the sales default set to cases) produces documents out by exactly the pack size whenever the default is accepted uncorrected — and those single-document errors, mixed among correct ones, are the signature of this trap.