Getting a stranded Batch Pool row back, and the four things that will not do it — transcript

Presentation 4 of 4 in Red rows in the Batch Pool: what each status means and what actually clears them · about 12 minutes · for the whole-system operator — you run the books.

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

This presentation is for whoever has found Batch Pool rows reading processed and failed and wants them back in the monthly batch. In about twelve minutes you will know the one route that works, why it works the way it does, and four reasonable-looking alternatives that quietly do nothing.

Step 1 — Accept that there is no reset, and know how that was established

After this step you will stop looking for an undo. There is no button and no background sweep that takes a Batch Pool row reading processed and leaves it unprocessed again. That is a strong claim, so it was checked rather than assumed, and the check found one near miss worth knowing about. Every reset on the paths you can reach is on a row the software has just built, never on one it loaded. The single exception is the storefront: when a shopper fills in their own tax details online, the request reopens that receipt’s row and then immediately turns it into an individual e-invoice, so it ends processed again and it leaves the monthly batch. Recovery here always means a new row.

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

Step 2 — Use the round trip, which is the route that works

After this step you will have the recovery in two clicks. Select the stranded rows and press Move to Individual. That marks the Batch Pool row deleted and creates an Individual Pool row for the same document. Then open the Individual Pool, select the same rows, and press Move To Batch Pool. That builds a brand new Batch Pool row, unprocessed, and sets the document’s submission type back to consolidated at the same time. You end up where you wanted to be — a fresh unprocessed row the consolidation run can collect — and the stranded row is gone rather than mended, which is exactly what the software is able to do.

Screen: the Individual Pool listing with rows selected and the Move To Batch Pool button above the grid

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

Step 3 — Expect the new row to be red, and check its date

After this step nothing about the result will alarm you. The row that comes back is unprocessed and failed, carrying forward the same missing-field message it always had. That is correct and it is the point of the first lesson in this series: the run does not read that column. What the run does read is the date, and the new row keeps the document’s own transaction date rather than today’s. So if the receipt is from two months ago, the round trip has put it back into a state the automatic run still will not select — you have made it recoverable, not collected. Finish the job by selecting it and pressing Consolidate.

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

Step 4 — Rule out the two alternatives that sound most plausible

After this step you will not waste a cycle. The first is waiting. Nothing ages a pool row, nothing alerts on one, and the recovery processors that could move rows between pools are switched on for almost nobody — four of the five can be scheduled and essentially no company schedules them, and the fifth cannot be put on a timetable at all. The second is pressing Process again. It reruns the same check on the same unchanged data, writes the same failure, and sets the same processed flag; you end exactly where you started, one audit entry worse off. Neither of these does anything, and both feel like doing something.

Reference: Pools and queues — How it behaves in BigLedger

Step 5 — Rule out the other two, including the one support would reach for

After this step you will know why an obvious request gets a strange answer. The third is asking support to push the documents back to the batch pool. That endpoint refuses any document that already holds a live pool row — and a stranded row is live, just processed — so it will skip your documents and report them skipped. It works only after the old row has been removed, which the round trip does. The fourth is Skip E-Invoice. It does delete the row, but it also marks the document as one you never intend to report, and it will still be listed as missing on the discrepancy report. That is an answer to a different question.

Reference: My E-Invoice Admin Applet — After a consolidated cancellation: where the receipts are, and what puts them back

Step 6 — Recognise the rows no route will help

After this step you will stop trying on a small, stubborn group. The automatic run asks for six sales document types — invoice, cash bill, credit note, debit note, refund note and return. A Batch Pool row of any other type, and a self-billed purchase document is the one you will meet, is never selected by it, whatever its status and whatever its date. Consolidate will not build a consolidated e-invoice around it either. These rows are few everywhere, and the honest answer for them is to complete the document and submit it individually, or to skip it deliberately with a note of why. Do not leave them looking like a backlog.

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

Step 7 — Check the work a week later

After this step you will know when to stop. Come back after the next consolidation and run the thirty-second check: filter the Batch Pool on process status unprocessed, sort by date, and look at the top. The rows you recovered should be gone, and gone means collected rather than deleted — confirm it by opening one of the source documents and reading the e-invoice number now stamped on it, then finding that e-invoice and confirming it reads Valid. If the row is still there and still unprocessed, its date is outside the window and it needs the Consolidate button, not more patience.

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

How the steps fit together

    flowchart TD
  s1["Step 1 — Accept that there is no reset, and know how that was established"]
  s2["Step 2 — Use the round trip, which is the route that works"]
  s3["Step 3 — Expect the new row to be red, and check its date"]
  s4["Step 4 — Rule out the two alternatives that sound most plausible"]
  s5["Step 5 — Rule out the other two, including the one support would reach for"]
  s6["Step 6 — Recognise the rows no route will help"]
  s7["Step 7 — Check the work a week later"]
  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.

1. What resets a Batch Pool row from processed back to unprocessed? The next consolidation run, which retries processed rows once
Save and Resubmit, when the check finally passes
Nothing you can reach — recovery means replacing the row, not repairing it

2. Which pair of actions gives you a fresh unprocessed Batch Pool row? Move to Individual, then Move To Batch Pool from the Individual Pool
Skip E-Invoice, then re-finalise the document
Move to Single General, then Consolidate

3. The recovered row reads unprocessed and failed. Is that a problem? Yes — it must read queued before the run will collect it
No — the run reads the process status only; what matters next is whether the row's date is inside the run's month
No — the run will clear the failure itself on the next tick

4. Why does asking support to push the documents back not work on a stranded row? Support has no endpoint for it
That endpoint skips any document that already holds a live pool row, and a processed row is still live
It only accepts documents from the current month

5. A Batch Pool row holds a self-billed purchase document. What will consolidate it? The automatic run, once its month comes round
The Consolidate button, which has no document-type filter
Nothing — the run asks for sales document types only, so complete it and submit it individually or skip it deliberately

Answer key

Nothing you can reach — recovery means replacing the row, not repairing it — My E-Invoice Admin Applet — 3. Pools — what the buttons do
Move to Individual, then Move To Batch Pool from the Individual Pool — My E-Invoice Admin Applet — 3. Pools — what the buttons do
No — the run reads the process status only; what matters next is whether the row's date is inside the run's month — My E-Invoice Admin Applet — 3. Pools — what the buttons do
That endpoint skips any document that already holds a live pool row, and a processed row is still live — My E-Invoice Admin Applet — After a consolidated cancellation: where the receipts are, and what puts them back
Nothing — the run asks for sales document types only, so complete it and submit it individually or skip it deliberately — My E-Invoice Admin Applet — 3. Pools — what the buttons do

This is a self-check. Your answers are marked in your browser and stay there — nothing is sent anywhere, nothing is recorded, and the marking is readable in the page source, so it is not a credential. Open the answer key at any time.

Back to the series · Play this as a presentation

Last updated on September 19, 2026

Getting a stranded Batch Pool row back, and the four things that will not do it