LHDN Consolidated e-Invoice Rules for B2C Retail, F&B & Micro-Transactions

What is an LHDN consolidated e-Invoice for B2C retail and F&B?

A consolidated e-Invoice is the monthly LHDN filing for eligible sales where buyers did not ask for individual e-Invoices. At the counter, the retailer or restaurant continues to issue its normal receipt. After month-end, it gathers the eligible receipts, creates a consolidated e-Invoice addressed to General Public, and submits that document to MyInvois for validation within seven calendar days.

This separates two documents that operators often confuse:

Document	When it is created	Sent to LHDN for validation?	Recipient
Normal POS receipt	At the sale	No	The customer
Individual e-Invoice	When the buyer requests one or the transaction cannot be consolidated	Yes	The identified buyer
Consolidated e-Invoice	After month-end for the remaining eligible receipts	Yes	General Public

The consolidated document is proof of the supplier's income. Because it is issued to General Public, LHDN's published workflow does not require the validated document to be shared with each retail customer. It also does not erase the underlying receipts: receipt references remain the audit trail from the submitted lines back to the tills, branches and daily sales records.

Which sales belong in the monthly consolidated pool?

Start with the buyer's choice, then apply transaction restrictions. A routine retail or F&B sale is a consolidation candidate only when the buyer did not request an individual e-Invoice and the transaction is legally eligible for consolidation.

Use this decision table at the point of sale:

Situation	Operational treatment
Buyer requests an e-Invoice	Capture the required buyer details and issue an individual e-Invoice
Buyer does not request an e-Invoice	Issue the normal receipt and place the sale in the provisional monthly pool
Single transaction exceeds RM10,000	Issue an individual e-Invoice; do not consolidate
Sale has already received an LHDN UUID individually	Exclude it from consolidation to prevent double filing
Activity is listed by LHDN as requiring an e-Invoice per transaction	Follow the individual e-Invoice rule, even if the buyer did not ask
Receipt is voided or fully reversed	Keep it out of gross eligible sales and retain the void evidence

The RM10,000 test is per single transaction, not the month's aggregate. From 1 January 2026, a transaction over RM10,000 cannot be placed in a consolidated e-Invoice. A café can still consolidate hundreds of small bills whose monthly total is much higher; the ceiling is applied to each bill.

The threshold is not the only legal filter. LHDN's current Specific Guideline contains a table of activities for which consolidation is restricted, including specified automotive, aviation, construction, betting and gaming, agent/dealer/distributor payment, electricity and telecommunications transactions, with qualifications and effective dates. The table has changed over time. Check the current LHDN publication before configuring a permanent POS rule.

GetPay's candidate filter is intentionally narrower than a legal opinion. It checks invoice data, status, buyer TIN, filing state, provenance and the RM10,000 ceiling. It does not infer whether a free-text sale belongs to every activity-specific restriction. The operator remains responsible for separating restricted transactions before submission.

What should a retail or restaurant POS capture each day?

Consolidation becomes difficult when the month-end team receives only a grand total. Preserve transaction-level values even if the POS presents them as a daily Z report.

For every receipt, retain:

• a unique receipt or invoice reference;
• transaction date and the correct outlet or branch;
• buyer e-Invoice request status;
• any individual e-Invoice UUID returned by LHDN;
• tax-exclusive amount after discounts;
• tax amount actually charged;
• tax-inclusive total;
• the applicable tax type and rate stored by the accounting system; and
• void, refund and correction references.

In GetPay's implemented model, each source invoice becomes one line in the consolidated UBL document. This is operationally useful: a reviewer can trace Consolidated transaction INV-1234 back to its source instead of trying to reconstruct an opaque monthly total.

The arithmetic control is exact at sen level:

tax-exclusive net = source subtotal - source discount
tax-exclusive net + source tax = source total
sum of source nets + sum of source taxes = sum of source totals

For example, if a source receipt records RM47.20 net, RM2.80 tax and RM50.00 total, the line reconciles. If another source says RM47.20 net, RM2.79 tax and RM50.00 total, the one-sen difference must be resolved at source; it should not be hidden by an opposite error on another receipt.

GetPay performs both per-source and aggregate cent checks and refuses to create the monthly record when the parts do not foot. It also subtracts discount_amount before treating the subtotal as the tax-exclusive line basis. This prevents the common mistake of reporting a pre-discount subtotal while keeping a post-discount gross total.

How should an F&B operator run the month-end cut-off?

Use a daily discipline and a short month-end close rather than attempting to repair a full month on filing day.

1. At each sale: ask whether the buyer requires an individual e-Invoice. Give every buyer the normal receipt, and route requested e-Invoices through the identified-buyer process.
2. At daily close: reconcile receipt count and gross sales to the POS close report. Separate cash, card, e-wallet and delivery-platform settlement channels without changing the sales value.
3. Review exceptions: investigate voids, refunds, missing receipt numbers, duplicate imports, negative totals and transactions above RM10,000.
4. Freeze the monthly pool: after the last trading day, ensure late individual requests received within the permitted monthly cut-off have been removed from consolidation.
5. Reconcile accounting: tie the source invoices to revenue, tax and cash or clearing postings. Net bank deposits from card acquirers and delivery platforms should not replace gross sales.
6. Preview before filing: compare source count, net, tax and total against the controlled POS report by outlet.
7. Submit by day seven: preserve the consolidated document number, LHDN submission UID, document UUID, validation status and any rejection evidence.

Suppose a restaurant records RM80,000 of gross dine-in receipts, RM20,000 of delivery orders and RM2,000 of buyer-requested individual e-Invoices for August. The preliminary consolidated population is not automatically RM98,000. First remove any individually filed sales, disallowed transactions, voids and other exceptions, then reconcile the remaining receipt-level total. The bank may show less because platforms deduct fees; those fees belong in settlement accounting, not as a reduction of consolidated sales.

How does the GetPay Consolidated B2C workflow work?

From the Invoices page, open Consolidated B2C. The page defaults to the last completed month and provides three operator actions:

1. Choose the year and month, then select Preview.
2. Review the candidate count, total and source invoice references.
3. Select Save draft only for a controlled review, or Save & submit to LHDN when the population is approved.

The current GetPay query includes invoices whose:

• issue_date falls inside the selected calendar month;
• status is ISSUED, PAID or OVERDUE;
• customer_tin is empty or the General Public TIN;
• lhdn_uuid is empty, meaning the source has not already been filed individually;
• tax-inclusive total is no more than RM10,000; and
• immutable import provenance does not identify the row as a historical niagawan:* document.

Draft creation writes one monthly record numbered CONS-YYYY-MM, preserves a source_snapshot, and stores the source count plus tax-exclusive subtotal, tax and total. A duplicate company-year-month draft is refused rather than silently creating a second filing.

Submission has additional safety checks. It re-reads the source IDs to catch an invoice that acquired an individual LHDN UUID after the draft was made. It also rechecks excluded historical provenance. An atomic claim allows only one concurrent submitter to call MyInvois, so two clicks cannot intentionally race into two government filings.

On acceptance, GetPay records the LHDN UUID, submissionUid, PENDING status and submission time, then marks the consolidated record ISSUED. The History card shows each consolidated number, period, source count, total and LHDN state. Status synchronisation also recognises consolidated records alongside standard invoices and credit notes.

This is consolidated support, not raw POS ingestion. The source transactions must already exist as correct GetPay invoices. The code also creates one consolidated record per company and month; no automatic split by MyInvois payload-size limits was found. High-volume retailers should measure their generated document and follow LHDN's current submission limits and permitted splitting method before submitting.

What exactly does GetPay send to MyInvois?

GetPay builds the JSON representation of a UBL 2.1 invoice with:

• document type 01, version 1.1, and currency MYR;
• the actual submission moment as IssueDate and UTC IssueTime;
• buyer name GENERAL PUBLIC and General Public TIN;
• one InvoiceLine per source invoice;
• classification 004 with listID: "CLASS" on each consolidated line;
• each source's tax-exclusive net in LineExtensionAmount;
• each source's tax in its line TaxTotal; and
• document totals for tax-exclusive amount, tax and tax-inclusive payable amount.

GetPay maps its stored tax types to MyInvois tax categories: service to 02, sales to 01, and exempt to E. Any other value fails closed; the mapper does not guess. Those are MyInvois tax-category identifiers in the filing payload, not GetPay general-ledger account codes or a statement that a particular statutory rate applies.

The monthly record stores its period-end ci_date, but the submitted e-Invoice's issue date and time come from the real submission moment. This distinction matters: the source period describes which receipts were grouped, while issuance describes when the consolidated document was actually sent.

Does consolidation change the accounting entries?

No additional revenue should be recognised merely because the monthly e-Invoice was submitted. The accounting event occurred when each sale was recorded. A typical cash sale may have this shape, using the business's own chart of accounts:

Dr Cash / Bank / Card or e-wallet clearing
    Cr Sales revenue
    Cr Output tax, where applicable

When a card acquirer or delivery platform settles net of fees, record the settlement and fee against the clearing balance. Do not reduce the receipt's gross sales value just to match the bank deposit.

At consolidated submission:

No new sales journal entry

GetPay's consolidated create and submit routes write the filing record, source snapshot, LHDN identifiers, statuses and audit events; they do not post another journal entry. Rebooking the monthly total would duplicate revenue and output tax already represented by the source invoices.

Final filing checklist

• Confirm every receipt in the pool belongs to the selected calendar month.
• Remove buyer-requested and already individually filed e-Invoices.
• Remove every transaction exceeding RM10,000 and review current LHDN activity restrictions.
• Confirm all branches or outlets are present exactly once.
• Reconcile each source net plus tax to total at sen precision.
• Reconcile aggregate net, tax and gross to controlled POS reports.
• Preserve receipt references in the submitted line trail.
• Check tax type and rate values; do not substitute a guessed category.
• Save a draft and review the candidate population before pressing submit.
• Submit within seven calendar days after month-end.
• Retain the CONS-YYYY-MM record, submission UID, UUID, validation status and rejection evidence.
• Do not post the consolidated total as a second sale in the general ledger.