Cloud ERP for Businesses with Complex Units of Measure: Selling by the Case, Buying by the Pallet, Tracking by the Each
You buy a product by the pallet. You receive it by the pallet. You store it by the pallet. You pick it by the case. You sell it by the case — except to three customers who buy by the each, two who buy by the inner pack, and one national account whose purchase orders specify a unit of measure you’ve never seen before that maps to nothing in your system.
Your inventory is tracked in eaches. Your purchase orders are in cases. Your price list is per case, except for the items priced per pound, the items priced per thousand, and the items priced per linear foot. When the customer orders 10 cases and the system shows 240 eaches, someone has to know that a case is 24 eaches for this product — but 12 for that one, and 48 for the other one — and whether the 240 eaches on hand actually means 10 cases or 9 cases and 24 loose eaches that can’t ship as a full case.
This is a Tuesday in wholesale distribution. And it’s the operational detail where generic ERP systems silently fall apart.
Units of measure sound like a simple data management question — just define the conversions and let the system calculate. But in distribution, where the same product flows through purchasing, receiving, warehousing, picking, selling, pricing, invoicing, and financial reporting — each potentially using a different unit of measure for legitimate operational reasons — the UOM challenge touches every function in the business. Get it wrong and the errors cascade: incorrect purchase quantities, wrong pick instructions, invoices that don’t match what shipped, inventory valuations that don’t add up, and customer confusion about what they ordered versus what they received.
This article explains why units of measure are genuinely complex in distribution, where ERP systems fail to handle them, and what a well-designed platform needs to do to make the complexity invisible to the people running the operation.
Why Units of Measure Are Actually Hard
The complexity isn’t in the math. Converting cases to eaches is arithmetic. The complexity is in the operational context — the fact that different business functions legitimately need to express the same quantity in different units, and the system has to maintain coherence across all of them simultaneously.
Every Function Has Its Own Natural Unit
Purchasing thinks in vendor units — pallets, cases, drums, rolls, whatever unit the supplier prices and ships in. The purchase order should express quantities in the unit the vendor expects, because that’s what they’ll pick, pack, and invoice against. A purchase order for “2,880 eaches” when the vendor sells by the case of 24 creates confusion, potential errors in vendor fulfillment, and invoices that don’t match the PO.
Warehousing thinks in storage and handling units — pallets for bulk storage, cases for pick locations, eaches for broken-case picks. The warehouse associate receiving a delivery needs to know they’re putting away 5 pallets, not 120 cases or 2,880 eaches, because the putaway instruction is about physical handling, and what you physically move is a pallet. The picker filling an order needs to know they’re picking 3 cases from a location, not 72 eaches — unless the order actually calls for 72 eaches that need to be broken from cases.
Sales thinks in customer units — whatever unit the customer orders in, which may be different from how you buy, store, or pick the product. One customer orders in cases. Another orders in eaches. Another orders in inner packs (the packaging layer between the case and the each). Another specifies a unit that’s unique to their industry — per hundred, per thousand, per linear foot, per square meter.
Pricing operates in its own unit — the unit the price is expressed against, which may or may not match the selling unit. A product might be priced per each but sold by the case. Or priced per pound but sold by the unit, with each unit having a different weight. Or priced per case but invoiced per each because the customer’s system requires each-level detail on the invoice.
Finance needs a consistent unit for inventory valuation, cost accounting, and financial reporting. If the system values inventory in eaches but reports cost of goods sold in cases, the conversion has to be precise and automatic — any inconsistency between the inventory valuation and the financial reporting creates audit issues.
A single product can legitimately be expressed in five or more different units of measure across a single transaction lifecycle — purchased in pallets, received in pallets, stored in cases, picked in cases or eaches, sold in the customer’s unit, priced in a pricing unit, invoiced in the customer’s unit, and valued in eaches. The system needs to handle all of these representations while maintaining a single, consistent underlying quantity that everyone agrees on.
Conversions Aren’t Always Simple
For many products, the conversions are fixed and clean. A case always contains 24 eaches. A pallet always holds 48 cases. The math is multiplication and division with whole numbers.
But distribution handles products where conversions are variable or approximate — and these are the scenarios that break systems designed for simple, fixed ratios.
Catch weights. Products sold by count but priced by weight — common in food distribution, chemical distribution, and building materials. You buy 100 units, but each unit weighs slightly different. The total weight — and therefore the total price — isn’t knowable until the product is weighed at receipt or at shipment. The system needs to track both the count unit (100 units) and the weight unit (2,347 pounds) simultaneously, with the pricing tied to the weight and the inventory management tied to the count.
Variable pack sizes. Some products come in cases that don’t always contain the same quantity. A supplier might ship cases of “approximately 50” units where the actual count varies. The system needs to handle the receipt of a case as a nominal unit while tracking the actual each count for inventory accuracy.
Dimensional units. Products measured in length, area, or volume — wire sold by the foot, fabric by the yard, chemicals by the gallon, lumber by the board foot. These units require conversions that may involve product-specific dimensions rather than simple ratios. A roll of wire contains 1,000 feet, but the rolls aren’t interchangeable with rolls of different wire that also contain 1,000 feet. The unit of measure is the same (feet), but the product is different, and the system needs to maintain that distinction while handling the dimensional quantity.
Customer-specific units. Large customers — particularly national accounts and government entities — sometimes specify units of measure in their purchase orders that don’t match your internal units. They order in “units” that correspond to your inner packs, or in “cases” that correspond to your master cartons, or in units defined by their own internal systems that require a customer-specific conversion factor. The EDI translation layer needs to map their unit to yours accurately, or every order arrives in the system with quantities that don’t make sense.
The Conversion Must Be Transparent
The system’s UOM handling is only as good as its transparency. When a purchasing agent sees a suggested purchase quantity, they need to know what unit it’s expressed in and how it maps to what they’ll actually order from the vendor. When a picker sees a pick instruction, they need to know whether “5” means 5 eaches, 5 cases, or 5 pallets — and the warehouse instruction should be in the unit that corresponds to how they’ll physically handle the product. When a customer receives an invoice, the quantity and unit should match what they ordered and what they received, in the unit they expect.
Opacity in UOM handling — where the system converts behind the scenes and the user isn’t sure which unit they’re looking at — produces exactly the kind of errors that are expensive to detect and expensive to fix. The purchasing agent who orders 10 thinking they’re ordering 10 cases and actually orders 10 eaches has created a problem that ripples through the supply chain. The picker who picks 5 cases when the system meant 5 eaches has shipped 120 units instead of 5. The invoice that shows “10” when the customer ordered “10 cases” and the system invoiced “10 eaches” triggers a dispute, a credit, and a trust erosion.
Where Generic ERP Systems Fail
Generic ERP platforms handle units of measure as a simple feature: define the item’s base unit, define the conversion factors, and the system converts. For businesses with one selling unit and one purchasing unit, this is adequate. For wholesale distribution, where UOM complexity is the norm rather than the exception, generic handling creates problems that range from annoying to operationally dangerous.
Only Two Units Supported
Many entry-level and general-purpose ERP systems support a base unit and one alternate unit — or a base unit with a single conversion factor. Buy in cases, sell in eaches, track in eaches. That’s the full extent of the UOM model.
This breaks immediately when the business needs a third unit. Buy in pallets (conversion: 1 pallet = 48 cases), store in cases, pick in cases or eaches (conversion: 1 case = 24 eaches), sell in cases or eaches depending on the customer. The system with a single conversion can handle pallet-to-each or case-to-each, but not both — and it certainly can’t handle the full chain from pallet to case to inner pack to each with independent conversions at each level.
Distributors working around this limitation maintain conversion information in spreadsheets outside the system, train users to do mental math, and accept a baseline error rate that erodes accuracy across every function. The workaround works until it doesn’t — until someone miscounts, misremembers, or mis-converts, and the error cascades through an order, a shipment, an invoice, and a customer relationship.
Conversions Disconnected From Transactions
Some platforms define conversions at the item master level but don’t enforce them throughout the transaction lifecycle. The conversion exists as reference data — “this item has 24 per case” — but the purchase order, the receipt, the pick, and the invoice all accept any unit the user enters, without validating against the defined conversion or automatically converting between units.
This produces inconsistency. The purchase order might be entered in cases, the receipt recorded in eaches because that’s what the warehouse counted, and the invoice from the vendor in cases. The system doesn’t reconcile these automatically because the conversions aren’t woven into the transaction logic — they’re just data sitting in the item record. Someone in purchasing or accounting has to manually validate that the 2,880 eaches received match the 120 cases ordered, and that the vendor’s invoice for 120 cases at $14.50 per case matches the received value of 2,880 eaches at $0.6042 per each.
This manual reconciliation is the work the system should be doing. Every manual validation is a cost. Every unvalidated discrepancy is a risk.
No Support for Catch Weights
Catch weight handling — tracking both a count unit and a weight unit simultaneously, with pricing based on weight and inventory based on count — requires specific architectural support that most general-purpose ERP platforms don’t provide. The system needs dual-unit tracking at the transaction level: this receipt is 100 units weighing 2,347 pounds. This pick is 25 units weighing 586.75 pounds. The invoice is for 586.75 pounds at $2.15 per pound.
Without catch weight support, distributors handling weight-priced products maintain weight data in spreadsheets, adjust invoices manually after weighing, and accept that inventory valuation is approximate because the system can’t track actual weights at the unit level. For food distributors, chemical distributors, and building material distributors — where catch weight products can represent a significant portion of the catalog — this limitation undermines the accuracy of the entire inventory and financial management function.
Pricing Unit Disconnected From Selling Unit
Distribution pricing frequently operates in a unit that differs from the selling unit. The price is per each, the customer orders in cases, and the system needs to calculate the line total as (case quantity × eaches per case × price per each). Or the price is per thousand, the customer orders 5,000 units, and the system needs to calculate the line total as (5,000 ÷ 1,000 × price per thousand).
When the pricing unit and the selling unit are disconnected in the system — or worse, when the system doesn’t support the concept of a separate pricing unit — the calculation either happens manually or happens incorrectly. Manual price calculation at order entry introduces error and consumes time. Incorrect automatic calculation introduces errors that may not be caught until the invoice is disputed.
EDI UOM Translation Failures
EDI transactions include unit of measure codes that specify how the trading partner expresses quantities. The customer’s purchase order might specify “CA” for case, “EA” for each, “PK” for pack, or any of dozens of standard UOM codes. These codes need to map to your internal units accurately, with the correct conversion factors, so that an inbound EDI order for “10 CA” translates to the correct internal quantity in the correct internal unit.
When the EDI translation layer doesn’t handle UOM mapping thoroughly — when a customer’s “CA” maps to your “case” but their case contains a different quantity than your case, for example — EDI orders arrive in the system with incorrect quantities. The errors are subtle because the unit looks right. The quantities just don’t match reality. These discrepancies surface as shipment errors, invoice disputes, and compliance penalties — all traceable to a UOM translation that nobody tested against the customer’s actual product packaging.
What a Well-Designed UOM System Actually Does
A platform built for distribution handles units of measure not as a simple feature but as a foundational capability woven into every transaction, every function, and every calculation in the system.
Multi-Level Conversion Chains
The system should support conversion chains with multiple levels — pallet to case to inner pack to each — with independent conversion factors at each level. These chains should be defined per product, because conversion factors vary by item. Product A has 24 per case. Product B has 12 per case. Product C has 48 per case and 4 cases per pallet. The system maintains each product’s specific chain and applies the correct conversions throughout the transaction lifecycle.
When a user enters a quantity in any supported unit, the system converts automatically to the appropriate unit for each function. The purchase order shows pallets because that’s what the vendor ships. The inventory shows eaches because that’s the base tracking unit. The pick ticket shows cases because that’s how the warehouse handles the product. The invoice shows the customer’s ordering unit. All of these are different representations of the same quantity, maintained coherently by the system without manual conversion by the user.
Transaction-Level Unit Enforcement
Every transaction in the system — purchase order, receipt, transfer, pick, pack, ship, invoice, adjustment — should respect the UOM framework. When a purchase order is created in cases, the receipt should validate in cases (or convert from eaches if the warehouse counts in eaches). When a sales order is entered in cases and the picker picks eaches, the system should convert and validate that the picked eaches equal the ordered cases. When the invoice generates, the quantity and unit should match what the customer ordered.
This enforcement isn’t just about preventing user error. It’s about maintaining data coherence across the full lifecycle. Every function sees the quantity expressed in the unit that’s meaningful for their work, and every conversion is automatic, validated, and auditable. The system never asks the user to figure out how many eaches are in 3.5 cases of product X — it knows.
Flexible Selling and Pricing Units
The system should support selling in any defined unit — cases, eaches, inner packs, pallets, or customer-specific units — with automatic conversion to the base unit for inventory and financial processing. The selling unit can vary by customer: Customer A buys in cases, Customer B buys in eaches, Customer C buys in a custom unit defined by their purchasing system. The platform handles all three through the same order entry workflow, with conversions happening automatically based on the customer’s configuration.
Pricing should support a pricing unit that’s independent of the selling unit. Price per each, sell by the case. Price per thousand, sell in specific quantities. Price per pound, sell by the unit. The system calculates the correct line total based on the selling quantity, the conversion to the pricing unit, and the price per pricing unit — without the user performing any mental arithmetic.
Catch Weight Support
For products that require dual-unit tracking, the system should maintain both the count unit and the weight unit at every transaction level. The receipt records 100 units at 2,347 pounds. The pick records 25 units at a specific weight determined at the point of pick — either weighed individually or estimated from the average weight per unit, depending on the operation’s process. The invoice calculates from the actual shipped weight. Inventory reflects both the unit count and the total weight, with the financial valuation based on whichever unit drives the cost.
Catch weight support should be configurable per product — not every item needs dual-unit tracking, and the system shouldn’t impose the complexity on products that don’t require it. But for the products that do require it, the support should be native and comprehensive, not a workaround bolted onto a system designed for single-unit tracking.
EDI UOM Translation
The system should map trading partner UOM codes to internal units with customer-specific conversion factors where needed. If Customer A’s “CA” is your standard case of 24, the mapping is straightforward. If Customer B’s “CA” is their master carton that corresponds to your 4-pack of inner packs containing 6 eaches each — a 24-each equivalent that’s packaged differently from your standard case — the system needs a customer-specific conversion that translates their unit to your unit accurately.
This mapping should be testable before live transactions flow. When a new trading partner is onboarded, the EDI configuration should allow test transactions that verify the UOM mapping produces correct quantities in the system before real orders arrive and real shipments go out.
Reporting and Analytics in Any Unit
Reports should be expressible in any defined unit of measure — not just the base unit. The purchasing report that shows volume in cases is more useful to the purchasing director than one that shows eaches. The inventory report that shows pallets on hand by location is more useful to the warehouse manager than one that shows eaches. The sales report that shows customer volume in the customer’s ordering unit is more useful to the sales director than one that requires mental conversion.
The reporting framework should convert automatically based on the user’s preference or the report’s configuration, using the same conversion factors that govern transactions. The numbers in the report should be consistent with the numbers in the transaction — because they come from the same data using the same conversions.
How to Evaluate UOM Handling in Your ERP Demo
UOM handling is easy to overlook in a demo because the standard demo dataset uses simple conversions that work on any platform. Testing your actual complexity requires deliberate scenarios.
Bring a product with a multi-level conversion chain. Pallet to case to inner pack to each, with specific ratios at each level. Ask the vendor to set up the product, create a purchase order in pallets, receive in pallets, pick a customer order in cases, and generate an invoice in eaches. Verify that the quantities convert correctly at every step and that the inventory reflects the base unit accurately after each transaction.
Bring a catch weight product. A product priced by weight with variable unit weights. Ask the vendor to demonstrate receipt with weight capture, picking with weight recording, and invoicing based on actual shipped weight. Verify that inventory tracks both count and weight, and that the financial valuation is based on the correct unit.
Bring a customer-specific UOM scenario. A customer whose ordering unit doesn’t match your internal unit. Ask the vendor to demonstrate how the system translates between the customer’s unit and your unit — both for manual order entry and for EDI processing. Verify that the conversion is customer-specific and that the correct quantity reaches the warehouse.
Test the pricing calculation. A product priced per each but sold by the case, with a volume-tier discount based on the total each count. Does the system convert the case quantity to eaches for pricing, apply the tier, and calculate the correct line total? Can the rep see both the per-each price and the per-case extended price on the order?
Check the reporting. Ask for an inventory report by location showing quantities in cases, then the same report in eaches, then in pallets. Verify that the conversions are consistent and that the report matches the transaction data. If the numbers don’t agree, the conversion framework has gaps.
How Bizowie Handles Units of Measure
Bizowie was built for the unit-of-measure reality that wholesale distributors live with every day — not the simplified version that generic platforms assume.
Multi-level conversion chains are defined per product and enforced across every transaction. Purchasing, receiving, warehousing, picking, selling, invoicing, and financial reporting each operate in the unit that’s natural for that function, with automatic, validated conversion at every transition. The user works in their unit. The system maintains coherence in the base unit. Nobody does mental arithmetic to figure out how many eaches are in 3.5 cases.
Pricing supports units independent of the selling unit — price per each, sell by the case; price per pound, sell by the unit; price per thousand, sell in any quantity. The calculation is automatic, transparent, and integrated with the full pricing engine that handles customer-specific, volume-tiered, contract-based, and cost-plus pricing simultaneously.
EDI translation maps trading partner UOM codes to internal units with customer-specific conversions where needed. Inbound orders arrive with correct quantities in the correct internal unit, regardless of how the trading partner expressed them.
And every report, every dashboard, and every analytical view expresses quantities in whatever unit the user needs — with conversions drawn from the same framework that governs transactions, ensuring that the numbers in the report always match the numbers in the operation.
The unit-of-measure problem doesn’t sound glamorous. It doesn’t headline a vendor’s features page. But it’s one of the most operationally consequential capabilities in distribution ERP — because when it fails, every function downstream of the failure pays the price. And when it works, nobody thinks about it at all. That’s the goal: invisible correctness, at every transaction, in every unit, across every function.
Test us with your hardest UOM scenario. Schedule a demo with Bizowie and bring the product with five levels of packaging, the catch weight item, the customer with the non-standard unit, and the pricing structure that mixes units. We’ll show you how a platform built for distribution handles the complexity that generic systems pretend doesn’t exist.