Line discount or invoice discount — which one is eating your margin?

Line discount or invoice discount — which one is eating your margin?

Tier: Business Central. Most teams answer this by looking at whichever one they can see. There are two, they stack, and one of them is governed by a field Business Central hides by default.

Two discounts, and Microsoft defines them differently on purpose

From Record special sales prices and discounts [GA] (ms.date 2026-04-07, updated_at 2026-04-09):

• Sales Line Discount — "Add an amount on sales lines that have a specific combination of information. For example, customer, item, minimum quantity, unit of measure, or starting and ending date. This type works in the same way as for sales prices."
• Invoice Discount — "A discount percentage that is subtracted from the sales document total if the sum of all lines on the document exceeds a certain minimum."

The structural difference is in the last four words of each. A line discount is resolved per line, against an agreement. An invoice discount is applied to the document total, against a threshold.

"This type works in the same way as for sales prices" is the important clause: the line discount is chosen by the best-price algorithm in chapter 1 — the same two-pass sequence, resolving toward the highest allowed discount.

They stack, and neither one can see the other

The line discount is resolved first, per line, by an algorithm whose inputs are customer, item, date, unit, quantity and currency. The invoice discount is then applied to the total of those already-discounted lines, against a minimum amount.

Nothing in the published behaviour of either mechanism references the other. The line-level engine resolves toward the largest allowed discount without knowing a second one is coming; the document-level rule tests a threshold the line discounts just helped the order fail — or pass. Discount a large order hard at line level and you can drop the total below the invoice-discount minimum, so the aggressive discount produces a smaller total discount. That is arithmetic, not a defect, and it is invisible on the document.

The field that decides participation, hidden by default

Here is the sentence to take to your controller:

"The discount is calculated based on all lines on the sales document where the Allow Invoice Disc. checkbox is chosen. By default, invoice discounts are allowed. However, lines with item charges, for example, are not included in the calculation of the invoice discount."

And then:

"By default, the Allow Invoice Disc. and Line Discount Amount fields are hidden on lines. If the fields aren't available, you can add them by personalizing the page."

A checkbox that governs whether a line participates in a document-level discount is not on the screen until someone personalises the page. The default is permissive — allowed — so the common failure is not a line wrongly excluded but a line nobody realised was included.

Microsoft names the recovery, and it is manual: for lines excluded from the invoice discount, "To apply a discount to such lines, enter a value in the Line Discount Amount field on the lines."

When it calculates is not one answer

"If you're using a sales order, the discount is calculated when you add a line. For all other sales documents, such as sales invoices, the discount is calculated when you do any of the following actions: View statistics / View a test report / Print / Post"

On an order the number moves as you type. On an invoice it may not exist until somebody prints or posts. A team comparing an order to its invoice, mid-flight, is comparing a computed figure with one that has not been computed yet. This is documented and correct — and it is why "the invoice discount changed" reports so often turn out to be a timing artefact.

That behaviour depends on a setting: "If you want invoice discounts to be calculated automatically, on the Sales & Receivables Setup page, turn on the Calc Inv. Discount toggle."

Two structural oddities worth knowing

Currency. "The currency code on the sales document is used to find the invoice discount terms in the corresponding currency." If you have not set terms for a foreign currency, the local ones are used, and the calculation "uses your local currency and the exchange rate that was valid on the document's posting date." So a foreign-currency invoice discount can be a local-currency threshold seen through a posting-date rate — a number nobody chose.

The code is a customer. "Invoice discount codes are represented by existing customer cards. This connection enables you to quickly assign invoice discount terms to customers by picking the name of another customer with the same terms." Your invoice-discount taxonomy is a set of pointers at customer records. It is efficient, and it means the discount structure has no separate object to review, own, or version.

So which one is eating the margin?

On this evidence the honest answer is that we cannot tell you, and neither can anyone who has not looked at your data — but the two are not equally likely to hide. A line discount is chosen by a documented algorithm from agreements somebody wrote and can list. An invoice discount is a threshold table pointed at by customer cards, applied to a total, on lines governed by a hidden checkbox, at a moment that depends on the document type.

One of those is auditable by reading a setup page. The other is auditable by querying posted documents. Start with the second.

How we build it: optimize both, together, because the ERP optimizes neither

Pricing & Discount Optimizer decides the line discount and the invoice-discount schedule as one problem — because they land on the same order and the ERP resolves them separately — and writes the answer back into the agreements and terms Business Central already reads, behind an approval step. Both mechanisms keep working exactly as documented. What changes is that the two numbers are chosen together.

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 the setup stays your implementation partner's.

Three things to check this week

1. Personalise a sales line to show Allow Invoice Disc. Then look at a large recent order. Every ticked line contributed to a document-level discount your line-level agreements never knew about.
2. List every customer card with an Invoice Disc. Code, and check when each code's terms were last changed. Because codes are customer records, this structure tends to be inherited rather than reviewed.
3. Take one large order and compute both discounts separately. Line discount total, then invoice discount. If the second is material and nobody in the room owns it, you have found the answer to the title of this article.

Chapter 1 is the algorithm behind the line discount. Chapter 9 is the set of pricing decisions Dynamics does not make in either tier.

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 which of your two discounts is the larger one? 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)

Sources

• learn.microsoft.com — sales how record sales price discount payment agreements