--- title: "Business Central or Finance & Operations — which pricing engine are you actually on?" canonical_url: "https://cognilium.ai/blogs/business-central-vs-finance-operations-pricing-engine" slug: "business-central-vs-finance-operations-pricing-engine" section: "blogs" date_published: "2026-08-05" date_modified: "2026-08-05" word_count: 1508 reading_time_minutes: 7 author: "Mudassir Marwat" author_identifier: "0009-0008-1927-2598" 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" entities: [] related: - "https://cognilium.ai/blogs/what-dynamics-365-pricing-will-not-decide" - "https://cognilium.ai/blogs/contract-price-versus-po-price" - "https://cognilium.ai/blogs/dynamics-365-pricing-margin-leakage" --- # Business Central or Finance & Operations — which pricing engine are you actually on? Business Central resolves every price contest toward the lowest allowed number. Finance & Operations has no single equivalent rule — resolution depends on the concurrency mode on each component code. Tier is both. Same vocabulary, different objects, and both tiers have a which-am-I-on problem. ## Key takeaways - Business Central publishes one global resolution rule — the lowest price with the highest allowed line discount on a given date — and applies it to every document. - Finance & Operations resolves per price component code, using one of five concurrency modes, so the direction is a configuration choice rather than a product rule. - Microsoft's own API walkthrough shows a trade agreement price superseding a lower base price, so the enterprise tier does not simply resolve downward. - The shared vocabulary is misleading: price group, discount group and price list name different objects in the two tiers, and attributes are a pricing concept in only one of them. - Both tiers make "which one am I on" a historical question about what an administrator enabled, not a question the interface answers. ## 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](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-how-record-sales-price-discount-payment-agreements) `[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](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-concurrence-within-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](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-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](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-how-record-sales-price-discount-payment-agreements). "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 1. **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. 1. **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. 1. **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. ## Sources - [Record special sales prices and discounts (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-how-record-sales-price-discount-payment-agreements) - [Unified pricing management module overview](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-pricing-management-overview) - [Resolve concurrency within price component codes](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-concurrence-within-codes) - [Calculate prices for external systems through the pricing calculation API](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-pricing-calculation-api) ## Sources - [learn.microsoft.com — sales how record sales price discount payment agreements](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-how-record-sales-price-discount-payment-agreements) - [learn.microsoft.com — upm pricing management overview](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-pricing-management-overview) - [learn.microsoft.com — upm concurrence within codes](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-concurrence-within-codes) - [learn.microsoft.com — upm pricing calculation api](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-pricing-calculation-api) --- Canonical HTML: https://cognilium.ai/blogs/business-central-vs-finance-operations-pricing-engine