Your ERP calculates every price. Why is the margin still…

Your ERP calculates every price. Why is the margin still leaking?

Business Central defines the best price as the lowest one with the highest discount allowed that day. That is not a criticism and it is not a bug — it is the documented behaviour, working exactly as written. Finance & Operations does something more elaborate and arrives at the same place.

Microsoft's own definition, and it is the whole argument

Tier: Business Central. Here is the sentence, from Record special sales prices and discounts (ms.date 2026-04-07, updated_at 2026-04-09):

"The best price is the lowest price with the highest line discount allowed on a given date."

Read it twice if you own a margin number. "Best" is defined from the customer's side of the invoice. Business Central is not choosing the price that earns you the most; it is choosing the cheapest one your own agreements permit.

A second clause sharpens it. When several currencies could apply, the page says the lowest price and the highest line discount for that currency are inserted, "even if local currency would provide a better price." Better for whom is not ambiguous there either.

So the margin question is not "is my ERP calculating correctly?" It almost certainly is. The question is what it was told to calculate, and by whom, and when.

What Business Central is actually checking

Tier: Business Central. The page publishes the criteria. On the first pass it checks the combination of the bill-to customer and the item:

"Does the customer have a price/discount agreement, or does the customer belong to a group that does? … Is the item or the item discount group on the line included in any of these price/discount agreements? … Is the date within the starting and ending date of the price/discount agreement?"

On the second pass it checks the line: whether a minimum quantity requirement "is fulfilled", and whether a currency requirement is. And if nothing matches:

"If no special price can be calculated for the item on the line, then either the last direct cost or the unit price from the item card is inserted."

Every one of those is a rule somebody wrote, on a date somebody chose, for a group somebody defined. Nothing in that sequence asks whether the resulting price is the one that makes you the most money — and nothing in it could, because the inputs contain no view of what the customer would have paid.

The bulk-change surface says it more bluntly. To move prices you use an Adjustment Factor: Microsoft's own example is that "you would enter 1.15 in Adjustment Factor for a 15% increase in item price." A flat multiplier across a filtered set. And the batch job that produces it "only creates suggestions and it doesn't implement the suggested changes" — the suggestion is arithmetic, and the decision is still yours.

The same shape at Finance & Operations scale

Tier: Finance & Operations. The enterprise tier does something far more sophisticated and lands in the same position. Unified pricing management [GA] (ms.date 2026-04-20, updated_at 2026-04-21) builds a price from four elements:

Price attributes — "give you a flexible way to define your pricing factors. They use information about customers, products, sales order headers, and sales order lines"
Price component codes — "group together price attributes. They represent the building blocks of your price structure"
Price structures — "help you understand the sequence of your price component codes"
Concurrency modes — "control how the final price is calculated in situations where multiple pricing rules are associated with the same price component code"

And it states the arithmetic outright: "Base price + Price adjustment = Selling price".

The capability behind that is genuine, and the page is precise about where it sits. Both products "use Commerce Scale Unit (CSU) Core", and it is the CSU Core function whose published capabilities include determining prices while considering "general base prices, sales trade agreements, long-term discount agreements, short-term promotion discounts, and retrospective rebate calculations for each sales order" — and the ability to "Simulate prices, and show detailed price calculations."

Simulation is the tell. It shows you what your rules produce. It does not tell you which rules you should have written. Microsoft even names the failure mode this cluster is about — the same list offers "enhanced discount budget controls to help avoid margin leakage from fund consumption" — but a budget control caps what leaks. It does not find the price that would not have leaked.

What the current release wave added

Tier: Finance & Operations. The 2026 release wave 1 plan (ms.date 2026-07-28) carries exactly one pricing row, under Sales and marketing: Calculate prices for external systems through API, with a check mark and Apr 26, 2026 against public preview and a check mark and Jun 5, 2026 against general availability.

By the plan's own legend — "Released features show the full date, including the date of release" — that is [GA]. A real addition: your webshop, your CPQ system or your customer portal can now ask Dynamics for the price instead of reimplementing your rules badly.

Note what it does. It calculates. The wave's 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.

How we build it: above both engines, writing into the objects they already run

Pricing & Discount Optimizer decides which price and which discount schedule earns the most margin across the whole book, re-plans them as demand and cost move, and writes the answer back into the price lists and agreements Dynamics already executes — behind an approval step.

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 building.

Three commitments, each with a reason:

Optimize the price, never the calculation — Both engines calculate correctly. A second calculator is duplication; choosing what they calculate from is the open problem
Write into existing objects, never new ones — A price list and a discount agreement are already executed by the ERP and understood by your commercial team. An optimizer needing its own price store has become a second ERP
Every write goes behind a human approval step — A price change is a conversation with a customer. The first time a model is wrong you want a rejected proposal, not a repriced order book

We do not touch your ERP core, and we do not step on your implementation partner — the pricing configuration above stays theirs.

The nine questions underneath this one

Each is a decision a commercial team makes once and lives with, and each names its tier.

How does Business Central decide which price applies? — Tier: BC · Chapter: 1
Draft, Active, Verify Lines — what does the new sales pricing experience change? — Tier: BC · Chapter: 2
Line discount or invoice discount — which one is eating your margin? — Tier: BC · Chapter: 3
What are price attributes, component codes and price structures? — Tier: F&O · Chapter: 4
Two discount rules hit the same line. Which one wins? — Tier: F&O · Chapter: 5
Unified pricing management or the module it replaced — which are you on? — Tier: F&O · Chapter: 6
Can an external system ask Dynamics for a price? — Tier: F&O · Chapter: 7
Business Central or Finance & Operations — which pricing engine are you actually on? — Tier: Both · Chapter: 8
What will Dynamics 365 pricing not decide for you? — Tier: Both · Chapter: 9

Read chapter 8 first if you are not certain which engine you run. The two tiers use the same vocabulary for different objects, and most confusion in a pricing project starts there.

Where we would draw the line

We would not replace your pricing engine, or propose it as a phase two. Both engines execute reliably, 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 — the condition Business Central's Verify Lines action exists to catch — the model would be optimizing on top of an already ambiguous calculation. Chapter 2 is the test.

What to do this week

Read your own best-price rule out loud. Find the sentence that says which price wins when several could. On Business Central it is published and quoted above. If your commercial lead is surprised by it, that surprise is the project.
Count the price agreements that have no end date. An agreement with a start and no end is a decision somebody made once, still running. Nobody is reviewing it, because nothing asks them to.
Ask when a discount schedule was last changed, and by whom. Not which system — which person, which month. If the honest answer is the implementation, your discount structure is as old as your ERP and the margin is paying for it on every order.
Check whether anything downstream reimplements your pricing. A webshop or a quoting system with its own copy of your rules is a second source of truth, and the two drift silently. Chapter 7 is the supported alternative.

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.

Your ERP calculates every price. Why is the margin still leaking?