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 one is normally all a company needs: the amount is worked out per document, not held on the item, so a second item earns its place only if you want a second GL code to post to.

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 header’s line-discount total, and so the e-invoice’s line allowance total, as above: the group discount is declared once, as the additional discount. (The per-line apportioned discount columns are the opposite case — they are filled from the group discount; see 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 transaction 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 and its mall-sales variant are the only things that read them.

Two things about them a reader will not guess:

• They are filled on save from the document’s Group Discount lines — the line the configured group-discount item creates — and spread over the active goods lines, leaving out rounding lines. A whole-document discount keyed onto an ordinary GL-code item is not apportioned: its columns stay empty and the report’s per-item figures stay gross of it. Key a whole-document discount through the group-discount item if you want each item’s reported figure net of it. The line’s own amounts are never changed; only the three columns are written.
• There is a repair endpoint that recomputes them for one document, or in bulk for every draft or final document of a type that carries a group-discount line. It exists because documents saved under the older rule — which apportioned only a GL-code discount line and never a Group Discount one — have them empty or filled the old way.

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.

Invoicing an order in parts

When a sales order is invoiced in two or more pieces, the group-discount line is a line in the open queue like any item line, and the knock-off copies whatever lines you tick by their open quantity, with no special treatment for it. Whichever invoice takes the discount row carries the whole discount. That is harmless when the priced goods travel with it. It is not harmless when the discount lands on an invoice whose other lines are free of charge: the apportionment has nothing to weight — every item line’s share is zero — while the discount line keeps its amount, so the invoice totals minus the discount, a balance that will not settle to zero, and its e-invoice goes out carrying that total.

Tick the discount row on the invoice that carries the priced goods, never on the one that carries only free ones. If it has already happened on a finalised invoice, the fix is a credit note.

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 among the lines it lists. Search By Invoice returns every live line of the invoice, and the discount line is one of them, so Add All — or a tick on its row — copies it onto the return like any item. That is the trap: a group-discount line on a return posts with the wrong sign (the sales return page has the journal), so a return that took the row comes out more negative than the goods by exactly the invoice’s group discount, and FINAL does not refuse it. Leave that row unticked. The goods lines then come across at their invoiced amounts, gross of the whole-document discount — so the credit is still too large by the discount, the other way — and until the sign fault is fixed the safe route is to take the discount off the returned lines’ prices as a unit discount and leave the group-discount boxes empty.

If a return already went through with the row copied, check the document for the discount line, and correct the difference with a journal entry.

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 change an item line’s own amounts. It reaches the item lines only through the apportioned columns above, which the sales reports read.
• 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.
• On the sales invoice, 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