After the physical pack hierarchy and contained counts have been approved, choose one smallest counted inventory unit for each SKU and approved product version. Then map every supplier case, warehouse pack, sales pack and customer each directly to that base unit. Record the factor, identifier, evidence source, owner and effective date, and test the entire transaction path before the mapping goes live.
That sounds elementary. It becomes difficult when a supplier quotes cases, a 3PL receives master cartons, the warehouse breaks those into inner packs, and ecommerce sells single units. A quantity of 10 is unsafe unless the record also says 10 of what, under which pack configuration and for which product revision.
The useful control is not a larger spreadsheet of numbers. It is a versioned relationship that survives purchase orders, receiving, stock movements, orders, returns and system integrations without silently changing meaning. This article sets out an operational method for Australian importers. It does not prescribe accounting valuation, regulated net content, product safety requirements or one software configuration.
Fix one base inventory unit before mapping packs
Start with the unit used to express physical on-hand quantity for the SKU. For a product sold singly, that may be each. A supplier case and an inner pack are then larger handling or transaction units with declared factors back to that base.
Microsoft's current unit-of-measure and stocking policy documentation describes unit sequence groups and conversions between warehouse units. Its example separates pallet receiving from piece-level stock. The product-specific settings are not a universal design, but they show the core issue: a larger receiving unit and a smaller inventory unit must have an explicit relationship.
Use a base unit that the business can count consistently. Do not pick case merely because that is how the supplier quotes today if the warehouse routinely opens cases and sells smaller quantities. Do not pick each if one each is not a stable, independently identifiable saleable unit. The product and operating model decide the label.
The chosen unit needs an owner. Procurement can supply the factory pack statement, but the inventory or operations owner should approve the quantity relationship used across systems. If the evidence is incomplete, leave the mapping provisional and block live transactions that depend on it.
Separate identity, physical package and quantity
Three related facts often get collapsed:
- the identity of a trade item or logistics unit;
- the physical package being handled; and
- the number of base units inside that package.
A barcode does not, by itself, prove the current contained quantity. A cardboard case does not guarantee every case with a similar description contains the same pack. A product record called box is not a conversion factor.
Oracle's WMS unit-of-measure documentation distinguishes case, pack, unit and licence-plate levels and stores standard pack and case quantities. Treat those labels as an example of one platform's model, not universal terminology. In your own record, use unambiguous names such as supplier master case, inner six-pack and saleable each.
Keep packaging measurements alongside, but separate from, conversion quantities. The packaged product dimensions and weight workflow controls length, width, height and gross weight for unit, inner and case levels. A case can retain the same dimensions while its quantity changes, or keep the same quantity while its dimensions change. Both data sets matter, but they answer different questions.
Build a conversion register that can be read back
Create one row for every allowed unit relationship. Store the direct factor to the base unit instead of relying only on chained conversions. If one inner contains six eaches and one case contains eight inners, record both inner = 6 each and case = 48 each.
| Field | Record | Release question |
|---|---|---|
| Product identity | Internal SKU, approved revision and description | Is this the same product and configuration across all records? |
| Unit identity | Supplier, warehouse and sales unit name plus identifier | Can each message distinguish case, pack and each? |
| Direct base factor | Base units per named unit | Is the factor supported at the approved precision for this product? |
| Evidence | Approved hierarchy record or reconciled production pack-count evidence | Has the source been read back rather than copied from memory? |
| Owner and status | Named approver; proposed, tested, approved or withdrawn | Who can release or stop the mapping? |
| Effective period | Start date and, when replaced, end date | Which transactions are allowed to use this version? |
| Exception rule | Partial package, shortage, damage, hold and return treatment | Does an exception remain a quantity, not disappear into notes? |
Avoid a free-text factor with no unit labels. 8 × 6 may be arithmetically correct yet still unsafe if nobody can tell whether it means six eaches per inner or six inners per case.
Do not round an intermediate relationship and then multiply it through the hierarchy. Store the supported direct factor for each unit-to-base relationship and test the exact quantities the system will exchange. Where fractional quantities are genuinely allowed, define precision and rounding with the system owner; where the product is counted only in whole eaches, reject a mapping that creates fractions.
Treat a pack change as controlled master data
Pack quantities can change without the base product appearing different to a hurried receiver. A factory may move from eight inners per case to ten, or a sales pack from four eaches to six. Do not overwrite the old factor and let open orders inherit the new meaning.
The GS1 GTIN Management Standard states that changing the number of trade items in a case, or the number of cases in a predefined pallet configuration, requires a new GTIN, with a unique GTIN assigned at every existing packaging level above the retail consumer trade item or base unit. Apply that rule within its scope and confirm any relevant trading-partner or local requirement. This article does not decide regulated net-content or product-specific identifier obligations.
Operationally, open a new conversion version. Record the new effective date, supporting pack evidence and identifier decision. Identify purchase orders, advance shipping data, warehouse records, listings and open customer orders that still refer to the earlier version. Do not relabel historical receipts as though the new pack existed when they were processed.
The SKU and GTIN setup guide covers the identifier decision itself. The SSCC and logistics-label guide covers unique logistics-unit identity. This conversion control uses those identifiers to preserve quantity meaning; it does not replace them.
Test the whole transaction path before release
A screen showing the right factor is not enough. Run a controlled test using the same product and version through every system boundary that will handle it.
- Create a purchase order in the supplier unit and confirm the base-unit equivalent.
- Receive a full case and read back both the received unit and base on-hand movement.
- Break one case into inner packs and eaches without changing total base quantity.
- Allocate and sell each permitted sales unit, then confirm the base movement.
- Process one return in its actual received condition and confirm its status before it becomes available.
- Reconcile supplier document, 3PL/WMS, ERP and ecommerce quantities at one declared cutoff.
Use production-intent configuration in a safe test path. A demonstration with a different SKU or convenient pack factor does not prove the target product works.
The test should retain inputs and read-backs. Capture the purchase unit sent, quantity received, conversion applied, inventory state changed, sales unit ordered and final base balance. When an integration transmits only a number and silently assumes the unit, treat that as a failed control.
Use a labelled worked example to expose an exception
Assume a fictional product with these approved factors:
- one inner pack equals 6 eaches;
- one supplier case equals 8 inner packs; and
- therefore one case equals 48 eaches.
A purchase order for 25 cases expects 1,200 eaches. The warehouse receives 24 sealed cases, 7 complete inner packs and 5 loose eaches from the opened final case. The supported receipt is 24 × 48 + 7 × 6 + 5 = 1,199 eaches. The record has a one-each discrepancy against the expected quantity; it must not be hidden by marking all 25 cases received.
If the warehouse later ships 2 cases and 3 inner packs, the base movement is 2 × 48 + 3 × 6 = 114 eaches. From the verified 1,199 eaches, the resulting balance is 1,085 eaches, before any separate hold or other movement.
| Event | Source quantity | Base-unit result | Required read-back |
|---|---|---|---|
| Purchase order | 25 cases | 1,200 eaches expected | PO retains case unit and factor version |
| Physical receipt | 24 cases + 7 inners + 5 eaches | 1,199 eaches received | One-each discrepancy remains open |
| Outbound movement | 2 cases + 3 inners | 114 eaches issued | Sales units and base movement agree |
| Balance after movement | Prior 1,199 − 114 | 1,085 eaches | WMS, ERP and channel basis reconciled |
These numbers are instructional, not a real customer result or standard pack. Their purpose is to show why a whole-case receipt flag cannot replace a counted quantity when the final package is partial.
Keep unavailable stock out of the selling quantity
Conversion tells you how many base units a package represents. It does not decide whether those units are saleable. Damaged, quality-held, quarantined, unidentified or otherwise unavailable stock needs an explicit state.
When a case is opened, preserve the total quantity while changing the package state. When units are held, preserve the physical quantity while removing them from the available pool under the approved inventory-state rule. Do not solve a status problem by altering the conversion factor.
Returns deserve the same discipline. Record the unit actually returned, convert it to base quantity and apply the correct status after inspection. A returned multipack missing one component is not automatically a complete sellable pack merely because the original order used that sales unit.
For fixed commercial bundles, use the bundle and kit component availability method. A bundle recipe combines sellable SKUs; it is different from converting one product's case or pack into its base unit.
Reconcile one cutoff and investigate differences
After testing, compare the same SKU, conversion version, base unit, location scope and timestamp across the 3PL/WMS, ERP and ecommerce channel. The 3PL, ERP and ecommerce inventory reconciliation guide provides the wider cutoff and status bridge.
For UOM-specific differences, work backwards through the event chain. Check whether a purchase unit was interpreted as the inventory unit, whether a case break created a duplicate movement, whether a sales pack used the wrong factor, or whether a partial receipt was closed as whole cases.
Preserve the original message, factor version and read-back before correcting a live quantity, then investigate and test the correction. If the mismatch affects historical financial values, regulatory declarations or customer claims, route that separate issue to the appropriate competent owner; this operational quantity workflow does not decide it.
Release the mapping with explicit ownership
Release only when the conversion register, identifiers, effective dates and end-to-end transaction tests agree. Keep one owner for the cross-system relationship even if procurement, packaging, warehouse and ecommerce teams each maintain part of the source data.
The release record should answer four questions:
- Which product revision and pack configuration is approved?
- Which direct factors and identifiers are active on the effective date?
- Which transaction paths passed, with what exact read-backs?
- Who stops or replaces the mapping when supplier or packaging evidence changes?
That record turns case, pack and each from informal labels into controlled quantities. It also gives the team a clear failure point: if a system cannot preserve the unit and factor through a transaction, hold the mapping before the error reaches live inventory.
Sources
.png)
