Group Discount: What It Is, and Everywhere It Lands

A group discount is the amount you take off the whole document rather than off a line: RM 120 off an order that came to RM 2,400, or 5% off the lot. Every retailer does it. What nobody is told is that BigLedger does not store it as a field on the document header — it stores it as another line on the document, with an item of its own.

That single decision is the reason for almost every surprise on this page: why the discount has its own account in the general ledger, why the header shows two different discount totals that do not add up the way you expect, why the e-invoice has it in a different field from your line discounts, why it sits at the bottom of the printed invoice looking like something you sold, and why the percentage you typed is nowhere to be found the next time you open the document.

None of that is visible on the screen you are looking at. All of it is predictable once you know the line is there.

Before anything works: the item

A group discount needs an item to hang on, and that item has to exist before the button does anything. It is an ordinary item record whose transaction type is Group Discount, and it is usually the only one a company ever creates — across 90 live tenants, 12 have a group-discount item at all and they hold 13 of them between them: a median of one per tenant, a maximum of two.

You then point the company at it. The setting lives on the branch, with the company as the fallback — BigLedger reads the branch’s group-discount item first and drops back to the company’s only if the branch has none. Point of Sale is the exception and keeps its own copy of the setting in the POS applet’s own defaults, so a branch that has been set up for the back office can still have a till that has not.

If it is not configured, the failure is a single toast and nothing else happens. The message is “Please configure the default group discount item code”, the discount is not added, and the document total does not move. If someone reports that the discount button “does nothing”, this is almost always it, and the fix is in Branch Settings rather than anywhere near the document.

What the line actually holds

Take GadgetSphere’s counter at GS-KV-01. An order comes to RM 2,400 across four lines, and you give the customer 5%. BigLedger works out RM 120.00 and writes one more line:

The percentage is not among them. 5% is used once, to work out RM 120.00, and is then gone: the document stores the amount and nothing else. This is the honest answer to “the group discount shows the wrong percentage on the printed invoice” — no printable can read back a percentage that was never written down, so any percentage a format shows is one it has re-derived from a base it chose itself, and it will disagree with yours the moment the base differs.

The base matters too, and it is not the subtotal you might have in mind. The percentage is taken on the sum of the line amounts as they stand at that moment, excluding rounding and excluding any group discount already there. Add a line after you key the discount and the RM 120.00 does not follow it — you have to key the discount again. At the till the base excludes one more thing: a member-point redemption line. So redeeming points does not shrink the base — a customer who pays half the bill in points still gets the full 5% of the goods, which is almost certainly what you intended and is worth knowing before someone reports it as a fault.

Keying it a second time replaces the first on a sales invoice, sales return or quotation. At the till it depends on how it was invoked: the manual discount dialog adds a second line rather than replacing the first, so a cashier who keys it twice has given the discount twice, and the till will show it. Setting the amount to zero removes the line.

Three discount figures on the header, and which is which

This is where “where did this amount come from” usually starts. The document header carries three separate discount totals, computed from the lines every time the document is saved:

So on GadgetSphere’s RM 2,400 order, if the four item lines also carried RM 60 of their own line-level discounts, the header reads: total discount RM 180, line discount RM 60, additional discount RM 120. Add the first and the third together and you get RM 300, which is RM 120 too much — and adding them is exactly what produced the complaint “Total Discount Amount plus Invoice Additional Discount Amount double-counts the discount”.

Nothing is wrong with the figures. Total discount is a grand total and the other two are its parts. The pair that partitions the discount without overlap is line discount and additional discount.

What it does to your accounts

The group discount posts to the general ledger account of the group-discount item, as a debit, on its own journal line. It does not reduce your revenue lines.

For GadgetSphere that means the RM 2,400 order still credits SALES-SMARTPHONE and friends with the full RM 2,400 between them, and debits the group-discount item’s account — typically a contra-revenue code such as SALES-DISCOUNT — with RM 120. Your gross revenue stays gross and your discounts are visible in one place, which is usually what a finance team wants and is occasionally a surprise to someone reconciling revenue to the invoice totals.

Two consequences worth planning for:

• Which account the discount lands in is a property of the item, not of the document or the branch. One group-discount item means one account for every branch’s discounts. If you want discounts split by business line, that is what the profit-centre column on the line is for — not a second discount item.
• A line-level discount behaves differently. It is netted into the line’s own amount and lands in that line’s revenue account. Line discount and group discount are not two ways of doing the same thing, and they do not produce the same accounts.

Where it lands on the e-invoice

Malaysian e-invoicing has two separate discount fields, and BigLedger feeds them from the two header figures that do not overlap:

• Total Discount Amount (LegalMonetaryTotal.AllowanceTotalAmount) is fed from the header’s line discount total — line discounts only.
• Invoice Additional Discount Amount (Invoice.AllowanceCharge, reason “Invoice Additional Discount”) is fed from the header’s additional discount — the group discount only.

Neither is fed from the header’s total discount, and that is deliberate: it is what stops the same money being declared twice.

The limit to know. The split is decided by the item’s transaction type on the discount line, not by how you meant it. A whole-document discount keyed onto a line whose item is an ordinary GL-code item rather than a group-discount item is counted as a line discount by both the header and the e-invoice. If your submitted figures put a whole-document discount in the wrong field, check the item type on the discount line before anything else.

On the printed invoice

The group-discount line is sorted to the bottom of the item list, below the goods, with rounding lines just above it. That is why customers describe it as “appearing as a line item at the bottom” — it is a line item, and the print service puts it last on purpose so the goods read as a block.

On a cash-bill printable the number of items shown to the customer excludes the group discount, the member-point discount, the rounding line and made-to-order parents. A bill for four phones and a 5% discount says four items, not five.

Four places a group discount is deliberately ignored

Each of these is a decision, not an omission, and each answers a question somebody has asked:

1. The Z-report’s cash-bill line aggregates skip group-discount, member-point-discount and rounding lines, so the day’s item counts and item-level takings are about goods sold. The bill totals still carry the discount.
2. A customer’s spending-limit usage — both the quantity and the amount consumed — skips the same three line types. A discount does not eat into a credit-controlled customer’s allowance.
3. The item count on a printable, as above.
4. The per-line apportioned discount columns, which is the subtle one and has its own section below.

The apportioned discount columns, and when they are filled

There is a second, quieter mechanism beside the group discount: three columns on every document line — an apportioned weight, an apportioned discount amount, and an apportioned transaction amount — that spread a whole-document discount back across the goods lines in proportion to each line’s net amount. They are what lets a sales report say what a particular item really earned after the document-level discount, and the sales report by document is the only thing that reads them.

Two things about them a reader will not guess:

• They are filled on save, from a line whose item is a GL-code item with a zero standard amount and a positive discount — not from a line whose item type is Group Discount. So on a document whose whole-document discount was keyed the normal way, through the configured group-discount item, these three columns stay empty and the sales report’s per-item margin is gross of that discount. Stated plainly because it is easy to act on the wrong assumption: the group discount reduces your document total and your ledger, and does not reduce any single item’s reported margin.
• There is a repair endpoint that recomputes them for one document or in bulk, which exists because documents saved before the columns did have them empty.

We could not establish whether the GL-code-only trigger is deliberate — a deliberate separation between “a discount posted to a nominal code, which we can apportion” and “a discount that is its own item, which we do not” is entirely plausible, and it is the kind of split this platform makes on purpose elsewhere. It is recorded as a question rather than asserted either way (planning/questions/ Q-1066).

The group discount you did not key: price-book promotions

At the till, a group discount is not only something a cashier types. A price-book line can carry a group-discount treatment with a minimum spend: when the total of the promotion’s own items on the bill reaches that minimum, BigLedger adds the group-discount line itself — either a fixed amount or a percentage, depending on how the promotion is written.

This is worth knowing for two opposite reasons. It is a capability most readers do not know they have: “spend RM 2,000 on laptops this weekend and take RM 150 off the bill” is a price-book rule, not a staff instruction. And it is the answer when a bill shows a group discount nobody remembers applying — look at the price book before you look at the cashier.

On a sales return

Building a return by searching for the original invoice copies the item lines, with each line’s saved amounts scaled by how many you are taking back, and with the invoice’s own saved figures treated as authoritative — the current price list is deliberately ignored, which is why a return credits what the customer actually paid.

The group discount is not among the lines it copies, because it is not an item line and cannot be selected from a list of goods. A return built this way therefore credits the goods at their invoiced amounts, gross of the whole-document discount, unless you add a matching group discount to the return yourself — which the return screen can do, with the same button and the same line shape.

The support corpus records the opposite symptom too — “sales return group discount double deduction”, “SR amount more negative than invoice amount”. Current source does not produce it: the copy reads item lines only. We could not establish from source which earlier behaviour did, so if you are looking at a return whose total is more negative than the invoice, check the document for two group-discount lines — one copied and one keyed — rather than assuming the arithmetic is wrong.

Checking one in thirty seconds

On any document you suspect:

1. Scroll to the bottom of the lines. A group discount is a line. If you cannot see it there, the document does not have one, whatever the totals suggest.
2. Count them. One is normal. Two means it was applied twice — common at a till, where the manual dialog adds rather than replaces.
3. Compare the header’s three discount figures. Additional should equal the group-discount line’s amount; line should equal everything else; total should be the two added together. If additional is zero but a whole-document discount is plainly there, the discount line is sitting on the wrong item type — and that is the same fault that will misfile it on the e-invoice.
4. Then look at the journal. One debit to the discount item’s account for the whole amount, and revenue untouched.

What it will not do

• It will not store the percentage. Only the amount survives the save.
• It will not follow the document. Add, remove or reprice a line afterwards and the discount stays at the amount it was; nothing recalculates it.
• It will not reduce an item’s reported margin. See the apportioned columns above.
• It will not net against your revenue accounts. It posts to its own.
• It will not be split across branches or profit centres by itself. The item decides the account; the line’s own branch and profit-centre columns decide the cut.
• It cannot be added after the document is final. The control is present only while the document is in draft — which is the correct behaviour, and is the “cannot edit, greyed out” shape rather than a fault.

Related documentation