How discounts post in LS Central

Posting & finance · 7 min read

"Discounts were about ten percent of sales last month." Can your ledger actually prove that — or is it a POS report nobody has ever tied to the G/L? Whether a discount shows up as its own number in the accounts, or silently shrinks revenue before it posts, is a setup decision most stores made during implementation and never revisited. This guide follows a discount from the POS key that creates it to the account it lands in, then gives a verification procedure and the misconfigurations that make discount totals impossible to trust. Discount posting is accounting setup: this is general information, not professional advice.

Two discounts, two very different paper trails

At the POS, discounts are created by different keys with different scopes. LS Retail's POS command reference draws the line clearly:

• Line discounts act on one sales line. DISCAM gives a discount amount on a specific line; DISCPR gives a discount percentage on a specific line; DISCPAYM works the other way round — the cashier types the total amount the customer will pay for the line and the system calculates the line discount amount.
• Total discounts act on the whole transaction. TOTDISCAM sets a discount amount on the total; TOTDISCPR sets a discount percentage on the total; TOTPAYAM takes a total payment amount and the system calculates the total discount from it.

One more category is worth separating before it confuses the verification step: LS Central offers. An offer works as a price change — the POS shows the changed price rather than a discount from the former price — and a discount offer is enabled before it is sent to the POS terminals. Promotional price changes and cashier-given discounts are different mechanisms, and only one of them should be expected in the discount accounts.

Where a discount can land: separate account or netted revenue

The switch is the Discount Posting field on the Sales & Receivables Setup page, which specifies which types of sales discounts post separately. Microsoft Learn documents its options plainly:

When a discount posts separately, the destination comes from General Posting Setup for the combination in play: the Sales Line Discount Account is where line discounts applied to individual sales lines are posted, and the Sales Invoice Discount Account is where the document's total invoice discount is posted. Microsoft Learn confirms that whether a G/L entry for the discount amount is created at all depends on that Discount Posting field — under No Discounts there is no discount entry to find, by design. POS transactions reach the ledger through statement posting, so the principle and the accounts have to be right before the statement posts, not after. (See how store posting groups route POS sales for the combination side of this.)

One terminology trap when tracing a POS discount on the Business Central side: the POS calls it a total discount, while the posting setup calls the document-total destination the invoice discount account. They are the two ends of the same trace — the Sales Inv. Disc. Account is where a total discount should appear when your principle posts invoice discounts separately. Start there when hunting a missing total discount; if the account is empty for a day when the POS clearly gave total discounts, the suspects, in order, are the Discount Posting principle, a blank discount account on the combination that store and those items used, and an unposted statement — all three are covered below.

The decision: which principle fits

• Choose All Discounts when anyone — finance, a category manager, a franchise report — will ever ask "how much did we discount?" as a ledger number. It is the only setting where both discount kinds are visible per posting-group combination.
• Choose Line Discounts only when line-level markdowns matter but basket promotions are tracked elsewhere and netting them is a deliberate reporting choice, not an accident.
• Choose No Discounts only when the business genuinely reports net revenue and accepts that the G/L can never answer the discount question. The POS still records the discounts; the ledger just cannot prove them.

Whatever you choose, write it down next to the mapping worksheet. Half the "discounts are wrong" investigations end at the discovery that the setting was changed at some point and nobody recorded when, so two periods were posted under different principles and cannot be compared.

How to verify posted discount totals

1. Pick one store and one short period — a day is enough. Note the discount totals the POS side reports for that store and day, split into line discounts and total discounts if your reporting allows it.
2. Confirm the statements for that day are posted. Discounts reach the G/L through statement posting, so an unposted statement explains a gap better than any setup theory.
3. Read the Discount Posting setting on Sales & Receivables Setup before looking for entries. It tells you which of the two discount kinds should exist as G/L entries at all.
4. Sum the G/L entries on the Sales Line Disc. Account and the Sales Inv. Disc. Account for the statement's posting date and the store's posting-group combination.
5. Compare. The separately-posted kinds should tie to the POS totals for the day; the netted kinds should be absent from the discount accounts and visible only as lower revenue. A mismatch inside a separately-posted kind is a real defect — work the misconfiguration list below.

Common misconfigurations

• Discount Posting set to No Discounts while management asks for discount reporting. Nothing is broken; the ledger was told not to keep the numbers.
• Discount accounts blank on some General Posting Setup combinations. The accounts are set per business-group and product-group combination, so a new store group or product group can quietly post its discounts somewhere else — or fail to separate them — while older combinations behave.
• Blocked discounts on charges. A real Dynamics Community case: a TOTDISCPR total discount discounted the line items but not a retail charge added at TOTAL, and the fix was the charge's three block settings — Block Line Discount Offer, Block Infocode Discount, and Block Total Discount Offer. If a total discount "mostly works," check what it is blocked from touching.
• Expecting offers in the discount accounts. Offers change the price at the POS instead of recording a discount from the former price, so a promotion can be entirely real and still leave the discount accounts unmoved.
• Comparing periods across a principle change. Discount Posting changed mid-year makes the two halves of the year answer the discount question differently; the trend line is an artefact, not a behaviour change.

What success looks like

For the test day, the G/L discount account totals tie to the POS discount totals for every discount kind your Discount Posting principle says should post separately; revenue for the netted kinds is lower by exactly their amounts; and a second store with a different posting-group combination produces the same tie-out against its own accounts. Once that holds, "discounts were about ten percent of sales" is a number the ledger can defend — and if your statements are part of a wider close, the end-of-day routine is where this check belongs.