Find every rejection you have

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 somebody has asked whether last month is really reported. You already know from the month-end course how to fix one rejection. This time you will build the complete list first, because the rejections that cost money are the ones nobody was looking at. In about eleven minutes you will learn the four screens that between them see every failure BigLedger knows about, the one screen that will lie to you if you let it, and the one thing none of them can see.

Step 1 — Separate the three ways a document fails

After this step you can sort any complaint into one of three boxes before you open anything. A document can be held by BigLedger, which means its own completeness check found a mandatory field missing and nothing was ever sent. It can be rejected by LHDN, which means the submission was accepted and the content was refused, with an error code written onto the record. Or it can fail in transit, which means it passed both of BigLedger’s gates, tried to go, and could not, so LHDN never saw it and there is no code at all. Three boxes, three screens, three completely different fixes. Everything in this lesson is about making sure none of the three is missing from your list.

Reference: E-Invoice Validation Rules & Troubleshooting — The two kinds of failure

Step 2 — Build the Invalid list from the screen that tells the truth

After this step you have every LHDN rejection for the month, and you have not been reassured by a false one. Go to Internal Submission, then To IRB E-Invoice, filter to the month and sort on the status column. The Invalid rows gather together, and the Export tab gives you the same rows as a spreadsheet if you would rather work there. Do not build this list from Submission History. That screen is a snapshot of each submission at the moment it was sent, so it reads Submitted forever, even for a document LHDN rejected an hour later. A list built there is short, clean and wrong, and the rejections it hides stay hidden until somebody reconciles months later.

Reference: The Month-End E-Invoice Cycle (1st to 7th) — Step 4: Pull the export that shows live status

Step 3 — Add the documents LHDN never saw

After this step your list includes the sales that were stopped before they left the building. Open all three pools in turn. Unprocessed Batch Pool rows need nothing from you; every row in the Individual and Single General pools is a sale you have not reported, and nothing will move it but you. Why each pool behaves that way is the pools course, not this one. What matters here is the row that hides. A Batch Pool row marked processed and failed is one somebody already tried to fix; it is no longer waiting for the consolidation, and it will not appear on any unprocessed filter. Filter for failed rows deliberately, every month, or you will never see them.

Reference: Pools and queues — How it behaves in BigLedger

Step 4 — Add the ones that failed on the way out

After this step you can spot the failure that leaves no trace anywhere obvious. A document that passed the completeness check gets a submission queue row, and if the send itself fails, that row is stamped as a failed submission with the reason written into its request error. The e-invoice keeps a queued status, LHDN has no record of it, and — this is the part that catches people — nothing is written to Submission History, because a history row is only created when LHDN accepts a payload. So the only place the failure exists is the queue row. Look in Individual Submission for an individual e-invoice and in Consolidated Submission for a consolidated one, and read the request error on each failed row.

Reference: My E-Invoice Admin Applet — Troubleshooting

Step 5 — Add the ones with no row at all

After this step you can find the sales that are not on any of the screens above. A document finalised while the company’s e-invoice setting was switched off is dropped silently: no pool row, no queue row, no error, nothing. You cannot find it by looking at e-invoice screens, because there is nothing there to look at. The tool for it is Monthly Report, then Discrepancies Report: create the report for the month and read the direction that says the document exists in your books and is missing from e-invoicing. Read the skipped bucket first and subtract it, and remember that foreign-currency documents are never examined on that side at all, so check those separately. One more limit, and it is the one that decides what this list is worth: the report compares your books against BigLedger’s own records, never against what LHDN holds. Anything keyed straight into the MyInvois portal is invisible to it.

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

Step 6 — Tell one bad document from a bad morning

After this step you will never spend an afternoon correcting customer records for a problem that is not about data. Look at the shape of your list before you work it. A handful of rejections spread over different customers, with different codes, is an ordinary month. Every document failing at once, on the same morning, with the same authentication message and not one of them carrying a data problem, is something else entirely: the authorisation you granted BigLedger as your intermediary on the MyInvois portal has lapsed, or the process that refreshes its token has stopped. Nothing you edit will move a single document until that is put right. Re-authorise on MyInvois and raise it with support, then come back to the list.

Reference: The Month-End E-Invoice Cycle (1st to 7th) — Before you start

How the steps fit together

    flowchart TD
  s1["Step 1 — Separate the three ways a document fails"]
  s2["Step 2 — Build the Invalid list from the screen that tells the truth"]
  s3["Step 3 — Add the documents LHDN never saw"]
  s4["Step 4 — Add the ones that failed on the way out"]
  s5["Step 5 — Add the ones with no row at all"]
  s6["Step 6 — Tell one bad document from a bad morning"]
  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 lesson: Read the error and tell whose it is · Back to the course