Volume-break and tier pricing: break quantities, two-dimension matrices, and what survives a connector

This is requirement three on Acro’s Acumatica fit test, matrix, tiered and volume-break pricing, filed under breaks. Contract pricingContract pricing is a price that applies to one customer or one group of customers rather than to everyone. In B2B it is normal for the same product to have a different price for every account on the book. covers the customer-specific half of it. This page covers the quantity half, which behaves differently and fails differently.

A break quantity is the threshold where the unit price changes. Buy 1 to 9 and pay 12 dollars each; buy 10 to 49 and pay 11; buy 50 and up and pay 9.75. The mechanic is simple. What makes it a platform decision is that B2B sellers run it in three distinct shapes, and only the first one maps cleanly onto anything a commerce platform ships.

Shape one is a single break table per item that applies to everybody. Shape two is a break table per price classA price class is a label on a customer account that decides which set of prices they see. Acumatica and most ERPs use price classes so a seller can maintain one price list for a whole tier of customers instead of one per account., so contractors see one set of thresholds and retail accounts see another. Shape three is a two-dimension matrix, where the price is a function of both quantity and something else, usually customer class but sometimes an attribute such as length, grade or finish.

Find out which you run before you look at a platform, because the answer is often not what the sales team says. Export your pricing and count distinct break tables per item. One table means you are in shape one and this requirement is not going to be your problem. Twelve tables per item means you are in shape three and you should stop evaluating storefronts on the strength of their price-break screenshot.

In Acumatica, quantity breaks are set per item through sales price worksheets, with a break quantity on each price line. That is the mechanism, and it works well for shape one and, with effort, for shape two.

What it does not do is set a break quantity at the item class level. Asked directly in Acumatica community thread 8555, Acumatica support answered that "There is no out of the box option available to set the quantity break at Item class level while setting up Item sale price using Price worksheets at present", and that reply is the thread’s accepted answer. That question was posted in March 2022, so re-check it against your release before designing around it. The practical effect, if it still holds in your tenant, is that a distributor who wants the same break structure across a thousand items configures it a thousand times or writes a tool that does.

A second Acumatica behaviour catches people out and it is worth checking yours: whether break quantities are evaluated per order line or across the order. If a buyer orders 30 of an item on one line and 30 on another, most distributors expect the 50-plus break. Whether they get it depends on configuration rather than on hope, and if you are quoting break pricing to customers on total order quantity, prove that behaviour before you publish it on a website where a buyer can test it in ten seconds.

Both of these matter more online than they do at the order desk, because a rep who sees a wrong price fixes it silently and a website does not.

Two of the four platforms publish specific limits, and the numbers are the fastest way to find out whether your pricing fits. Read them against the count of break tables you did in the first section.

Shopify B2B ships volume pricing inside catalogues. Shopify documents that "You can add up to 10 price breaks per product which are applied to each variant", and that break quantities must be "greater than the minimum order quantity, as well as a multiple of the increment that you set in your quantity rules". Prices are entered as fixed unit prices rather than as percentages. The important structural point is that breaks live in a catalogue, and on Basic, Grow and Advanced you get three active catalogues across all B2B markets, so shape two costs you a catalogue per price class and you have three.

BigCommerce ships bulk pricing rules on the product. The API documents quantity_min and quantity_max as required integers, and a type of price, percent or fixed with an amount, and the endpoint sits under a product rather than a variant. Percentage-based breaks are useful here, because a percentage off list survives a list price change and a fixed unit price does not.

Shopware expresses breaks through advanced pricing tied to its rule builder, documenting that "In the tab advanced pricing you can define different prices based on Rule Builder rules" and that "Scaled prices can be represented here via an individual allocation of quantities and prices". Because the rule can test the customer as well as the quantity, this is the one of the four that models shape three without custom code. Drupal Commerce resolves price in code, so it can express anything and will express nothing until somebody builds it.

A connector maps one model onto another, and when the source model has a dimension the target does not, the connector drops it. Nothing errors, because from the connector’s point of view nothing went wrong. That is the failure mode to design against.

The dimension that gets dropped is almost always the customer. Acumatica holds break quantities per item, and it holds price classes and customer-specific prices as separate objects. A platform that stores breaks on a product has one place to put them, so the connector writes one break table, and the one it writes is whichever the mapping picked. Every customer whose break table differed is now looking at somebody else’s pricing, and the only way you find out is a customer telling you.

Three checks will tell you whether you have this problem, and all three take minutes rather than a project. Pick your largest contract customer and one small cash account, and compare what they should each pay at quantity 100. If the two answers differ and the storefront can only hold one, the connector cannot carry your pricing. Second, check whether your break thresholds themselves differ by customer, rather than only the prices at those thresholds, because differing thresholds are strictly harder and rule out more designs. Third, check whether anything in your pricing depends on order total rather than line quantity.

Where the connector cannot carry it, the answer is not usually a different platform. It is resolving price at request time from the ERP for the customers who need it, and publishing static breaks for the customers who do not. That split is unglamorous and it is what most working ERP-connected storefronts actually do.