Work the Batch Pool without stranding a receipt — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for you if you run the books at GadgetSphere and the Batch Pool holds tens of thousands of rows that you are not sure whether to touch. In about twelve minutes you will learn which of them to leave completely alone, which handful to hunt for every cycle, and what each of the buttons above the list actually builds. Nearly all of the work here is in one filter, and the rest is knowing when not to press anything.

Step 1 — Leave the healthy rows alone

After this step you will stop treating the size of this pool as a problem. GadgetSphere’s counters produce roughly 38,000 receipts a month and every one of them arrives here, unprocessed, waiting for the monthly consolidation to sweep it up. That is the design. There is nothing to approve, nothing to check row by row, and no virtue at all in opening thirty-six thousand receipts to confirm that a walk-in shopper had no tax number. The word to watch on a row is its process status. Unprocessed means waiting, and waiting is correct. Anything else on a Batch Pool row means somebody has already touched it, and the next step is about what that did.

Reference: Pools and E-Invoice Submission Routing — Batch Pool

Step 2 — Hunt the rows that will never be swept

After this step you can find, in one filter, the receipts that would otherwise vanish from your month. When somebody presses Save and Resubmit on a Batch Pool row and the mandatory check fails again, the row is marked processed and failed. It is no longer waiting for anything. The monthly consolidation only takes unprocessed rows, so that row is stranded, and worse, it disappears from the unprocessed filter you were using to check your work. Filter on process status processed together with failed, every cycle, not on failed alone: almost every healthy unprocessed row is red and failed too. Open one, read the Validation Error panel, fix the fields on its Account tab, and resubmit, or move it to the Individual Pool and back. This is the most expensive quiet failure in e-invoicing and it takes two minutes a month to catch.

Reference: Month-end e-invoicing: check the Batch Pool, and work the Invalid list before the run — Step 2: Check the Batch Pool for rows that will not be swept

Step 3 — Pull one receipt out for a customer who asks

After this step you can serve the customer who comes back a few days later wanting their own e-invoice. Find their receipt in the Batch Pool, complete the buyer’s tax number, identity type and value and address on the row, and press Save and Resubmit. The row leaves the batch and is submitted as an individual e-invoice in its own right. This works until that receipt has been consolidated, and for last month’s receipts the runs start on the 1st. Not one moment after, because once the sale is inside a validated consolidated e-invoice the only routes are a cancellation inside 72 hours or a credit note. Two neighbouring buttons, Submit as Individual and Submit as Single General, move the row and attempt the submission in one press.

Reference: E-Invoice Pools: What You Can Do in Each Pool, and the Questions That Come Up Most — Frequently asked questions

Step 4 — Know what the Consolidate buttons build

After this step you can use the manual buttons without being surprised by the result. Process simply re-runs the mandatory check on the rows you selected, with no edits. Consolidate, and its by-branch sibling, take the selected unprocessed rows and build the actual documents LHDN will see: the buyer on every one of them is General Public, the line classification is 004, the billing frequency is monthly, and the rows you selected become processed and successful. By branch, each line covers a consecutive range of that branch’s receipt numbers and no e-invoice carries more than 200 lines. Normally you press none of this. It is the fallback for a run that has to be repeated, and for rows older than last month, which the run never takes.

Reference: My E-Invoice Admin Applet — 3. Pools — what the buttons do

Step 5 — Know what the automatic run takes, and how it dates it

After this step you can predict exactly what the automatic run will do to this pool. From the 1st, every half hour by default, it takes unprocessed sales rows dated last month, a hundred at a time, and nothing else. Rows from the current month wait for next month’s runs, which is right. Rows older than last month are never taken, however long you wait: they are outside its window. Each consolidated e-invoice is dated the last day of its receipts’ own month. That is why you sort the pool by date every cycle. If you find old rows, select them and press Consolidate yourself; it has no date window, and the e-invoice it builds reaches LHDN late.

Reference: E-Invoice Pools: The Monthly Consolidation Cycle and Backdated Documents — Backdated documents

Step 6 — Skip a document only when you mean it

After this step you can take a sale out of e-invoicing deliberately, and you will know what that does not do. Skip E-Invoice deletes the pool row and marks the document skipped, and it is the right answer for a sale that must not be e-invoiced, such as one where the other party issues the e-invoice instead. What it does not do is make the document disappear from your month-end. Skipping removes it from the report’s own transaction summary, but it is still listed on the discrepancy tab as a document that exists in your books and not in e-invoicing. So a document skipped by mistake still becomes a question in front of you on the 7th.

Reference: My E-Invoice Admin Applet — 3. Pools — what the buttons do

Step 7 — Do not let one sale be reported twice

After this step you will avoid the one mistake in this pool that has no quiet fix. A sale can end up inside two validated e-invoices, and it happens in two ways: a push to the batch pool run twice, or a document submitted individually while a copy of it was still sitting unprocessed here. Neither path removes duplicates by document, though the repeated push itself was fixed in the backend in August 2026 for pushes made since. The habits that prevent it are small. Check the row count in the Batch Pool before you consolidate. Never repeat a push because the screen timed out; go and look at what the first one did. If it has already happened, you have 72 hours from validation to cancel one of them, and a credit note after that.

Reference: My E-Invoice Admin Applet — Troubleshooting

How the steps fit together

    flowchart TD
  s1["Step 1 — Leave the healthy rows alone"]
  s2["Step 2 — Hunt the rows that will never be swept"]
  s3["Step 3 — Pull one receipt out for a customer who asks"]
  s4["Step 4 — Know what the Consolidate buttons build"]
  s5["Step 5 — Know what the automatic run takes, and how it dates it"]
  s6["Step 6 — Skip a document only when you mean it"]
  s7["Step 7 — Do not let one sale be reported twice"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  s6 --> s7
  

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.

Next: The pool everyone forgets · Back to the series · Play this as a presentation