Disabling and Restricting Discounts in SAP CPQ: Where the Rules Live

The request usually arrives as one sentence. Sales leadership wants to disable discounts in SAP CPQ for one team, one product line or one stage of the quote, and the admin is expected to find the switch. I went looking for it in SAP’s help pages, the support notes and the community threads, and what I found instead is a handful of separate mechanisms, none of them labelled “disable discount”.

That matters, because a discount in SAP CPQ is controlled in several places, and the place you pick decides whether the user is blocked, sent to an approver, or simply looking at a grey field. This is the map I would hand a new administrator: where each rule lives, what it really does, and the order I check them in when a discount refuses to behave. Setting names are written the way SAP writes them, and where SAP’s own pages disagree I say so instead of picking a winner. The help portal pages I cite showed version 2609 when I read them on 2 October 2026.

Four layers decide how you disable discounts in SAP CPQ

Discount rules: minimum, default and maximum

The core is the discount rule, found under Setup > Pricing/Calculations. In Quote 1.0 the page is called Discounts/Multipliers, in Quote 2.0 it is called Discounts, and SAP’s text for the newer engine says “The Discounts can be accessed through the Discounts link under Pricing/Calculations.” Each rule carries a Minimum Value, a Default Value and a Maximum Value, and a new rule starts with zero in all three. The Default Value is applied only the first time a user generates the quote. If the user then changes the discount, the changed value stays, and reopened quotes keep it. The full behaviour is described on SAP’s Discounts page for Quote 2.0.

Who a rule applies to is decided by five criteria: User Group, User, Category, Product and Product Type. You can select only one value inside each group, you can combine groups, and the discount applies only when every selection is true. The Condition field is a formula that “must resolve to 1”, and conditions can also sit inside the Discount fields themselves, so one rule can serve several values. When two rules exist for the same product and the same user, the most restrictive one wins, but SAP says that only holds for rules defined on a product, not on a product type. If you want the wider picture of how these rules sit inside pricing as a whole, my piece on pricing logic for internal teams covers the guardrail side, and the SAP CPQ pricing automation page describes what we build around it.

One trap sits in the priorities. The Discount Priorities page says the rank runs from 0 to 5, “0 being the highest rank”. SAP Learning says “a ranking of 1 is the highest priority”, and the Integration Guide gives the Product rule Rank 1 as well. I could not reconcile the three, so test a two-rule setup on your own tenant before you trust either reading. Also note that if you apply a discount to a product type, the rules based on category and on a specific product are not evaluated at all.

Field editability

A discount rule says how far a value may go. Editability says whether the user can touch the field in the first place. In Quote 2.0 this lives in the Quote Field Editability tab under Fields, Calculations, Layout, and SAP is blunt about the model: editability is set per column, so if a column is editable, all fields in that column are editable for all items. By default every field on a quote is read-only until its editability is defined, and when a user belongs to several permission groups the logic between groups is OR, so one group with edit rights is enough.

Quote 1.0 does the same job in Cart Fields Administration, per user group and order status. That is also where a well-known community post lands: the Additional discount amount and Additional discount description rows are greyed out when those options were never added to the editable field group. The SAP Product Expert who commented on that post asked the author to state that it applies only to Quote 1.0, and I would repeat the warning. One caution of my own: none of the editability pages I read names the Discount column specifically, so confirm on a test quote what a given column controls.

Approval rules and workflow

Approval is the layer people mistake for a restriction. SAP’s wording is that an approval rule “by itself doesn’t do any work” and a workflow must be set up before anything happens. The rule condition SAP uses in its own example is <*GI(EXCEEDEDISCOUNT)*>, which checks a global information flag that is set when discounting rules are violated. Yes, it is spelled without the second D, so copy it rather than retype it. The workflow actions then use <*APPROVALREQUIRED*> and its negation to decide who can approve and who must escalate. SAP’s example has one approver handling discounts up to 10 and the next approver up to 20.

Rules are re-evaluated every time a quote is loaded or reconfigured, or when quote prices are refreshed. Here the sources disagree again: the Quote 2.0 approval page still uses the GI variable, while the migration guide lists Global Information variables as obsolete and says CTX tags should be used instead. Treat that as a reason to test your approval condition after any move to Quote 2.0.

Application parameters

The fourth layer is easy to forget because it is not a rule at all. Quote 2.0 has a parameter called Calculate Discounts only for Changed Items on the Discounts page, which makes the engine check discount rules only for items that changed. It does not exist in Quote 1.0, and the same migration page lists Quote Multipliers as obsolete, with Discounts to be used instead. The second parameter, When updating quote item, reapply default discount, has its own section further down, because it causes most of the “my discount vanished” tickets.

Matching the goal to the layer

“Disable”, “restrict” and “block” are three different jobs, and each one lands on a different layer. I ask the requester which one they mean before I try to disable discounts in SAP CPQ on any setup page.

A hard stop for values outside the range

The only setting in the pages I read that literally stops entry is the checkbox User can override values? on the discount rule. SAP’s text: “If this box is unchecked, the user will be unable to enter the value.” The scope is narrower than it sounds. It concerns values outside the Minimum and Maximum range, not the discount field as a whole. Inside the range, the user can still type freely. A new rule starts at zero for minimum, maximum and default, so the practical question is not how to turn discounts off but how far you let each rule open.

Review instead of a block

With the same box checked, the user can enter the out-of-range value, and the quote is automatically submitted for approval to the user’s approve parent. SAP adds that the approval process must be set up for the checkbox to work correctly, which is the detail most half-finished configurations miss. This is the right layer when the business wants a conversation, not a wall. My guide to how approval rules are structured walks through thresholds and dependencies, and the approval workflow design page covers routing and escalation.

Be aware of one limit. A Quote 2.0 community thread from October 2022 asks: “The standard approval rule functionality works on the header level of an quote. Is it possible also to use the approval rule functionality on quote item level?” The author’s own answer was that it is not possible yet without development effort, and an SAP expert suggested setting a flag on item level to mark which lines need approval. That thread is nearly four years old, so check the current documentation before you promise item-level approvals to anyone.

A read-only field, and where scripting fits

If the goal is a field the user cannot edit, you are back at editability, and the least-privilege thinking in my article on roles and least privilege applies directly. Which events a script can attach to, and which objects exist there, is covered in our article on how scripts are organized and where they fail. Scripting enters in one documented place: Dynamic Access Control for Quote Item Custom Fields in Quote 2.0, where SAP says scripting lets you “control their editability, read-only status, and visibility”. Note the scope. It is for Quote Item Custom Fields, and SAP does not claim it for the standard discount field. I found no documented script example that restricts a discount, so I would not promise one.

Why a discount resets, greys out or still triggers approval

When a user reports a discount problem, I work through the layers in a fixed order: the rule, the editability, the approval, the parameter. The practitioner questions below are the ones I could actually find, quoted as asked.

The value snaps back after an update

SAP KBA 3741192, “Discount Values Are Reset After Updating Quote Items”, describes the symptom as “User-entered recurring or one-time discount values are not preserved after updating a quote item.” The cause is the application parameter When updating quote item, reapply default discount being enabled, and the fix is to set it to False. In Quote 1.0 the Event Pipeline page lists the raw name Cart.EditItemApplyDefaultDiscount with a slightly different label, ending in “discount/multiplier”. I did not find a page that says whether the two labels are one parameter, so check which label your tenant shows. This is the first thing I look at for anything that behaves like a reset, before I touch a rule, and our SAP CPQ troubleshooting hub follows the same top-down habit.

Additional discount fields are greyed out

The question was short: “I am not able to add additional discounts in SAP CPQ Quotes.” The thread itself ended without an answer, and the closest thing to one is the community blog described earlier. It points at Cart Fields Administration, and it applies to Quote 1.0 only.

The approval message stays after approval

A 2022 thread, marked solved, asked why a quote still showed the approval message after it had been approved, even with the status added to the condition. The accepted answer was a formula that tests the discount and excludes approved and placed quotes. The Quote 2.0 version reads [AND]([GT](<* AverageDiscountPercent *>,0),[NEQ](<*CTX( Quote.StatusName )*>,Approved),[NEQ](<*CTX( Quote.StatusName )*>,Order Placed)). In Quote 1.0 the status reference is written Quote.Status.Name, so copying a formula between engines silently breaks it.

Prices that come from the back end

With a pricing procedure from SAP Variant Configuration and Pricing, SAP states it is possible to make condition types visible or editable on the quote, but you need a script to map individual condition types to custom item columns. In other words, a discount that originates in the back end is not governed by the rule page alone.

Before you change a rule

Two facts from SAP’s pages shape how I roll out a change. Rules are evaluated again whenever a quote is loaded, reconfigured or repriced, so a new approval condition reaches quotes already in flight. And because a modified discount is kept on reopened quotes, editing the Default Value will not rewrite what users already changed. Quotes that are already waiting for an approver are a separate case, which I covered when I wrote about retracting an approval.

My routine, whenever someone asks me to disable discounts in SAP CPQ for a group, is simple. Change one layer at a time, then test with a user from every group the rule names, in both a low and a high discount case, on a quote in each status your editability grid covers. If the answer to “which layer is this?” still is not obvious after that, the setup has usually outgrown its original design, and a second pair of eyes saves a lot of ticket ping-pong.