Back to Blog
Published:
Last Updated:
Fresh Content
Pricing & MarginChapter 1

How does Business Central decide which price applies?

6 min read
1,257 words
high priority
Muhammad Mudassir

Muhammad Mudassir

Founder & CEO, Cognilium AI

TL;DR

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.

How does Business Central decide which price applies?

Tier: Business Central. A customer qualifies for three overlapping agreements. One is a customer-group price, one is a campaign, one is a quantity break. Business Central puts a number on the line in a fraction of a second and never explains itself. This is what it did.

Where the calculation actually runs

Narrower than most people assume. From Record special sales prices and discounts [GA] (ms.date 2026-04-07, updated_at 2026-04-09), best prices are calculated on:

"- Sales and purchase documents - Project and item journal lines"

And the rule that resolves every contest between them:

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

Two separate things are being chosen — a unit price and a line discount percentage — and each is resolved toward the customer independently. A price that is not the lowest can still lose to one that is, and then the highest discount is applied on top of the winner.

Pass one — the customer and the item

Microsoft publishes the criteria as a numbered sequence. Step one 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? - Is a unit of measure code specified?"

Note the bill-to customer, not the sell-to customer. On an order shipping to a subsidiary and billing to a parent, the parent's agreements are the ones the engine reads.

The date criterion has a detail worth the whole section. Which date the engine compares against is not fixed — it depends on the document:

"For invoices and credit memos, this date is the date in the Posting Date field on the document header. For all other documents, it's the date in the Order Date field on their headers."

So an order taken inside a promotion window and invoiced after it closes is priced on the order date, and a credit memo raised against that same order is priced on its posting date. Those can be different prices for the same goods, and both are correct.

The unit-of-measure criterion is a superset rather than a filter:

"If so, Business Central checks for prices/discounts with the same unit of measure code, and prices/discounts with no unit of measure code."

A price with a blank unit of measure competes against your case price. If it is lower, it wins.

Pass two — quantity and currency

Step two checks the line, and this is where the tie-break becomes explicit:

"- Is there a minimum quantity requirement in the price/discount agreement that is fulfilled? - Is there a currency requirement in the price/discount agreement that is fulfilled? If so, the lowest price and the highest line discount for that currency are inserted, even if local currency would provide a better price."

"Even if local currency would provide a better price" is the sentence to take to a pricing meeting. Where a currency-specific agreement exists, it is used — and better here means better for whoever is paying. If no agreement exists in the document's currency:

"If there's no price/discount agreement for the specified currency code, Business Central inserts the lowest price and the highest line discount in your local currency."

Currency is not a rounding question. It is a different price book, and a stale exchange assumption inside one of them is a margin leak that never appears as an error.

When 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."

Last direct cost is a cost, not a price. If your setup lands there for an item, the line carries a number that was never set by anyone with a margin target — it is what you last paid a supplier. That is a configuration to find, not a default to rely on.

Purchases are not the mirror image

Microsoft flags it explicitly:

"The following steps describe how Business Central calculates the best price for sales. For purchases, the calculation is similar but is based on the available parameters. For example, item discount groups aren't supported for purchasing."

Similar but based on the available parameters is doing real work. A purchasing structure designed by analogy with the sales side will have a group layer that does not exist.

The input the algorithm never receives

Read the criteria as a list of what the engine is allowed to know: customer, customer group, item, item discount group, date, unit of measure, minimum quantity, currency.

That is a complete description of who is buying what, when, in what units, how many, in which currency. There is nothing in it about what the customer would have paid, what a competitor charges, what this item costs you today, or what happened the last four times you quoted this account.

The engine is not failing to weigh those. It was never given them. Business Central applies the rule it was configured with, correctly, every time — and the rule was written by a person, often during an implementation, often years ago.

How we build it: above the rule, not inside it

Pricing & Discount Optimizer decides which price and which line discount earn the most margin across the whole book, re-plans them as demand and cost move, and writes the answer back into the price and discount agreements Business Central already reads — behind an approval step. The algorithm above stays exactly as it is. What changes is the content of the agreements it resolves.

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, and the pricing configuration stays your implementation partner's.

Three things to check this week

  1. Find every agreement with a blank unit of measure code. Each one competes with your unit-specific prices and wins whenever it is lower. Most were created to be a fallback and are now the answer.
  2. Price one historical order twice — once as an order, once as a credit memo posted today. If the numbers differ, you have found the Order Date / Posting Date split above, and your returns process is quietly repricing goods.
  3. Look for items falling through to last direct cost. They are being sold at a number derived from what you paid, not from what you decided to charge.

If you run Finance & Operations rather than Business Central, chapter 8 is the bridge — the vocabulary overlaps and the objects do not.

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 Business Central and unsure which of your agreements is winning? Book a 15-minute call — we'll walk the decision and the model with you, on your data if you bring it. No deck.

Sources

Sources

Share this article

The work behind this series
Margin leakage in Business Central

Where realised price drifts from list, how to find it in posted sales lines, and what to do about it.

Muhammad Mudassir

Muhammad Mudassir

Founder & CEO, Cognilium AI

Mudassir Marwat's argument is that ERP systems record decisions they never optimise.

Founder & CEO of Cognilium AI; 37 AI agents in production across four products; 4 production AI products built and operated; three clouds in production (AWSGCPAzure)
Agentic AIRAG → GraphRAG retrievalVoice AIMulti-Agent Orchestration
ContactView Profile
Next in this series
Draft, Active, Verify Lines — what does the new sales pricing experience change?
Chapter 2 · 6 min
In short

Key takeaways

  • Business Central resolves both a unit price and a line discount, independently, toward the lowest price and the highest allowed discount on a given date.
  • Pass one matches on the bill-to customer and the item; pass two applies minimum quantity and currency, and a currency-specific agreement wins even when local currency would give a better price.
  • The date the engine compares against is the Posting Date on invoices and credit memos and the Order Date on everything else, so the same goods can price differently by document type.
  • Agreements with no unit of measure code compete against unit-specific ones, which makes a fallback behave like a rule.
  • When nothing matches, the line takes last direct cost or the item card unit price — a cost, not a priced decision.
What goes wrong

Common mistakes to avoid

  • Assuming the sell-to customer drives pricing. The published criteria name the bill-to customer, which differs on any parent-and-subsidiary account.
  • Copying the sales discount structure into purchasing. Microsoft states that item discount groups aren't supported for purchasing, so the group layer silently does nothing.
  • Treating last direct cost as an acceptable default. It is the last thing you paid a supplier, and nothing about it reflects a margin target.
  • Reading "best price" as best for the seller. It is defined as the lowest allowed, and every tie in the algorithm resolves the same direction.

Still have a question this did not answer?

The person who wrote this article answers these. Describe your setup and what you are stuck on — you will get a straight answer, including where we think the approach is wrong.

Ask the engineer who wrote this