Bottom line up front: eighty percent of "inventory discrepancies" in a warehouse are not counting problems. They are UOM (unit of measure) problems. Get one uom unit conversion wrong in your WMS — eaches vs. cases vs. pallets — and inventory, picking, and billing are all wrong, silently.
I have seen this exact failure three times. The worst was May 2024, an auto parts client in Los Angeles, three weeks after a new WMS go-live. The warehouse supervisor called me, voice shaking: "The system says we have 8,000 brake pads, the shelf has 3,000. Five thousand pads missing — is someone stealing?" I told him to hold off on calling the police and export the UOM setup for that SKU. Purchasing unit: case, 20 pads per case. Sales unit and stock unit: each. The conversion table said 1 case = 12 eaches — someone had typed 12 during implementation. Receiving booked cases and the system recorded 12 eaches; shipping pulled eaches while the physical goods moved 20 at a time. Three weeks of drift. I changed one number and the variance disappeared. A 5,000-pad "theft" was the difference between 12 and 20.
The second time was November 2023, a food importer with three packaging levels: each, case, pallet — 40 cases per pallet, 24 eaches per case. Implementation only built two levels (each and case); pallets were handled as a "note" field. At month-end count, 200-plus pallets in the pallet zone showed up in the system only as loose eaches, and the inventory clerk multiplied pallet by pallet on a calculator. Worse, billing: the 3PL charged storage per pallet, the invoice never reconciled, and every line had to be checked by hand. After that I made a rule: any warehouse with pallet operations builds UOM down to the pallet level, no matter what the client says about "our pallets aren't standard." Build it on a standard pallet as the baseline and book the variance on an adjustment slip.
The third one was the sneakiest. February 2025, a beauty client with units of piece, box, case: 6 pieces per box, 12 boxes per case. The catch: there were two kinds of "box" — a 6-piece retail box and a 12-piece promo box, same SKU, different packaging. The WMS had one "box." When promo season hit, 12-piece boxes were booked as 6-piece, doubling on-hand inventory on paper; customer service took orders against system stock and ran dry mid-shipment. We added a "packaging version" dimension overnight, turning UOM from three levels into a two-dimensional "SKU + packaging version" model. Lesson: UOM is not a simple conversion table. It has to track your real packaging.
How to Build the UOM Conversion Table in Three Steps
Step one: survey every SKU's packaging hierarchy on the floor. Do not trust the ERP master data — ERP units are finance's view; the warehouse needs the operations view. Walk the floor with a tape measure: what is the smallest sellable unit (piece, bottle), how many inner packs exist (box, bag), how many outer cases, how are pallets stacked. Produce a packaging hierarchy sheet: SKU, L1, L2, L3, conversion factor, notes (multiple packaging versions?).
Step two: build "base unit + conversions" in the WMS. Pick the smallest unit (each) as the anchor; every uom unit conversion hangs off it. Maintain only adjacent-level conversions — 1 case = 24 eaches, 1 pallet = 40 cases — and let the system derive cross-level ones. Never hand-type "1 pallet = 960 eaches." Change one middle level and every hand-typed number breaks.
Step three: lock down who can change a conversion. Changing a conversion revalues historical inventory. Restrict the permission to the implementation consultant and the warehouse manager, and require a "conversion impact report" before any change: which SKUs' on-hand, in-transit, and in-pick quantities get revalued, and by how much. Changing it without that report is no different from deleting the database.
| Process | What breaks when the conversion is wrong | How to check |
|---|---|---|
| Receiving | Booked by case, recorded by each — quantity inflates or shrinks | Spot-check 3 SKUs: physical count x factor = system qty |
| Putaway | Pallet counts don't reconcile, slotting utilization lies | Count cases on sampled pallets |
| Picking | Picked by each, deducted by case — chaos compounds | Shadow one pick wave, compare deductions |
| Billing | 3PL bills per pallet, invoices never reconcile | Back out pallet counts from the 3PL invoice |
| Cycle count | Never balances, variance reason: "unknown" | Check the conversion before counting the stock |
The Counterintuitive Part: UOM Is an Operations Problem, Not an IT Problem
Most people treat UOM as system configuration — IT's job. Wrong. When UOM breaks, the root cause is always on the floor: the packaging changed and nobody told the system (supplier switched case specs), promo packs and standard packs share one SKU, how many cases go on a pallet depends on the forklift driver's mood. The system just faithfully records the floor's chaos, amplified.
So my rule: the conversion table is not one-time configuration, it is a monthly review item. Every month, the inventory clerk samples 10 SKUs, counts the packaging hierarchy on the floor, and reconciles it against the system table. Ten minutes of work stops ninety percent of book-to-physical variances. On every go-live night checklist I have ever run, UOM review is item number one — because counting, billing, and KPIs all stand on that number.
Go-live night checklist (UOM section): packaging hierarchy verified on the floor for all SKUs; base unit unified to the smallest unit; only adjacent-level conversions maintained; conversion-change permission revoked; conversion impact report run. Miss one checkbox and expect a 2 a.m. phone call.
By Lin Xiao, WMS Implementation Consultant
