What will Dynamics 365 pricing not decide for you?

Tier: both. Every article in this cluster ends in the same place from a different direction. This one says the thing directly, and shows its working — because an article about what software does not do is the easiest kind to get wrong.

What this article searched, before it claims anything

An absence claim is only as good as its bound. Everything below is bounded to six pages, all listed in this article's sources and all opened in full:

Business Central — Record special sales prices and discounts (ms.date 2026-04-07)
Unified pricing management module overview (ms.date 2026-04-20)
Price component codes (ms.date 2026-05-18)
Resolve concurrency within price component codes (ms.date 2024-10-25)
Calculate prices for external systems through the pricing calculation API (ms.date 2026-03-24)
New and planned features … 2026 release wave 1 (ms.date 2026-07-28)

We did not search Commerce, Sales, Customer Insights, the Power Platform, or any partner solution on AppSource. Nothing below is a claim about the Dynamics portfolio. Each is a claim about what these six pages describe, which is the pricing surface of the two ERP tiers.

First, what Microsoft does ship near this

Skip this and the rest reads as a straw man. Three things sit close to the decisions below:

Simulation. The module overview attributes to Commerce Scale Unit Core the ability to "Simulate prices, and show detailed price calculations."
Discount budget controls. The same list includes "enhanced discount budget controls to help avoid margin leakage from fund consumption" — Microsoft naming margin leakage explicitly.
A price breakdown over an API. Chapter 7's endpoint returns base price, trade agreement price, adjusted price and final customer price per item, [GA] since June 2026.

These are real and useful. Each answers what did my rules produce. None answers which rules should I have written — and that distinction is the whole of what follows.

1. What the price should be

What it does: Business Central defines the best price as "the lowest price with the highest line discount allowed on a given date". Finance & Operations computes "Base price + Price adjustment = Selling price".

What it does not: neither page describes any step that evaluates whether the resulting number is the one that earns the most. Business Central's rule is explicitly a lowest-allowed rule; the Finance & Operations equation is an arithmetic identity over values you configured. Both are correct executions of a decision made elsewhere.

2. Whether a discount should exist at all

What it does: chapter 5's five concurrency modes decide which of several competing discounts applies, and Microsoft's worked example traces six rules to a final price.

What it does not: every mode takes the set of rules as given. Across the six pages, nothing evaluates whether a rule should have been created, or should be retired. Always apply is the sharpest illustration — "The pricing rule always applies" — a discount that by configuration cannot be competed away, and nothing asks whether it should still exist.

3. When to change a price

What it does: Business Central's Adjustment Factor moves a filtered set when you run the batch job, and "only creates suggestions and it doesn't implement the suggested changes."

What it does not: the trigger is a person running a job. Nothing in these six pages proposes a moment — no cost-movement threshold, no demand signal, no review cadence. Price agreements carry starting and ending dates, so an agreement can expire; nothing proposes that it should.

4. What the customer would have paid

What it does: Business Central checks customer, item, date, unit of measure, minimum quantity and currency. Finance & Operations builds attributes from "customers, products, sales order headers, and sales order lines".

What it does not: none of those inputs is an outcome. The engines know who is buying what, when, in what units, how many and in which currency — and nothing about what the buyer accepted, refused or would have accepted. That is the input a price optimization model exists to supply, and its absence here is a design boundary rather than a gap.

5. Which customers to protect and which to test

What it does: combination rank breaks ties, and Microsoft states the problem honestly — "if two equally general rules apply … it can be difficult to determine which rule should have priority."

What it does not: the rank is a number you assign. The page's own framing is that the module "lets you specify a rank for each attribute group" — it is a mechanism for recording your judgement, not for forming it.

6. Whether an agreement should still be running

What it does: Business Central checks "Is the date within the starting and ending date of the price/discount agreement?"

What it does not: an agreement with a start date and no end date passes that check forever. Nothing in these pages reviews it, ages it, or surfaces it. This is the most mundane item on the list and, in our reading of how these systems are configured, the most common.

7. The aggregate margin consequence of stacking

What it does: both tiers stack. Business Central applies a line discount and then an invoice discount to the document total. Finance & Operations compounds according to a tenant-wide model and then applies every Always apply rule last.

What it does not: across the six pages, no mechanism reports the combined effect of stacking against a margin target. The pricing calculation API returns DiscountAmount per item — a fact, not an assessment — and its published not-supported column includes "Basket pricing or promotion concurrency". Optimization needs a target; these surfaces report an outcome.

And what the current release wave adds

The 2026 release wave 1 plan for Supply Chain Management carries one pricing feature, chapter 7's API, and it calculates. Its Copilot and AI innovation section contains three features — generative demand insights, forecast accuracy explanations, and Procurement Agent impact analysis — and none of the three is about price. Bounded to that page and that section, on ms.date 2026-07-28.

How we build it: the last mile, on your stack, into your objects

Pricing & Discount Optimizer decides which price and which discount schedule earn the most margin across the whole book, re-plans them as demand and cost move, and writes the answer back into the price lists, agreements and pricing rules Dynamics already executes — behind an approval step. Seven decisions above; that sentence is our answer to all seven. Dynamics is the system of record. This is the system of intelligence, and the last mile is where the margin lives.

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. Built on Power Platform, Dataverse and Azure, so it sits inside the governance your IT team already approved.

Where we would draw the line

We would not replace either pricing engine. Both execute reliably, your team knows the screens, and the decision worth optimizing sits above them.

We would not build a price calculator. Microsoft ships two and now an API for the enterprise one. We advise rather than build wherever the vendor can ship it from data it already holds.

We would not optimize a price book nobody has audited. If your agreements contain overlapping rules nobody has verified, or lines sitting in Draft, the model would be optimizing on top of an already ambiguous calculation. Chapters 2 and 6 are the tests.

We would not write a price into a live order book without a person in the loop. A price is a promise to a customer, and a promise is not a field.

What to do this week

Pick the largest discount your business granted last quarter and ask who decided it. Not which system applied it — which person, which month, and against what target.
Count the agreements with a start date and no end date. Section 6 is the cheapest finding in this cluster.
Establish which experience or module you are on. Chapter 2 on Business Central, chapter 6 on Finance & Operations. Everything else depends on it.
Ask what your margin target per product family is, and whether the pricing setup encodes it anywhere. If the answer is that it lives in a spreadsheet and a person's judgement, that is the gap this cluster has been describing for nine articles.

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/

Runs Dynamics and wondering what the last mile is worth on your data? Book a 15-minute call — we'll walk the pricing decision and the model with you, on your data if you bring it. No deck.

What will Dynamics 365 pricing not decide for you?