If you run a distribution business, “matrix pricing” and “multiplier pricing” are not jargon – they are how you actually price. A customer at price level 3 gets list times a multiplier; a contract account gets a negotiated number; quantities trigger breaks; some SKUs are cost-plus. It works fine on the counter and in the ERP. Then someone asks to put it online, and the pricing that felt normal for decades becomes the hardest part of the whole project.
This guide explains how distributor pricing really works – multipliers, price columns, cost-plus, matrices, quantity breaks – and, more importantly, how to put it on a storefront or B2B customer portal so the web price matches the counter price to the penny. We build exactly this for manufacturers and distributors on Shopware and Adobe Commerce.
One disambiguation first. “Matrix pricing” also has a finance meaning – estimating a bond’s value from comparable instruments. That is not this. This is the distribution/ERP sense: the rules table that decides a customer’s price. If you found this looking for the CFA concept, you want a finance resource instead.
The building blocks: multipliers, columns, and cost-plus
Distributor pricing is assembled from a handful of mechanisms that predate ecommerce and are not going anywhere:
- Price levels / columns. Customers are assigned a level (often 1-5 or A-D). Each level maps to a discount off list or a multiplier. “Level 2 gets list times 0.85.” Simple to state, and the backbone of most distribution pricing.
- Multipliers. The factor applied to a base. Off list (list x 0.75) or on cost (cost x 1.30, i.e. cost-plus). Multipliers frequently vary by product group, so one customer can be list-minus on hardware and cost-plus on specialty items simultaneously.
- Cost-plus pricing. Common for volatile or made-to-order goods: price floats with cost so margin is protected. This means the web price has to move when cost moves – a sync requirement, not a static number.
- Quantity breaks. Buy more, pay less per unit, in tiers. Tiers can be per price level and per product, which multiplies the combinations quickly.
- Contract / negotiated pricing. Specific prices for specific customers on specific items, often with their own effective dates and sometimes per ship-to. These override everything else.
None of these is exotic. The difficulty is that a real distributor runs all of them at once, and the storefront has to resolve the right one for every customer-product-quantity combination, the same way the ERP does.
The matrix: how the right price gets chosen
“Matrix pricing” is the table of rules that decides which of the mechanisms above wins. Think of it as a precedence engine. For a given customer and product, it walks the rules in order and returns the first (or best) match:
| Precedence | Rule type | Example |
|---|---|---|
| 1 (highest) | Customer-specific contract | This account, this SKU: $12.40 through year-end |
| 2 | Quantity break | 25+ units at level 2: list x 0.78 |
| 3 | Product-group multiplier | This account, hardware group: list x 0.85 |
| 4 | Price level / column | Level 2 default: list x 0.88 |
| 5 (lowest) | List / base | Published list price |
The exact order varies by business and by ERP, but the principle is universal: pricing is resolved by precedence, not by a single lookup. Get the precedence wrong online and a customer sees a quantity-break price where they should see their better contract price – or worse, a price below their contract that you now have to honor.
Why this breaks on a storefront (the parity problem)
Most ecommerce platforms were built for retail: one product, one price, maybe a sale price. B2B distribution pricing is customer-resolved and rules-driven, and that mismatch produces the failure we are called in to fix most often – price parity. The web price must equal the price the same customer would get from a rep or the counter. When it does not:
- Your best accounts stop trusting the site and go back to calling – so the portal that was supposed to reduce order-entry load increases it, because now every web price gets verified by phone.
- If the web price is too low, you either eat the margin or have an awkward conversation. Too high, and the customer feels punished for self-service.
- Finance finds the discrepancies at reconciliation, and the project’s credibility takes the hit.
Parity is not a nice-to-have. For a distributor it is the whole ballgame, and it is a pricing-architecture problem, not a storefront-design problem.
Where the price should live: the ERP owns it
The durable answer is that pricing is ERP-owned and storefront-displayed. Your ERP already holds the price levels, customer assignments, product-group multipliers, quantity breaks, and contracts – and it is the system your counter quotes from. The storefront should resolve price from those rules, never maintain a second price list by hand. The same data-ownership discipline we describe in our ecommerce ERP integration guide applies here with unusual force, because pricing is the object customers check most closely.
We covered the mechanics of syncing account-specific pricing in depth in our guide to customer portals with account-specific pricing; this section is the short version of getting it right.
Putting matrix and multiplier pricing online without drift
Three patterns work, and most distributors end up with a blend:
- Real-time price resolution. The storefront calls the ERP (or a pricing service in front of it) to resolve the logged-in customer’s price at page or cart load. Most accurate, but it puts the ERP in the request path, so it needs caching and a fallback for when the ERP is busy or in a maintenance window.
- Synced resolved prices. A job resolves each customer’s prices and pushes them to the storefront on a schedule, with an event-driven refresh when a contract or cost changes. Fast for browsing; the risk is staleness, which you manage with short cycles for volatile items and immediate refresh on contract changes.
- Hybrid (the usual answer). Synced prices for fast browsing, a real-time revalidation at cart or checkout so the committed price is always correct, and event-driven refresh on changes. You get storefront performance and penny-accurate orders.
Whichever pattern, three rules are non-negotiable: reproduce the ERP’s precedence exactly, lock the quoted price onto the order so the invoice matches, and never let anyone maintain prices in two systems. For distributors whose pricing lives in a system like Epicor P21, NetSuite, or Dynamics, the resolution logic is specific to that ERP’s pricing model, which is why we scope pricing first on every distribution build.
Who we are
Web Solutions NYC builds B2B commerce for manufacturers and distributors, with pricing fidelity as the thing we scope before anything else. Across 50+ B2B implementations – anonymized examples in this guide include an MRO/industrial-supply distributor with dynamically calculated account pricing and a calibration/test-equipment distributor running an enforced multi-tier hierarchy – the pattern holds: get the pricing right and the rest of the portal follows. We are a Shopware Platinum Partner and an official Adobe Commerce partner, and we integrate pricing from NetSuite, SAP, Microsoft Dynamics, Acumatica, Sage, and Epicor P21.
Frequently asked questions
In distribution, matrix pricing is a rules table that resolves the price for a given customer and product from dimensions like customer class or price level, product group, quantity break, and effective dates – rather than a single list price. It is different from the finance meaning of matrix pricing (estimating a bond’s value from similar bonds); this guide covers the distribution sense used by wholesalers, manufacturers, and their ERPs.
Multiplier pricing sets a customer’s price by applying a factor to a base – list times 0.75, or cost times 1.30 (cost-plus) – often by customer and product group. Matrix pricing is the broader table of rules that decides which multiplier, column, or contract price wins for a given customer, product, and quantity. In practice distributors run both: multipliers inside a matrix, with contract overrides on top.
The ERP. It already holds the price levels, customer assignments, quantity breaks, and contract records, and it is the number your counter and reps quote. The storefront should resolve price from those rules – via real-time calls or a synced, rules-aware copy – not maintain a parallel price list that drifts. Dual maintenance is the single most common cause of a distributor’s web price not matching its quoted price.
Resolve the logged-in customer to their ERP price level and contracts, apply the same precedence the ERP uses (contract beats matrix beats list), and either call the ERP at cart/checkout for validation or sync resolved prices on a short cycle with an event-driven refresh when a contract changes. The order must lock the quoted price so the invoice matches to the penny.
Yes, and they must – it is normal distribution reality. The rule is precedence: a customer-specific contract price overrides a quantity-break price, which overrides a price-level multiplier, which overrides list. Reproduce that exact order of operations in the storefront, or customers will see a break price where they should see their negotiated one, and trust in the site erodes fast.
Pricing that won’t map cleanly to a storefront? That is the work we do. Bring us your price levels, multipliers, and contract rules, and we will tell you exactly how to put them online so the web price equals the quoted price. Let’s talk.