Skip to content
What runs without you, and what never will — transcript

What runs without you, and what never will — transcript

Presentation 6 of 7 in Read a rejection and fix it · about 11 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 lesson is for you if you run the books at GadgetSphere and you suspect you are doing work the system already does. You are, and this lesson names it. But the more useful half is the other half: three places where nothing runs, nothing warns and nothing retries, and where a standing habit is the only thing standing between you and unreported revenue. About eleven minutes, and no screens to fix.

Step 1 — Let the pipeline run itself

After this step you will know how much of a clean month needs nobody at all. Finalising a sales document is the last manual act in the normal path. A trigger fires at that moment and routes the document. A scheduled processor then builds the e-invoice record, runs the completeness check and either queues it for LHDN or parks it in a pool with the reason attached. Another sends the queued documents, one at a time. Consolidation and consolidated submission run on a schedule set for your company, a few days before the seventh. The buttons you know — Process, Consolidate, Submit — exist for the day a run has to be repeated, not for every month.

Reference: E-Invoice Pools & Submission Routing — The monthly consolidation cycle

Step 2 — Stop asking LHDN for its verdict

After this step you will never refresh a screen waiting for a decision that is already being fetched. Once a payload is accepted, a processor polls LHDN on your behalf and writes the answer onto the e-invoice record: Submitted, then Valid or Invalid, along with the LHDN document identifier and the exact validation date and time. That written-down validation time matters later, because the seventy-two-hour cancellation window is measured from it. There is a manual nudge for a row that has stopped moving — the Validation Queue, where Submit asks LHDN again for up to twenty rows at a press — but on a healthy document you press nothing and the verdict simply appears in the status column.

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

Step 3 — Stop minding the authorisation

After this step you know why nobody at GadgetSphere logs into MyInvois to keep submissions flowing. BigLedger submits on your behalf using a token generated against your company’s tax number, and a processor regenerates that token roughly every twenty minutes, keeping a few of them live per company and environment. You will never see it working. You will see it stop: every submission failing at once with a message that the access token is not available, no data problem on any of them. That is the whole signal, and it has only two causes — the processor is not running, or the authorisation you granted on the MyInvois portal has expired or been removed. Both need someone else; neither needs a customer edited.

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

Step 4 — Stop sending the buyer their copy

After this step the delivery half of the job is off your desk, if it is on at all. Once LHDN validates an e-invoice, a processor e-mails the validated document to the buyer — but only for a company whose Send Email To Buyer switch is on, which is a setting on that company’s own E-Invoice tab, not a tenant-wide one. Where it is on, the processor works through a queue in small batches and retries a handful of times. When a customer says they never received theirs, the Email Dashboard tells you which of three things it was: a row still queued, a row with an error, or a blank e-mail address on the buyer. No row at all means the company switch is off.

Reference: My E-Invoice Admin Applet — Screens and menus

Step 5 — Let the failures come to you

After this step you can stop opening the applet to find out whether anything went wrong. Three things arrive by e-mail without anyone looking at a screen. A processor sends a spreadsheet of the failed individual-pool transactions for each company to the addresses configured for it. A standing sweep looks for finalised documents that never entered the pipeline at all and e-mails a digest when it confirms one — which matters because those documents appear on no e-invoice screen anywhere. And the discrepancy report can be generated for last month automatically, for every company with e-invoicing switched on, and e-mailed out. Ask your BigLedger contact which of the three are switched on for you, and where they are addressed. Then check each company’s own E-Invoice tab: consolidated and single-general can each be taken out of its Submission Type list, which is why a type somebody used last year may not be offered any more.

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

Step 6 — Know exactly what nothing will tell you

After this step you know where the automation stops, which is the only part of this lesson you have to act on. Three gaps. A document in the Individual or Single General pool waits for a person indefinitely; no rule ages it and nothing warns you it has been there since March. Five processors exist that could move these rows, and measured across ninety tenant databases they were configured on exactly one, so assume manual unless support says otherwise. A failed submission row shows a retries-remaining figure that is written once and never counted down — it is decorative, and the one processor that does revisit failed rows takes the newest ones first, so an old one can wait behind newer ones forever. And the ghost sweep has no screen at all; the e-mail is the only way you learn. So: a weekly look at both waiting pools, and treat that digest as post you open.

Reference: My E-Invoice Admin Applet — Troubleshooting

How the steps fit together

    flowchart TD
  s1["Step 1 — Let the pipeline run itself"]
  s2["Step 2 — Stop asking LHDN for its verdict"]
  s3["Step 3 — Stop minding the authorisation"]
  s4["Step 4 — Stop sending the buyer their copy"]
  s5["Step 5 — Let the failures come to you"]
  s6["Step 6 — Know exactly what nothing will tell you"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

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. Who fetches LHDN's verdict on a submitted e-invoice?


2. How often is the authorisation token that BigLedger submits with regenerated?


3. A customer says they never received their validated e-invoice. Where do you look?


4. A failed submission row shows five retries remaining. What will happen to it?


5. What tells you a document in the Individual Pool has been sitting there since March?


Answer key
  1. A processor polls LHDN and writes Valid or Invalid onto the recordMy E-Invoice Admin Applet — 4. Submission, validation and e-mail (cron)
  2. About every twenty minutes, by a processorMy E-Invoice Admin Applet — Before you can use it
  3. The Email Dashboard, at the queue row's retry count and errorMy E-Invoice Admin Applet — Screens and menus
  4. Nothing dependable — the figure is never counted down, and old failed rows can be starved by newer onesMy E-Invoice Admin Applet — Troubleshooting
  5. Nothing — the pool waits indefinitely, which is why you look at it on a schedulePools and queues — How it behaves in BigLedger
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.

Next: When a document will not go at all · Back to the series · Play this as a presentation

Last updated on