What am I supposed to do between the 1st and the 7th? The month-end e-invoice cycle

“What am I supposed to do between the 1st and the 7th?” Make sure everything you sold last month reached LHDN once and only once: clear the pools that wait for you before consolidation runs, let consolidation run, pull the export that shows live status, work the Invalid list and reconcile, so that last month’s consolidated e-invoices are validated by the 7th.

Every month you have seven days to prove that everything you sold last month reached LHDN — once, and only once. Consolidated e-invoices for last month must be validated by the 7th, and the work that gets you there is a short, repeatable loop you can run yourself. This guide walks that loop end to end. Budget about two hours on the 1st or 2nd, then a few short check-ins until the list is clean.

Meet GadgetSphere

GadgetSphere Sdn Bhd runs 22 consumer-electronics branches across Malaysia, plus an online arm and a distribution company. Last month its counters rang up roughly 38,000 receipts, almost all walk-in sales under RM 10,000 with no buyer details — those become one consolidated e-invoice per group. Another 112 invoices were RM 10,000 or more, so each of those has to go to LHDN individually with the buyer’s real tax number. Getting all of it reported by the 7th is the job below.

What you need to know first

Three ideas do all the work in this cycle. If any of them is new to you, read it first — two minutes each, and the rest of this page follows on its own.

• Consolidated e-invoices — how a month of counter receipts is reported in one document, and why a sale of RM 10,000 or more can never be one of them.
• Pools and queues — which holding areas empty themselves and which wait for you. Steps 1 and 2 below are entirely about the ones that wait.
• Validation and clearance — what Submitted, Valid and Invalid actually mean, and why the Submission Status column in Submission History is not LHDN’s verdict.

The one you have to have straight before you start is the last. Internal Submission → Submission History has two status columns that look alike. Submission Status records what happened when the document was sent, and it stays Submitted even after LHDN rejects the document. E-Invoice Status is the one BigLedger updates when LHDN answers. Internal Submission → To IRB E-Invoice carries one row per e-invoice with that live verdict, and it is the screen to work from.

Before you start

• You can open the My E-Invoice Admin Applet and use the Export button on the submission screens.
• Last month’s sales are all finalised. A document still sitting in draft has never entered the e-invoice pipeline at all, and no amount of pool-clearing will find it.
• You know whether the consolidation clock is running on your tenant, and how fast it gets through a month. It is not a date: by default the consolidation run fires every half hour from the 1st, taking a batch of last month’s Batch Pool rows each time, and the consolidated submission follows every 20 minutes. The clock’s row in the Scheduler applet shows whether it is ACTIVE and its interval; if you do not have that applet, or your month runs to tens of thousands of receipts, ask support before the 1st — not on the 6th.
• Your company’s e-invoice authorisation is healthy. If every document is failing with an authentication error and none of them has a data problem, the intermediary authorisation you granted BigLedger on the MyInvois portal has lapsed and needs renewing — no amount of month-end work will move anything until it is.

Step 1: Clear the Individual Pool before consolidation runs

Outcome: every high-value and named-buyer sale from last month either has a real tax number on it or has been consciously moved somewhere it can still be reported.

My E-Invoice Admin Applet → Individual Pool

The Individual Pool is where documents land when they were meant to go to LHDN on their own but something mandatory is missing — usually the buyer’s tax number, identity type or address. Nothing moves them on for you. No rule ages a pooled row and nothing warns you it is old, so they will sit there for months — and every one of them is a sale you have not reported.

Work the list in two passes:

1. Get the buyer details. Open the row, complete the buyer’s tax number, identity type and value, and the address, then use Save and Resubmit. GadgetSphere’s corporate sales — the RM 24,600 laptop fleet order for an accounting firm — belong in this pass. If the buyer’s identity type is a business registration number and the tax number is blank, use Get TIN / Verify TIN on the row: it asks LHDN for the number that goes with the identity type and value in front of you, at any amount. The RM 10,000 threshold belongs to the automatic lookup, not to the button — BigLedger searches by itself only on a document of RM 10,000 or more whose identity type is a registration number, so on a RM 4,000 corporate invoice nothing has been tried and the button is exactly the thing to press.
2. Move what you genuinely cannot complete. For a receipt under RM 10,000 where the customer has walked away and you will never get their details, use Move To Batch Pool so it is consolidated with everything else. Since 2 October 2026 the run also does part of this for you: when it executes for a month that has ended, every individual e-invoice record from that month that never got an LHDN document ID — still IN_QUEUE, never sent or failed to send — under RM 10,000 and a sales document, is moved into the Batch Pool as consolidated and its row leaves To IRB E-Invoice. That sweep reads records, so a receipt still sitting in the Individual Pool — which never got one — is not touched, and Move To Batch Pool remains its only way out. Nor does it touch an Invalid record: that one has an LHDN document ID already, and Step 5 is the only thing that moves it. Do it before your consolidation run: a row moved afterwards is picked up by the next run and dated to the last day of the previous month, which is only right while that is still the month it belongs to.

If you skip this step: the consolidation runs, everything else reports cleanly, and your Individual Pool documents quietly stay unreported. You will find them the next time somebody reconciles — possibly months later, well past any chance of cancelling or correcting cleanly.

Step 2: Check the Batch Pool for rows that will not be swept

Outcome: you know that every Batch Pool row for last month is genuinely waiting to be consolidated, not stuck.

My E-Invoice Admin Applet → Batch Pool

Most Batch Pool rows need nothing from you — they are unprocessed, and the monthly consolidation sweeps them up. But there is one row state that looks harmless and is not:

• Unprocessed — will be consolidated. Leave it alone. This is true even when the row is red. A receipt lands in the Batch Pool precisely because it could not have been an individual e-invoice, so most unprocessed rows carry a failed queue status and a Validation Error listing the buyer fields you do not have. The consolidation run never looks at that column. A wall of red unprocessed rows is what a healthy Batch Pool looks like at month end.
• Processed / Failed — somebody pressed Process or Save and Resubmit on it, the data still wasn’t good enough, and the row was marked processed with the reason in Validation Error. Those two buttons mark a row processed whether they succeed or fail. It is the processed, not the failed, that matters: the row is no longer waiting for anything, the monthly consolidation will not pick it up, and it is invisible on any “unprocessed” filter.

Open a failed row and read the Validation Error panel — it names exactly which fields are missing.

Fix the underlying customer record, then use Save and Resubmit again — if it passes this time the receipt goes out as an individual e-invoice. If you cannot complete the buyer’s details and you just want the receipt back in the monthly batch, there is no “unprocess” button and nothing resets the row: use Move to Individual, then Move To Batch Pool from the Individual Pool. That pair replaces the stranded row with a fresh unprocessed one, and the run can see it again. Either way it has to be dealt with by hand.

And the mistake that creates the problem: do not press Process on a batch of red unprocessed rows to “clear” them. They were going to be consolidated. Pressing Process runs the individual check, the check fails for the same reason it failed the first time, and the row is marked processed — you have taken it out of the run. Fleet-wide, genuinely stranded rows are a handful per tenant against tens of thousands that are simply waiting, and every one of them was made by a button.

The most common way this goes wrong: a clerk works the pool on the 2nd, fixes a batch of rows, half of them fail the check again, and nobody looks at the result. Those receipts never reach LHDN and turn up as the gap in Step 5.

Step 3: Let the consolidation run — or trigger it yourself

Outcome: last month’s Batch Pool has become consolidated e-invoices sitting in the submission queue, and then at LHDN.

My E-Invoice Admin Applet → Batch Pool → Consolidate (or Consolidate By Branch), then Internal Submission → Consolidated Submission → Submit

For most companies you do not press anything. Consolidation starts on its own from the 1st: by default the run fires every half hour, takes up to 100 of last month’s unprocessed Batch Pool rows each time, and the consolidated submission sends the results on to LHDN every 20 minutes. There is no one consolidation day — last month is worked through in batches, and the 7th is the deadline the batches must beat. At the default that is up to 4,800 rows a day, so a month of a few thousand receipts is through on the 1st; a high-volume tenant on the default batch can need several days, which eats into the time you have to fix rejections, so if yours is large, check how far the Batch Pool has got by the 2nd. The run is one clock for the whole tenant, so every company in a group is consolidated by the same runs. The manual buttons above are the fallback, and they are what support uses when a run has to be repeated.

Two things worth knowing about the result:

• The automatic run looks at one month, and it is last month. It takes unprocessed Batch Pool rows whose transaction date falls in the previous calendar month — nothing from this month, which is right, and nothing older, which is the part that catches people. A receipt still sitting in the pool from two months ago is not late, it is out of the window, and no number of runs will pick it up. That is what Step 2’s old-row check is for. The fix is yours, not support’s: select those rows and press Consolidate, which has no date window and dates the resulting e-invoice to the last day of the receipt’s own month. Expect it to be reported late — that month’s deadline was the 7th of the month after it.
• If your company consolidates by branch, an unprocessed row is not automatically an eligible one. That run takes a sales row only when its buyer’s tax number is the General Public, foreign-buyer or government one, and a purchase row only when its supplier’s tax number is the General Public, foreign-supplier or government one. A row carrying a real customer tax number, or none, belongs to no group and is silently passed over — nothing marks it, it just stays unprocessed. So on a by-branch company, come back to the Batch Pool the day after your run and look at what is still unprocessed for the month that was just consolidated. Check the run finished and the rows have a branch before you blame the tax number; either way, select them and press Consolidate, which applies no such test. Companies on the by-document run are unaffected — that run reads no tax number at all. (Why, and how to tell which you are on.)
• A passport buyer is not a consolidation problem you can defer. If a tourist bought a laptop at the Penang branch and gave you a passport, that sale must be keyed with identity type Passport and submitted individually, with their real tax number. There is no General TIN substitution for a passport, so leaving it to the monthly run never produces the e-invoice they wanted: a receipt keyed Individual, or of RM 10,000 or more, waits unreported in the Individual Pool; a smaller one left blank or marked Consolidated is either skipped by a by-branch run or swept into the General Public consolidation by a by-document one. Ask for the tax number at the counter.

Step 4: Pull the export that shows live status

Outcome: you have one spreadsheet of last month’s e-invoices with LHDN’s current verdict on each.

My E-Invoice Admin Applet → Internal Submission → To IRB E-Invoice → Export

This is the screen and the export to work from. Each row is one e-invoice, with a status you can act on:

Also open Monthly Report → Discrepancies Report and create the report for last month. It compares your finalised documents against your e-invoice records per company and period, and it is the only self-service reconciliation tool in the applet. You will use it in Step 5.

Step 5: Work the Invalid list

Outcome: every Invalid row from last month is either Valid or has a known, owned reason for not being.

Nothing does this for you. The consolidation run’s month-end sweep takes only records that never got an LHDN document ID, and an Invalid record has one — LHDN accepted it and then rejected it. So an Invalid row you leave alone stays on this list, and its sale stays unreported, next month and every month after, until somebody fixes and resubmits it. Work it before the 7th, not because a run will take it from you, but because no run on the default schedule ever will.

My E-Invoice Admin Applet → Internal Submission → To IRB E-Invoice

The loop is the same for each row, and it is quick once you have the rhythm:

1. Sort the export on status and take the Invalid rows.
2. Read the rejection reason on the row. Most of them will be the buyer’s identity — a foreign customer keyed as Malaysian, a national identity number stored with hyphens, or a company registration number typed into the wrong field. Validation Rules & Troubleshooting has the full list with fixes.
3. Look the correct tax number up on the MyInvois portal.
4. Correct it on the customer record in the Customer Applet, so the next sale to that customer is right too.
5. Back on the To IRB E-Invoice row, use Save and Resubmit.

If a row keeps failing on a field you can see is correct on the customer record, the document is carrying its own copy of the buyer’s details and the customer record is never being read — fix it on the document’s own e-invoice block instead. Which record does BigLedger actually send? has the rule.

If dozens of customers have a missing or wrong tax number, Tools → Bulk TIN Validation will not correct them for you. Its CSV carries name, e-mail, phone and customer code, and no tax numbers. Each row starts a request that e-mails the matched customer a link to fix their own details. Only the customer’s answer changes the record, and it may come after your month-end, or never. Correct urgent rows yourself on the customer record or on the document’s e-invoice block. Read what the upload actually starts before you upload: one row can match several records.

One trap before you cancel anything. If two rows in the listing show the same document number, that is very often not a duplicate: sales invoices and self-billed purchase invoices draw their numbers from two independent sequences that both start at the same value, and the listing does not show which direction a document went. Check the document type first. Cancelling a genuine e-invoice because a report looked odd is unrecoverable once its 72 hours are up — see Cancelling and Correcting an E-Invoice.

Step 6: Chase anything still IN_QUEUE the next morning

Outcome: you know whether a queued row is simply waiting its turn or has quietly failed.

My E-Invoice Admin Applet → Internal Submission → Individual Submission

Submission is a background queue. BigLedger sends one document per call to LHDN, serially — there is no burst mode — and each pass of the submitter sends at most 49 documents before it stops until its next turn. So a big month-end batch is measured in hours, not minutes. Measured across every BigLedger customer from August 2026, the busiest single hour anywhere carried about 1,900 submissions, and even the busiest days averaged no more than about 640 an hour. Plan on a few hundred documents an hour and start on the 1st, not the 6th.

That said, waiting is not the same as retrying:

Step 7: Reconcile, and understand the five reasons a tally does not balance

Outcome: for each sales document type, what you invoiced last month equals what reached LHDN.

My E-Invoice Admin Applet → Monthly Report → Discrepancies Report

Compare, per document type and per month, the sales you finalised against the e-invoice records BigLedger holds for them. A document counts as reconciled here as soon as an e-invoice record exists for it — including one still sitting in the consolidated queue, which LHDN has not seen yet — so a balanced report is not by itself proof that the month reached LHDN. Internal Submission → To IRB E-Invoice is the screen that tells you that. When the two sides do not match, work through these five in order — this is the order support checks them, cheapest first:

1. Documents still in the Individual Pool. Step 1 missed some, or new ones arrived after you worked the list.
2. Batch Pool rows marked processed but failed. The trap from Step 2. They are not waiting for the consolidation; they are stranded.
3. Documents in the Single General Pool. Same shape as the Individual Pool, different routing — check it separately, it is easy to forget.
4. Documents that never entered the pipeline at all. A document finalised while the company’s e-invoice setting was still switched off is dropped silently — no pool row, no queue row, no error. This is why the enable-then-finalise order matters so much during onboarding. If you find these, raise a support request with the document numbers; they have to be pushed in by hand.
5. Sales that fell through — and sales voided after submission. A finalised sale that did not happen, such as an order keyed twice or a customer who walked away before paying, is still FINAL, so the Discrepancies Report counts it as missing until the sale itself is corrected. Skip E-Invoice does not correct it. Skipping stops the e-invoice and nothing else: no journal, stock or receivable job reads the flag, so the revenue, the stock movement and the amount owed all stay in your books for a sale that never happened. Correct the books through the document instead. A cash bill can be voided before its e-invoice goes out: the void reverses what finalising posted and removes the bill from the submission queue, but it leaves the bill’s Batch Pool row where it is. The by-document consolidation run reads final documents only and passes over it; the by-branch run reads the Batch Pool row alone. So if your company consolidates by branch, use Skip E-Invoice on that row after the void. That is what skipping is for: a document that must not be e-invoiced, once the books are already right. A sales invoice cannot be voided at all while e-invoicing is on (nor can a return, credit note, debit note or refund note). Once its e-invoice is Valid, the route is a cancellation request with void original document inside 72 hours, or a credit note after that, with a sales return as well if goods came back (Cancelling & Correcting an E-Invoice). For an invoice LHDN has never seen, for example one still waiting in the Individual Pool, BigLedger offers no void, and we have not established which correcting document is right. Take it to whoever owns the books before the run. A sale voided after its e-invoice went out is the mirror image: it drops off the report’s ERP side, which counts FINAL documents only, while its e-invoice stays on the LHDN side, so the two summaries disagree by that amount until it is cancelled or credited. A cash bill can still be voided at that point, and LHDN keeps its e-invoice. Treat a void after submission as a cancellation job.

What success looks like

Thirty seconds, four screens, on or before the 7th:

1. Batch Pool, filtered to last month — no unprocessed rows left, and no processed-but-failed rows either.
2. Individual Pool and Single General Pool — empty, or every remaining row has a person chasing the buyer’s details.
3. Internal Submission → To IRB E-Invoice, filtered to last month — no Invalid rows, and nothing still waiting to be sent: no IN_QUEUE rows, and no consolidated e-invoice still sitting in the consolidated queue.
4. Monthly Report → Discrepancies Report for the month — the document count and totals match per document type.

If all four are clean, the month is closed.

Common mistakes

Related documentation