Core Concepts
This page is the architecture. If you want the plain-English meaning of consolidated e-invoice, pool or validation, start at Concepts instead — this page assumes them.
The trigger is FINAL, and nothing else
A document enters the e-invoice pipeline when it reaches FINAL and its company is enrolled. There is no approval step, no review queue and no separate “submit for e-invoicing” action in the normal path. The same button that posts the journal queues the e-invoice.
Two consequences:
- A document that is never finalised is never reported.
- A document finalised while the company is not enrolled is dropped silently — no queue row, no pool row, no error.
The five stages
| Stage | What happens | Where you watch it |
|---|---|---|
| 1. Entry | A sales or purchase document reaches FINAL. BigLedger decides, from the document’s submission type, its amount and whether every mandatory field is filled, whether it can go individually or must be pooled | My E-Invoice Admin |
| 2. Build and sign | The document is mapped into LHDN’s schema and signed with a certificate BigLedger holds at platform level, then sent on your company’s authorisation of BigLedger as intermediary. You do not load a certificate of your own | My E-Invoice Admin |
| 3. Submission | One document per LHDN call, taken from the submission queue in order | Internal Submission → Individual / Consolidated |
| 4. Validation | A poller asks LHDN for the verdict and records Valid, Invalid or Cancelled, with the validation time in UTC | Internal Submission → Validation Queue |
| 5. Delivery to the buyer | The validated e-invoice with its QR code becomes viewable by the buyer, and can be e-mailed | MY E-Invoice Portal for viewing; e-mail follows the company’s Send Email To Buyer switch |
Validation is a one-way door
Once LHDN returns Valid, you have 72 hours from the validation timestamp to cancel it. After that the document can only be corrected by issuing a credit, debit or refund note.
BigLedger records that timestamp in universal time, which can read earlier than the MyInvois portal appears to show. When the deadline is close, trust the earlier reading.
PEPPOL is a parallel pipeline, not a later stage
flowchart LR
DOC["Document reaches FINAL"] --> L["LHDN pipeline<br/>submission → validation"]
DOC --> P["PEPPOL pipeline<br/>waiting queue → To Peppol AP<br/>→ access point"]
L --> LV(["Valid / Invalid"])
P --> PD(["Delivered to the<br/>partner's access point"])
The two run from the same event and neither waits for the other. Specifically, the PEPPOL waiting queue does not wait for LHDN to return Valid — any wording that says “after LHDN validates” is describing a sequence the product does not implement.
BigLedger runs an accredited Malaysian access point, using the PINT-MY profile. Delivery over the network is not guaranteed instant: a failed AS4 transmission sits in the queue and is resent row by row.
What the module does not do
- It does not post to the ledger. Every accounting entry belongs to the underlying sales or purchase document. An e-invoice is a report of a transaction, not the transaction.
- It does not gate anything. A document finalises whether or not its e-invoice succeeds. That is why the pools matter: the sale is correct and the report is outstanding, and only a person closes the gap.
- It does not alert you unless someone schedules it. There is no ageing alert on any pool or queue. A failure e-mail and an individual-pool failure e-mail exist, but neither runs on a default clock. The Batch Pool is emptied by the consolidation run, which since October 2026 also sweeps last month’s Invalid or still-queued sales e-invoices under RM 10,000 into it; the Individual and Single General pools wait for a person.