Read the buyer's screen before you answer — 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 a buyer has written to GadgetSphere saying their e-invoice is stuck, and you would like to know what they are actually looking at before you reply. About ten minutes. The screen they are reading is more misleading than yours, in one specific and important way, and knowing where tells you what to say.

Step 1 — Know that In Queue is three situations wearing one number

After this step you will stop reading a shopper’s In Queue count as good news. That counter adds up three different things. One: the e-invoice is genuinely on its way and the Inland Revenue Board has not seen it yet. Two: the board has it and has not answered. Three — and this is the one that matters — the pool row failed, which means BigLedger tried to build or send the document and could not. All three show the shopper the same calm word. So “it has been in the queue for a week” is not a reassurance you can pass on; it is a prompt to go and look.

Reference: Storefront E-Invoice Request — Requested E-Invoices, Cancellation and History

Step 2 — Know exactly what Validation Error means

After this step you will treat that counter as precise, because it is. Validation Error counts one thing only: an e-invoice whose status came back Invalid. The document reached the board, the board examined it, and the board refused it on its content — usually a tax number that does not belong with the identification number, or an address with no state. Nothing else is ever counted there. A request that BigLedger never managed to send is folded into In Queue instead. So if a shopper tells you they have a validation error, you already know the document exists at LHDN and was rejected.

Reference: Storefront E-Invoice Request — Requested E-Invoices, Cancellation and History

Step 3 — Know why they cannot simply correct it and ask again

After this step you will know which side of the fence a fix sits on before you promise anything. Once a pool row has been submitted it reads as a success, and the request endpoint refuses any further request against a successful row. The shopper’s own search then finds the submitted e-invoice rather than a pool row, and the Request button is not offered at all. So a shopper whose e-invoice came back Invalid is genuinely stuck — only you can correct the buyer details and resubmit, from the pools or from the To IRB listing. Say so plainly rather than asking them to try again.

Reference: Storefront E-Invoice Request — Troubleshooting

Step 4 — Know the one case where they can help themselves

After this step you will stop doing work the buyer could do faster. The mirror image of the last step is the request that is still sitting under In Queue because BigLedger never sent it. That pool row is not a success, so a second request against it is accepted. If the details were wrong — a mistyped tax number, a missing city — the shopper can correct them and request again, and it will go through. The test is simply whether anything was submitted. Nothing submitted means they can retry; something submitted means it is yours.

Reference: Storefront E-Invoice Request — Troubleshooting

Step 5 — Remember how little a guest can see

After this step you will judge what a buyer is able to check before you ask them to check it. A shopper who never signed in has no account and no history. The only way back to their request is the tracking link e-mailed to them, and that link is the whole of their access. They cannot see a cancellation list, they cannot see a history list, and they cannot raise a cancellation request at all, because that path needs an authorised session. Their details were never saved as a customer record either — they travelled with the request onto that one document.

Reference: Storefront E-Invoice Request — Feature visibility / permissions

Step 6 — Answer with the pool row in front of you

After this step you will have a reply that is true the first time. Find the document by its number in the pools. If the row is unprocessed, the request has not been sent and the buyer can correct it themselves. If it reads processed and failed, nothing will happen on its own and it will not be swept into the consolidation either; read the validation error, fix exactly what it names, and use Save and Resubmit. If there is no pool row and a to-IRB header instead, the sale has been reported, and your route is a correction rather than a resubmission.

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

How the steps fit together

    flowchart TD
  s1["Step 1 — Know that In Queue is three situations wearing one number"]
  s2["Step 2 — Know exactly what Validation Error means"]
  s3["Step 3 — Know why they cannot simply correct it and ask again"]
  s4["Step 4 — Know the one case where they can help themselves"]
  s5["Step 5 — Remember how little a guest can see"]
  s6["Step 6 — Answer with the pool row in front of 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.

Next: The complaints you will actually get · Back to the series · Play this as a presentation