Why restaurants have it harder
Most businesses issue a handful of invoices a day. A restaurant can run into the hundreds — every dine-in bill, takeaway order and delivery transaction. Add peak-hour pressure, mixed payment methods, and staff trained to cook rather than to navigate a tax portal, and the compliance problem is real.
But the volume problem is smaller than it first looks, because most restaurant transactions never become an individual e-invoice at all. Understanding which ones do, and when the rest get reported, is the whole of the job.
First: does the mandate reach you?
LHDN's MyInvois rollout affects many Malaysian F&B businesses, but the obligation depends on your annual turnover or revenue, the implementation phase that follows from it, and whether an exemption applies.
LHDN currently exempts taxpayers with an annual turnover or revenue of less than RM 3,000,000, subject to carve-outs where the taxpayer has a corporate shareholder, holding company, or related company or joint venture of at least that size. A single-outlet restaurant and a 30-outlet group can therefore be in quite different positions. The threshold has been revised more than once, so check yours against the current guideline on the LHDN e-Invoice microsite rather than against a figure you remember. The complete guide to e-invoicing in Malaysia sets out the phases, and who is exempt from e-invoicing covers the exemption and its carve-outs.
The rest of this guide is for restaurants that are in scope.
Daily capture, monthly consolidation
This is the distinction that resolves most of the confusion in F&B e-invoicing guidance, including in the earlier version of this article.
Consolidation is monthly. LHDN allows a supplier to aggregate transactions with buyers who do not require an e-invoice on a monthly basis, and to submit that consolidated e-invoice within seven calendar days after the month end. There is no daily consolidated e-invoice in the rules. Consolidated e-invoices covers the permitted structures and the transactions that cannot be consolidated.
Capture is daily. What happens at close of service is operational, not a submission:
The table follows the ordinary workflow. During an applicable interim relaxation, eligible transactions may instead be consolidated even when a customer requests an individual e-invoice; exclude any transaction already covered by one.
| At close of each service day | Within 7 calendar days after month end |
|---|---|
| Cash up and reconcile the POS against takings | Build the consolidated e-invoice for the month |
| Identify bills where a customer requested an e-invoice | Apply the description-field requirements for your circumstances |
| Confirm any individual e-invoices issued were validated | Exclude everything already covered by an individual e-invoice |
| Flag any single bill above RM 10,000 | Split across submissions if the size or count limits require it |
| Keep receipt numbers in an unbroken chain | Submit, confirm validation, resubmit anything rejected |
The reason to do the daily half properly is not compliance timing — it is that reconstructing a month of covers at month end, from a POS export nobody has looked at since, is where errors come from. A day's discrepancy found the same evening is a five-minute conversation. Found five weeks later it is an investigation.
What goes into the monthly consolidated e-invoice
| Field | Value |
|---|---|
| Buyer's Name | General Public |
| Buyer's TIN | EI00000000010 |
| Buyer's Registration / Identification Number | NA |
| Buyer's Address | NA |
| Buyer's Contact Number | NA |
| Buyer's SST Registration Number | NA |
For the line items, LHDN permits one or a combination of three methods:
- the summary of each receipt as a separate line item;
- the list of receipts in a continuous receipt-number chain as line items, with a new line item wherever the chain breaks; or
- per branch or location, using either method above for that outlet's receipts.
For a multi-outlet group, method 3 is usually the sensible one — each outlet consolidates its own receipts.
Whichever method you use, the receipt reference number for each transaction is required in the Description of Product or Service field (the interim relaxation period below allows free text instead). This is more demanding than the "summarise by food, beverage and service charge" approach many restaurants assume, and it makes the receipt-numbering discipline at the POS the foundation of the whole workflow.
Submission limits apply: 5MB per submission, 100 e-invoices per submission, 300KB per e-invoice. A busy month may need splitting across several consolidated documents.
The interim relaxation period
Eligible taxpayers in the specified 1 January or 1 July 2026 implementation phases have an interim relaxation period until 31 December 2027. During it, LHDN allows free text in the Description field instead of receipt references, permits consolidation for all activities, and does not oblige you to issue an individual e-invoice even where a customer requests one — provided you are issuing consolidated e-invoices.
Build towards the rules above; treat the relaxation as time to get the POS discipline right, not as the permanent position. See what happens if you miss the e-invoicing deadline.
When an individual e-invoice is needed
The customer asks for one
The business-lunch case. A diner needs the bill as a claimable expense and asks for an e-invoice. Outside an applicable interim relaxation, handle the request under the ordinary individual-invoice rules; during eligible relaxation, the transaction may instead be consolidated as described above.
Two things make this less painful than it sounds. First, for a Malaysian individual (MyKad/MyTentera) or a MyPR/MyKAS holder, LHDN's concession lets them provide a TIN, their identification number, or both — a Malaysian diner does not have to produce a TIN. A non-Malaysian visitor gives a TIN, or a TIN with their passport number; where they have no TIN, the guideline allows the general TIN together with the passport number. Second, the transaction that gets an individual e-invoice is then excluded from the monthly consolidated document; it is not reported twice.
The practical requirement is a way for the front-of-house to capture a name and MyKad or company details at the point of payment without stalling the queue — and a rule about how long after the meal a request will still be honoured. LHDN's own example shows a supplier declining a request made after the consolidated e-invoice for that month had already been issued, so set that cut-off deliberately rather than by accident.
The bill exceeds RM 10,000
From 1 January 2026, across all industries, any single transaction exceeding RM 10,000 cannot be consolidated and needs its own e-invoice — except while you are using the interim relaxation period described above, which allows consolidation of all transactions.
For most restaurants this is rare, and it is exactly the kind of rule that gets missed because it is rare: a wedding banquet, a corporate function, a large private dining booking. Put the check in the POS so the flag is raised at the table, not at month end.
The customer is a business
Corporate catering, company accounts, event bookings billed to a company: these buyers need the document for their own tax reporting, so treat an individual e-invoice as the default rather than waiting to be asked.
Dine-in, takeaway and delivery
The treatment does not change with the channel — what changes is where the transaction data lives.
Dine-in. The POS is the source of truth. Bills, service charge, SST and rounding all come from it.
Takeaway and counter service. Same as dine-in, with higher volume and shorter interactions, which makes the "can we capture a MyKad quickly?" question sharper.
Delivery through your own channel — phone orders, your own website, WhatsApp. You are the supplier dealing with the customer directly, and the ordinary rules apply.
Delivery through an aggregator platform. This is genuinely different. For transactions concluded on an e-commerce or intermediary platform, LHDN treats the platform provider as assuming the Supplier role towards the purchaser, and the platform issues a self-billed e-invoice to the merchant for the supply. If a meaningful share of your revenue comes through a delivery platform, that revenue is something you receive documents for and reconcile, not something you consolidate yourself. Confirm how each platform you use actually operates, and see self-billed e-invoices in Malaysia and the e-commerce guide.
Getting this wrong in either direction is costly: consolidate platform orders that the platform is already self-billing you for, and you have reported the same revenue twice.
Payment methods, service charge and rounding
Payment method does not change whether a transaction is reported. Cash, card, e-wallet or a split across them, the transaction is captured the same way.
| Payment method | Reported? | Note |
|---|---|---|
| Cash | Yes | No digital trail, so POS capture is the only record |
| Credit/debit card | Yes | Terminal reference is useful for reconciliation |
| E-wallet (Touch 'n Go, GrabPay) | Yes | Provider transaction ID aids reconciliation |
| Split across methods | Yes | One transaction, one document |
Payment Mode is an optional field in LHDN's list, so recording it is for your own reconciliation rather than for validation.
On the rest of the bill:
- Split bills. The document covers the transaction. How the table divides payment among themselves does not appear.
- Service charge. A line item with its own tax treatment.
- SST. Broken out correctly. Note that the tax type code for Service Tax is
02; code06means Not Applicable. - Rounding. There is a Rounding Amount field for the Malaysian 5-sen rounding, applicable at invoice level.
POS integration is the whole game
The only workable arrangement for a restaurant is that the reporting falls out of the POS rather than being a separate task somebody performs.
- Staff takes the order — no change to the process.
- POS calculates totals, service charge, tax and rounding.
- Customer pays; a receipt with a clean sequential number is issued.
- If an individual e-invoice is required, or you choose to issue one, the POS captures the customer details; exclude that transaction from consolidation.
- The POS flags a bill above RM10,000 so you can check whether an individual e-invoice is required under the applicable rules.
- At month end, consolidate eligible receipts that are not already individually invoiced, applying the description-field requirements for your circumstances.
The critical point: staff should not need to do anything extra in the normal case. If compliance requires waiters to fill in fields on a Friday night, it will not survive a Friday night.
Practical groundwork that removes most of the per-transaction effort:
- Pre-configure the menu with classification codes, tax types and unit measures, so no per-bill data entry is required.
- Keep receipt numbers sequential and unbroken. Breaks in the chain force additional line items in the consolidated document and complicate every later lookup.
- Validate locally before submitting. Check the document against LHDN's field requirements before it goes to MyInvois — see the 55 MyInvois fields and which are actually mandatory.
- Use API submission for volume. LHDN's Specific Guideline (section 3.6.4) sets MyInvois system limits of 100 e-invoices, 5MB per submission and 300KB per e-invoice, so a busy month may need splitting. Uploading through the portal adds its own, separate Excel file requirements, which are covered in the portal guide and should not be assumed to match those figures. What the API removes is the manual spreadsheet upload step and the person doing it. Portal versus third-party apps compares the two.
When things go wrong
Wrong amount on an individual e-invoice. Within 72 hours of LHDN validating it, the supplier can cancel with a justification and reissue. After that the document is final and the correction is a credit or debit note. How the 72-hour window works.
Voided order after an individual e-invoice went out. Cancel within the 72-hour window if you catch it; otherwise a credit note.
Refund to a customer. Where money is returned, a refund note (document type 04) records it, referencing the original document by its IRBM Unique Identifier Number. Where the adjustment reduces what is owed without a payment back, a credit note (02) is the document. Credit notes and debit notes in MyInvois covers the distinction and the reference rules.
An error inside a consolidated e-invoice. Adjustments reference the consolidated document, so keeping the mapping from receipt numbers to the consolidated document that covered them is what makes this tractable weeks later.
A rejected submission nobody resubmitted. The most common silent gap. Build a check for it into the month-end routine.
Getting started
The order that works: confirm whether the mandate reaches you at all; get receipt numbering and menu master data clean at the POS; work out how front-of-house captures details when a customer asks for an e-invoice; then automate the monthly consolidation.
Finvo’s developed workflow includes UBL formatting, daily-sales records, consolidated e-Invoices and MyInvois status handling. Daily takings are entered manually in the inspected workflow; do not assume a direct till integration. Confirm current access and how bulk actions work for your business during rollout.
The takeaway: automate the reporting, and keep the daily discipline manual and simple. Volume is too high and service too fast for anything else, and the daily half is the part that makes the monthly half correct.
