E-Invoice & PEPPOL Module

Malaysia requires you to report your invoices to LHDN and get them back validated. This module is the machinery that does it: it picks up documents when they are finalised, fills in what LHDN insists on, sends them one at a time, waits for the verdict, and puts the ones it cannot send somewhere you can find them. It also carries the separate PEPPOL path, for exchanging documents directly with trading partners.

Applets in this module

Four, and all four are documented. Membership is an editorial judgement — the product carries no module↔applet relationship of its own.

Looking for the Applet Store entry MY E-Invoice For Customer And Supplier? It is a separate applet, not the Portal under an older name. Its menu is the seller’s operator console, with the same groups as My E-Invoice Admin. Its old wiki address leads to the Portal page for now.

How a document gets to LHDN

    flowchart TD
  FIN["A sales document<br/>reaches FINAL"] --> GATE{"Is e-invoicing<br/>enabled for<br/>this company?"}
  GATE -->|No| DROP(["Dropped silently —<br/>no queue row, no pool row,<br/>no error"])
  GATE -->|Yes| CHK{"Does the buyer's<br/>identity pass<br/>LHDN's rules?"}
  CHK -->|Yes| Q["Submission queue<br/>one document per call"]
  CHK -->|No| POOL["A pool —<br/>waiting for a person"]
  Q --> LHDN["LHDN"]
  LHDN --> VQ["Validation queue<br/>polls for the verdict"]
  VQ --> VALID(["Valid — 72 hours<br/>to cancel, then never"])
  VQ --> REJ(["Rejected —<br/>fix and resubmit"])
  POOL -->|Month end| CONS["Consolidated e-invoice"]
  CONS --> Q
  

A document finalised while its company is not enabled is dropped silently. No queue row, no pool row, no error anywhere. This is the single most expensive misconfiguration in the module: you find out weeks later, from a reconciliation report, that a month of invoices was never reported. Enable the company before anyone finalises anything.

A document that never reached LHDN has a deadline you did not set. Since the backend of 2 October 2026, every consolidation run begins by sweeping the previous month: any sales e-invoice record for a month that has fully ended, under RM 10,000, that never got an LHDN document ID (still waiting to be sent, or its sending failed) is moved into the Batch Pool as a consolidated receipt under the General Public number, and its individual record is retired. Such a document is then reported as an anonymous sale. That is right for a walk-in receipt and wrong for a named business customer who wanted their own e-invoice, so send the failed ones inside the month. A record LHDN accepted and then judged Invalid already has an ID, so the sweep leaves it alone. It stays Invalid, unreported, until somebody fixes and resubmits it.

Every status you see is a copy, taken at a known moment

Nothing on these screens is a live view of LHDN. Each status and figure was written at a moment you can name, and knowing which moment answers most “this is wrong” questions before you have to ask them.

• The status on an e-invoice record — Submitted, Valid, Invalid, Cancelled — is what LHDN said the last time BigLedger asked. A background run asks every ten minutes, up to twenty records a run, one question per record, and writes the answer onto the record. For Valid it also stores LHDN’s own validation time, and that stored time, not the moment you looked, starts the 72-hour cancellation window.
• The asking stops. A record LHDN still reports as Submitted three days after it received it, or one LHDN gave no usable answer for ten runs, is taken off the list and never asked about again. It keeps its last status until someone opens it in To IRB E-Invoice and presses Refresh, which asks LHDN once about the submission that record holds and writes the answer. Nobody is told when a record drops off the list. So the person who reads yesterday’s records each morning (step 3 of the check below) is the one who catches it. A record still Submitted the next morning is worth a Refresh, and after three days nothing else will refresh it. While it reads Submitted, Save and Resubmit refuses it, so Refresh comes first. A Refresh that turns a record Valid does not send the buyer’s e-mail, because only the background check does that. Use Resend Email on the record.
• The record itself is a frozen copy of your document — buyer, supplier and totals as they were when the record was built. Correcting the customer afterwards changes nothing on it; see Submission mechanics.
• Submission History keeps what was sent and what LHDN answered at the time. Its Submission Status column is never revisited, so treat it as evidence, not as a work list (Reports).
• The Discrepancies Report is built once, when you create it, and stored. Nothing updates it afterwards. After you fix something, create a new one rather than re-reading the old one.

When e-invoicing looks wrong, start from what you see

The four kinds of e-invoice

These are document reporting types. None of them posts a journal — the accounting is done by the underlying sales or purchase document, and the e-invoice is the report of it.

A consolidated e-invoice is not a summary or a report. It is a tax document in its own right. How many receipts fit on one depends on which way your company consolidates, and the two are not alike: by document puts one line per receipt and has no line cap — the run is bounded only by how many batch-pool rows it picks up at a time; by branch puts one line per consecutive document-number range and stops at 200 lines, returning what it has and leaving the rest for the next run. Which one your company is on is set for you and is visible on the e-invoice itself — one document number per line means by document, a range like 1001-1005 means by branch. See Consolidated e-invoice.

The PEPPOL path runs beside LHDN, not after it

PEPPOL is a separate network for exchanging documents with trading partners. The important thing to understand is the sequencing: the PEPPOL pipeline does not wait for LHDN to return “Valid”. The two run in parallel from the same finalised document. A diagram that shows PEPPOL as a step after tax clearance is describing something the product does not do.

BigLedger runs an accredited Malaysian access point. The Malaysian profile in use is PINT-MY.

What it touches elsewhere

What must exist before anything is sent. Three things, and each one fails without a message when it is missing. The company must be ENABLED, or its documents are never queued at all. BigLedger must be authorised as your intermediary on the MyInvois portal, or every call to LHDN fails for that company: submission, the status check, consolidated submission and the TIN search. And the background clocks must be on the Scheduler (step 2 of the check below). When the authorisation has lapsed, consolidation and the Discrepancies Report keep running, because they work inside BigLedger, so the screens look normal while nothing reaches LHDN.

The master data each document draws on comes from these modules:

What a Valid record makes possible. Once the status check reads Valid, LHDN’s validation link and QR code are stored on the record and appear on the LHDN-format printable. When the status check is what turned it Valid, the buyer’s e-mail goes out too. The 72-hour cancellation window opens, and after it closes the correction is a credit or debit note that names this e-invoice (Cancel and correct).

Which of two to use.

• Individual or consolidated. A walk-in sale under RM 10,000 can wait for the month’s consolidated e-invoice. At RM 10,000 or more, a sales invoice or cash bill on consolidated submission is sent to the Individual Pool instead, because it can no longer be consolidated. A buyer who wants their own e-invoice has to ask at the till, before the month’s run.
• Validation Queue → Submit, or Refresh on the record. Submit asks LHDN again about the rows you select (up to twenty) from those still on the status-check list. Refresh asks about one record, including one the list has already dropped.
• LHDN or PEPPOL. They are two separate paths from the same finalised document, not two steps of one path (see above).

What breaks if a setting is wrong. A company that is not ENABLED queues none of the documents it finalises: sales invoices, cash bills, notes, returns and self-billed purchases alike. You find out from a Discrepancies Report you create for that company; the automatic monthly one covers only companies that are ENABLED. A lapsed intermediary authorisation stops one company’s LHDN traffic. A single ACTIVE row on the Scheduler with a cron expression the clock cannot read stops every clock on the tenant, e-invoice included. The symptom is a frozen Last Run Date on every row (Scheduler).

What it pairs with in practice. The Scheduler, where the clocks live. Sales and POS, whose documents it reports. And The Month-End E-Invoice Cycle, the routine that the check below feeds.

Who actually uses this module

It is worth being blunt, because it changes who you train. E-invoice is not a job. In BigLedger’s own installation data, a login that holds My E-Invoice Admin holds nine of fifteen functional families on average, and fewer than two dozen logins across the whole platform hold e-invoice applets and nothing else. The person doing this also runs the sales documents, the ledger and usually the till. Write the procedure for them, not for a specialist.

How you know e-invoicing is actually working

When a company is not enabled, a clock is off or the authorisation has lapsed, nothing in BigLedger comes to tell you; you find it only by looking. Looking is a person’s job: whoever runs the sales documents, as above. It takes a few minutes a day and one report a month.

1. The company reads ENABLED. Check this once, and again after any change to a company. In My E-Invoice Admin, every company that issues documents should read ENABLED. A company that does not is not an error anywhere; its documents are simply never queued.
2. The clocks are ACTIVE. Check this once, and again after anyone edits the Scheduler. In the Scheduler, these rows should read ACTIVE: routing (E_INVOICE_GENERIC_DOCUMENT_TO_IRB_PROCESSOR), submission (E_INVOICE_TO_IRB_SUBMISSION_PROCESSOR), the status check (E_INVOICE_TO_IRB_VALIDATION_STATUS_UPDATE_PROCESSOR) and token renewal (E_INVOICE_INTERMEDIARY_ACCESS_TOKEN_PROCESSOR). If you consolidate, add the run that builds consolidated e-invoices (E_INVOICE_BATCH_PROCESSING_CYCLE_RUN_PROCESSOR) and the one that submits them (CONSOLIDATED_E_INVOICE_PROCESSOR). A row named E_INVOICE_TO_IRB_SUBMISSION_QUEUE_PROCESSOR that is missing or off is not a fault, because the routing run puts documents on the submission queue itself. A current Last Run Date proves only that a clock fired, not that its job worked, which is why step 3 exists.
3. Yesterday’s records have all moved on. Check this every morning. In To IRB E-Invoice, look at yesterday’s records. You are done when nothing reads IN_QUEUE. A record still IN_QUEUE a day later failed to send, and nothing in the default schedule sends it again: read its Request Error under Individual Submission, fix the cause, select the row and press Submit. Nothing should read Submitted either; press Refresh on any that does. And every Invalid record should be resubmitted, or have someone’s name on it.
4. The pools have owners. Check this every week. The Individual and Single General pools never empty themselves. You are done when every row in them is one someone is chasing.
5. Last month reconciles. Check this between the 1st and the 7th. Create a fresh Discrepancies Report for last month. You are done when both directions read zero, or every line on them is one you can name. The report does not examine foreign-currency documents, so check those from the document listing.

When all five hold, every document you finalised is either at LHDN with a verdict, or on a list that a named person is working through.

Where to go next