Customer-Specific Pricing Rules That Survive Contact With Reality

A buyer calls to say the price on their portal is wrong. You ask three people what the price should be and get three answers. Each one is right, according to a different document.

Sales has the email where the discount was agreed in March. Finance has the invoice history. The store has whatever was typed into it last. Somewhere there is a spreadsheet called price list FINAL v4 that everyone quietly treats as the truth.

Pricing gets named as the hard part of business to business e-commerce constantly, and then left at that. It is not hard because the arithmetic is difficult. It is hard because several correct rules apply to the same line at the same time, and nothing anywhere says which one wins.

The short answer: B2B customer specific pricing works when one system owns the price, the order of precedence between rules is written down, every negotiated price has a start and end date, and a small set of representative accounts is tested after every change. Automation should carry the agreed number reliably. It should never decide the number.

Customer specific pricing is the practice of showing each business buyer the price agreed with them, instead of one public list price, by layering rules on top of a base price list.

What actually decides the price on a B2B order?

Seven layers show up in almost every wholesale business. They stack, and each one can override the one below it.

1. Base price list. The default trade price for a product.
2. Customer or group override. A percentage or fixed price for a tier such as distributors, or for one named account.
3. Volume or quantity break. A lower price above a certain quantity.
4. Contract price. A negotiated number for one account, usually with a start and end date.
5. Temporary promotion. A seasonal or clearance price, meant to expire.
6. Currency. The same product sold in euros, pounds and dollars, where converting on the fly is not the same as a deliberate local price.
7. Cost-plus. A price derived from your cost, so it moves when your supplier moves.

Each layer has an owner, and each one fails in a specific way when nobody owns it.

Rule type	Who usually owns it	The failure when unmanaged
Base price list	Commercial or finance	Price rises never reach the store, so margin quietly shrinks
Customer or group override	Sales leadership	Every rep invents a tier, and tiers stop meaning anything
Volume or quantity break	Commercial, with finance sign-off	Buyers split or combine orders to game the break
Contract price	The account owner who negotiated it	Runs forever because nobody set an end date
Temporary promotion	Marketing	Becomes the permanent price nobody dares raise
Currency price	Finance	Auto-conversion drifts from the local market price
Cost-plus	Finance or purchasing	Supplier cost changes, sell price does not, margin goes negative

Print that table and write a name in the middle column. If a cell is empty, that is the rule that will break first.

What do the platforms actually document about precedence?

Here is the part that surprises teams. Your platform already has a precedence rule. You just did not choose it.

Shopify B2B resolves ties by lowest price. In Shopify, a catalog combines product availability with a price list, and catalogs are assigned to companies and company locations. The Help Center states plainly that "if there are multiple catalogs and prices for a specific product, then the lowest price displays to the customer". Assign an account two catalogs and the cheaper number wins, whether or not that was the agreed one.

Volume pricing then behaves differently again. Shopify documents up to ten price breaks per product, applied per variant, and adds that "after you apply volume pricing to a product the price becomes fixed. Any overall adjustment discount set on the catalog won't apply". So a later catalog-wide adjustment silently skips exactly the products you discounted most.

Adobe Commerce resolves ties by an explicit priority number. Its catalog price rules carry a Priority field, and the documentation says "the rule with the highest priority (lowest number, for example, 0, 1, 2, 3…) takes effect". The same page notes that Magento Open Source uses From and To dates on the rule, while Adobe Commerce removed those fields and requires a scheduled update instead.

BigCommerce falls back to the catalogue price. A price record there is "a price override for a particular variant" containing a variant, a price and a currency, and price lists are assigned to customer groups or channels. Crucially, "if an active price list doesn't contain prices for a variant, then the catalog pricing will be used". A missing row does not raise an error. It shows your wholesale buyer the retail price.

Three platforms, three different answers: lowest wins, lowest priority number wins, and fall back to list. None of them is wrong. All of them will happily produce a price your sales director never agreed to.

Five ways customer-specific pricing breaks

1. A spreadsheet is the real source of truth

The store holds a copy that was current the last time someone remembered to upload it. Nothing is wrong with a spreadsheet as a working tool. The problem is two systems both believing they are authoritative, with no direction of travel between them.

2. Contract prices with no expiry

A three-month introductory price agreed in March is still running in November, because the field for an end date was blank. This is the most expensive item on this list, and the easiest to fix.

3. No written precedence

Two rules match, one wins, nobody predicted which. If your team cannot answer "a distributor with a contract price orders 600 units, which price applies" without opening the admin, the rule is not written down.

4. Rounding, tax and currency applied in the wrong order

Discount then round, or round then discount, gives different totals at scale. Tax is worse, because it depends on settings most people never open. Adobe Commerce, for example, lets you calculate tax based on unit price, row total or order total, and hold catalogue prices either including or excluding tax. Those choices change the invoice. Currency has the same trap: BigCommerce requires a price record per currency, and without one it converts automatically, which is a display decision standing in for a commercial one.

5. No record of who changed a price

When a buyer disputes a price, the useful question is not what the price is. It is what it was on the day they ordered, and who set it. Some platforms log this for you. Adobe Commerce keeps an admin action log with a configurable retention period, archived to file. Many setups keep nothing at all, which turns every dispute into an argument about memory.

A worked example: when two rules collide

The numbers below are illustrative. Use your own products and your own margins.

An account is set up like this:

• Base trade price: €10.00 per unit
• Distributor group override: 20% off, so €8.00
• Volume break at 500 units and above: €7.60
• Contract price agreed in March for this one account: €7.90, no end date recorded

The buyer orders 600 units. Two rules match. The contract says €7.90. The volume break says €7.60.

On a platform that resolves ties by choosing the lowest price, the buyer pays €7.60. That is €0.30 below the negotiated number, or €180 on this order. If the account reorders 600 units every month, that is €2,160 a year, on one product, for one customer, from a rule collision nobody decided.

Now the second half, which is worse. The €7.90 contract price was meant to run for three months. It is still active. So the business is simultaneously losing €0.30 a unit to the volume break and carrying a contract price that expired in June. Two errors, pointing in opposite directions, on the same line.

Neither is a bug. Both systems did exactly what they were configured to do. The missing piece is a written rule saying a contract price outranks a volume break, and a date field that would have retired the contract on time.

The design that holds

Five commitments, none of which require new software.

• One system owns price. Everything else holds a copy that can be deleted and rebuilt from the owner. If you cannot rebuild your store's prices from one source in an afternoon, you do not have an owner, you have two masters.
• Precedence is written down, as an ordered list. For example: contract price, then promotion, then volume break, then group override, then base list. Whatever order fits your business, it must exist on paper before it exists in code, and the platform's own default must be checked against it.
• Every negotiated price has a start and an end date. No exceptions. An indefinite price is a decision to never revisit it. Where the platform supports scheduled updates, use them.
• A price change is a release, not an edit. Draft it, test it, publish it, and be able to roll it back.
• Everything is logged. Who, what, when, and the previous value. If the platform will not do it, a simple append-only record of price changes is a few hours of work and settles disputes permanently.

This is ordinary business process automation applied to the one area where a small error repeats on every line of every order.

The test matrix you run after every price change

The cheapest safety net in pricing is a short list of real accounts with known correct answers. Ten rows, checked after every change, by hand at first.

Account	Product	Quantity	Expected price	Rule that should win
Distributor with a contract	Core SKU	600	€7.90	Contract price
Same distributor	Core SKU	100	€7.90	Contract price, below volume threshold
Distributor without a contract	Core SKU	600	€7.60	Volume break
New account, no overrides	Core SKU	10	€10.00	Base list
Export account, other currency	Core SKU	100	Local list price	Currency-specific record

Illustrative figures again. Fill the expected column from the commercial agreement, not from what the system currently shows, otherwise you are testing that the bug is still there. Once the list is stable, the same rows make an obvious automated check that runs after every price import.

When should pricing stay human?

Automation carries the agreed number. It does not agree it. Keep a person in charge of:

• The negotiation itself. Volume commitments, annual terms and the price at the end of them.
• Exceptions. A one-off price to win back an account is a commercial decision, not a rule.
• Cost-plus renegotiation. When a supplier raises cost, a person decides what to pass on.
• Credit and terms. Price and payment terms get negotiated together. Terms belong with net terms and accounting, and they need approval, not a trigger.
• Very small catalogs. Twenty products and six accounts do not need a rules engine. A checked list and a calendar reminder are enough.

The same boundary applies to machine learning. Extraction tools can read a purchase order and propose lines, but the price must come from your own price rules, which is the core argument in AI order entry accuracy. Never let a model decide a number a customer will be invoiced for.

What to measure before and after

Write these down before you change anything.

• Price disputes raised by buyers, per month
• Credit notes issued because of a pricing error, per month
• Negotiated prices currently live with no end date
• Days from a price decision to that price being live for buyers
• Number of places a price can be changed

The last one is the real health metric. It should be trending towards one. If you are weighing a portal or a platform change at the same time, price this work separately, because pricing rules follow you into any new system. That is part of the calculation in build versus buy for a reorder portal.

Fix one pricing rule this week

1. Export every live negotiated price and sort by start date. Find the ones with no end date.
2. Give each one an end date, even if that date is twelve months out.
3. Write your precedence list in one sentence per layer, and check it against what your platform documents.
4. Build the ten-row test matrix and run it once, by hand.
5. Name one owner per rule type from the first table.

That is one week, no new software, and it removes the two failures that cost the most. Then the next layer. It is the same Find, Prioritize, Automate methodology we apply to every handoff in B2B ecommerce automation.

FAQ

How do B2B customer-specific prices actually work?

A base price list sets the default, and rules layered on top change it for particular buyers: group overrides, volume breaks, contract prices, promotions and currency-specific prices. When more than one rule matches an order line, the platform applies its own precedence rule to pick a winner, so the agreed price only reaches the buyer if your configuration matches your commercial agreement.

Which price wins when two pricing rules apply to the same order?

It depends on the platform, and the defaults differ. Shopify's B2B documentation says the lowest price displays when multiple catalogs apply, Adobe Commerce uses an explicit priority number where the lowest number takes effect, and BigCommerce falls back to catalog pricing when a price list has no record for a variant. Write your intended order of precedence down, then check it against what your platform documents.

Should contract prices have an expiry date?

Yes, every one of them. A negotiated price with no end date runs until someone notices, which is usually a margin review months later. Record a start and an end date on every contract price, and put the renewal in the account owner's calendar before the price goes live.

Can I keep my price list in a spreadsheet?

As a working document, yes. As the source of truth for a live store, it causes trouble, because the store holds a copy that ages the moment it is uploaded. Pick one system that owns price, treat the spreadsheet as an input to it, and make sure the store's prices can be rebuilt from the owner at any time.

How do I stop rounding and tax errors on wholesale prices?

Decide the order of operations and document it: discount, then rounding, then tax, or whichever sequence your accountant requires. Check your platform's tax settings, since options such as calculating tax on unit price versus row total, or holding catalog prices with tax included, change the final invoice. Then verify with a test order per country and currency.

Should AI set prices for B2B customers?

No. Use automation and AI to carry an agreed price accurately and to extract order lines from documents, but keep the number itself coming from your own price rules. Negotiated pricing is a commercial decision with contractual weight, and a model that guesses a price creates an invoice you have to defend.

Sources

• Catalogs and pricing in B2B, Shopify Help Center documents that a catalog pairs product availability with a price list, and that the lowest price is displayed when several catalogs apply.
• Quantity rules and volume pricing in B2B, Shopify Help Center documents price breaks per variant and that volume pricing fixes the price so catalog adjustments no longer apply.
• Manage B2B catalogs, Shopify developer docs covers creating price lists and percentage adjustments through the API.
• Create a catalog price rule, Adobe Commerce documents the Priority field and how From and To dates differ between Magento Open Source and Adobe Commerce.
• Scheduled changes for catalog price rules, Adobe Commerce covers scheduling a price rule to start and stop.
• Tax configuration settings, Adobe Commerce documents calculating tax on unit price, row total or order total, and catalogue prices including or excluding tax.
• Price Lists, BigCommerce developer docs documents price records per variant and currency, assignment to customer groups and channels, and the fallback to catalogue pricing.
• Action Logs report, Adobe Commerce documents logging of administrator actions, which is the basis of a price audit trail.