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.
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 daily check) 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.