Fix it at the source, not on the e-invoice — 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 you run the books at GadgetSphere and you have already fixed a rejection once and watched it come back. There are three places a buyer’s details can live, and the e-invoice was built from exactly one of them. In about twelve minutes you will learn to find out which, correct that one, and leave the customer in a state where the next sale does not land back on your desk.

Step 1 — Find out which record was actually read

After this step you will stop correcting records that were never consulted. When BigLedger builds a sales e-invoice it looks for the buyer in three places, in order. First, an e-invoice buyer block typed directly onto the sales document — if anything is there, those details are used exactly as typed and the customer record is never read at all. Second, the document’s general e-invoice counterparty block. Only if both are empty does it read the linked customer record, fresh, at the moment of submission. So before you open the Customer applet, open the sales document and look at its e-invoice tab. If somebody typed something there months ago, that is your record.

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

Step 2 — Understand the half-filled block

After this step you can explain the most baffling rejection in e-invoicing. BigLedger tests eight fields and treats the block on the document as being in use if any single one of them has something in it — the name, the identity type, the identity number, the tax number, the service tax number, the e-mail, the phone, and the customer reference sitting behind them that nobody types. Fill in one and the other seven are sent blank, even though every one of them is perfectly correct on the customer record. That is how a document fails on a field you can see with your own eyes is right. The rule is simple and absolute: fill the block completely, or empty every field of it. Half is the only wrong answer.

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

Step 3 — Know which address goes

After this step an address rejection will not send you through six records looking for the offending one. A GadgetSphere corporate customer may have a shipping address, a billing address and a main address on file. BigLedger sends the first one flagged as the e-invoice address, looking in a fixed order: shipping first, then billing, then main. So the address on the rejected e-invoice may not be the one you would have guessed. Flag exactly one address as the e-invoice address on each customer and the guesswork disappears for good. And remember the exception from step one: if the address was typed onto the sales document itself, that typed address is what went, exactly as entered.

Reference: E-Invoice Validation Rules & Troubleshooting — Which address

Step 4 — Correct the customer properly

After this step the customer record is right, not merely different. Open the customer in the Customer applet and go to its E-Invoice tab. What belongs there is the buyer’s name as registered with LHDN, their tax number, their identity number with the matching identity type, the full e-invoice address with city and state, and a contact number. Look the tax number up on the MyInvois portal rather than accepting whatever was on the sales order, and type it in by hand. A number pasted from a browser or a PDF can carry an invisible character that makes it fail every single time while looking flawless on screen. If the tab is simply empty, that alone explains the rejection.

Reference: Customer Maintenance — Edit customer — E-Invoice

Step 5 — Let BigLedger fetch what it can

After this step you will stop typing numbers the system can find for itself. On a sale of ten thousand ringgit or more where the buyer’s identity type is a business registration number and the tax number is blank, BigLedger searches LHDN’s registry by that registration number and writes the number back for you when it finds a match. You can also ask for it deliberately, at any amount: open the row in the Individual Pool and use Get TIN or Verify TIN, which call the same LHDN tax-number search for whatever identity type and value are on the row. The ten-thousand line belongs to the automatic search and not to the button, which is exactly why a small sale with a missing tax number simply parks — nothing was tried for it, and pressing the button is the thing nobody thinks to do.

Reference: E-Invoice Pools & Submission Routing — The RM 10,000 rule

Step 6 — Correct many customers in one pass

After this step a hundred bad tax numbers is one upload rather than a hundred records. If a whole category of GadgetSphere’s corporate customers was set up without tax numbers, correcting them one record at a time is the wrong shape of work. Go to Tools, then Bulk Tin Validation. Download the template from the screen, fill it in, choose the matching delimiter, upload the file and submit it. Each row is queued, and on approval the tax number is written onto the customer record itself — which is the point, because it fixes the master data rather than the e-invoices. Then come back to the rejected documents and resubmit them, which is the next lesson.

Reference: My E-Invoice Admin Applet — Fields

How the steps fit together

    flowchart TD
  s1["Step 1 — Find out which record was actually read"]
  s2["Step 2 — Understand the half-filled block"]
  s3["Step 3 — Know which address goes"]
  s4["Step 4 — Correct the customer properly"]
  s5["Step 5 — Let BigLedger fetch what it can"]
  s6["Step 6 — Correct many customers in one pass"]
  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: Resubmit, and prove it landed · Back to the series · Play this as a presentation