Which customer records ever reach LHDN

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 are about to work through your customer list and would rather not fix eighty-five thousand records. Most of them never reach the Inland Revenue Board — LHDN — at all, a small minority decide whether your month goes through cleanly, and there is a third group that BigLedger will not read even when it is perfect. About fourteen minutes, and telling the three apart is what makes every lesson after this one a much smaller job.

Step 1 — Know which sales carry a name at all

After this step you will know which slice of your customer list actually matters. Most of what GadgetSphere’s twenty-two branches ring up over a counter carries no buyer at all. Those receipts wait in the Batch Pool and are reported once a month inside a consolidated e-invoice, and what goes on that e-invoice is fixed. The buyer is General Public, with the general public tax number, identity type passport, identity value NA, and every contact and address field set to NA. You cannot type over any of it, and your customer record is never read to build it. So the walk-in shopper who gave you nothing costs you nothing here.

Reference: Consolidated e-invoices — How it behaves in BigLedger

Step 2 — Know which sales force the record to be right

After this step you can predict, before anybody finalises anything, which sales will be built from a customer record. Five cases do it. A document whose submission type is Individual. A document marked Single General. A document with no submission type set, where the mandatory fields happen to be complete. Any sales invoice or cash bill of ten thousand ringgit or more marked Consolidated, which is diverted to the Individual Pool automatically because a sale that size cannot hide inside a consolidation, and ten thousand exactly is already above the line. And every sale to a foreign customer, because a consolidated e-invoice cannot carry one at all. Those are your real e-invoice customers.

Reference: E-Invoice Pools & Submission Routing — Where does a finalised document go?

Step 3 — Find out which record BigLedger actually reads

After this step you will stop correcting the wrong record. When BigLedger builds the buyer block it looks in three places in a fixed order: the e-invoice buyer details typed onto the sales document, then the document’s own general e-invoice counterparty block, then the linked customer record, read fresh at the moment of submission. The first of the three that is in use wins outright, and when it does, the customer record is never consulted at all. That is why a document can fail on a field you can see is perfectly correct on the customer. Somebody typed into the document’s buyer block, and it has been overriding your master data ever since.

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

Step 4 — Understand why one filled field blanks seven

After this step you will understand the most baffling rejection in e-invoicing. BigLedger decides whether that on-document block is in use by testing eight fields, and if any single one of them holds anything at all, the whole block is treated as in use. The eight are the buyer’s name, identity type, identity number, tax number, service tax number, e-mail and phone, plus a customer reference sitting behind them that nobody ever types and that counts exactly the same. Fill in one and the other seven go to LHDN blank, even though all seven are right on the customer. So fill that block completely, or leave every field of it empty.

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

Step 5 — Know the two ways a sale leaves the pipeline entirely

After this step you will know which customers are deliberately out of scope and which sales have gone missing by accident. The customer’s E-Invoice tab carries a skip flag for buyers who do not need an e-invoice at all, and a skipped document is removed from the ERP transaction summary. It is not removed from the discrepancy tab, where it still reads as missing, so a skip made by mistake resurfaces as a question at month end rather than as a silence. The dangerous one is different. If a company is not enabled for e-invoicing, every document finalised under it is dropped at the gate with no queue row, no pool row and no error anywhere.

Reference: My E-Invoice Admin Applet — 1. Entry gate (trigger processor, at FINAL)

Step 6 — Know what a wrong record costs you, and when

After this step you will know why an afternoon on your customer list is cheap. Every field you get wrong here comes back later, on a different day from the mistake, in a small and predictable set of shapes. A foreign customer keyed as a Malaysian individual returns as an invalid identity number. A tax number pasted out of a browser with an invisible character in it returns as an invalid buyer tax number, looking perfectly correct on screen. An address with no state never leaves at all and parks in a pool that nothing ages and nothing alerts you about. Reading and clearing those is a separate course. Preventing them is this one.

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

Step 7 — Keep four words apart that everybody runs together

After this step you will read any e-invoice screen correctly. Pooled, queued, submitted and Valid are four different states and only the last one is a tax record. A pooled document is not going anywhere; it is waiting for you. A queued document is on its way, and a queue status saying it is waiting is not an error — the right answer is usually to look again tomorrow. Submitted means the board has it, not that it accepted it. And on a Batch Pool row the word Processed means the row has left the consolidation, not that anything was reported — which is the most expensive misreading in e-invoicing, because a failed row reads exactly like a finished one.

Reference: Pools and queues — What it is not

How the steps fit together

    flowchart TD
  s1["Step 1 — Know which sales carry a name at all"]
  s2["Step 2 — Know which sales force the record to be right"]
  s3["Step 3 — Find out which record BigLedger actually reads"]
  s4["Step 4 — Understand why one filled field blanks seven"]
  s5["Step 5 — Know the two ways a sale leaves the pipeline entirely"]
  s6["Step 6 — Know what a wrong record costs you, and when"]
  s7["Step 7 — Keep four words apart that everybody runs together"]
  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.

Next lesson: The identity each kind of customer needs · Back to the course