Order minimums and MOQs in a B2B ordering portal: how NZ distributors enforce them

Order minimums exist for a reason. Small orders that cost as much to pick and dispatch as the margin they generate erode the economics of wholesale distribution. Per-SKU minimum quantities reflect how product is packed and handled — you can't split a case of twelve into a single unit and still make the logistics work. When a food distributor or wholesaler launches a B2B ordering portal, those rules need to transfer into the self-service environment — and they need to come from the right place.

The mistake that creates problems is treating order minimums as a portal configuration task rather than an integration question. When minimum rules are entered manually in the portal, they drift out of sync with the ERP. When they're applied at the wrong level — site-wide rather than per customer or per product — they either block legitimate orders or let unprofitable ones through. Getting it right requires understanding the difference between minimum order value, per-SKU minimum quantity, and the rep override case, and designing where each rule lives before the portal goes live.

Two different problems, one shared name

"Order minimums" in wholesale covers two distinct rules that are often conflated:

• Minimum order value. A threshold on the total value of the order — commonly expressed as a dollar amount before GST. Orders below the threshold cost more to service than they're worth. The minimum order value is typically a policy applied at the customer account level or customer group level: large accounts with high order frequency may have no minimum; smaller accounts on lower-margin price levels may face a $200 or $300 minimum. It's an economic boundary, not a product specification.
• Minimum order quantity (MOQ) per SKU. A threshold on how many units of a specific product must be ordered when that product is included in an order. This usually reflects how the product is packed — inner pack sizes, minimum case quantities, or catch-weight minimums where a product must meet a minimum weight at dispatch. The MOQ is a product attribute, not an order-level rule, and in most ERPs it lives on the item master record.

Both can coexist in the same portal — and for many NZ food distributors and wholesalers, both are active simultaneously. Designing them correctly means treating them as separate rule layers with separate data sources and separate enforcement points in the checkout flow.

Per-SKU minimum quantities: where the rules live

Minimum order quantities per product are a product attribute. They reflect physical packaging constraints — a product sold in inners of six cannot sensibly be ordered in quantities of one or two, because the inner pack is the base unit of handling. In your ERP's item master, each product typically has fields for minimum order quantity, inner pack size, or both. These fields may also feed into ordering UOM conversions — the customer orders in cases, and the minimum of one case corresponds to whatever the inner pack specifies.

In a well-designed portal integration, these values are sourced directly from the ERP item master. When the integration pulls the product catalogue for the portal, it brings the minimum order quantity along with the product name, description, pricing, and stock status. The portal uses the ERP's minimum quantity as the floor for the quantity selector on that product listing: a customer cannot enter a quantity below the minimum, or if they do, the portal immediately corrects to the minimum and explains why.

The alternative — configuring minimum quantities manually in the portal — is the source of ongoing maintenance problems. When your product team updates an inner pack specification in the ERP, the portal doesn't know. The portal continues enforcing the old minimum. A customer places an order for a quantity that no longer matches the packaging. The warehouse has to handle the exception. Multiply that across a product catalogue that changes regularly and the overhead compounds.

Minimum order value: customer-level rules

Minimum order values per transaction are typically a customer relationship policy, not a product specification. They vary by account type, price level, or delivery route. Some distributors apply different minimums to different geographic routes — a long regional run requires a higher minimum to be economically viable than a local metro delivery. Others apply minimums by customer group: all accounts on the foodservice price level face a $250 minimum; hospitality chains with guaranteed weekly volumes have no minimum.

These rules can be held in the ERP's customer or debtor master — particularly if your ERP already uses minimum order values to govern sales order creation. In that case, the portal integration should read the minimum from the customer record and enforce it at checkout, just as the ERP would enforce it on a manually entered order. If the ERP doesn't carry customer-level order minimums, they can be configured in the portal against customer groups or customer segments, but the design principle still applies: the rule should live in one place, and the portal should reference it, not duplicate it.

A practical point for food distributors: minimum order value enforcement needs to account for how your delivery routes work. If a customer's delivery day is Tuesday and they place an order Sunday night that's below the minimum, it's better for the portal to surface that before checkout — giving them a chance to add to the order — than to accept the order and have your operations team reject it on Monday morning.

The rep override and exception case

In a rep-driven sales environment, order minimums are not always absolute. A long-standing customer who's had a bad week might place a small order. A rep knows that relationship justifies the exception. In the phone and email ordering model, the rep applies their judgment and the order goes through.

In a portal environment, reps aren't present at the moment of ordering. The portal needs a mechanism for handling legitimate exceptions without undermining the minimum enforcement that applies to the general customer base. There are two common approaches:

• Rep-override flag on the customer account. Certain accounts are marked in the ERP or portal as exempt from the minimum — either permanently (a key account with a genuine exception) or temporarily (a flag the rep sets that expires after a defined period). The portal reads the flag and skips the minimum check for that session or that account.
• Pending approval workflow. Sub-minimum orders are accepted by the portal but placed in a pending state, flagged for a sales rep or sales manager to approve before they're sent to the ERP for processing. The customer is told their order is pending approval. The rep sees the flagged order in their queue and approves or contacts the customer to top up. This gives the business visibility into how often exceptions occur and who is making them.

Both approaches are legitimate. The choice depends on how tightly the business needs to control exceptions and how much manual review your operations team has capacity for. What doesn't work is a binary hard block with no exception path — it frustrates good customers and forces them back to the phone or email channel that the portal was meant to replace.

Enforcement in the checkout flow

Minimum order rules enforce at different points in the checkout flow, and the timing matters for the customer experience:

• Per-SKU minimums enforce as items are added to the cart. The quantity selector on the product page doesn't allow a quantity below the minimum. If the customer types a quantity below the minimum, the portal corrects to the minimum immediately and displays the reason: "This product is sold in packs of 6." Enforcing this at the line level — rather than at checkout — avoids the frustration of building a large order and then being blocked at the final step.
• Minimum order value enforces at checkout. The portal evaluates the cart total against the customer's applicable minimum before allowing checkout to proceed. The most useful implementations show the customer how far they are from the minimum — "your order total is $195, minimum is $250 — add $55 to continue" — rather than just blocking with a generic error. Some portals surface this as an ongoing indicator in the cart so customers can see their progress toward the minimum as they add items.

What breaks without a designed-in approach

The failure modes that appear when order minimums are treated as an afterthought are consistent:

• Minimums maintained manually in the portal drift from the ERP. An item's inner pack changes from 6 to 12. The ERP item master is updated. The portal still shows 6. Sub-minimum orders come through at the wrong quantity. The warehouse exception rate increases.
• A single site-wide minimum doesn't fit the account base. A $250 minimum blocks a genuine high-value key account from placing a legitimate low-value top-up order. Or a $50 minimum that was set to avoid blocking anyone lets genuinely uneconomical small orders through from lower-tier accounts. One-size rules don't match a wholesale account structure with meaningful variation across customer relationships.
• No exception path forces customers back offline. A hard block with no override or pending-approval mechanism tells the customer to call or email. One call isn't a problem. A pattern of calls because the portal can't handle normal account relationship exceptions defeats the purpose of the portal.
• Minimum order value is checked at submission, not earlier. A customer builds an order, fills in delivery details, reviews the order, and submits — and then gets blocked. The minimum was never surfaced during the cart-building phase. They abandon the order rather than add more items, because the checkout page doesn't make it easy to go back and add.

For more detail on how other ordering rules are configured in a wholesale portal, the customer-specific pricing guide covers the ERP pricing hierarchy in the same context, and the credit limit management guide covers the AR integration that runs alongside order enforcement. The delivery scheduling guide explains how per-route and per-customer delivery rules connect to the order placement flow.

If you're scoping a B2B ordering portal and want to understand how your ERP's item-level and customer-level minimum rules would transfer into the portal, talk to the Zeabyte team. We build and operate the Provender B2B ordering platform, which handles per-SKU minimum quantities, minimum order value enforcement, and customer-level exceptions — sourced from Accredo, MYOB, and more than 25 accounting and ERP systems. Order minimum design is part of the scoping process before build starts.