---
title: "Why Business Central Pulls the Wrong Price on an Order"
canonical_url: "https://cognilium.ai/dynamics-365/pricing-optimization"
slug: "dynamics-365/pricing-optimization"
section: "dynamics-365"
page_type: "pillar"
date_modified: "2026-09-29"
description: "Business Central applies the lowest price you already entered. It never asks whether that price was right. See why the wrong price reaches the invoice."
publisher: "Cognilium AI"
author: "Mudassir Marwat"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
answers:
  - "What Business Central does with price, and where it stops"
  - "What computing an optimal price actually requires"
  - "Why pricing is the first place to look"
  - "How the Pricing Optimizer works"
  - "On your governed stack, not ours"
  - "What we need, and what we will tell you"
  - "What makes this work"
  - "When we will say no"
  - "What this is not"
  - "The rest of the family"
  - "Start with the data, not the pitch"
entities: []
related:
---

# Why Business Central Pulls the Wrong Price on an Order

**Does Dynamics 365 Business Central optimize pricing?** 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.


## In short

**Does Dynamics 365 Business Central optimize pricing?** 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.

**Do you change prices automatically in our ERP?** 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.

**What data do you need before this is worth doing?** 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.

**Do we have to leave our Dynamics implementation partner?** 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.

**Where does the app actually run?** 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.

**Is this available for Finance & Operations too?** 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.

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

Stacked coils of steel wire in an industrial yard

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

A lattice of cut and layered kraft packing paper

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

Yellow painted boundary lines on a concrete floor

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.

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.

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.

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.

**Margin and discount optimization for Microsoft Dynamics 365** A companion app that estimates price response from posted sales history, solves for a margin-optimal price and discount schedule inside contracted floors and minimum-margin constraints, and writes the recommendation back into Dynamics 365 Business Central for human approval. Built on Power Platform, Dataverse and Azure without modifying the ERP core.

Mid-market manufacturers, distributors and retailers running Microsoft Dynamics 365 Business Central

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.


## 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.”

Microsoft Learn, Extending Price Calculations (Business Central)

That is a well-designed rule and it does exactly what it says. But read what it ranges over:

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.

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.


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


## 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

Price actually charged, not just list price

Written constraints — floors, minimum margins


## When we will say no

Discounts live outside the ERP, in spreadsheets

Nobody owns the pricing decision internally


## What this is not

Not a change to the Business Central core

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.


## The rest of the family

Pricing, pick-path, demand and inventory, contract review — and what Dynamics does with each.

Technical drawings and drafting tools on a desk

Travel is roughly half of order-picking time. Where inventory lives decides how far anyone walks.

A factory floor lined with machinery and stacked crates

The supported integration surface, the security model, and what we do not touch.

Abstract blue light trails against a dark background

Business Central vs Finance & Operations

Which one has which module, and the row where both of them say no.

A set of balance scales holding two chess pieces

Finding realised-price drift in posted sales lines, and the arithmetic behind the diagnostic.


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


---

Canonical HTML: https://cognilium.ai/dynamics-365/pricing-optimization