Reports
There are fewer e-invoice reports than people expect, and the difference between two of them is the single most expensive misunderstanding in the module. This page names the ones that exist and what each is for.
To IRB E-Invoice carries the live LHDN status. Submission History does not. Submission History is an archive of what each submission looked like at the moment it was sent, so it will keep saying “Submitted” for a document LHDN has since marked Invalid. Never build a work list of rejections from Submission History.
Which report answers which question
| Your question | Where to look | What you get |
|---|---|---|
| “Which e-invoices did LHDN reject, and why?” | Internal Submission → To IRB E-Invoice in the MY E-Invoice Admin Applet, tab Export | One row per e-invoice with the live status (Valid, Invalid, Submitted, IN_QUEUE), the LHDN error code and message, document number, branch and company. Sort on status and your work list writes itself. |
| “What exactly did we send LHDN on the 3rd, and what did they say back at the time?” | Internal Submission → Submission History, tab Export | The submission archive: request, response and the status as at submission. Use it for evidence, never for current status. |
| “Does everything we invoiced last month have an e-invoice record?” | Monthly Report → Discrepancies Report | Per company and period: your own documents (ERP Transaction Summary); the e-invoice records dated in the period that are neither Cancelled nor Invalid — including ones still queued — split by document type, with the Cancelled amount beside each (IRB Audit Summary); and the gap in both directions (Document vs E-Invoice Discrepancy), with a drill-down to the documents behind every line. This is the module’s reconciliation. It cannot answer “did it reach LHDN?” on its own: a rejected e-invoice appears nowhere on it, and a cancelled consolidated e-invoice leaves its receipts reading as reported — the applet page gives the arithmetic that exposes both. |
| “What is still waiting, and where?” | Batch Pool, Individual Pool, Single General Pool, and Internal Submission → Individual / Consolidated / Validation Queue | Every document that has not reached LHDN yet, and the reason. Two of the three pools never empty themselves. |
| “Which supplier e-invoices have we received, and do they match our purchase documents?” | Reconciliation (Purchase) | Your purchase documents on one side, and on the other the supplier documents that reached you over PEPPOL or through the OCR e-mail intake — never the ones your suppliers filed with LHDN. External Reception → From IRB E-Invoice is filled by a five-minute default clock since 28 September 2026 (backend 432ed15e2c) and still held no rows on any production tenant on 4 October 2026; whatever lands there is not paired with your purchase documents. Incoming Supplier E-Invoices explains the gap and the manual check that covers it. |
| “What did we send and receive over PEPPOL?” | Internal Submission → To Peppol AP / Queue / History and External Reception → From Peppol AP in the MY PEPPOL Admin Applet | One row per PEPPOL document with sender and receiver participant IDs, plus the transmission outcome on the queue rows. Monthly Report → Queue / History holds the per-company period summaries. |
The monthly rhythm these reports support
- Daily — read To IRB E-Invoice, clear anything Invalid.
- Weekly — read the Individual and Single General pools, and filter the Batch Pool for processed / failed rows. Nothing here moves on its own and nothing raises an alert.
- Monthly, between the 1st and the 7th — run the Discrepancies Report for the closing month and clear it before the consolidation deadline, while cancellation is still possible.
The step-by-step version is The Month-End E-Invoice Cycle.
What none of these reports can see. They compare your documents against BigLedger’s e-invoice records. They do not pull back what LHDN holds — so an invoice keyed straight into the MyInvois portal, or sent by another system, never appears in a BigLedger report. If your LHDN dashboard shows more documents than BigLedger does, that is the first thing to check.