E-Invoice & PEPPOL Module
Watch this as a presentation — 1 on this page, slides with narration.
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 recorded in
planning/specs/module-applet-membership.md — the product carries no module↔applet relationship of
its own.
| Applet | Who opens it | What it is for |
|---|---|---|
| My E-Invoice Admin | You | The control room. Company enrolment, the submission queues, the three pools, submission history, the monthly reconciliation reports. |
| MY E-Invoice Portal | Your customer | A buyer-facing portal. A customer with a login completes their tax number, identity and address so you can issue them an individual e-invoice, views their validated e-invoices, and raises a rejection request inside the 72-hour window. |
| My Peppol Admin | You | PEPPOL participant registration and the outbound/inbound PEPPOL queues. |
| Peppol AP Admin | Access-point operations | Administration of the access point itself. |
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.
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, and it has a hard structural limit: 200 lines, each line one consecutive document-number range.
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 this module needs from others
| Module | What it supplies |
|---|---|
| Core | Organization — the company tax registration and MSIC industry code; Customer Maintenance and Supplier — tax number, identity type and value, and an address with line 1, city and state; Doc Item Maintenance — item classification codes and units; Tax Configuration |
| Sales and Point of Sale | Every document that is reported: cash bills, invoices, returns, credit, debit and refund notes |
| Purchasing | The purchase documents behind self-billed e-invoices and the incoming reconciliation |
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.