Customer-specific pricing in a B2B ordering portal: how it actually works for NZ distributors

In a rep-driven sales model, pricing is managed by people. Reps know which customers are on which rates. They know which accounts have individually negotiated prices on certain SKUs, which ones get volume breaks, and which promotions apply to which relationships. When a distributor moves that same customer base to a self-service B2B ordering portal, all of that knowledge has to be encoded into the integration. The portal doesn't have a rep's memory — it has whatever data the ERP provides it.

Customer-specific pricing is consistently the most technically complex part of a wholesale B2B portal integration. It is also the most commercially important: if a customer sees the wrong price at checkout, the trust problem is immediate. If every account sees the same price, the portal can't serve the customer relationships your reps have spent years building. Getting it right requires a clear model of where prices live, how they resolve, and how changes propagate.

Why a single trade price list doesn't work for NZ wholesale

Most NZ food distributors and wholesalers operate with multiple pricing layers simultaneously. A customer's actual price for a given SKU depends on several things:

• Price level. The broad tier the account sits in — effectively a named price list that applies to all customers in that group. Large hospitality chains get one rate; small café accounts get another. Most ERP systems call these price levels, price groups, or price classes depending on the platform. Each debtor record is assigned to one.
• Per-customer override. An individually negotiated rate for a specific SKU on a specific account that overrides whatever the price level says. A key account might have 20 or 200 such overrides, built up over years of rep negotiation. In Accredo, these are debtor specials. In MYOB Exo, customer pricing. Other ERPs use similar constructs.
• Quantity breaks. The per-unit price changes based on how many units the customer orders — 1–5 cases at one rate, 6–11 at another, 12 or more at a third. Common for high-volume lines in food distribution.
• Promotional pricing. Time-limited rates agreed for seasonal campaigns or supplier promotions, applied to specific SKUs for some or all accounts.

A generic e-commerce platform offers customer group pricing: all accounts in "Group A" get a 10% discount from RRP. That model works for straightforward retail scenarios. It does not replicate a wholesale distributor's pricing structure, where the operative price for any given account and SKU is the result of resolving a hierarchy of overrides, levels, and breaks.

Price levels: the base layer

Every debtor record in your ERP is assigned to a price level. This is the starting point for pricing in the portal: when a customer logs in, the portal retrieves their price level from the ERP's customer master and applies the corresponding price list to every product they browse. Two customers in different price levels see different catalogue prices.

For the majority of accounts, the price level is the entire pricing story. The integration syncs the price lists for each level from the ERP, maps each customer to their assigned level, and the portal displays the right price. Where this model works well is for accounts whose pricing is genuinely tier-based — they get level pricing and that's correct.

Where it breaks down is accounts with individual overrides on top of their tier.

Per-customer overrides: where the complexity lives

Per-customer, per-SKU pricing overrides are the defining challenge of wholesale portal pricing integration. A food wholesaler with 200 accounts might have a handful of key accounts, each with dozens of individually negotiated prices that override their assigned price level for those specific products.

Generic connector tools that sync a single price per SKU from the ERP miss this entirely. They sync the price level rate and stop there — so a customer who has a specifically negotiated override in your ERP sees the wrong price in the portal. The order is placed at the displayed rate. The invoice comes out at the correct rate. There's a discrepancy. Your accounts team has to resolve it.

A properly designed integration resolves the full pricing hierarchy for each customer and SKU: does this customer have an individual override for this product? If yes, use that rate. If not, what price level are they on? Apply that level's rate. If no price level is configured, apply the standard trade price — or flag the account for your pricing team's attention. That resolution logic must run correctly at the point of display and again at order confirmation.

Quantity breaks in the cart

Quantity break pricing — where the per-unit rate changes with order volume — needs to be visible to the customer as they build their order, not just at checkout. A buyer who knows they can get a better per-case rate by adding one more box should see that in the cart. The break thresholds and rates are held in your ERP's pricing configuration; the integration must sync the full break structure for each SKU, not just the single-unit price.

For food distributors, quantity breaks often apply differently per account: a key account might have negotiated better break thresholds than the standard tier. Those account-level breaks are part of the per-customer override structure — the same integration challenge, at one more level of specificity.

The ERP is the source of truth — not the portal

The architecture that makes customer-specific pricing manageable is simple in principle: the portal does not maintain its own pricing database. Prices are sourced from the ERP and kept in sync by the integration. Your pricing team manages rates in the ERP — the same place they've always managed them — and the portal reflects whatever the ERP holds.

This matters operationally. When a rep renegotiates a rate on Monday morning, the ERP is updated. The portal's integration picks up that change at the next sync cycle — typically within minutes to an hour during trading hours — and the customer sees the updated rate at their next session. Nobody has to update pricing in two places.

Most production deployments handle pricing in two layers: a regular sync pulls the full pricing dataset from the ERP at frequent intervals (for display across the catalogue), and a live verification runs at order confirmation against the current ERP rate. The live verification at confirmation is the safety net: it catches any discrepancy between the displayed price and what the ERP currently holds, before the order is committed. This matters most when a price change happens while a customer has items in their cart — they see one price browsing, but the portal confirms the current rate at checkout.

What goes wrong without a proper pricing integration

A few failure modes appear predictably when customer-specific pricing isn't handled correctly:

• Wrong price displayed, right price invoiced. The portal shows the price level rate because the integration doesn't carry per-customer overrides. The ERP generates the invoice at the correct override rate. The customer disputes the difference. Your accounts team has to resolve it manually — and the customer's trust in the portal's accuracy is damaged.
• New account with no configured pricing. A new customer is set up in the ERP but their price level isn't assigned yet, or the integration hasn't picked up the new record. The portal defaults to standard pricing — which may be significantly higher than the trade rate the customer expects. Their first portal order comes through at the wrong rate.
• Stale pricing after a rate change. A price list is updated in the ERP. The integration hasn't synced yet when the customer places an order. They order at the old rate. Depending on whether the new rate is higher or lower, the problem falls on the customer or on the distributor.
• Missing quantity breaks. The integration syncs a single price per SKU. Quantity breaks exist in the ERP but aren't carried through. Customers who should see a volume discount don't — and either don't order the volume they would have, or order at the wrong price and expect a credit.

Design decisions before go-live

The pricing integration requires a set of design decisions that should be resolved with your pricing team and your ERP vendor before the portal build starts. The key questions:

• Which ERP pricing fields need to be included in the integration — price levels, customer overrides, quantity breaks, promotional pricing?
• What is the correct resolution hierarchy when multiple pricing rules apply to the same customer and SKU?
• How frequently does the pricing sync run, and is a live verification at order confirmation required for your account relationships and trading volumes?
• What should the portal display when no price is configured for a customer — a default rate, a "contact us" message, or is the account blocked from ordering until pricing is set up?
• How are promotional prices shown to customers — as a line-through RRP with the promotional rate, as a standard price, or not surfaced at all?

These aren't configuration options that get set on day one — they're business decisions that shape the integration design. Getting them settled before build starts avoids expensive rework after go-live.

For more on what credit limit management looks like alongside pricing in a live wholesale portal, the credit limit management guide covers the AR integration that runs in parallel. For Accredo users evaluating how a portal integrates with their specific pricing setup, our Accredo ordering platform guide goes into the Accredo-specific pricing sync in detail.

If you're scoping a B2B ordering portal and want to understand how your ERP's pricing structure would map into the portal, talk to the Zeabyte team. We build and operate the Provender B2B ordering platform, which handles customer-specific pricing — price levels, per-customer overrides, quantity breaks — sourced from Accredo, MYOB, and more than 25 accounting and ERP systems. Pricing integration, including per-customer override resolution and live verification at checkout, is part of the standard implementation.