A supplier ships ten cases. The warehouse receives ten. The ecommerce connector publishes ten available units. Every system can appear internally consistent while the storefront understates stock by a factor of twelve. The missing information is what the quantity represents at each handoff.
EcomToolkit’s approach is to make the unit part of every quantity definition. This article explains how to reconcile purchasing, inventory, storefront sales, and returns when a product moves between cases, packs, and individual items. All quantities and costs are original illustrative examples. The method concerns data and operating controls, rather than a claim about any merchant’s actual stock losses.
Table of Contents
- Define the base unit and selling unit
- Write a conversion contract
- Reconcile a worked inventory ledger
- Measure conversion exceptions
- Handle changing packs and partial returns
- Test the platform handoffs
- Questions about unit analytics
- EcomToolkit point of view
Define the base unit and selling unit
Choose a base unit for stock accounting, such as one bottle. Purchasing may use a case of twelve bottles, while the storefront sells a pack of three. Those are legitimate differences if each system preserves the relationship. A quantity field without its unit is incomplete operational data.
Odoo’s units of measure documentation describes buying in larger packs and selling individual units, with conversion between the relevant measures. The implementation details vary by system. Confirm the capabilities and configuration of the actual ERP, warehouse tool, storefront, and connector in use.
Distinguish a unit conversion from a bundle recipe. A three-pack of identical bottles has a simple quantity relationship to the base item. A gift box containing a bottle, a glass, and a card needs a component model. The bundle and kit inventory guide covers that different problem.
Also distinguish the physical shipping box from the sellable product pack. A carton may contain several different products and exist only for transport. Its count should not automatically become a sellable-unit quantity. Use explicit names such as bottle, three-pack, supplier case, and shipping carton.

Write a conversion contract
For each product relationship, record the source SKU, source unit, destination SKU, destination unit, factor, rounding rule, and effective date. The contract should state whether the factor means base units per source unit or its inverse. A field named conversion rate is too ambiguous on its own.
| Business quantity | Source unit | Base units per source unit | Example conversion |
|---|---|---|---|
| Supplier receipt | Case | 12 bottles | 10 cases become 120 bottles |
| Storefront sale | Three-pack | 3 bottles | 8 packs consume 24 bottles |
| Individual sale | Bottle | 1 bottle | 5 sales consume 5 bottles |
| Approved restock | Bottle | 1 bottle | 2 inspected returns add 2 bottles |
Keep the conversion factor product-specific when packaging varies. A case of twelve small bottles and a case of six large bottles share a word, not a quantity. The SKU or product relationship must disambiguate them. A global “case equals twelve” rule is an avoidable source of stock errors.
Declare precision separately for quantities and money. An indivisible bottle should not become 0.33 sellable units because an integration divided stock by a three-pack factor. If 10 bottles are available and only three-packs are sold, at most three complete packs are available before other reservation rules. The remaining bottle stays in base-unit inventory.
For measured goods such as fabric, fractional quantities may be valid. Use the product’s actual measurement and rounding policy rather than copying the bottle example. Do not convert between incompatible dimensions without a defined product relationship; kilograms and individual items are not interchangeable merely because both are numeric fields.
Reconcile a worked inventory ledger
Start with zero bottles in this simplified example. Receive ten cases containing twelve bottles each. Sell eight three-packs and five individual bottles. Then return two inspected, resellable individual bottles to available stock. Ignore reservations and other stock states temporarily so the unit arithmetic is clear.
| Ledger movement | Source quantity | Base-unit change | Running bottle balance |
|---|---|---|---|
| Opening balance | Zero bottles | 0 | 0 |
| Receipt | 10 cases of 12 | +120 | 120 |
| Pack sales | 8 packs of 3 | −24 | 96 |
| Individual sales | 5 bottles | −5 | 91 |
| Approved restock | 2 bottles | +2 | 93 |
The ending balance is 93 bottles. If the entire balance is eligible for sale and there are no reservations, it can support 31 complete three-packs. In a real store, subtract commitments and other unavailable states before publishing availability. A correct on-hand balance is not automatically a correct sellable balance.
Now imagine the receipt connector records ten bottles instead of ten cases. The incoming balance is understated by 110 bottles. Subsequent sales may trigger apparent shortages even though the physical inventory exists. Correcting the available-stock number manually treats the symptom; repairing the receipt mapping prevents repetition.
Cost calculations need the same discipline. An illustrative case cost of 36 implies a base cost of 3 per bottle, excluding additional costs. A three-pack consumes base product cost of 9. Using the case cost as the per-bottle cost would distort margin even if inventory quantities were fixed. Keep the cost basis visible in profitability analysis.
Measure conversion exceptions
Track the share of eligible quantity movements with a valid unit mapping, using movement lines as the denominator. Also calculate the share of base-unit volume and value affected by unresolved mappings. One incorrect high-volume receipt can matter more than dozens of harmless low-volume records.
Maintain separate exception categories: missing unit, unknown factor, inconsistent SKU relationship, invalid fractional quantity, and expired mapping version. Assign each category to the team able to fix the cause. A missing supplier case definition may belong to purchasing; an inverted factor in an API transformation belongs to integration ownership.
Reconciliation residual is opening base stock plus receipts and approved returns, minus consumption and other departures, minus closing base stock. A nonzero residual identifies a difference to explain. It does not prove theft or shrinkage. Check timing, pending transactions, duplicate messages, and stock-state definitions before assigning a loss reason.
The inventory shrinkage guide becomes relevant after measurement and movement explanations are resolved. Unit errors should not be buried inside a shrinkage adjustment, because doing so makes the same faulty integration appear operationally normal.

Handle changing packs and partial returns
Suppose a supplier changes a case from twelve bottles to ten. A historical receipt of ten cases still represents 120 bottles if it used the earlier packaging. Applying today’s factor to every old transaction would rewrite history. Store the factor used on the movement or preserve an effective-dated relationship that reproduces it.
Use a new packaging identifier where possible and record the change explicitly. Purchasing, receiving, catalog operations, and finance should agree on the effective boundary. Old and new cases can coexist in the warehouse, so a date alone may be insufficient without lot, barcode, or packaging evidence.
Partial returns require a separate inspection decision. A returned three-pack with one damaged bottle should not automatically add three sellable bottles. Record what physically returned, what passed inspection, and what remains unavailable. The refund amount and restock quantity describe different events and must not be forced into a one-to-one relationship.
Odoo’s packaging documentation illustrates packaging as a grouping of product units. When evaluating another platform, ask how it represents that relationship and whether the connector preserves it through receipts, sales, and returns. A packaging label on a product screen is not proof of end-to-end conversion behavior.
Test the platform handoffs
Build a small acceptance set with one ordinary receipt, one pack sale, one individual sale, one partial return, and one packaging change. Use isolated test records and verify the resulting quantities in each participating system. Compare the transmitted payload with the displayed balance so a UI formatting issue is not confused with a transformation error.
Add duplicate delivery of the same integration message to the test. A correct factor applied twice still creates incorrect stock. Preserve a stable movement identifier and inspect the receiving system’s duplicate handling. Test an unknown unit too: the integration should surface an actionable exception rather than silently assume individual items.
Confirm outbound stock publishing. With a base balance of ten bottles, a three-pack listing should receive the appropriate whole-pack availability after reservations. A single-item listing drawing from the same stock requires shared allocation; publishing both independent quantities without reservation logic can oversell the common pool.
After release, reconcile the first production movements and retain their mapping versions. Review the exception queue daily until the new relationship is stable. Thereafter, include supplier packaging changes and connector releases in the control process rather than relying on a one-time spreadsheet cleanup.
Questions about unit analytics
Should every product use each as its base unit? No. Use the measure appropriate to the product and system, including valid fractional measures where needed.
Is a pack always a separate SKU? That depends on the catalog and inventory design. The relationship still needs an explicit definition.
Can correcting a stock balance finish the repair? Only after the underlying mapping and affected movement history have been reconciled.
Does a refund imply stock should increase? No. Restocking depends on physical return and condition, not the refund event alone.
EcomToolkit point of view
Quantity becomes trustworthy when its unit survives every handoff. Preserve the conversion used, reconcile in a common base measure, and make exceptions visible before they become availability or margin decisions. For help reviewing those connections, request an ecommerce operations audit.