Direct answer: in B2B ecommerce, minimum order quantity (MOQ), order increment and unit of measure must be resolved as one commercial rule. The buyer needs to know which unit they are selecting, how many base units it contains, the minimum permitted quantity and the valid steps above that minimum. The ERP must receive an unambiguous quantity and unit, not a number interpreted differently by each system.
A correct setup can sell a valve by each, case of six or pallet of 120, require a two-case minimum for one account, and hold inventory in eaches. The portal displays two cases, calculates 12 base units, applies the case price and sends both quantities to ERP with the conversion used.
Separate five different concepts
- Base unit: the smallest unit used for inventory or physical quantity, such as each, kilogram or metre.
- Selling unit: the presentation available to the buyer: each, case, roll, drum or pallet.
- Conversion factor: the relationship between selling and base units for a SKU or variant.
- MOQ: the first acceptable quantity in a named unit.
- Increment: the valid step above the minimum.
“MOQ = 10” is incomplete. It must say ten eaches, cases or kilograms and include scope and validity. A usable rule reads: “For account ACME, SKU VAL-80 sells from two cases in one-case increments; one case equals six eaches; effective from 1 October.”
Minimum data model
| Field | Example | Purpose |
|---|---|---|
| product_variant_id | VAL-80-BRASS | Conversion can differ by variant |
| selling_uom | CASE | Unit entered and seen by the buyer |
| base_uom | EA | Inventory or reference unit |
| conversion_factor | 6 EA/CASE | Provides an exact conversion |
| minimum | 2 CASE | First purchasable quantity |
| increment | 1 CASE | Valid sequence: 2, 3, 4… |
| maximum | 40 CASE | Optional commercial or logistics limit |
| scope | ACME / BCN warehouse | Defines who and where the rule applies to |
| valid_from / valid_to | 1 Oct–31 Dec | Prevents expired or overlapping rules |
Store conversions as exact ratios where possible, not rounded decimals. A case of six is 6/1; a 12.5-metre roll can be 25/2. Attach the conversion to the product or variant when packaging differs. An XL variant may fit four items per case while other sizes fit five; Microsoft Dynamics 365 documents this exact per-variant conversion pattern.
Define rule precedence
MOQ and increments can vary by product, account, catalogue, market, warehouse, channel or period. When rules overlap, use an explicit order such as:
- Account + variant + unit + warehouse.
- Account group + variant + unit + market.
- B2B catalogue + variant + unit.
- Variant-wide logistics rule.
- Product-wide default.
Select one winning rule or document how constraints combine. If a contract requires two cases but the warehouse handles complete layers of eight, choosing the lower value is wrong. The stricter constraint may make eight the first valid quantity, but that policy must be approved by the business.
Validate the sequence correctly
For requested quantity q, minimum m and increment i, a line is valid when q >= m, does not exceed any maximum, and (q - m) mod i = 0.
First normalise all values to the same unit and exact integers. For 0.25 kg steps, work in grams or scale by 100. Do not calculate remainders directly on binary decimals: precision error can reject a valid order. With a minimum of six and increment of four, valid quantities are 6, 10, 14 and 18—not every multiple of four.
Validate in the selected unit and repeat the check on the server and at checkout. Browser controls are only an aid; APIs, CSV order entry, saved lists and reorders can bypass the interface.
Conversion, rounding and variable quantity
Never round silently. If the buyer asks for 2.5 kg but the warehouse handles one-kilogram bags, decide whether to reject it, propose 3 kg or offer another unit. The rounding policy—up, down or nearest—belongs to the conversion and must be visible before the line enters the basket.
For catch weight or cut length, keep requested, fulfilled and invoiced quantities separate. A customer can request 10 kg and receive 10.34 kg; the portal should state the tolerance, estimated charge and point at which the final amount becomes known.
Price and stock need compatible units
Every price has a unit. EUR 12 per each does not automatically mean EUR 72 per case where packaging attracts a discount or charge. Retain price unit and price quantity, order unit, conversion factor, displayed unit price, line total and the unit used to evaluate volume tiers.
Inventory must be equally clear. With 35 eaches available and sealed cases of six, only five cases are sellable; the five remaining eaches do not create a sixth case. If warehouses use different packs, resolve availability after sourcing or show an explicit split.
Prevent errors in the buyer experience
Show “Minimum: 2 cases · Increments: 1 case · 6 eaches per case” beside the quantity control. Changing unit must recalculate minimum, increment, price, availability and delivery. Keep the selected unit in the basket and show its base-unit equivalent.
Do not silently replace invalid input. Explain: “Sold from two complete cases. Suggested quantity: three cases (18 eaches).” Ask for confirmation if the change affects value, weight, freight or lead time. For quick order and CSV, return a line-level error containing the received value, applicable rule and nearest valid quantities.
Portal-to-ERP contract
Each order line should send SKU and variant, requested quantity and selling unit, base quantity and conversion, MOQ/increment rule ID and version, price and price unit, currency, and warehouse where it affects the rule.
ERP must validate again. If it rejects a line, the portal must not change the quantity or create an order different from the buyer’s confirmation. Return an actionable state: accept new packaging, change warehouse, request a quote or ask sales to intervene.
Import and reconciliation
Before activating a rule version, reject zero or negative conversion factors, unknown units, negative minimums, non-positive increments, maxima below minima, overlapping periods and unknown variants. Compare a deterministic sample between ERP and commerce and count received, accepted and rejected records.
Do not overwrite the version used for historical orders. Publish a new effective-dated version and store the resolved rule on every line, so a packaging change cannot rewrite the explanation of an old invoice.
Essential test cases
- Values below, equal to and above MOQ.
- First valid increment and values immediately either side.
- Each, case and pallet changes with exact conversion.
- A variant with a different case quantity.
- Account-specific rule versus the general rule.
- Inventory not divisible by the selling pack.
- Warehouse, market, currency and effective-date changes.
- Product page, basket, list, CSV, API and reorder entry.
- Matching unit price and total in portal, ERP and invoice.
- Missing rule, invalid conversion and overlapping versions.
Frequently asked questions
Are MOQ and order increment the same?
No. MOQ defines the first acceptable quantity; increment defines subsequent steps. A minimum of six with an increment of two allows 6, 8, 10 and 12.
Should customers select eaches or cases?
Offer only genuinely sellable units and show their equivalence. Do not offer loose items from a sealed case merely because inventory is held internally in eaches.
Which system owns the conversion?
Usually ERP or PIM, with one named owner. Commerce consumes a published version and must not invent a factor when data is missing.
Can the portal round automatically?
Only under a visible, authorised policy. If value or logistics changes, display the proposed quantity and ask for confirmation.
Primary documentation
- Shopify: B2B quantity rules and volume pricing, covering variant minimums, maxima and increments.
- Microsoft Dynamics 365: unit conversion per product variant, covering pack factors that differ by variant.
- Microsoft Dynamics 365: manage units of measure, covering conversion, precision and rounding.
- Microsoft Dynamics 365: unit-of-measure stocking policies, covering logistics layers.
Next step
Select ten SKUs with different packaging and document base unit, sellable units, factor, MOQ, increment, stock and price. Then prove that portal and ERP accept and reject exactly the same quantities. For further functional design guidance, explore the CODE B2B resources.