Blog
Regional Discount Policies in SAP CPQ: Where Market Ends and the Rules Begin
SAP documents no single feature for regional discounts. This article maps where discount rules, markets, pricebooks and approval rules meet, and which parts SAP documents and which need testing in your tenant.
What you will learn
- Which criteria a discount rule offers and why market is not one of them
- How market factor, currency and pricebooks shape the price before and around a discount
- How approval rules can route by customer territory
- Four knowledge base articles that break regional setups
- A layering model that keeps each regional decision in one place
Ask an SAP CPQ admin how to set up regional discounts in SAP CPQ and the first answer is usually a question: which part do you mean? People say localization, but SAP’s documentation never uses that word for discounts. What it describes instead are separate mechanisms that do not share a screen: a market with a currency and a multiplier, pricebooks that sit under that market, and a discount rule that knows nothing about either of them.
This article walks through the places where discounts and regions actually meet, using the Quote 2.0 administration guide (documentation version 2609), SAP knowledge base articles and a recent community thread. Where a point is my own recommendation or something I could not find documented, I say so, and I left out what I could not confirm.
What a Discount Rule Can See, and What It Cannot
Start with the page most people assume handles this. In the Quote 2.0 guide, the Discounts page says a rule is built from five criteria groups: User Group, User, Category, Product and Product Type. Market, country, region and currency are not on the list. You cannot select several values inside one group, selections across groups combine so that the rule applies only when all of them are true, and every rule carries a Minimum Value, a Default Value and a Maximum Value. A new rule starts with 0 in all three.
That is the first thing to internalize: a discount rule says who may discount which products and by how much. It does not say where the customer is. How those values, the field editability and the approval step interact is covered in the article on where the rules for restricting discounts live in SAP CPQ, so I will not repeat it here.
Two Fields Where Regional Discounts in SAP CPQ Can Sneak In
The same page documents two places that take expressions. The Condition field decides when a rule runs and must resolve to 1, and leaving it empty makes the rule active at all times. The Discount fields accept conditions as well: SAP says that “multiple rules do not need to be created for separate values”, and tags and IF statements are allowed.
SAP CPQ also has a context tag for the selected market. KBA 3759712 shows the syntax <*CTX( Quote.SelectedMarket.MarketCode )*>. Combining the two, a Maximum Value formula that returns a different ceiling per market code is the obvious design for regional discounts in SAP CPQ. Here is where it stands: neither the Discounts page nor any other page I read gives an example of it. Treat it as a design to prove in a non-productive tenant, not as documented behavior. The tag also has a known limit, which I come back to below.
The Rank Scale Depends on Which Page You Read
When several rules match, Discount Priorities decide. The Quote 2.0 page says rank runs from 0 to 5, “0 being the highest rank and 5 the lowest”, and its example lets a user from Paris at rank 0 discount up to 20 percent while everyone else at rank 1 gets up to 10. The Integration Guide, on its page about pricing and discounting setup for the SAP ERP integration, says to select rank 1 for the highest priority, and the SAP Learning course says a ranking of 1 is the highest.
Three SAP sources, two scales. The integration page is written in a different context, so it may simply describe a different setup, but nothing on the pages says so. Before you build a regional hierarchy on top of a rank number, create one test rule in your tenant and see which one wins.
Where the Market Actually Enters the Price
Currency First, Then the Market Factor
The Markets page puts it in one sentence: Market Definition factors are multiplied by the calculated currency to get the final price. Every field on a market (Market Code, Market Name, Currency Sign and Market Factor) is required, and the Market Code is returned by the <*CTX( Market.Code )*> tag, or by <*CTX( Quote.SelectedMarket.MarketCode )*> when Parallel Quoting is enabled. The older <*MCODE*> tag is marked obsolete on Quote 2.0. SAP Learning gives the sequence for foreign currencies: the amount in the default currency is multiplied by the rate from the Currencies table, and the result is multiplied by the market factor. A market is therefore more than a currency. It is also a price multiplier.
One detail to know before you test. The worked example on the Markets page uses a EUR rate of 0.95, a Market Factor of 1.2 and a cart of $2000, and ends at €1656. Multiply the three numbers as written and you get 2,280. Do not use that example to validate your own setup.
The other consequence concerns discounts. Discount values on the Discounts page are percentages taken off the list price, so a Default Value of 10 means the same 10 percent in every market. If Germany and the United States should open with different defaults, that difference has to come from the rule, not from the market. Also remember that the Default Value is applied only the first time a user generates the cart. If the discount is modified, the modified value stays on the quote when it is reopened.
One Market, One Currency, Many Pricebooks
The pricebook page states that the currency is shared across all pricebooks of a market. Several prices for the same product, such as discounts, special offerings or loyalty prices, live in separate pricebooks grouped under the market. A pricebook needs at least one visibility condition, and one that is tied to a condition is not selected automatically, so the user has to pick it. For the default, SAP says that when a market has several pricebooks the first one is selected. Definitions of market and pricebook in plain words are in our SAP CPQ glossary.
This is where real projects get stuck. A recent SAP Community question on Quote 2.0 asks: “Is there a way (possibly via scripting) to change the currency on quote level and keep the Market and pricebook settings?” The asker wanted to avoid maintaining 100+ copies of pricebooks per currency. One answer said to create one market per region in its leading currency, because a market allows only one currency, and to accept the many pricebooks that result. Another described a currency field on the quote, a quote script that updates item prices from the selected currency, and base prices and rates kept in custom tables. Both answers come from community members, not from SAP, but together they show the real trade-off: more pricebooks to maintain, or more script to own.
For the pricebook and FX side of that decision, our article on attribute pricing, price books and FX goes deeper, and the piece on what happens to approval thresholds when currencies multiply explains why thresholds tied to an implicit base currency drift. One more limit: SAP evaluates market visibility rules at login, so quote-dependent tags do not work in the market visibility condition.
Approval Is Where Regional Rules Become Enforceable
The Discounts page has a switch that matters here. With “User can override values?” unchecked, a user cannot enter a value outside the Minimum and Maximum range. With it checked, the user can, and the quote goes to the approve parent automatically. A discount rule can only block or escalate. The place that can look at where a customer is located is approval.
Dynamic Approvers by Territory
The Quote 2.0 Approval Rules page lets a rule apply to a user, a user group or a company, evaluates the specific user first, then user type, then company, and takes a Condition formula that returns 1 or 0, with <*GI(EXCEEDEDISCOUNT)*> as the standard example. The approve logic is AND by default, so everyone must approve, or you can choose OR. The useful part is Custom Approver Selection Logic: an expression that returns a Name, an Email or a Username. SAP’s example compares <* CustomerTerritory *> to a value, and the text says the approver can be determined by the country or region the customer is located in, or by the total amount of the quote.
A rule alone does nothing. The Quote 1.0 guide states that “Approval Rule by itself doesn’t do any work” and that the workflow must be set up, with <*APPROVALREQUIRED*> in the action condition. I only confirmed that wording in the Quote 1.0 guide, so check how your Quote 2.0 workflow is wired. The service page on SAP CPQ approval workflow shows how we usually structure it. The examples I read on the SAP page use the customer territory, not the market tag.
Traps That Break Regional Setups
Four knowledge base articles cover most of what goes wrong once markets, pricebooks and discounts are combined:
- KBA 3759712: “Currently Pricebook Distribution Channel and Market Code tags are not supported when parallel quote is enabled.” The market code can be read from the CTX tag shown earlier or through scripting, and for the pricebook there is no tag workaround. Any regional formula built on market tags needs this check first.
- KBA 3761355: when a quote is created from Sales Cloud v2, the user’s default pricebook is not applied and the first available one is chosen. The cause is a bug, with CPQ-2608 named as the tentative fix version. The workaround is to send the distribution channel in the payload, and its values must be unique within the same market.
- KBA 3428300: the message “Pricebook matching the provided distribution chain and currency is not available.” is one of the entries in our decoded SAP CPQ error messages.
- KBA 3741192: a manually entered discount snaps back to the default after the item is saved. The parameter “When updating quote item, reapply default discount” must be set to False.
The last one deserves a note for regional rollouts, because a local team that overrides a discount and sees it reset will report it as a bug in the regional rule when it is a general parameter.
A Layering Model You Can Maintain
Putting the documented pieces together, this is how I would assign each decision behind regional discounts in SAP CPQ to exactly one layer. The model is my recommendation. The last column says whether SAP documents the mechanism.
| Decision | Layer | Status |
|---|---|---|
| Currency and price multiplier a region sees | Market, Currencies | Documented |
| Price level for a region or customer group | Pricebook under the market, with a visibility condition | Documented |
| How much any user may discount | Discount rule: Minimum, Default, Maximum | Documented |
| A different ceiling per market | Formula in a Discount field with the market tag | Not documented, test first |
| Who must approve above the ceiling | Approval rule with a dynamic approver by territory | Documented example |
| Time-limited local campaigns | Promotion with Markets in its visibility | Documented, not with Variant Configuration products |
Promotions are worth a sentence. The Promotion Visibility section lists Company, Custom Permission group, Brands, Markets, User Types and Users as criteria, which makes it the one discount feature I found with Markets as a stated filter. ‘Enable Promotions’ is FALSE by default for Quote 2.0 tenants, and SAP states that promotions are not supported in scenarios with Variant Configuration products or other back-end products. If your configurable products are priced through SAP Variant Configuration and Pricing, this layer is closed to you.
The general rule I follow is to put each regional difference in as few layers as possible, because every extra layer is another place to look when a quote shows the wrong number. Name one owner for local exceptions and write down which layer each exception lives in. If you inherit a tenant where all of these layers carry regional exceptions, that cleanup is the kind of work we do in SAP CPQ customization and optimization.