Why Business Central pulls the wrong price
Business Central applies the lowest price you already entered. It never asks whether that price was right.
Price lists, customer price groups, discount groups and line discounts are all places to record a number a person chose. When an order line is entered, the system applies the best price principle and selects among those numbers.
Nothing in that path asks whether the number was right. That question — what price, for this customer, on this item, today — is a data-science question, and the app we build answers it and writes the answer back for a human to approve.
4
places a price can be recorded
1
rule that picks between them
0
of them ask if the price was right
What Business Central does with price, and where it stops
Business Central is thorough about pricing as a system of record. You can set a sales price list and point it at a customer, a customer price group, a campaign or all customers. You can layer sales line discounts on top, grouped by customer discount group. You can date-bound every one of them. When a line is entered, the system resolves all of it.
The rule it resolves by is documented and specific.
“The price is the lowest permissible price with the highest permissible line discount on a given date.”
That is a well-designed rule and it does exactly what it says. But read what it ranges over: permissible prices — the ones already sitting in a price list because somebody typed them there. Business Central selects the lowest one. It is not choosing the best price for the business; it is choosing the lowest price you have already agreed to.
This is the manage-versus-optimize line, and it is not a criticism. Recording, enforcing and consistently applying commercial policy is the job of a system of record, and Business Central does it well. Computing what the policy should be is a different job, and it was never in scope.
What computing an optimal price actually requires
A price list holds one number per combination. The optimal price is not a number you store; it is the output of a function over things that move.
Response to price
How much volume moves when the price moves, estimated per segment rather than assumed globally. Two customers buying the same item rarely respond the same way, and a single elasticity across the catalogue is usually wrong everywhere.
Cost at the moment of sale
Landed cost moves. A margin target set against last quarter’s cost quietly becomes a different margin, and the price list has no way to notice.
The discount already granted
Line discounts, invoice discounts and one-off overrides compound. The realised price is frequently some distance from the list price, and the gap is where margin goes without anyone deciding it should.
Constraints you actually have
Contracted floors, most-favoured-customer terms, minimum margins, competitive positions you will not cross. An optimizer that ignores these produces recommendations nobody can act on.
None of these is a field you fill in. Each is estimated from history, and the estimate changes as the history changes. That is why the answer lives in an app that computes, not in a table that stores.
Why pricing is the first place to look
Every order line carries a price, so a pricing decision touches the whole revenue base rather than a corner of it. Nothing has to be moved, installed or physically rearranged for a better price to take effect — the change is a number, and it applies from the next order.
It is also the domain where the gap between what the ERP records and what the business intended is easiest to see. Pull the realised price against list for the last two years, segment it, and the pattern is usually visible without any model at all. That first look is cheap, and it tells you whether there is anything worth optimizing before anyone commits to building.
Dynamics is your system of record. We are your system of intelligence.
How the Pricing Optimizer works
Four steps, in tandem with Business Central rather than around it.
Read the history
Posted sales lines, the price actually charged, cost at the time, customer, item and date — pulled through the documented API and Dataverse. Read access only, and nothing leaves your tenancy.
Estimate response, per segment
Fit price response where the history supports fitting it, segment by segment. Where it does not support fitting, the app says so rather than producing a confident number from thin data.
Solve inside your constraints
Contracted floors, minimum margins and policy limits go in as hard constraints. The result is a recommended price and discount schedule that is feasible by construction, not a theoretical optimum you then have to argue down.
Write it back for approval
The recommendation returns to Business Central as a proposed price-list entry with the reasoning attached. A person approves it. The price your ERP applies is still a price a human signed off.
On your governed stack, not ours
The app is Dataverse-native and runs on Power Platform, with Azure for the model workload, shipped via AppSource where that fits your procurement. Your pricing and customer history stay inside your own tenancy.
For an IT buyer this is usually the deciding detail, and it is the reason we build this way rather than as an external service with a data export attached. We read and write through documented integration surfaces. The ERP core is not modified, so your upgrade path and your implementation partner's work are both left alone.
Your tenancy
Business Central
System of record
Posted sales lines, the price actually charged, cost at the time, customer, item and date.
Dataverse
Documented surface
Pulled through the documented API and Dataverse. Read access only, and nothing leaves your tenancy.
Power Platform
Where the app runs
The Pricing Optimizer is Dataverse-native and runs here, beside the ERP rather than around it.
Azure
Model workload
Price response estimated per segment, then solved inside your contracted floors and minimum margins.
Back to Business Central. The recommendation returns as a proposed price-list entry with the reasoning attached. A person approves it, and the ERP core is not modified.
What we need, and what we will tell you
The requirement that decides whether this is worth doing is not volume. It is variation. If every customer in a segment has always paid list, there is nothing in the history to estimate a response from, and no amount of modelling invents it.
We check this before proposing a build, and we say so plainly when the data cannot support it. A pricing recommendation from history that cannot support one is worse than no recommendation, because it looks like arithmetic.
What makes this work
- Two years or more of posted sales lines
- Price actually charged, not just list price
- Cost as at the transaction date
- Some genuine variation in past prices
- Written constraints — floors, minimum margins
When we will say no
- Everyone has always paid list
- Cost history is missing or unreliable
- Discounts live outside the ERP, in spreadsheets
- Nobody owns the pricing decision internally
What this is not
- Not a second ERP, and not a migration
- Not a change to the Business Central core
- Not a report or a chart to go and read
- Not a robot quietly changing your prices
- Not a reason to change implementation partner
- Not a shipped product with a user count to quote
A working demo exists and we build the app on request, against your systems and your constraints. That is the honest state of it. When we have delivered pricing engagements worth quoting numbers about, the numbers will appear here — and not before.
FAQ
Common questions
No, and it is not meant to. Business Central stores prices in sales price lists and applies the best price principle — the lowest permissible price with the highest permissible line discount on a given date. That is deterministic selection across values a person already entered. It answers 'which of my configured prices applies here?', never 'what should this price be?'. The second question is a data-science question, and it is the one we build for.
Not unless you ask for that, and it is not where anyone should start. The default is that the app computes a recommended price with the reasoning attached, and a person approves it. The recommendation lands in Business Central as a proposed price-list entry, so the pricing your ERP applies is still the pricing a human signed off. You can move to straight-through processing for defined segments later, once the recommendations have been right for long enough to trust.
Transaction history with the price actually charged, the cost at the time, the customer and item, and the date — ideally two years or more. Enough variation in past prices to learn from, which is the requirement most often missing: if every customer in a segment has always paid list, there is nothing to estimate a response from. We check this before proposing any build, and we say so plainly when the data cannot support it.
No, and we do not want you to. They put Business Central in and keep it running; that relationship is not one we compete for. We build a companion app that reads from and writes to documented integration surfaces. The ERP core is untouched, your upgrade path is untouched, and your partner's work is untouched.
On your own governed stack — Power Platform and Dataverse, with Azure for the model workload — and shipped via AppSource where that fits. Your data stays inside your tenancy. For an IT buyer this is usually the deciding detail: nothing here asks you to export pricing and customer history to somebody else's cloud.
Yes. The pricing question is the same on both, and the difference is where the data lives and which integration surface we read: Business Central through its API and Dataverse, Finance & Operations through OData data entities and Business Events. Business Central is where we lead because that is where the mid-market pricing pain concentrates.
The rest of the family
Pricing, pick-path, demand and inventory, contract review — and what Dynamics does with each.
Travel is roughly half of order-picking time. Where inventory lives decides how far anyone walks.
The supported integration surface, the security model, and what we do not touch.
Which one has which module, and the row where both of them say no.
How the margin work is done
Finding realised-price drift in posted sales lines, and the arithmetic behind the diagnostic.
Three-way matching cannot catch a purchase order that was priced wrong
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.
Read more6 min read
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 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.
Read more8 min readPricing & Discount Optimizer — the agreement-leakage audit (reference build)
Reference build, not a delivered engagement: three-way matching checks the invoice against the purchase order, never against the price you agreed.
Read more5 min readHow does Business Central decide which price applies?
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.
Read more6 min read
Draft, Active, Verify Lines — what does the new sales pricing experience change?
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.
Read more6 min readLine discount or invoice discount — which one is eating your margin?
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.
Read more6 min readWhat are price attributes, component codes and price structures?
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.
Read more6 min read
Two discount rules hit the same line. Which one wins?
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.
Read more6 min read
Start with the data, not the pitch
The first conversation is whether your pricing history can support this at all. If it cannot, that is a useful answer and it costs you one call.