Skip to content

Read a pool row before you touch it

Lesson 2 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 a pool row is open in front of you. In about eleven minutes you will learn to read what the row is telling you, work out which of your records the missing field really lives on, fix it there rather than in the place that looks obvious, and know what happened when you pressed the button. Getting this order right is the difference between one correction and the same correction three times.

Step 1 — Read what the row says is missing

After this step you will never guess at a pooled document again. Open the row in whichever pool it is in and look at the Validation Error panel. It names the fields, one by one: supplier tax number is missing, buyer address is missing, contact number is missing. That list is not a summary of the problem, it is the problem, and when the last name on it is filled in the document goes. Remember what a pooled row means before you start typing: nothing was sent, LHDN has never seen this sale, and there is no rejection to read because there was no submission. The whole of this lesson happens before LHDN is involved at all.

Screen: a pool row opened with its Validation Error panel beside it, listing each missing counterparty field by name

Reference: The Month-End E-Invoice Cycle (1st to 7th) — Step 2: Check the Batch Pool for rows that will not be swept

Step 2 — Get the buyer’s identity right

Every e-invoice carries the buyer’s tax number together with an identity document type and the number that goes with it. That one little group of fields causes more rejections than everything else in e-invoicing put together. The rule is short enough to keep in your head. Passport for anyone who is not Malaysian. Business registration number for a company. National identity number only for a Malaysian individual, and only as twelve digits with no dashes in them. And one habit matters as much as the rule: type the number, never paste it. A number copied out of a browser or a PDF can bring an invisible character with it, and the field will look perfectly right on screen while LHDN rejects it every single time.

Reference: E-Invoice Validation Rules & Troubleshooting — Get the buyer’s identity right — this is where most rejections come from

Step 3 — Work out which record is actually being sent

After this step you can solve the most baffling case in e-invoicing: a field that is plainly correct on the customer record and plainly missing on the e-invoice. The buyer’s details can live in two places, on the customer record or typed directly onto the sales document, and the document always wins. Worse, a half-filled block on the document still wins the whole block. BigLedger tests eight fields — the seven on the block itself, name, identity type, identity number, tax number, service tax number, e-mail and phone, and the customer reference sitting behind them that nobody ever types — and treats the block as in use the moment any one of the eight has something in it, sending the other seven blank however perfect the customer record is. So before you correct anything, look at the document’s own e-invoice block. Fill it completely, or empty every field of it.

Reference: E-Invoice Validation Rules & Troubleshooting — Which record does BigLedger actually send?

Step 4 — Fix the address and the state, in the right place

After this step you can clear the second most common reason a row is stuck. Both addresses need a line one, a city and a state, and without them nothing is submitted. If your customer has several addresses, BigLedger sends the first one flagged as the e-invoice address, looking at shipping, then billing, then main, so flag exactly one and the guessing stops. The state is matched to LHDN’s code for you, first exactly, then after stripping punctuation, then partially, then through a list of abbreviations, and Penang, KL and N9 all resolve. When nothing matches, the code is left empty and the document waits. One more: your own company record is the supplier on every sales e-invoice, so one bad field there fails every branch at once.

Reference: E-Invoice Validation Rules & Troubleshooting — Addresses

Step 5 — Check the lines, not just the parties

After this step you will catch the failures that have nothing to do with the buyer. Every line of the document needs five things: a classification code, an item name, a unit price, a tax type and a tax amount. Leave the classification blank and BigLedger fills in 022, Others, so a blank rarely pools a document. A wrong value is different: whatever is there is sent as it is. The one to watch is classification 004, which is reserved for consolidated e-invoices. On an individual e-invoice it is rejected by LHDN even when the buyer’s tax number is perfect, and it is a cheap mistake to make when somebody copies an item setup across.

Reference: E-Invoice Validation Rules & Troubleshooting — Line items

Step 6 — Press Save and Resubmit, then read what it did

After this step you can tell a correction that worked from one that only looked like it did. Save and Resubmit is the same button in all three pools. It writes your corrections back, runs the mandatory check again, and if everything passes it builds the record for LHDN and puts it in the submission queue. If it does not pass, the check fails again and the reason is back in Validation Error. On a Batch Pool row there is a sting: whichever way it went, the row is now marked processed, either successful or failed. A failed row is no longer waiting for the monthly consolidation. That is lesson four, and it is the single most expensive thing in this course.

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

How the steps fit together

    flowchart TD
  s1["Step 1 — Read what the row says is missing"]
  s2["Step 2 — Get the buyer's identity right"]
  s3["Step 3 — Work out which record is actually being sent"]
  s4["Step 4 — Fix the address and the state, in the right place"]
  s5["Step 5 — Check the lines, not just the parties"]
  s6["Step 6 — Press Save and Resubmit, then read what it did"]
  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. A pooled document keeps failing on the buyer's tax number, which you can see is correct on the customer record. What do you check?


2. Your customer has a shipping, a billing and a main address on file. Which one goes on the e-invoice?


3. A line is saved with no classification code. What is sent to LHDN?


4. You press Save and Resubmit on a Batch Pool row and the check fails again. What is the state of that row?


5. A document is sitting in a pool. What has LHDN been told about that sale?


Answer key
  1. The e-invoice block typed onto the document itself, which wins over the customer recordE-Invoice Validation Rules & Troubleshooting — Which record does BigLedger actually send?
  2. The first one flagged as the e-invoice address, looking at shipping, then billing, then mainE-Invoice Validation Rules & Troubleshooting — Which address
  3. 022, Others, which BigLedger fills in when the code is blankE-Invoice Validation Rules & Troubleshooting — Line items
  4. Processed and failed, so the consolidation will not pick it upMy E-Invoice Admin Applet — 3. Pools — what the buttons do
  5. Nothing at all; a pooled document was never sentE-Invoice Validation Rules & Troubleshooting — The two kinds of failure
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 lesson: Clear the Individual Pool · Back to the course

Last updated on