Business Central or Finance & Operations

Business Central or Finance & Operations — which pricing engine are you actually on?

Tier: both. The two tiers share a vendor, a vocabulary and a marketing family, and almost no pricing objects. Getting this wrong is why a pricing project's first three weeks disappear.

The literal question, answered quickly

If your users say Sales Prices, Sales Line Discounts, price lists and customer price groups, you are on Business Central. If they say price attributes, price component codes, price structures and concurrency modes, you are on Finance & Operations, in the Unified pricing management module.

If they say Pricing management and the screens do not match the documentation, read chapter 6 — you may be on a deprecated module that shares its menu paths with the supported one.

The sharpest difference: which way a contest resolves

Business Central publishes a single global rule. From Record special sales prices and discounts [GA] (ms.date 2026-04-07):

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

One sentence, one direction, every document. It is even explicit across currencies: the currency-specific agreement is used "even if local currency would provide a better price."

Finance & Operations has no equivalent single rule on the pages we opened. Resolution is a property of each price component code, chosen from five concurrency modes documented in Resolve concurrency within price component codes [GA] — one of which competes for "the largest discount (lowest price)", one of which combines everything, and one of which "always applies … last within a price component code".

The direction is not fixed, and Microsoft's own worked example shows it going the other way. In the pricing calculation API walkthrough [GA] (ms.date 2026-03-24), a product's base price of $7.99 is superseded by a trade agreement price of $30.00, and $30.00 is what the discount is then taken off.

So: Business Central resolves down, by published rule. Finance & Operations resolves according to how you configured each component code, and a trade agreement can raise a price rather than lower it. That is the single most consequential difference for anyone who has worked in one tier and is now in the other.

Bound: this compares the pages listed in this article's sources. It is a claim about the documented resolution rules on those pages, not a statement that no other Finance & Operations mechanism exists.

The same words, pointing at different things

Price group — On Business Central: A customer price group — a grouping of customers that agreements attach to · On Finance & Operations: "price component groups" group component codes; "price attribute groups" group attributes. Neither is a customer grouping
Discount group — On Business Central: "item discount groups" on the line, checked in pass one of the best-price algorithm · On Finance & Operations: Discounts are pricing rules assigned to a price component code, resolved by concurrency mode
Price list — On Business Central: A first-class object with a Draft / Active status and a Verify Lines action · On Finance & Operations: Not the primary object. "Price structures help you understand the sequence of your price component codes"
Base price — On Business Central: Implicit — "the unit price from the item card", used when nothing matches · On Finance & Operations: An explicit component: "Base price + Price adjustment = Selling price"
Attribute — On Business Central: Not a pricing concept · On Finance & Operations: The foundation: price attributes "use information about customers, products, sales order headers, and sales order lines"

Read the last row twice. On Finance & Operations, the pricing model is built from attributes of the customer, the product, the order header and the order line. On Business Central, the equivalent inputs are a fixed published list of criteria — customer, item, date, unit of measure, minimum quantity, currency. One is extensible by configuration; the other is a defined algorithm.

Where a rule physically lives

On Business Central a rule is an agreement row: a combination of customer or group, item or item discount group, dates, unit of measure, minimum quantity and currency, sitting on a price list or a sales price page. You find it by looking at a customer or an item.

On Finance & Operations a rule is a record assigned to a price component code: "When you create a price and discount rule record, you also assign that record to a price component code." You find it by looking at the component code, then at the structure that sequences the codes.

That difference decides who can audit your pricing. On Business Central, a commercial person can list the agreements attached to a customer. On Finance & Operations, the same question requires knowing which component codes exist, what sequence the structure puts them in, and which concurrency mode each carries — which is chapter 4.

Bulk change looks nothing alike

Business Central: an Adjustment Factor on a worksheet, per Record special sales prices and discounts. "For example, you would enter 1.15 in Adjustment Factor for a 15% increase in item price" — and the batch job "only creates suggestions and it doesn't implement the suggested changes."

Finance & Operations: you do not multiply a list. You change rules, and the engine recomputes. The capabilities list on the module overview attributes to Commerce Scale Unit Core the ability to "Simulate prices, and show detailed price calculations" — so the enterprise tier's answer to what will this change do is a simulation, not a worksheet of proposed rows.

Both stop in the same place. A suggestion you approve, or a simulation you read. Neither proposes which change to make.

Both tiers have a which-am-I-on problem, for opposite reasons

This is the symmetry worth taking away.

Business Central: two pricing experiences, and whether you have the newer one depends on "whether your administrator enabled the New sales pricing experience feature update in Feature Management". A new tenant has it; an older one may not. Chapter 2.
Finance & Operations: two pricing modules, and they "use similar or identical navigation paths in the Supply Chain Management user interface, so only one of these modules can be active at a time". Chapter 6.

In both tiers the interface is a poor witness, and in both the answer is historical — what did someone enable, and when. That is the actual first question of any pricing project, on either tier, and it is the one most often assumed rather than established.

How we build it: one Optimizer family, two tiers, the same last mile

Pricing & Discount Optimizer decides which prices and discounts earn the most margin across the whole book, re-plans them as demand and cost move, and writes the answer back into whichever objects your tier executes — price lists and agreements on Business Central, pricing rules under your component codes on Finance & Operations — behind an approval step. Both tiers sit on the same governed stack, so one Optimizer family surrounds both. What differs is the write target, not the decision.

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 we do not step on your implementation partner.

Three things to check this week

Establish which experience or module you are on, from history rather than screens. Who ran feature management, and when. Both tiers make this the first question.
Ask your commercial lead to list the rules affecting one large customer. On Business Central that is a short task. If it is not, you are on Finance & Operations and the answer needs the component codes.
Find out which direction your engine resolves. On Business Central it is published and it is down. On Finance & Operations it is whatever concurrency mode sits on each component code.

Chapter 1 is the Business Central algorithm. Chapter 4 is the Finance & Operations structure. Chapter 9 is what neither of them decides.

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/

Not certain which pricing engine you are running, or what it is deciding? Book a 15-minute call — we'll walk the decision and the model with you, on your data if you bring it. No deck.

Business Central or Finance & Operations — which pricing engine are you actually on?