Two discount rules hit the same line. Which one wins?

Tier: Finance & Operations. A seasonal promotion, a customer-group discount and a volume break all apply to the same order line. Finance & Operations does not pick one at random, and it does not always pick one at all.

Two different collisions, and they are not the same problem

From Resolve concurrency within price component codes [GA]:

"Across-price-component-code concurrency – This type of concurrency controls how the different price component codes that are included in a price structure combine with each other."

"Within-price-component-code concurrency – … This type of concurrency occurs when an order or order line qualifies for more than one pricing rule that's associated with the same component code."

Across is the structure question — chapter 4's evaluation sequence. Within is the one that surprises people, and it is what this article is about. Microsoft's own example is a code named Seasonal promotion events with several discount rules under it.

The five modes

Quoted whole, because the fourth changes the answer and is the easiest to skim past:

Exclusive — "The pricing rule can't be combined with other rules that are associated with the same price component code. If more than one of these rules are set up as exclusive, the price engine applies the rule that has the largest discount."
Best price — "Pricing rules that use this concurrency mode will compete for the largest discount (lowest price)."
Compounded — "All applicable pricing rules are combined. On the Pricing management parameters page, you can configure the system so that each calculation is based on either the original price or a running total of all adjustments so far."
Always apply — "The pricing rule always applies. This calculation is always applied last within a price component code."
Price attribute combination rank — "Pricing rules that use this concurrency mode don't compete for prices. Instead, they compete based on which rule has the highest price attribute combination rank. If multiple rules have the same highest rank in the same price component code, they're combined."

Always apply is the one to look at first. It does not compete — it lands on top of whatever the others resolved to, last, every time. A rule in that mode is not part of the contest; it is an additional discount that the contest cannot suppress.

And note the tie behaviour in the fifth mode: rules at the same highest rank are combined, not resolved. A ranking scheme with duplicate ranks stops being a tie-breaker and becomes a stacking rule.

The available modes are not universal — the page states they vary "depending on the type of price component code", and chapter 4's Price component codes page confirms the default mode field appears "only when the Price component field is set to Margin component or Discount".

Where the mode is set — four places, one winner

The page lists the levels. The precedence sentence is the one that matters:

"Pricing rule level for discounts and margin price adjustments – The concurrency mode that's assigned to a pricing rule overrides the default mode that's assigned by its associated price component code."

So the component code sets a default, the rule overrides it, and the price structure shows the default but "you can't edit it here". Reading the mode off the price structure tells you what the bucket intends, not what any given rule does. Sales trade agreements are different again: their concurrency is set per company on the Pricing management parameters page.

The model above the modes

Three options on Pricing management parameters change what "best price" and "compounded" mean:

"- Best price and compound within priority, never compound across priorities - Best price only within priority, always compound across priorities - Best price and compound within priority, best price and compound across priority"

Plus a compounding basis — "Compound" or "Compound on the original price" — and a switch for whether "exclusive threshold discounts should compete with exclusive non-threshold discounts".

These are tenant-wide and they were almost certainly set during implementation. Every mode on every rule is interpreted through them. If you have never seen this page, someone chose your discount arithmetic for you.

Microsoft's worked example, and two things in it worth knowing

The page publishes a full trace: item BT023 at $1,565.00, six discount rules across three component codes, "The result is a final price of $1,080.45." It is the only published end-to-end trace of the algorithm, and it repays reading line by line — three competing rules resolve, then three Always apply rules land on top, in pricing-sequence order.

Two inconsistencies inside that example, stated precisely and bounded to it:

The rule table defines DIS03-01 with calculation method Amount and value 20; the result table shows the same rule with calculation method Percentage, value 20, and a discount amount of 20.00. The arithmetic follows Amount — twenty per cent of the running total would not be 20.00 — so the result table's label is the one out of step.
The result table's first column is headed Concurrency mode and one row reads Threshold, which the rule table lists as a Discount type rather than a mode.

Neither breaks the example. Both are worth knowing before you reproduce it in a workshop and spend an hour wondering why your numbers disagree.

The page's own date, because it matters here

This is the primary source for how your discounts combine, and it carries ms.date 2024-10-25 with updated_at 2025-05-07. That is well over a year old, while the module overview it belongs to was refreshed in April 2026 and the price component code page in May 2026.

We are not implying the behaviour has changed — we have no evidence of that, and the page is current documentation. We are saying that the one page describing your discount arithmetic has not been revised in the period when the rest of the module was, and that is worth a sentence rather than silence.

How we build it: choose the rules, never re-implement the resolution

Pricing & Discount Optimizer decides which discount rules to run, at what depth, in which component codes, and re-plans them as demand and cost move — writing them back as rules under your existing concurrency modes, behind an approval step. The resolution stays Microsoft's. We would not reimplement the algorithm above; we would choose better inputs for it, which is the harder and more valuable half.

A working demo exists; it is not off the shelf. We build it against your systems and your constraints on request, and we have no delivered pricing engagements — so this is a capability, not a report on somebody's business. We do not touch your ERP core.

Three things to check this week

List every pricing rule whose concurrency mode is Always apply. Each one is a discount that cannot be competed away, applied last, on top of everything else.
Open Pricing management parameters and read the three settings above. Note who set them and when. They govern the meaning of every mode in your system.
Find any price component code where several rules share the highest combination rank. By the quoted definition those rules are combined rather than resolved, which is rarely what a ranking scheme was designed to do.

Chapter 4 is the structure these codes sit in. Chapter 7 is how an external system asks for the result.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want to know which of your discounts can't be competed away? Book a 15-minute call — we'll walk the decision and the model with you, on your data if you bring it. No deck.

Two discount rules hit the same line. Which one wins?