B2B contract pricing: the layers of price and which rule wins

A B2B pricing policy is two things at once. The pricing model is the set of rules that decides what a given product costs a given customer. The framework agreement fixes terms for a period, before any order exists. The pricing model answers „what does this cost”. The framework agreement answers „on what terms, for how long, and against what commitment”. This article covers both layers: how to build the rule hierarchy, what a framework agreement has to settle, and what your platform and ERP need to carry so the terms survive contact with real orders.

A per-customer price is not a „global discount”

The most common mistake at the start is reducing your whole pricing policy to one slider: „this customer gets minus 12 percent”. In real B2B, several independent layers run at once. Price levels (price lists) describe different grids, for example retail, wholesale, chain wholesale. Customer groups assign accounts to shared terms so you do not configure each one separately. Individual prices are exceptions negotiated with a specific customer. Contracts add the dimension of time and commitment: an agreed price on selected products, valid from-to, often tied to a declared volume. These are four different mechanisms, and cramming them into one Excel column is the source of most errors: six months later nobody knows why a given customer has that particular price.

Why Excel stops being enough

A spreadsheet works fine with a handful of customers and one grid. The trouble starts at scale: copied tabs, prices sent by email as PDFs, quick manual overrides and no change history whatsoever. You cannot answer a simple question like „what price applied to this customer in March and who changed it”. Excel also does not resolve conflicts: when a group discount and a promotion both apply, chance or a salesperson's memory decides. A pricing model needs rules, priorities and an audit trail, and a spreadsheet has none of that by nature.

The rule hierarchy: who wins when conditions overlap

The key question in any pricing policy is: what happens when several rules apply to one product and one customer at the same time? The system must resolve this deterministically, always the same way, not „however it turns out”. A proven order in B2B is: the customer's individual (contract) price, then their group price, then the volume discount, then the promotion, and finally the base price. The higher a rule sits in the hierarchy, the more strongly it binds. Writing this order down explicitly, before configuring any tool, is the single most important decision in the whole project. We do this as standard when modelling B2B price lists and quotes.

An example hierarchy of B2B pricing rules and the order in which they resolve. A higher-priority rule overrides a lower one.

The table alone does not close the topic, because some decisions are commercial, not technical. The most common dilemma: can a promotion go below a contract price? Usually not, because a contract is a commitment and takes precedence, but there are exceptions (an end-of-line clearance, for instance). The same goes for volume discounts: are they calculated off the base price or off the already reduced group price? This has to be decided once and written down, so that the system and the sales team calculate the same way. There is one good rule: no priority without a documented reason, because a year from now nobody will reconstruct it from memory.

Volume discounts and tiers

Volume discounts reward larger orders, but modelling them has traps. You have to decide whether the tier counts per line item, per whole order, or per purchases in a period (quarterly, for example). You also have to settle whether crossing a tier lowers the price of the entire quantity or only the units above the tier. Below is a simple, explicitly labelled example of tiers counted per line item, where the lower price covers the entire ordered quantity:

• 1 to 9 units: customer group price, no extra discount
• 10 to 49 units: an extra minus 3 percent
• 50 to 99 units: an extra minus 6 percent
• 100 units and above: an extra minus 10 percent, but never below the contract price

Contracts as a layer: fixed once, then read by every order

A framework agreement sits above your price list. It fixes the terms once, for a defined period, and every later order draws on them instead of reopening the negotiation. That is why a regular buyer does not ask for a price on every purchase, they order against the contract, and a salesperson only steps in when an order falls outside the agreed scope. This piece covers the pricing layers inside your system; for what a German Rahmenvertrag settles specifically and which billing models follow from it, we wrote that up separately in framework agreements in German B2B.

How a framework agreement relates to a contract price

A contract price is usually one clause of a framework agreement, not a separate object. The same agreement can also fix payment terms, minimum order quantities, order units, lead times, a rebate settled after the period and who carries the stock. A system that only stores „customer X pays 42.00 for product A” holds a fragment of the deal; the rest comes back over email at the first disputed delivery.

Six things from the signed document have to survive the move into the system:

• Scope: which products, which legal entities on the customer side and which delivery locations the terms cover. A framework agreement rarely spans the whole catalogue.
• Validity: a start date and an end date, plus a decision on what happens at expiry: fall back to the group price, auto-renew, or block ordering until the agreement is renewed.
• Committed volume: the quantity or value the buyer declared, together with a running counter of what has already been called off against it.
• Call-off orders: every order has to reference the agreement it draws on, so that the counter and the price come from the same place.
• Settlement: an invoice per order, one collective invoice per period, or a rebate calculated only once the period closes.
• Versioning of terms: a renegotiation creates a new version with its own effective date, while the previous one stays readable for invoices already issued.

The market you contract in is a separate matter. Payment periods, early-payment discounts and invoice formats are often stricter abroad than domestic practice suggests, and that is where framework agreements tend to cost more than planned. We worked that through on the German example in our piece on framework agreements in German B2B.

Units, packaging and currencies

In B2B a price rarely applies to „one piece”. The same product is often sold in units, cartons, pallets or by weight, and each unit can carry its own price and its own conversion factor. The model must ensure a discount applied to a carton does not drift out of line with the single-unit price. On top of that comes currency: a German customer wants EUR, a domestic one PLN, and the exchange rate is a separate decision (fixed in the contract, daily from the ERP, or from a bank table). If you sell in several currencies, each one needs its own price list or a clear conversion rule, not an ad hoc multiplication by a rate in the salesperson's head.

Net or gross? VAT in B2B

In B2B relationships you work by default with net prices, because those are what gets negotiated and put into contracts, with VAT added at the end. This is an important difference from retail stores, where the customer sees gross. Your model, however, must correctly handle different VAT rates (products with different rates in one basket), intra-EU sales with a zero rate for a VAT-registered buyer, and cases where the same catalogue serves both companies and, exceptionally, a buyer with no VAT number. The tax rate is a property of the product and the transaction, not part of the price itself, so keep them separate: the net price on one side, the VAT rule on the other. This should be confirmed with accounting, because the details depend on the country and type of sale.

Expiry and versioning of price lists

A contract with no date is a delayed-action landmine. Every contract price should have a start and end date, and the system should automatically fall back to a lower level in the hierarchy once the contract expires. Add versioning to that: a new price grid for next year does not delete the old one, it comes into force from a specific date, while the previous version stays in the history. That way you can answer „what price applied on 15 March” and settle a complaint or an invoice correction without guessing. Without dates and versions, every price increase is a manual „change everyone at once” action, usually done in a hurry and with errors.

Quotes and offers with an approval flow

Not every price is ready in a price list. A large part of B2B is individual quoting: the customer asks for an offer on a specific basket, the salesperson prepares prices, the customer approves, and the approved quote becomes the basis for the order. If that process lives in emails, you lose control: nobody knows which version of the offer is binding, or whether the customer ordered at the prices they agreed to. In a platform, a quote has a status (draft, sent, approved, expired), a validity date and a full history. An approved offer can automatically create a temporary individual price, so the order goes through exactly at the agreed rates. This turns email agreements into an auditable process.

Where the single source of truth for prices lives: ERP or platform

The hardest architectural question is where the „truth” about prices lives. In most companies with a real warehouse and accounting, the ERP is the master of prices and contracts, and the eCommerce platform consumes and presents them. This is a healthy default, because the sales team works where they always have, and the store does not become a second, competing source of prices. Alternatively, some rules (promotions, online quotes) can originate on the platform side and flow back to the ERP. What matters is that for each rule type you clearly name the owner and the direction of synchronisation. How to wire this up in practice is covered in our piece on integrating a B2B store with an ERP.

Pitfalls that break even a good model

A few mistakes recur in almost every rollout. The first is a mismatch between ERP and store prices, when synchronisation is infrequent or one-way and the customer sees a different price than on the invoice. The second is manual overrides with no trail: a salesperson „fixes” a price on an order, bypassing the rules, and a month later nobody knows why the margin dropped. The third is a missing resolution order, so the same configuration yields different prices depending on which rule fired first. The fourth is contracts with no dates, which stay in force long after they should have expired. They all share one root cause: no single, deterministic model with an audit trail.

Where to start

Before you pick a tool, describe your real pricing layers on paper: what price levels, groups, contracts, tiers and currencies you have, and in what order they should resolve. This model matters more than any specific system, because well-mapped rules translate to any platform, while bad rules will spoil even the best one. At Seedlight we treat pricing policy as part of a B2B platform wired to the ERP, and we map the pricing rules themselves before the build, at the Blueprint stage, so the model is created once and done properly. If you want broader context on how putting wholesale sales in order looks from the process side, see our piece on wholesale digitisation in 90 days. We do not promise the model will raise your margin on its own, but it removes the pretext for chaos and price disputes.