Skip to content

What runs for you, and how you know

Lesson 6 of 6 in Work the pools until nothing is stuck · about 11 minutes · for the whole-system operator — you run the books.

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 you would like to stop opening screens to find out whether anything is wrong. In about eleven minutes you will learn which parts of the pool work BigLedger does for you, which e-mail or screen proves each one ran, and which three things look automatic and are not. The honest answer is that the automation is real but silent, so the last step is the small routine that covers the difference.

Step 1 — Name what genuinely runs without you

After this step you can list the work you are not doing by hand. Six things run in the background on your tenant’s schedule. The batch cycle run sweeps every unprocessed Batch Pool row into consolidated e-invoices. A consolidated processor sends those to LHDN. A submission processor drains the individual queue, one document per call. A validation processor polls LHDN and writes Valid or Invalid back onto each record. A printable e-mail processor sends the validated document to the buyer. And underneath them, a token processor renews the authorisation you granted on the MyInvois portal roughly every twenty minutes. Without it nothing that talks to LHDN moves — the submissions and the validation polling all stop — though consolidation itself keeps building documents locally.

Reference: My E-Invoice Admin Applet — 4. Submission, validation and e-mail (cron)

Step 2 — Find out which of them are switched on for you

After this step you will know what to ask, and who to ask. None of those processors is universal. Each is enabled for your tenant by BigLedger support, and the symptom of a missing one is very specific: documents stop, quietly, at the queue that processor was supposed to drain, and nothing on the screen says why. So the question worth asking your support contact once, and writing down, is which of the e-invoice processors are enabled for each of your companies, and on what schedule. Then open each company’s E-Invoice tab and read the three switches that are yours rather than theirs: whether the validated document is e-mailed to the buyer at all, and whether consolidated and single-general are still offered as submission types on that company’s documents. For a three-company group that is three answers, not one.

Reference: My E-Invoice Admin Applet — Before you can use it

Step 3 — Let the Individual Pool come to you

After this step you have a way of hearing about failed individual-pool rows without opening the pool. There is a processor whose whole job is to e-mail a list of failed individual pool transactions, per company, as a spreadsheet, to addresses configured for your tenant. If it is switched on for GadgetSphere, the three companies each produce their own list and it arrives in your inbox instead of waiting for you to remember. This is the closest thing e-invoicing has to an alert on a pool, and it is worth confirming that the address on it is one somebody actually reads, because the pool it describes is the one holding your five-figure sales.

Reference: My E-Invoice Admin Applet — 4. Submission, validation and e-mail (cron)

Step 4 — Let the documents that never started come to you too

After this step you know where the hardest failure announces itself. A sale that was finalised while something was wrong at the entry gate has no pool row, no queue row and no error, so no pool or queue screen can show it to you. A standing detection sweep looks for exactly this shape, finalised documents that e-invoicing should have picked up and did not, records each one, and e-mails a digest when it confirms one. Nothing reads that list on screen, so the e-mail is its whole interface — the next step’s report is the other place the same document turns up. Treat one of these digests as a support ticket rather than a notification: the documents on it have to be pushed into the pipeline for you.

Reference: My E-Invoice Admin Applet — Troubleshooting

Step 5 — Have last month’s proof generated for you

After this step your month-end reconciliation can start with a report you did not have to build. The Discrepancies Report is the one screen that compares what you sold against what BigLedger holds e-invoice records for, and a scheduler can produce last month’s report for every company that has e-invoicing enabled and e-mail it to a configured address. Like the others, it is switched on for your tenant rather than by you. Remember its one blind spot when you read it: it compares your books against BigLedger’s records, not against what LHDN holds, so anything keyed straight into the MyInvois portal will never appear on it.

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

Step 6 — Name the three things that are not automatic

After this step you will stop waiting for things that are never coming. First, nothing ages a pool row, and nothing recovers one. The Individual and Single General pools have no alert of any kind, so a document can sit in one for a year and no screen will say so. BigLedger does contain five processors that could move these rows for you, and measured across ninety of ninety tenant databases they were configured on exactly one. So assume manual, plan for manual, and ask support if you want to know about your own tenant. Second, the retries-remaining figure on a failed submission is decorative: it is written once and nothing counts it down, so a row showing five retries left is not going to be retried. Third, the one processor that does revisit failed submissions takes the newest ten first, which means an old failed row can be passed over indefinitely while newer ones keep arriving.

Reference: Pools and queues — How it behaves in BigLedger

Step 7 — Run the thirty-second round that covers the gap

After this step you have the routine that sits exactly where the automation stops. Once a week, three screens. Individual Pool: empty, or every row has a name against it and a reason. Single General Pool: the same test, and open it even when you are sure it is empty. Batch Pool, filtered to this month: rows unprocessed, and no processed-but-failed rows hiding underneath them. That is the whole round, and the guide budgets thirty seconds for it. Everything else in this lesson happens whether or not you log in. These three things happen only because you looked.

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

How the steps fit together

    flowchart TD
  s1["Step 1 — Name what genuinely runs without you"]
  s2["Step 2 — Find out which of them are switched on for you"]
  s3["Step 3 — Let the Individual Pool come to you"]
  s4["Step 4 — Let the documents that never started come to you too"]
  s5["Step 5 — Have last month's proof generated for you"]
  s6["Step 6 — Name the three things that are not automatic"]
  s7["Step 7 — Run the thirty-second round that covers the gap"]
  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. Which pool work happens on a schedule without anybody pressing a button?


2. How can you learn that individual-pool transactions have failed without opening the pool?


3. A document was finalised while the company's e-invoice setting was off. How does that reach your attention?


4. A failed submission row shows five retries remaining. What does that number mean?


5. You want to know which background processors are running for your companies. Where does that answer come from?


Answer key
  1. The sweep of every unprocessed Batch Pool row into consolidated e-invoicesMy E-Invoice Admin Applet — 3. Pools — what the buttons do
  2. A processor e-mails a spreadsheet of them per company to the configured addressesMy E-Invoice Admin Applet — 4. Submission, validation and e-mail (cron)
  3. The detection sweep e-mails a digest; there is no screen for these documentsMy E-Invoice Admin Applet — Troubleshooting
  4. Nothing; it is written once and never counted downPools and queues — How it behaves in BigLedger
  5. BigLedger support, who enable them per tenantMy E-Invoice Admin Applet — Before you can use it
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 course

Last updated on