Matrix Pricing, Contract Pricing and Special Price Agreements: How ERPs Decide What a B2B Buyer Pays

Ask a distributor what a 3/4-inch ball valve costs and the honest answer is a question: for whom, how many, and when? The same valve carries a list price, a contractor price, a price for the national account that negotiated a contract last spring, a quantity-break price above fifty units, and a special price for one mechanical contractor's hospital job that the manufacturer authorized last week. None of those numbers is stored on the item. Every one of them is calculated by the ERP when someone asks. That single fact, that a B2B price is an output rather than a field, decides whether a storefront can be trusted, and it is the part most ecommerce projects get wrong.

Quick answer: In B2B distribution, the price a buyer pays is resolved by the ERP at the moment of the request, not read from the product. Contract pricing is a negotiated price for a specific customer over a defined period; matrix pricing resolves a price from the intersection of a customer grouping and a product grouping, usually with quantity breaks inside. A special price agreement is a narrower, typically supplier-authorized price for one customer or project. Each ERP evaluates these through its own hierarchy, most specific rule first, so the net price is the survivor of that evaluation. A storefront that stores an exported copy of those prices drifts out of agreement with the ERP within days; a storefront that asks the ERP for the net price for the logged-in account, and renders the answer, cannot drift, because nothing commercial exists in two places.

Three pricing terms, defined

Contract pricing is a price negotiated with a specific customer for specific items, usually with a start and end date. It is the commitment a sales team made to an account, and it outranks almost everything else in the price calculation because it is the most specific promise the business has made.

Matrix pricing is a price resolved from a grid: a customer dimension on one axis (the customer, or a customer price class) and a product dimension on the other (the item, or a product line or price class), with the cell holding a price, a discount off list, or a markup on cost. A price matrix lets a distributor price 40,000 items for 800 accounts without writing 32 million individual prices, which is why nearly every wholesale ERP has one.

A special price agreement (SPA) is the most specific rule of all: a price authorized for one customer, one project, or one set of items, often because a supplier agreed to support the deal with a lower cost. In electrical and industrial distribution an SPA commonly touches two ledgers at once, what the buyer pays and what the distributor claims back from the manufacturer, which is why getting it wrong costs twice.

The three are not competitors; they are layers. Most distributors run all of them at once, and the ERP's job is to decide which one wins for this buyer, this item, this quantity, today.

Every ERP resolves a price. None of them store it.

Underneath the different vocabularies, every serious ERP follows the same principle: evaluate the pricing rules from most specific to least specific, and the first rule that applies sets the price. A price for this customer and this item beats a price for this customer's group and this item's product line, which beats the list price. Quantity breaks apply inside whichever rule won, and date ranges decide whether a rule applies at all.

That is why "the price" does not exist until the question is asked. Change the account, the quantity, or the date and the same item resolves differently, correctly. An integration that pulls "the price" off the item record and pushes it to a storefront has captured one answer to a question with thousands of correct answers.

How five ERPs decide what a buyer pays

Epicor Prophet 21 holds customer-specific pricing, contract matrices, special price agreements, and break quantities, all with effective dates on top. A single item can resolve to many different net prices depending on who is asking, how much, under which agreement, and when, which is why on a P21 build contract pricing is the project rather than a line item in it.

Infor SX.e documents its matrix pricing through numbered price types rather than the informal names the trade uses: type 1 resolves on customer and product, while type 4 resolves on customer price type and product price type, the broader grouping most distributors run at volume, with quantity breaks operating inside both. Practitioners call this buy matrix and sell matrix pricing, and that vocabulary is real, but it is not Infor's documented terminology.

Microsoft Dynamics 365 Finance and Operations resolves prices through trade agreements, evaluated by specificity: an agreement for this customer and this item beats one for this customer group and this item group, quantity breaks apply inside, and sales agreements can override the result for committed volume. Discounts then stack according to their own rules.

SAP Business One starts from Special Prices for a specific business partner and item, which take precedence; below them sits the price list assigned to that business partner, with period and volume discounts applied within it. Most B1 distributors have spent years encoding their commercial relationships into exactly that structure.

Sage 100 resolves a price through a six-level price hierarchy, in Sage's own terms: promotional pricing first, then the customer price schedule, then item pricing by customer price level, then the price level in Price Code Maintenance, then the standard price code, and finally the item's standard price. The number a customer pays is whatever survives that sequence.

Five vocabularies, one architecture. In every case the price is computed from a hierarchy, and in every case the hierarchy is the commercial structure of the business, negotiated account by account over years.

Why an exported price file always drifts

The tempting integration is the simple one: run the pricing logic once, export the results into the storefront's price lists, and refresh on a schedule. It works on the day it ships. Then the business keeps doing business.

A contract renews at a new rate on the first of the month. A special price agreement expires at midnight. A rep adds a quantity break for a strong account. A supplier authorizes a new SPA for a job that starts Monday. Each change is correct in the ERP and absent from the copy until the next export runs, and the next export only captures the rules someone remembered to include.

The arithmetic makes the problem permanent rather than occasional. Forty thousand items across 800 accounts is 32 million potential price points before quantity breaks and date ranges multiply them. No export keeps that many answers current, and no one can audit it by eye. The failure mode always looks the same: a buyer sees one number online, gets invoiced another, and starts calling inside sales to confirm every order, which is the precise cost the storefront was built to remove.

Ask the ERP, do not copy it

The design that survives is the one where the pricing logic stays where it is maintained and the storefront asks a question: what is the net price of this item, at this quantity, for this logged-in account, right now? The ERP evaluates its own hierarchy and returns the answer, and the storefront renders it. Under that design, the price a buyer sees is the price the ERP would quote them at that moment, including the agreement that expired last night.

A few practical rules make runtime resolution work in production. Shopify catalogs still earn their place, controlling which products each account is entitled to see, which is what they do well; the Shopify-side mechanics of company catalogs and price lists are covered in the guide to running contract pricing cleanly on Shopify B2B. Caching is allowed, but deliberately: short-lived, per account, and invalidated when pricing changes, rather than accidental. The cart re-resolves at checkout, so a price that changed between browse and order is caught before the invoice. And where the integration writes pricing back into the ERP, it follows the ERP's own rules, SX.e's documented guidance, for example, is to add pricing records rather than overwrite them so history survives.

This is the architecture Uncap Connect is built on: the ERP resolves customer-specific pricing, credit terms, and tax the way it already does, and Shopify displays the result instead of maintaining a second, weaker version of the rules.

What it looks like at scale

On Dynamics 365 Finance and Operations, Farmers Depot runs its Shopify Plus B2B storefront with the ERP as the system of record for products, companies, pricing, and inventory: 13,046 companies with catalog and pricing relationships, 14,528 customers buying under company accounts, and roughly ten company-specific pricing catalogs with catalog-aware volume discounts, where every buyer logs in and sees their company's price. Nothing is managed twice, which is the whole point.

Uncap has been a Shopify Platinum Partner since 2013, with 380+ storefronts launched on Shopify, including for manufacturers, distributors, and wholesalers. Book a Demo and bring one account's pricing, a contract, a matrix row, and an SPA if you have one. Watching the storefront resolve all three against your ERP is the fastest way to see whether the number on screen will match the invoice.