In consumer commerce, pricing is usually a number. In B2B, pricing is a rule.

The same product can cost different amounts to a distributor, a retailer and an end business, in different currencies, at different quantities, under a negotiated contract. Getting those rules into software is one of the hardest and most valuable parts of a B2B commerce project.

At a glance

  • Price is context: customer, company, location, quantity, contract and market.
  • Decide early which system is the source of truth for price.
  • Catalogs control both visibility and pricing, not just merchandising.
  • Volume, contract and customer-specific pricing must be modelled, not patched.

Why B2B pricing is harder than it looks

A consumer price answers “how much does this cost?” A professional price answers a set of questions: who is buying, for which company, at which location, at what quantity, under which agreement, in which currency and market, with which tax treatment.

A single flat price breaks as soon as any of those variables matter. Spreadsheets and emailed price lists survive for a while, but they reintroduce manual work into every order and make errors invisible until a customer notices.

The layers of a B2B price

A useful model separates the inputs that can influence a final price:

base price
+ customer group
+ specific contract
+ product or variant
+ quantity tier
+ promotion
+ currency
+ market
+ tax treatment
= final price

Not every business uses every layer. The important step is deciding which ones apply, in what order, and which one wins when two rules match. Ambiguity here becomes ambiguity in every quotation and order.

Customer-specific catalogs

In B2B, a catalog is often the unit that carries both visibility and pricing. A catalog can define which products a buyer can access and at what price, using fixed prices, percentage adjustments, volume breaks or quantity rules.

That makes catalogs commercial instruments, not just merchandising tools. A single account may have its own catalog, or share one with a segment, or inherit a base catalog with an override. The model has to support those relationships cleanly — this is described further in the B2B customer portal and Shopify B2B.

As a concrete platform example, Shopify’s current plan matrix distinguishes catalogs assigned to markets from catalogs assigned directly to companies or locations, with different availability by plan. Treat that as a platform constraint to validate—not as a universal pricing model (Shopify B2B plan features).

Volume and tiered pricing

Professional buyers expect quantity to change the price. Volume pricing introduces tiers — for example a unit price at 1–9 units, a better one at 10–49, another at 50+. Two things matter in implementation: the tiers must be visible before ordering, and the calculation must be consistent between the catalog, the cart and the invoice.

If the storefront shows one price and the ERP charges another, trust in the whole system collapses. That consistency problem is fundamentally a data-ownership problem, covered in ERP, CRM and ecommerce integration.

Make rule precedence explicit

For example, a business might resolve a price in this order: customer contract, account-specific adjustment, quantity tier, then base price. Another business may need the quantity break to override a contract. Write the chosen order down, test overlapping rules with representative accounts, and expose the resolved price consistently in catalog, cart and order confirmation. The example is a decision aid, not a default that every business should copy.

Contract and negotiated pricing

Some accounts pay according to a negotiated contract rather than a public tier. Contract pricing can be time-bound, product-specific or tied to a minimum commitment. It usually lives in the ERP or a commercial system, not in the storefront.

The storefront’s job is not to invent the price. It is to resolve, display and respect the price that the commercial system owns.

Currency, market and tax

Multi-market B2B adds currency, rounding rules and tax treatment. Rounding matters more than it seems: a price shown to a buyer must match the price on the invoice, to the cent. Decide where rounding happens and keep it in one place.

Payment terms are part of pricing

Payment terms — Net 30, Net 60, deposits, credit limits, invoice after approval — are commercial conditions that belong with the price. A buyer who sees “€4.20 per unit, Net 30” is making a different decision from one who must pay immediately. Terms should be attached to the account or location, not improvised per order.

Where should pricing live?

There are three broad options, and the right one depends on where commercial truth already sits.

Model Best when
Pricing in the commerce platform Catalog and pricing change frequently online
Pricing in the ERP or commercial system Contracts and conditions are already authoritative there
Dedicated pricing service Rules are complex and shared across channels

Hard-coding customer prices into frontend logic is rarely sustainable. A single source of truth, consumed by every channel, is the goal.

A pricing architecture checklist

  1. What determines a customer’s price?
  2. Which layer wins when two rules match?
  3. Where is the canonical price stored?
  4. How is a price change propagated to every channel?
  5. Are volume tiers visible before ordering?
  6. Are rounding and currency rules defined once?
  7. Are payment terms attached to the account?
  8. Can the system explain why a price was applied?

If pricing rules are still maintained in spreadsheets, that is the first thing to change — before choosing a platform.

Continue reading

Pricing architecture is part of the B2B Systems work at FRN.Q. To map your commercial rules, start on the contact page.