Pricing optimization for
Dynamics 365 Business Central

Business Central stores your prices and decides which of them applies. It does not decide what the price should be. 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.

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:

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.

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.

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.

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.

Four steps, in tandem with Business Central rather than around it.

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.

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.

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.