Close the cycle

Play this lesson as slides — one slide per step, with the same narration. The full text of every step is on this page.

This lesson is for you if you run the books at GadgetSphere and it is the 5th or 6th: the run happened, the rejections are fixed, and someone is about to ask whether the month is closed. In about ten minutes you will learn the four-screen check that answers that question in under a minute per company, how to explain any gap the last screen shows, and the small things to keep and to do now so that the 1st of next month starts with clean pools and no surprises. Once these four screens are clean, the BigLedger side of the month is closed. Step 7 is the part no screen here can show you, because it lives at the Inland Revenue Board, LHDN, rather than in BigLedger.

Step 1 — Confirm the Batch Pool is empty for last month

After this step you can prove every counter receipt that reached the Batch Pool went into a consolidated e-invoice. Open the Batch Pool and filter to last month. What you want to see is nothing waiting: no unprocessed rows, and no rows that read Processed and Failed. An unprocessed row was missed by the run or arrived after it, and the next run will take it and date it to the last day of the previous month, which is right only while that is still its month. A processed-but-failed row is worse, because it looks finished. Someone pressed Save and Resubmit on it, the check failed again, and it will never be swept; it also vanishes from any unprocessed filter, so filter for failed rows explicitly, every cycle. If both filters come back empty, every receipt that reached the Batch Pool is inside a consolidated e-invoice. Screen four is what catches the ones that never got that far.

Reference: E-Invoice Pools & Submission Routing — Frequently asked questions

Step 2 — Confirm the two waiting pools are owned

After this step you know that nothing is quietly unreported. Open the Individual Pool, then the Single General Pool; the second is the one people forget. Neither empties itself. A row in either is a sale that has not been reported and will not be until a person acts, and nothing ages it or warns you it is old. The test is not that they are empty, because a corporate buyer who has not sent their tax number yet is a legitimate reason for a row to exist. The test is that every remaining row has a name against it: someone is chasing that buyer’s details this week, and you could say who. A RM 24,600 laptop fleet order waiting for a registration number is an owned exception on the 6th, and still an unreported sale. It is not fine if you find it in March. Make the Individual Pool a weekly look, not a monthly one.

Reference: E-Invoice Pools & Submission Routing — What success looks like

Step 3 — Confirm every e-invoice is Valid or explained

After this step you can say that everything sent last month reached LHDN and was accepted, or is a row you are chasing. Go to Internal Submission, then To IRB E-Invoice, filter to last month, and sort on the status column. There should be no Invalid rows and no rows still In Queue. Submitted rows are not failures, but they are not done either: LHDN is still deciding, and that usually takes minutes, so a Submitted row on the 6th deserves a look in the Validation Queue rather than a shrug. Cancelled rows are fine when you can say what replaced them: a re-issued e-invoice, a voided or reversed sale. A credit note is different; it sits against an e-invoice that is still Valid. The rule for this screen is Valid or explained. And remember which screen you are on: Submission History would show the same month as a short, reassuring list of Submitted rows.

Reference: The Month-End E-Invoice Cycle (1st to 7th) — What success looks like

Step 4 — Run the Discrepancies Report for each company

After this step you have the one report that compares your books against your e-invoices. Go to Monthly Report, then Discrepancies Report, and create it for last month, once per company. GadgetSphere has three, retail, online and distribution, so that is three reports. Each compares the sales documents you finalised in the period against the e-invoice records BigLedger holds for them, and shows the result on four tabs: the report header; your own transaction summary; the e-invoice side per document type, with the cancelled amount beside each; and the discrepancy tab, which lists the gap in two directions. Any line on that tab drills into the documents behind it, including the receipts inside a consolidated e-invoice. The report counts a document as e-invoiced once an e-invoice record exists for it, which is not the same as LHDN having seen it. If support has enabled it, last month’s report can be e-mailed to you automatically.

Reference: My E-Invoice Admin Applet — 8. Monthly Report → Discrepancies Report

Step 5 — Read what the report calls missing

After this step you will not chase a gap that is not one. The first direction, exists in your books but missing from e-invoice, counts a document only when it is finalised, not deleted, dated in the period, in the company’s own currency, with no e-invoice record and no link to one. Two consequences. Foreign-currency documents are never examined, so the distribution company’s US dollar invoices need a separate look from the document listing. And a sale marked Skip E-Invoice has no record either, so it meets the test: twenty skipped voids show as twenty missing documents. Read the skipped bucket first and subtract it. The other direction, exists in e-invoice but missing from your books, finds orphan records pointing at nothing, and is repeated excluding consolidated e-invoices so you can tell whether consolidation explains it. The distribution company’s report showing four documents, the four in the Individual Pool, and nothing the other way, is the report working.

Reference: E-Invoice Submission Mechanics — The discrepancy report: what “missing” means

Step 6 — Explain a gap in the order support would

After this step you can name the cause of any real gap without opening a ticket first. There are five, and this is the order support checks them, cheapest first. One, documents still in the Individual Pool: Step 2 missed some, or new ones arrived. Two, Batch Pool rows marked processed but failed: the trap from Step 1, stranded, not waiting. Three, documents in the Single General Pool: same shape, easy to forget. Four, documents that never entered the pipeline at all: a sale finalised while the company’s e-invoice setting was still off is dropped silently, with no pool row, no queue row and no error, and only support can push those in, so raise a request with the document numbers. Five, sales you abandoned without marking them Skip E-Invoice, which the report counts as missing, and sales voided after submission, which leave a Valid e-invoice with no sale behind it and need a cancellation or a credit note.

Reference: The Month-End E-Invoice Cycle (1st to 7th) — Step 7: Reconcile, and understand the five reasons a tally does not balance

Step 7 — Know what BigLedger cannot see

After this step you know the two things no screen in this applet will ever show you, so you check them elsewhere. First, the report compares what you invoiced against what BigLedger sent. It does not pull back what LHDN holds. An invoice someone typed straight into the MyInvois portal, or one sent by another system, never appears in any BigLedger report, so if your LHDN dashboard shows more documents than BigLedger does, that is the first place to look. Second, if a buyer rejects one of your e-invoices on the MyInvois portal rather than through BigLedger, that rejection does not come back. Nothing in your queues or reports changes. If a customer tells you they have rejected an e-invoice, open the portal yourself and act on it in BigLedger. Both are checks you make on LHDN’s side, and we suggest once a month, with the four screens already clean.

Reference: Cancelling and Correcting a Validated E-Invoice — What we cannot see for you

Step 8 — Keep the record and set up next month

After this step the month is closed in a way you can show someone later, and the 1st will be quiet. First, keep the evidence. The export from To IRB E-Invoice reads each record as it is now, so an e-invoice cancelled in October will read Cancelled on a file you pull in November. For what was true on the 7th, export on the 7th and keep the file: filter to last month, use the Export tab, wait for the row to show Done, and download. One export at a time per kind; a second request while one is building is refused. Then three habits. Mark any abandoned sale Skip E-Invoice before the next run, so it is not consolidated. It still shows as missing on the Discrepancies Report, as Step 5 explains. Note who owns each Individual Pool row still open. And confirm your company’s run day for next month with support before the 1st, not on the 6th.

Reference: E-Invoice Submission Mechanics — Export files: the month in a file

How the steps fit together

    flowchart TD
  s1["Step 1 — Confirm the Batch Pool is empty for last month"]
  s2["Step 2 — Confirm the two waiting pools are owned"]
  s3["Step 3 — Confirm every e-invoice is Valid or explained"]
  s4["Step 4 — Run the Discrepancies Report for each company"]
  s5["Step 5 — Read what the report calls missing"]
  s6["Step 6 — Explain a gap in the order support would"]
  s7["Step 7 — Know what BigLedger cannot see"]
  s8["Step 8 — Keep the record and set up next month"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  s6 --> s7
  s7 --> s8
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Back to the course