To prevent carton and piece conversion errors in distributor orders, treat units per carton as versioned master data, not a fixed constant. Store the conversion on each SKU with effective dates, record which version was used when the order was confirmed, verify the arithmetic before the warehouse picks, and route every mismatch to a named exception queue with a reason code. The relationship between a base unit, an order unit and a carton changes by SKU, packaging version and date.
Why order unit conversion goes wrong in distributor orders
Most errors of this type are not keying mistakes. They are data-governance failures that surface at order entry:
- The order is captured in cartons while stock, pricing and allocation live in pieces, and the two records are maintained by different teams.
- A supplier repacks a SKU — for example from 24 per carton to 12 — and one distributor price list or order template is updated before the other.
- A display or shipper pack contains more than one SKU, so no single units-per-carton figure describes it.
- Loose or partial cartons are rounded differently by the buyer and the warehouse.
- Conversion sits in a spreadsheet with no version history, so nobody can state which figure applied on a given date.
The result is a quantity that is arithmetically valid but commercially wrong: short shipments, credit notes, or a stock record that no longer matches the physical count. Related failure patterns are covered in Order Errors in Distribution: Reduce Them Before Fulfillment.
The unit data every SKU record should carry
Conversion is a data field, not a mental calculation. Each SKU needs an explicit hierarchy that any order, stock or pricing process can read from one source.
| Field | What it holds | Why it matters at order time |
|---|---|---|
| Base unit | The smallest unit you count, price or allocate — for example one bottle | Gives stock, orders and claims a common denominator |
| Order unit | What the buyer actually keys, for example carton, shipper or display | Prevents cartons being silently treated as pieces |
| Units per order unit | Pieces contained in one order unit, for this SKU and this version | The multiplier in every conversion calculation |
| Unit hierarchy | Any intermediate level, such as inner pack or layer | Explains partial or split quantities |
| Mixed pack composition | Component SKUs and their quantities inside one shipper | Stops a mixed pack being booked as units of a single SKU |
| Packaging version and effective dates | Version identifier with valid-from and valid-to dates | Lets you re-derive historic orders after a repack |
| Price basis | Whether the price list is per piece, per carton or both | Catches quantity that is right but value that is wrong |
| Data owner | The role accountable for the record and its changes | Answers the question of who fixes a disputed conversion |
Worked example: one hypothetical SKU across a packaging change
Hypothetical example. A brand sells Demo Choco Drink 320 ml. The base unit is one bottle (piece) and the order unit is one carton. In packaging version A, one carton holds 24 pieces and applies to orders dated up to 28 February. From 1 March, version B applies with 12 pieces per carton. The same portfolio also ships a single display shipper containing eight original bottles and four less-sugar bottles.
| Order line | Conversion used | Arithmetic | Base units |
|---|---|---|---|
| 5 cartons, ordered 20 February | Version A, 24 per carton | 5 × 24 | 120 pieces |
| 5 cartons, ordered 5 March | Version B, 12 per carton | 5 × 12 | 60 pieces |
| 1 display shipper, ordered 5 March | Mixed pack, no single multiplier | 8 original + 4 less-sugar | 12 pieces across two SKUs |
Three lessons follow. First, the text 5 cartons means different volumes before and after a repack, so the order record must store which conversion was applied and when. Second, a February order delivered in March needs an explicit rule — keep the conversion valid at confirmation, or re-confirm with the buyer before picking; never re-convert silently. Third, the display shipper is not one SKU: it expands into component quantities, and stock, pricing and claims should treat those components separately.
Who owns unit master data, and how a change is approved
Assign one accountable owner, commonly channel operations with input from supply chain and pricing, and run a written change process:
- The change request names the SKU, the old and new units per order unit, the production or repack date, and the first delivery date affected.
- Effective dates follow the physical cut-over, not the date someone edited a file.
- List every downstream artefact: order templates, distributor price lists, promotion mechanics, shelf communication, stock on hand.
- Publish the new version and obtain written acknowledgement from distributors before the cut-over date.
- Retire the old version but keep it for audit, so past orders can be reconstructed.
Where possible, freeze structural unit changes during a live promotion. If a change cannot wait, apply the same version discipline to the promotion itself, as described in Version Control for Changes to a Live Trade Promotion.
Order confirmation and exception checks before fulfillment
Run these checks on every order line between confirmation and picking:
- Requested quantity × units per order unit equals base units, and the base-unit figure is what the buyer expects to receive.
- The conversion used is the one valid for the requested delivery date; if it differs from the version at confirmation, flag the line.
- Mixed packs are expanded into component SKUs, each checked against stock separately.
- Partial cartons are accepted or rejected by a stated rule, not by whoever keys the order.
- Stock availability is expressed in the same base unit used in the conversion.
- Any variance above an agreed tolerance enters an exception queue with a reason code, a named owner and a hold on fulfillment until the buyer confirms in writing.
Amendments after confirmation need the same treatment, because changing quantity or delivery date can move an order across a version boundary; see Order Changes After Confirmation: Manage Distributor Amendments.
Where Airpalm fits in a conversion-control process
Airpalm’s public site describes mobile visits, route planning, store audits, sales orders, inventory and promotion management (airpalm.com, checked 9 October 2026). Unit hierarchy, effective-dated conversion and mixed-pack handling are configuration and scope questions rather than headline features. Ask for them to be demonstrated on your own SKU data and written into the scope document, together with supported order types, inventory boundaries, pricing rules and access controls. The evaluation questions in Order Management in a Distributor Management System (DMS) are a useful starting point, and the vendor overview sits at airpalm.com.
Next step: choose one SKU that has been repacked in the last two years, write down its full unit hierarchy for both versions, and use that record as the test case in your next order-process review or system demonstration.
Frequently asked questions (FAQ)
Should distributor stock be held in cartons or in pieces?
As a working convention, hold stock, pricing and allocation in the smallest base unit you actually sell or count, and let the order unit be a presentation of that base unit. The important control is consistency: one convention, documented per SKU, with every order and stock record referring to it. Whatever convention you choose, confirm how your specific systems store and display each level before you rely on it.
What should happen when a SKU is repacked in the middle of a promotion?
Create a new packaging version with a valid-from date tied to the physical cut-over, keep the old version for history, and review open orders that span the change. Open orders should either keep the conversion valid at confirmation or be re-confirmed with the buyer in writing. Re-converting confirmed orders without notification is what produces short shipments and credit-note disputes.
Who should own units-per-carton data?
Give one role accountability — typically channel operations, with supply chain and pricing consulted — and require distributors to acknowledge each new version before it goes live. Shared ownership across sales, supply chain and distributors is the usual reason a repack is applied in one place and missed in another.
Can a distributor management system convert cartons to pieces automatically?
Do not assume it. Airpalm’s public site describes sales orders and inventory management, but conversion behaviour depends on configuration, unit hierarchies and the order types in scope. Ask for carton-to-piece calculation, mixed-pack expansion, effective-dated versions and partial-carton rules to be demonstrated with your own SKU data, and record the agreed behaviour in the scope document.
Put this guide into practice
This general-purpose worksheet is a starting point. Adapt its fields, responsibilities and rules to your business process.




