How pricing works

In B2B there is no such thing as the price of an article. There is a price for a buyer, in a currency, at a quantity, on a date. This article explains how those resolve into the one number a buyer actually sees.

The problem, in one article number

Take ball valve 4711-A. Ask four people in the company what it costs and every answer is correct:

• The catalogue price is €19.90. That is what a walk-up buyer pays.
• Müller Industriebedarf has a framework agreement at €16.20, negotiated in March and valid until the end of the year.
• Anyone ordering 50 or more gets €14.00, agreement or not.
• The Swiss subsidiary buys in CHF, off a different list, at a different number that is not €19.90 converted.

Four true prices for one article, all live at the same moment. A B2C shop stores one number on the product and is done. That model collapses on the first framework agreement, which is usually before the shop goes live.

A price is not a field on a product

Everything else on this page follows from one shift in thinking.

In the Revenue Cloud, a price is not an attribute of a product. It is a row in a price list. The product carries what it is; see How product information management works. The price list carries what it costs, to whom, in what currency, from what quantity, between which dates.

That indirection is what makes the four answers above possible without duplicating the article four times.

Price lists

A price list is a container with a scope. Every field on it takes part in resolution:

Price entries

An entry is one priced item inside one list:

• SKU or catalogue product: at least one. An entry can price a SKU your catalogue does not carry (a service, a surcharge item, a supplier article you sell but do not describe).
• Type: Standard or On request.
• From quantity: the tier. 1 is the base rung.
• Unit price and Unit (PCE, M, KG).
• Valid from / Valid until: a promotional window on this one row.

The tier ladder for an item is the set of entries that share the same SKU or product inside the same list. There is no separate tier object; entries at quantity 1, 10 and 50 are the ladder.

Which price wins

This question generates most pricing support cases, so know it precisely. Resolution runs in this order:

1. Currency. The buyer's market decides the currency. Only lists in that currency are candidates. A list in CHF is invisible to a buyer shopping in EUR; nothing converts it.
2. Status and validity. Inactive lists are out. Lists whose validity window has not opened or has closed are out.
3. Market. Lists assigned to markets resolve only in those markets. Lists with no market assignment resolve everywhere.
4. Authentication. If the buyer is anonymous, every list marked Logged-in buyers only is skipped.
5. Specificity. Of what survives, the most specific list wins:

   Rank	List scope
   1	Bound to this contact
   2	Bound to this organization (account)
   3	Bound to this channel
   4	Open, with no scope at all
   5	The default list, as the last resort

6. Priority. Among lists of equal specificity, the higher priority number wins. This is your tool for "two customer lists overlap and I know which one should win".
7. The tiebreak rule. If specificity and priority tie, a configured rule decides, by default the cheapest price for the buyer. See Rounding, defaults and resolution rules.
8. The tier. Inside the winning list, the highest From quantity that is less than or equal to the ordered quantity wins. Order 12 against a ladder of 1 / 10 / 50 and you get the 10-rung.

"On request" is a price, and zero is not

Two situations look the same in a spreadsheet and are completely different here.

No list prices the item. Nobody has ever entered a price. The buyer is shown "on request", not €0.00.

An entry says On request explicitly. Somebody decided this article is not sold at a published price: a project item, a made-to-order assembly, a spare part whose price depends on the machine. That decision outranks a number: where an on-request entry applies, the answer is "ask us", even if another list carries an amount.

What a wrong price costs

A buyer who sees the wrong price does not file a ticket. They phone their contact in the Innendienst, get the right number by voice, and then keep phoning, for that article and for the next one. The shop quietly reverts to being a catalogue with a phone number next to it, and the self-service ratio you built the project for never arrives.

That is the failure mode of B2B pricing: a trust problem before it is a legal or a margin problem. Trust is asymmetric. One wrong price loses it, and months of correct ones rebuild it. Everything in this area, from the resolution rules and the net/gross statement to the validity windows and the import discipline, exists to keep the number a buyer sees identical to the number their sales contact would have quoted.

The second failure mode: the price nobody can explain

A wrong price is one failure. A price nobody can account for is the other.

If your list structure has grown to forty overlapping lists with hand-tuned priorities, then "why did this customer get €17.44?" becomes an archaeology project. The answer exists, but nobody can produce it in a phone call. In a margin discussion with a large account, an answer you cannot produce on the phone is an answer you concede.

Keep the structure small enough to reason about. Three well-scoped lists beat thirty that overlap. See Design your price lists.

How this works in the Revenue Cloud

Everything above lives in two screens.

Order Management › Prices › Price lists is the list of containers. The grid shows status, currency, net/gross, priority, whether a list is the default, which account it applies to, its validity and its markets. That is deliberately the same set of fields resolution reads, so reading the grid top to bottom is reading your pricing logic.

Opening a list shows its settings, its Applies to scope, its validity, its markets, and the price entries it holds as an editable grid. Entries above quantity 1 are chipped as tiers.

Order Management › Prices › Price entries is the same data seen the other way round: every entry across every list, filterable by SKU, by list and by type. That is the view you use to answer "where else is 4711-A priced?".

Next

• Price models in B2B — list, contract, scale, project and on-request pricing, and when each is right.
• Design your price lists — turning all of this into a structure you can maintain.