Unit of measure in inventory — case vs each and the errors that poison your data
Unit of measure inventory errors — cases counted as eaches, mixed-UOM reorders — poison your velocity and reorder math. The discipline and a cost table.
InventoryX is in development and not available today. ClearStock is the live Shopify app.
A unit of measure (UOM) is the unit your inventory is counted, bought, and sold in — and most inventory pain around UOM comes from one store having several of them at once: you buy spices by the case of 12 jars, sell them one jar at a time, and count the shelf in jars. When the unit you buy in and the unit you track in differ, every conversion between them is a chance to corrupt your on-hand quantities, your reorder math, and your velocity data. The fix isn't software; it's picking one canonical unit per SKU and never letting the others touch your records.
The rule: one canonical UOM per SKU
Pick the unit you sell in — the "each" — as the canonical unit for the SKU, and hold it everywhere Shopify tracks quantity. Cases, inner packs, and pallets are purchasing units that get converted to eaches exactly once, at receiving, on paper. Nothing downstream of receiving should ever see a case.
Why sell-unit wins: your demand data (orders), your availability math, and your reorder points all live in the sell unit. If the canonical unit were the case, every order would need a conversion to record — and repeated conversion is where errors breed. Convert once at the dock, never again.
Two setup consequences in Shopify, as of October 2026:
- Enter your cost per item in the canonical unit — cost per jar, not per case — or every margin and valuation number is off by the pack size. Shopify's Help Center documents the per-unit "Cost per item" field on product/variant records and what it feeds (Shopify Help Center, "Cost per item and margin analysis," accessed October 2026).
- If a product genuinely sells in two units (a single marker and a 12-pack of markers), those are two SKUs, not one SKU with a unit switch. One record, one unit. Shopify's Help Center covers variant setup the same way — each variant is its own record with its own SKU, price, and inventory (Shopify Help Center, "Adding, editing, and deleting variants," accessed October 2026).
The cost-of-error table: what one conversion slip does
The sensitivity below shows what a single mis-entered receiving event does to a SKU that sells 2 units a day, bought in cases of 12. Each row is one event; the damage compounds through every downstream calculation:
| The slip | On-hand error | Reorder signal damage | What it costs |
|---|---|---|---|
| Received 1 case of 12, entered 12 cases | +132 units | Reorder point won't trigger for ~2 months; velocity looks fine, cover is fake | Weeks of false availability, then a sudden dark SKU |
| Received 1 case of 12, entered 1 | −11 units | Triggers early reorders; inventory shows shortage that isn't there | Over-ordering, cash tied up, phantom "missing" stock hunt |
| Reordered "10" meaning 10 cases, PO says 10 eaches | 110 units short at arrival | The PO can't cover the demand window it was sized for | A surprise gap in weeks, after paying for freight anyway |
| Counted 3 cases + 4 loose jars (40 jars), entered "7" | 33 units under | Triggers an early reorder; the variance looks like a shortage or theft | Over-ordering, cash tied up, a phantom shortage hunt |
That last row is worth a second look: mixed-unit counting is a leading cause of inventory discrepancies that survive investigation, because the recount matches the records and the paper trail shows nothing wrong. The count wasn't wrong — it was in the wrong unit.
Case-pack reorders: the math that respects reality
Your reorder math should compute in eaches and then round up to case multiples at the last step. The mechanics of the trigger itself are the reorder point formula; the UOM-specific addition is one line:
Order qty (eaches, from the formula) → round up to the nearest case multiple → write the PO in cases, receive in eaches.
Worked example: a spice SKU sells 2 jars/day, lead time is 30 days, and the formula says order 96 jars. Cases are 12. 96 ÷ 12 = 8 exactly — clean. If the formula had said 88, you'd round to 96 and write "8 cases" on the PO. The record that matters for the reorder point stays in eaches; the PO speaks the supplier's language; receiving converts once.
Two cautions:
- Don't let case multiples quietly inflate order sizes. Rounding 88 to 96 is fine; rounding 13 to 48 (a case of 48) is an MOQ decision, not a rounding one — the supplier-minimum side of that tradeoff is covered in MOQ meaning.
- Note the case size on the PO line. "8 cases (12)" survives a forwarding change or a temp employee; "8 cases" doesn't.
How UOM errors poison velocity
Velocity is units sold ÷ days available — and if sales are recorded in eaches but a receiving error inflates or deflates on-hand, the availability half of the math goes wrong in both directions. An inflated on-hand makes cover look long, delays reordering, and manufactures future out-of-stock days that then drag your measured velocity down — the same downward bias the corrected velocity method exists to remove (the in-stock-only correction). A UOM error doesn't just distort one SKU's quantity; it distorts the demand signal you'll use to buy that SKU for the next quarter.
A five-minute UOM audit
Run this against your catalog once; it catches most latent errors:
- Export SKUs with cost per item and on-hand quantities.
- Flag every SKU where cost per item is suspiciously high or low versus what you know you pay — a per-case cost on a per-each SKU (or the reverse) is the fingerprint of a UOM setup error.
- Flag every SKU whose on-hand is a clean multiple of its case size with zero loose units — that's either a fresh receipt (fine) or a case-counted record (not fine).
- Check your last five POs: do PO quantities match the units you actually received and entered? Any mismatch is a live error to correct now, while the paperwork is fresh.
- Confirm every "sells in two sizes" product is two SKUs with two canonical units.
Common questions
What does unit of measure mean in inventory? Unit of measure (UOM) is the unit a SKU's quantity is counted in — each, case, inner pack, pound, or liter. Best practice is one canonical UOM per SKU, ideally the unit you sell in, with all purchasing units converted to it exactly once at receiving.
Should I track inventory in cases or eaches? Track in eaches (the sell unit) and purchase in cases. Orders, velocity, and reorder points all live in sell units, so keeping records there avoids repeated conversions; the case quantity belongs on the PO line, converted to eaches when you receive.
How do I record case quantities in Shopify? Enter the converted number of eaches when receiving — a case of 12 raises on-hand by 12, not 1 — and keep cost per item at the per-each level as of October 2026. If customers buy whole cases too, set up the case as its own SKU rather than switching units on one record.
How do unit of measure errors affect reorder points? An on-hand error from a UOM slip shifts the trigger point's denominator: inflated stock delays reorders until a sudden gap appears, while deflated stock triggers early orders. Either way the reorder point computes correctly on wrong inputs, so the error is invisible until it's expensive.
What is a case pack? A case pack is the number of sell units a supplier ships per case — 12 jars, 24 bottles, 6 boxes. It belongs in your purchasing records and on PO lines ("8 cases (12)") so orders round cleanly to supplier multiples and receiving converts once into your canonical unit.
Your next step
Run the five-minute UOM audit on your 50 fastest-moving SKUs this week — they carry most of the demand math, so a UOM error there is the most expensive kind. Fix any cost-per-item and on-hand errors you find with reason-coded adjustments, and record the case-pack size for every SKU you buy by the case so the next PO rounds cleanly.