Where your prices come from
Before you type a single price into the Cockpit, decide where prices are made. For most B2B companies the answer is the ERP, and getting that boundary wrong costs more than any pricing feature saves.
The one decision to make first
There are exactly two coherent answers, and both work:
| ERP is the system of record | The Revenue Cloud is the system of record | |
|---|---|---|
| Prices are created in | SAP, Navision, proAlpha, abas, Sage | The Cockpit |
| The shop gets them by | Import or interface, on a schedule | Directly |
| Sales quotes from | The ERP, same numbers | The Cockpit or the ERP, kept in sync |
| Editing a price in the Cockpit | Is overwritten at the next sync | Is the change |
| Right when | You have an established price maintenance process, conditions logic and an Innendienst that lives in the ERP | Online is a distinct channel with its own price book, or you have no meaningful ERP pricing |
The incoherent answer, and the one that causes real damage, is "both". Two systems that each believe they own prices produce a shop whose prices are right on Monday and wrong on Thursday, and nobody can say which system was correct.
Pick one. Write it down. See Deciding your system of record for the same decision applied across every data domain.
What an ERP price actually is
This trips up almost every project, because ERP pricing and shop pricing are not the same shape.
A classic ERP does not store "the price of 4711-A for Müller". It stores a set
of conditions that are evaluated in a defined sequence: a base price, a
customer discount group, an article discount group, a quantity scale, a campaign,
a surcharge. The final number is computed at order entry, and it may never be
stored anywhere at all.
The Revenue Cloud stores resolved prices: the number, per list, per item, per tier. That is deliberate. It makes a shop page fast, and it gives you a price you can point at during an argument. It also means the integration has to do one of two things:
- Flatten the conditions upstream. The ERP (or the middleware) evaluates its condition logic per customer and per article and hands over the resulting numbers. This is the common path and the one to plan for.
- Call the ERP live. Pricing is the most-customised surface in any B2B platform, and the price call is designed to be replaceable for exactly this reason. It is the right answer when prices cannot be pre-computed at all, raw-material index pricing for example. It costs you latency on every product page and a hard dependency on ERP availability, so choose it deliberately.
Talk about which of the two you are doing before the first import file gets built, not after. See Field mapping.
The volume question nobody asks early enough
Flattening has a size consequence. If 800 customers each have negotiated prices for 2,000 articles, a fully flattened price book is 1.6 million entries, and a nightly full replacement of it is a heavy job.
Two things keep this sane:
Only export what is actually agreed. Most framework agreements cover a few hundred articles, not the whole catalogue. Everything not covered should fall through to the list price rather than be copied. A customer list with 300 entries does the same job as one with 2,000 and is a hundred times easier to check.
Sync deltas, not the world. Send what changed since the last run. A full rebuild is a recovery tool, not a nightly routine.
Where margin leaks
Pricing projects usually get audited for correctness. They rarely get audited for margin, and margin leaks in boring, repeatable ways:
Manual overrides on order lines. Somebody types a better price at order entry as a one-off. It never appears in any price list, so it is invisible to every report, and it recurs because the customer now expects it. This is the single largest leak in most B2B businesses, and it is the one a shop can close: a price that comes from a list is a price somebody decided.
Concessions that never expire. A project price granted for one job, entered with no Valid until, still applying four years later. The fix is mechanical: a project price without an end date is not a project price.
List price rises that skip contract customers. You raise list prices 4 % and feel covered. Your largest customers are on net contract prices and did not move at all, and they are the ones with the volume. Every annual price round needs an explicit decision per contract list, not only a bulk change on the default one.
Scale rungs that reward nothing. A ladder of €19.90 / €19.50 / €19.20 gives away margin for orders that would have happened anyway. Rungs need to be far enough apart to change a buyer's behaviour, or they are a discount with extra steps.
Rounding that always goes the wrong way. A 6 % increase applied across 40,000 entries and rounded down every time is a rounding policy that costs money at scale. Decide it once; see Rounding, defaults and resolution rules.
Currency drift. A CHF list created from a EUR list at a rate from two years ago, never revisited. Foreign-currency lists are separate price books, not conversions, and they need their own review date.
A workable division of labour
For most companies where the ERP owns prices, this is the arrangement that holds up:
| Lives in the ERP | Lives in the Revenue Cloud |
|---|---|
| Base prices and condition logic | The resolved list, per list and item |
| Customer discount agreements | The customer price list they produce |
| Cost prices and margin calculation | Nothing; never publish cost prices |
| Article and customer master data | Product content and account records |
| Web-only campaign lists with their own validity window | |
| Channel-specific lists, e.g. punchout |
The last two rows are the useful exception: a campaign list or a channel list that exists only online, has its own end date, and never round-trips into the ERP. It gives marketing somewhere to work without touching the price book the Innendienst depends on.
Next
- Design your price lists — the structure to receive all of this.
- Import prices in bulk — the mechanics of getting an ERP export in.