Skip to content
Five ways a tax number lands on a record, and one that lands none — transcript

Five ways a tax number lands on a record, and one that lands none — transcript

Presentation 1 of 5 in Where a tax number comes from · about 12 minutes · for the whole-system operator — you run the books.

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 the tax numbers on your customer list are patchy and you do not know which of them BigLedger will fill in by itself. GadgetSphere carries about eighty-five thousand customer records, and most of them will never need one — but the ones that do are the ones your business customers will telephone you about. Twelve minutes to learn the five routes, which run for you, and which one is named after a job it does not do.

Step 1 — Name the five routes before you plan any work

After this step you will stop looking for a single button. A tax number reaches a customer record by exactly five paths. Somebody in your office types it. BigLedger searches the board for it while turning a finalised document into an e-invoice, without being asked. You run the same search by hand from a pool row. Your customer supplies it themselves, through the portal or through a link you send them. And there is a screen called Bulk Tin Validation which, despite its place in every plan, writes no tax number at all. Four of those five put a number on the record. Knowing which is which is most of the job.

Reference: My E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts

Step 2 — Learn the one that runs for you, and its three conditions

After this step you will stop keying numbers you never needed to key. When a finalised document is turned into an e-invoice, BigLedger checks three things together: the amount is ten thousand ringgit or more, the buyer’s identity type is a business registration number, and the tax number is blank. All three, not any of them. When all three hold it searches the board by that registration number and writes what it finds in three places at once — onto the customer record, into the document’s own stored copy of the buyer, and onto the e-invoice header. So a large corporate sale can correct your master data as a side effect, and nothing tells you that it did.

Reference: My E-Invoice Admin Applet — 2 posting queue to irb or a pool cron e_invoice_generic_document_to_irb_processor

Step 3 — Know which of the two pool buttons can never give you a number

After this step you will get more out of a pool row than most people do. Open an Individual Pool row and two actions sit beside the tax number. Get TIN searches the board by identity type and identity number and fills the field for you. Verify TIN checks a number you already hold against that same identity pair, and it can never hand you one — it only answers yes or no. The names are close and the jobs are opposite. Crucially, neither carries the ten thousand ringgit condition the automatic search has, so press Get TIN on a nine hundred ringgit corporate sale that the automatic route ignored entirely.

Screen: an Individual Pool row with the buyer block open, showing Get TIN and Verify TIN beside the tax number field

Reference: My E-Invoice Admin Applet — Fields

Step 4 — Understand why the bulk screen writes nothing

After this step you will plan around the bulk tool honestly. Open the file it takes and there is nowhere to put a tax number: the four columns are a name, an e-mail address, a telephone number and a customer code, and there is no template to download, so you type that header row yourself. You are not uploading corrections. You are naming customers whose identity BigLedger should check with the board and, where the check fails, write to. If the check passes, nothing at all happens — no record anywhere that the customer was fine. The number, when it arrives, is typed by your customer, not by you.

Reference: My E-Invoice Admin Applet — Fields

Step 5 — Put the number where the e-invoice will actually read it

After this step you will stop filling the wrong half of the record. A customer holds identity details in two places, the Main tab and the E-Invoice tab, and only the E-Invoice tab is read when an e-invoice is built. Neither screen says so, and both show what look like the same three fields. That matters here because the routes differ: the automatic search and the customer’s own reply both write the E-Invoice tab, and the reply writes the Main tab as well — but a colleague typing into the Main tab alone has changed nothing that LHDN will ever see. When you audit your list, audit the E-Invoice tab.

Reference: Customer Maintenance — Edit customer — E-Invoice

Step 6 — Decide which route each part of your list gets

After this step you will have a plan instead of a backlog. Sort your customers by what they are. Corporate buyers with a registration number and large orders will largely fix themselves, and Get TIN clears the small ones in seconds. Business buyers who ask for named invoices are worth a telephone call, because one call is cheaper than a rejection at month end. Retail walk-ins mostly need nothing, because their receipts are consolidated. That leaves a middle band — business customers you invoice regularly and rarely for much — and those are the ones the request campaign was built for. Size that band first.

Reference: My E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts

How the steps fit together

    flowchart TD
  s1["Step 1 — Name the five routes before you plan any work"]
  s2["Step 2 — Learn the one that runs for you, and its three conditions"]
  s3["Step 3 — Know which of the two pool buttons can never give you a number"]
  s4["Step 4 — Understand why the bulk screen writes nothing"]
  s5["Step 5 — Put the number where the e-invoice will actually read it"]
  s6["Step 6 — Decide which route each part of your list gets"]
  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 corporate customer with a registration number and no tax number buys RM 24,000 of laptops. What happens?


2. The same customer buys RM 900 of accessories instead, and the document lands in a pool. What gives you a tax number?


3. You upload four hundred customers to Bulk Tin Validation. Which of them gets a tax number written from your file?


4. A colleague fills the identity type and number on the customer's Main tab and leaves the E-Invoice tab empty. What will LHDN see?


Answer key
  1. BigLedger searches the board by the registration number and writes the number onto the customer, the document and the e-invoiceMy E-Invoice Admin Applet — 2 posting queue to irb or a pool cron e_invoice_generic_document_to_irb_processor
  2. Get TIN, which searches by identity type and number — and has no amount conditionMy E-Invoice Admin Applet — Fields
  3. None — the file has no tax-number column, and the correction is written by the customer when they answerMy E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts
  4. Nothing — only the E-Invoice tab is read when an e-invoice is builtCustomer Maintenance — Edit customer — E-Invoice
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: The registration the board has no number for · Back to the series · Play this as a presentation

Last updated on