Realised price versus list, discount drift, and finding the leak in posted sales lines.
Most discounts are approved by rule of thumb, not by how customers actually respond to price. Here's how pricing optimization on Dynamics 365 recovers the margin that leaks between the list price and the invoice.
Ordered by chapter. Each post stands alone but builds on the one before it.
Dynamics 365 checks the invoice against the purchase order and the receipt against the purchase order — never the purchase order against the agreement that was supposed to price it. Why every three-way matching control passes on a PO that was priced wrong, and where the leak sits.
Business Central defines the best price as the lowest one with the highest discount allowed on the day — its own documentation says so. Finance & Operations builds the price from attributes and component codes you configured. Both tiers calculate correctly and neither decides what the price should be, which is where the margin goes.
Reference build, not a delivered engagement: three-way matching checks the invoice against the purchase order, never against the price you agreed.
Business Central runs a published two-pass algorithm to pick a price — customer and item first, then quantity and currency — and resolves ties toward the lowest price with the highest line discount. Tier is Business Central. Here is each step, quoted, and the one input the algorithm never sees.
Editing a line on an active Business Central price list silently sets that line back to Draft, and it stops counting in price calculation until someone runs Verify Lines. Tier is Business Central. Here is the status model, the toggle that governs it, and why the change you made may not be the price you are charging.
Business Central has two sales discounts that stack — one resolved per line by the best-price algorithm, one applied to the document total afterwards. Tier is Business Central. Neither knows the other's size, and the field that decides which lines participate is hidden by default.
Finance & Operations builds a selling price from four objects — price attributes, price component codes, price structures and concurrency modes — and adds base price to price adjustment to get there. Tier is Finance & Operations. Here is what each one is, in Microsoft's words, and the four you can only have one of.
Finance & Operations has five concurrency modes for deciding which of several competing discounts applies to one order line, plus three system-level models that change what those modes mean. Tier is Finance & Operations. Microsoft publishes one worked example, and it is the only trace of the algorithm.
Two Finance & Operations pricing modules use similar or identical navigation paths, only one can be active at a time, and Microsoft has deprecated the older one. Tier is Finance & Operations. The menu will not tell you which you are on — here is the test that will.
Yes — the pricing calculation API went generally available in June 2026 and returns a full price breakdown without creating a sales order. Tier is Finance & Operations. It also has a published Not-supported column, and a default that returns simple discounts only.
Business Central resolves every price contest toward the lowest allowed number. Finance & Operations has no single equivalent rule — resolution depends on the concurrency mode on each component code. Tier is both. Same vocabulary, different objects, and both tiers have a which-am-I-on problem.
Both Dynamics tiers resolve prices correctly and neither chooses what the price should be. Tier is both. Seven decisions no page in this cluster's sources claims to make — each bounded to the pages we searched, with what Microsoft does ship nearby stated first.