Draft, Active, Verify Lines — what does the new sales…

Draft, Active, Verify Lines — what does the new sales pricing experience change?

Tier: Business Central. You changed a price on an active price list. You saw it save. It is not the price Business Central is charging, and nothing told you.

First: do you even have it?

Two Business Central tenants on the same version can behave differently here, and the reason is published in a Note at the top of Record special sales prices and discounts (ms.date 2026-04-07, updated_at 2026-04-09):

"2020 release wave 2 introduced new, streamlined processes for setting up and managing prices and discounts. If you're a new customer using the latest version, you're using the new experience. If you're an existing customer, whether you're using the new experience depends on whether your administrator enabled the New sales pricing experience feature update in Feature Management."

A new tenant has it. An older tenant has it only if somebody turned it on. The page is explicit that price lists themselves depend on this: "Using price lists requires that your administrator enabled the New sales pricing experience feature update in Feature Management."

The capability is [GA] and has been for years. The 2021 release wave 1 plan entry (ms.date 2021-05-03) carries a check mark and Apr 7, 2021 for public preview, and a check mark and May 3, 2021 for general availability, enabled for "Users by admins, makers, or analysts". That page is also archived — it opens with "This content is archived and is not being updated" — which matters in section 6.

The status model, list level

The straightforward half:

"By default, the status of new price lists is Draft. Draft price lists aren't included in price calculations. When you're done adding lines and want to start using the prices, change the status to Active."

A draft list is inert. That is the intended safety property, and it works.

The status model, line level — this is the one that costs money

Now the Note that governs day-to-day editing:

"When you edit a line in an active price list the status of the line becomes Draft, and the line isn't considered during price calculation until you use the Verify Lines action. After you verify the price, the status of the line becomes Active and it's considered in price calculations."

Read it against chapter 1. That article's algorithm resolves toward the lowest applicable price. A line sitting in Draft is not applicable. So the engine does not fall back to your new number — it falls back to whatever else matched: another agreement, another price list, or the item card price.

You raised a price and the system kept charging the old one. No error, no warning, no failed posting. The document is valid and the margin is gone. It is not a bug — the behaviour is documented in two places, and both say the same thing. It is a workflow that assumes somebody remembers a second action.

The related toggle:

"When the Allow Editing Active Price toggle is turned off, to update prices in a price list you must change the status of the price list to Draft, make your change, and then reactivate the price list."

Turned off is the safer setting, because the whole-list round trip is visible and hard to half-finish. Turned on is the convenient one, and convenience is what leaves lines in Draft.

What Verify Lines is actually for

Not a spell-check on your number:

"After you modify prices, you must use the Verify Lines action to verify the prices against other price list lines. Verifying prices helps avoid duplicates and ambiguity during price calculation."

It is a collision check across your whole price book, and the collision it prevents is stated plainly elsewhere on the page: "You can't have two items that have the same settings but different prices. If that happens, a message displays when you activate the price list."

That constraint is the reason this cluster's pillar argues optimization sits above the engine rather than inside it. Business Central will not let two contradictory rules coexist — but it has no opinion about which of two compatible rules should have been written.

The conversion fork you chose once

When the feature update is enabled, a data-update guide runs, and one toggle sets the shape of your pricing for years:

"If you want to work with all prices on a single page, turn it on. Existing prices convert to one default price list for each of the following documents: Sales / Purchases / Job sales / Job purchases"

Or:

"To use sales price lists, turn it off. Existing prices convert to a new price list for each combination of the following things: Customer / Customer group or campaign / Starting and ending dates / Currencies"

followed by the sentence that decides most people's experience of the module:

"If you have many combinations, you get many price lists."

And a Note that catches teams out:

"If prices are set only on item or resource cards, default price lists aren't updated with those prices during the data update."

Prices that lived only on item cards do not arrive. The Suggest Lines action brings them in afterward, but only if you know to look.

Two Microsoft pages, one difference worth knowing

The live page lists four conversion dimensions. The archived 2021 plan page lists five:

"If Use default price lists is turned off, existing prices will be converted to new price lists according to what they apply to, what starting and ending dates they have, currencies, units of measure, and the minimum quantity."

Units of measure and minimum quantity appear on the archived page and not on the current one. The live page governs — the archived page says of itself that it is not being updated — but if you are auditing a tenant converted in 2021, the list you got may be the longer one, and that is more price lists than the current documentation would lead you to expect.

How we build it: above the list, never a second price store

Pricing & Discount Optimizer decides which price and which discount earn the most margin across the whole book, re-plans them as demand and cost move, and writes the answer into the price lists Business Central already reads — behind an approval step. Into existing lists, never a parallel one: a price list is already executed by the ERP and understood by your commercial team, and an optimizer that needs its own price store has become a second system of record.

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.

Four things to check this week

Filter the Prices Overview page for lines in Draft status. Every one is a price somebody changed and nobody activated. This is the single highest-yield query in this article.
Check the Allow Editing Active Price toggle on Sales & Receivables Setup. On means your team can edit in place — and can leave lines in Draft. Decide it deliberately rather than inheriting it.
Ask which way the Use default prices toggle went, and when. It explains whether you have four price lists or four hundred.
Run Suggest Lines against a default price list and see what appears. Prices that lived only on item cards never made the conversion.

Chapter 1 is the algorithm those lists feed. Chapter 3 is the second discount that lands on top of all of it.

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/

Want to know how many of your price list lines are sitting in Draft? Book a 15-minute call — we'll walk the decision and the model with you, on your data if you bring it. No deck.

Draft, Active, Verify Lines — what does the new sales pricing experience change?