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.
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.
| Kind | When | The underlying document |
|---|---|---|
| Individual e-invoice | A buyer who has given you a tax number and identity | A sales invoice, or a cash bill for an identified buyer |
| Consolidated e-invoice | Retail receipts to buyers who gave you nothing | Cash bills, gathered monthly. See Consolidated e-invoice |
| Self-billed e-invoice | You buy from someone who is not required to e-invoice you — imported services, unregistered suppliers, commissions | A purchase document flagged self-billed |
| Credit, debit and refund notes | Correcting a document already validated | The corresponding sales or purchase note |
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.
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 sales e-invoices under RM 10,000 that LHDN rejected or refused into it (one never sent is left for the submission run); the Individual and Single General pools wait for a person.