For wholesalers who sell the same product as an each, a carton and a pallet

Unit of Measure Conversion: Eaches, Cartons and Pallets Between ERP and Ecommerce

Your supplier sells you pallets. Your warehouse counts cartons. Your ERP holds stock in eaches. Your trade customers buy inners of six, and your website only understands a single number called quantity. Every one of those is a unit of measure, and every time data crosses from one system to another, something has to multiply or divide. When that conversion is wrong, nothing errors. The order goes through, the stock moves, and the mistake shows up weeks later as stock that is not on the shelf or a margin that makes no sense.

Unit of measure handling is one of the less visible parts of an ERP to ecommerce integration, and it is expensive to get wrong. This page explains how base, sales and purchase units work, how to model pack sizes on a platform like Shopify that has no native concept of them, how to convert stock and price without rounding errors, and how to catch a mismatch before it costs you. It also says plainly when a single unit and a simple rule is the better answer.

Book a UOM Review (03) 9003 0111

Unit of Measure in Numbers

3 unit roles

Base, sales and purchase

Every product has all three, even when they happen to be the same unit

4 to 5 pack levels

Each, inner, outer or carton, layer, pallet

Typical for a distributor of packaged goods, though most products only use two or three

1 quantity

Per variant on most ecommerce platforms

Shopify, WooCommerce and BigCommerce sell in whole units of whatever the variant represents

Per product

Is where every conversion factor belongs

A global rule such as one carton equals twelve is wrong for part of almost every catalogue

Four Facts That Shape Every Unit of Measure Design

Unit of measure problems usually come from treating conversion as a formatting detail, when it decides what your stock figure, your price and your cost actually mean.

The ERP thinks in several units, the website thinks in one

NetSuite, Dynamics 365 Business Central and MYOB Acumatica all let a single item carry a base unit plus alternative units with conversion factors, so the same product can be bought by the pallet, stocked in eaches and sold by the carton. Shopify, WooCommerce and BigCommerce do not. A variant has one quantity, and the platform assumes a quantity of one means one of whatever that variant is. The integration is where those two world views meet, and it has to know, for every product, what one means on each side.

Stock must live in the smallest unit you can actually count

The base unit should be the smallest unit you physically sell or count, usually the each. If stock is held in cartons and you then sell one loose item, the ERP has to record a fraction of a carton, and fractions of cartons drift, round and disappear. Holding stock in the smallest unit means every other unit is a clean multiple of it, and every conversion is a multiplication rather than a division with a remainder.

Conversion factors belong to the product, not the system

A carton of glue sticks holds 24, a carton of paint holds 4, a carton of cable ties might hold 1,000. Any integration that applies one conversion rule to the whole catalogue is wrong for most of it. Each product needs its own factors per unit, maintained in the system that owns product data, and the integration should refuse to sync a product whose factors are missing rather than guess.

A mismatch never throws an error

Selling twelve eaches when you meant twelve cartons is a perfectly valid transaction as far as every system is concerned. Nothing fails. The error surfaces later as a stocktake variance, a customer who received one twelfth of their order, or a margin report showing an impossible figure for one product. That is why unit of measure design needs explicit checks and a reconciliation routine, not just correct mapping on day one.

How Unit of Measure Conversion Actually Works

Six areas where unit of measure decisions have to be made deliberately. Most of the remaining integration logic follows from these decisions.

One unit per role, per product

Base, sales and purchase units

The base unit is what stock is held and costed in. The sales unit is the default unit a customer buys in. The purchase unit is what you order from the supplier. For a box of nitrile gloves you might buy in cartons of 10 boxes, stock in boxes and sell in boxes or cartons. In Business Central these are the base, sales and purchase unit of measure fields on the item. In NetSuite they sit within a units type. MYOB Acumatica holds base, sales and purchase units with conversions that can be set globally, by item class or per item. Cin7 and Unleashed hold a primary unit per product and handle alternative pack sizes in more limited ways, often as linked products or pack settings, so check exactly what your edition supports before designing around it.

Variants, products or quantity rules

Modelling pack sizes on the storefront

There are three workable patterns. Pack sizes as variants (Each, Inner of 6, Carton of 24) on one product page, which suits retail and mixed buyers and keeps the page tidy. Pack sizes as separate products, which suits catalogues where each pack has its own barcode, image and search behaviour. Or a single sellable unit with quantity rules, where the customer buys eaches but must order in multiples of six with a minimum of 24. Shopify B2B can enforce minimums, maximums and increments per variant in a company catalogue, which often removes the need for separate pack variants entirely. Pick one pattern per product type and apply it consistently.

Whole sellable units only

Stock availability conversion and rounding

If the ERP holds 100 eaches and the website sells cartons of 12, the website should show 8 cartons, not 8.33. Always round sellable availability down, never to the nearest. When eaches and cartons are both on sale from the same pool, both variants draw on one stock figure, so the integration must recalculate both after every sale: one carton sold leaves 88 eaches and 7 cartons. Decide up front whether you will break cartons to fill each orders, because if you will not, loose stock and sealed carton stock need to be tracked as separate figures.

Prices set per pack, not derived

Price per unit and trade breaks

A carton is rarely priced at twelve times the each price. It is usually cheaper per unit, which is the point of buying the carton. Prices should be held per unit of measure in the ERP or pricing system and pushed as they are, rather than calculated by multiplying the each price on the way through. Trade price breaks then sit on top: for example, an each at $5.20, a carton of 12 at $54.00 ($4.50 per each), and 10 or more cartons at $51.00. All figures are illustrative and ex GST. Keep enough decimal places in the base unit price to avoid rounding drift, and round at the line, consistently.

Decimal quantities handled safely

Weight and measure items

Cable sold by the metre, chemicals by the litre, produce or meat by the kilogram, fabric by the centimetre. ERPs usually accept decimal quantities. Most ecommerce platforms only accept whole numbers. The common workaround is to sell in a fixed small increment (one unit equals 0.1 metre, or 100 grams) and convert back on the way into the ERP. For variable weight goods, where the final weight is only known at picking, the order needs to be captured at an estimated quantity and price, then adjusted to the actual weight before invoicing, with the payment authorisation set to cover the difference.

Dimensions on every pack level

Freight weight and cube per unit

Freight quotes need the weight and dimensions of what will actually ship. An each, a carton and a pallet all have different weights and cubes, and a carton is not simply twelve eaches in a row because of the packaging. Australian carriers typically charge on the greater of dead weight and cubic weight, so missing carton dimensions lead to quotes that are wrong in a way that only appears on the carrier invoice. Hold weight, length, width and height per unit of measure, not just per item.

Common Unit of Measure Situations

Task	Traditional	Done Properly	Notes
Same item sold as an each and a carton	Two unrelated stock figures	One pool, both variants recalculated	Both variants draw down the same base unit stock in the ERP. After each sale, availability for every pack is recalculated and rounded down.
Customer orders 7 of a carton only item	Phone call to correct the order	Blocked at the cart by quantity rules	Minimums and increments enforced on the storefront, with the same rules held in the ERP so rep and portal orders behave identically.
Supplier sells in cartons, you stock eaches	Receiver converts in their head	Purchase unit converts on receipt	The purchase order is raised in cartons, received in cartons and converted to eaches by the per product factor, so cost per each is correct automatically.
Cable sold by the metre online	Quantity typed as a note	Fixed increment converted to metres	The storefront sells whole units of 0.5 metres, for example, and the integration converts to decimal metres for the ERP order line.
EDI order arrives in a trade unit	Keyed in after a guess	Mapped via the item pack table	Retailers order in the unit they buy in. The order is converted using the product specific factor, never a global one. See our EDI page for the message side.
Supplier price file quoted per case	Cost entered against the wrong unit	Normalised to base unit cost	Per case cost divided by the case quantity before it lands in the ERP. A missing case quantity stops the line rather than guessing.
Opening a carton to sell loose	Stock adjusted at stocktake	Break bulk transaction recorded	One carton out, twelve eaches in, recorded at the time, so carton and loose availability both stay accurate.
Pallet order needs a freight quote	Estimated from item weight	Pallet weight and cube used directly	Dimensions per pack level mean the quote reflects what the carrier will actually measure on the dock.

Where Unit of Measure Integrations Go Wrong

A global conversion rule

One carton equals twelve, applied to everything, is a common mistake. It is correct for some products and silently wrong for the rest. Conversion factors must be held per product and per unit, in the system that owns product data, and the integration should reject any product that does not have them. A rejected product is a short exception to fix. A wrongly converted one is a stock and margin problem that compounds every day.

Ghost stock from receiving in the wrong unit

If 10 eaches are received as 10 cartons of 12, the ERP believes there are 120 on hand when there are 10. The website can then sell 110 items that do not exist. The reverse, receiving 10 cartons as 10 eaches, hides 110 units, which then sit unsold while purchasing reorders more. Both show up as stocktake variances weeks later. Receiving screens should show the unit clearly, and a large receipt variance against the purchase order should be flagged before posting.

Price converted, cost not converted

When sell price is held per carton and cost is held per each, or the other way around, margin reports show impossible figures: a product apparently marked up by several hundred percent, or losing money on every sale. Cost and price must be compared in the same unit. The cleanest approach is to hold cost in the base unit and convert price to the base unit for reporting, so every margin figure is like for like.

Rounding availability up or to the nearest

Showing 9 cartons available when you hold 100 eaches against a carton of 12 means one order will be short. Availability must always round down to whole sellable units. When the same pool feeds several pack sizes, the integration should also hold a small buffer or reserve stock per pack, because two near simultaneous orders for different pack sizes can each see stock that only one of them can have.

Supplier changes the pack size

A supplier moves from cartons of 12 to cartons of 10 and the item code stays the same. Old stock is in twelves, new stock is in tens, and one conversion factor cannot describe both. Treat a pack size change as a product data event: a new purchase unit or a new item, an effective date, and a check on open purchase orders. Under GS1 numbering each pack level normally carries its own barcode, so this is also the moment barcodes usually change, which is why barcode structure and unit design need to agree.

Building multiple units when one would do

If you only ever sell cartons, stock cartons and sell cartons, with no loose sales and no supplier conversion, a single unit is simpler and safer. Multiple units of measure add configuration, testing and reconciliation work. They earn their place when you genuinely sell or buy the same product in more than one pack, and not before. We will tell you if your catalogue does not need them.

How Yes AI Approaches Unit of Measure Integration

A catalogue audit before any mapping

We pull every product and its units from your ERP and look for the problems first: missing factors, inconsistent base units, cost held in a different unit from price, products sold online in a unit the ERP does not know. Fixing the data is often a large part of the project.

A pack modelling decision per product type

Variants, separate products or quantity rules, chosen per category rather than for the whole catalogue, with the reasoning written down. Where Shopify B2B quantity rules or a native connector already handle it, we say so and configure that rather than building something custom.

Built, hosted and monitored by us

Conversion, rounding and availability logic runs on a managed cloud automation layer we operate, with each conversion logged so any stock or price figure can be traced back to the source value and factor that produced it. You do not maintain scripts or servers.

Reconciliation checks from day one

Scheduled checks compare ERP stock against storefront availability per pack, flag products whose margin falls outside a sensible range, and catch receipts with an unusual variance. The aim is to find a unit mistake in a day, not at the next stocktake.

How a Unit of Measure Project Runs

Most of the work is in the product data and the decisions. The integration build itself is usually the shorter part.

Audit units across every system

List every unit in use in the ERP, the storefront, supplier files and EDI partners. Identify the base unit per product, find missing or inconsistent factors, and check where cost and price are held in different units.

Decide the model

Agree the base unit rule, the storefront pattern per product type, whether cartons can be broken, how decimal and variable weight items are handled, and which system owns conversion factors. Written down and signed off.

Fix the product data

Correct factors, add missing pack levels, attach weight and dimensions per unit, and align barcodes with pack levels. This is often the longest step and the one with the most lasting value.

Build and test with awkward products

Implement conversion, rounding and availability logic, then test with the difficult cases: mixed pack sales from one pool, broken cartons, decimal quantities, a pack size change and a supplier file in a different unit.

Go live with reconciliation running

Launch with daily stock and margin checks in place, review exceptions closely for the first few weeks, then settle into a weekly rhythm once the figures have proven stable.

FAQ

What is the difference between a base unit, a sales unit and a purchase unit?

The base unit is the unit stock is held and costed in, ideally the smallest unit you physically count or sell, usually an each. The sales unit is the unit a customer normally buys in, such as a carton. The purchase unit is what you order from the supplier, such as a pallet or a case. Each alternative unit carries a conversion factor back to the base unit, set per product. Every transaction is stored in base units underneath, which is what keeps stock and cost consistent across systems.

Does Shopify support multiple units of measure?

Not in the way an ERP does. A Shopify variant has one quantity, and one means one of whatever that variant represents. You model pack sizes as variants, as separate products, or as a single unit with quantity rules. Shopify B2B can set minimum, maximum and increment quantities per variant within a company catalogue, along with volume pricing, which covers many wholesale cases without custom work. The conversion back to the ERP unit then happens in the integration.

Should pack sizes be variants or separate products?

Variants work well when customers compare packs on one page and the packs share an image and description, which suits retail and mixed buyers. Separate products work better when each pack has its own barcode, its own search behaviour and its own buyers, which is common in foodservice and industrial supply. Quantity rules on a single unit are often the simplest of all for trade customers who already know the pack size. The right answer is usually different for different categories in the same catalogue.

How do we sell cartons online when we hold loose eaches in the warehouse?

Hold stock in eaches as the base unit, and calculate carton availability by dividing eaches on hand by the carton quantity and rounding down. If you sell both eaches and cartons from the same pool, recalculate both after every sale. If you do not break cartons, track sealed and loose stock separately, because 100 eaches made up of 8 sealed cartons and 4 loose is not the same as 100 loose eaches when a customer wants a sealed carton.

How do we handle products sold by the metre, litre or kilogram online?

Most storefronts only accept whole number quantities, so sell in a fixed increment such as 0.5 metres or 100 grams and convert to the decimal ERP quantity in the integration. For variable weight goods where the final weight is known only at picking, capture the order at an estimate and adjust to the actual weight before invoicing, with the payment authorisation set to cover a reasonable variance. If you sell goods by measure, trade measurement rules administered by the National Measurement Institute may apply to how quantities are measured and stated, so confirm your obligations with an adviser.

How can we tell if our unit of measure setup is already wrong?

The signs are consistent: stocktake variances concentrated on products with more than one pack size, margin reports with impossible figures on a handful of items, customers occasionally receiving a fraction or a multiple of what they ordered, and receivers adjusting quantities by hand on goods inwards. A quick check is to sort your margin report by margin percentage and look at both ends. The products at the extremes are very often unit of measure errors rather than real pricing.

Do we always need multiple units of measure?

No. If every product is bought, stocked and sold in the same unit, a single unit is simpler and less likely to go wrong. Multiple units are worth the setup when you genuinely sell the same product in more than one pack, buy in a different unit from the one you sell, or trade with partners who order in their own units. Many businesses only need them on part of the catalogue, and an off-the-shelf connector that maps one ERP unit to one variant can be perfectly adequate for the rest.

Get Your Units of Measure Straight Before They Cost You

Book a call. We review how your products are set up across ERP, storefront and supplier files, show you where conversions are likely to go wrong, and recommend the simplest model that fits. The findings are yours either way.