Invalid is three different things — 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 the first time a tax-number check tells you a number is invalid and you are about to ask a customer to correct something that was never wrong. The word covers three quite different situations and the screen shows you the same thing for all three. Eleven minutes to learn to tell them apart, and the two-minute check that does it.

Step 1 — Learn that one word covers three situations

After this step you will stop treating invalid as a fact about your data. When BigLedger asks the board to confirm a tax number, it sends three things together and gets one answer back. That answer is recorded as valid or not valid, and not valid is written the same way whatever caused it. It might mean the board looked and disagreed. It might mean the board never answered at all. Or it might mean the question was never askable, because one of the three fields was empty. Three causes, three different remedies, and one word on the screen.

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

Step 2 — The board looked and disagreed

After this step you will know what a genuine disagreement looks like. The check is not a format check. It asks whether this particular tax number belongs to this particular identity — this registration number, or this identity card number. So a perfectly well-formed number can be invalid simply because it belongs to somebody else, which is what happens when a group’s head-office number is keyed onto a subsidiary’s record, or when two customers were merged badly. Submitted anyway, that combination comes back from LHDN as a rejection naming an invalid buyer tax number. This is the only one of the three causes where asking the customer is the right next move.

Reference: My E-Invoice Admin Applet — Troubleshooting

Step 3 — The board never answered

After this step you will stop mass-mailing your customers over an outage. Any response that is not a success is recorded as not valid — an outage, a refusal, a timeout, and above all an expired access token. BigLedger talks to the board on your behalf using a token that is regenerated roughly every twenty minutes, and when that stops working every call fails, including this one. The symptom is unmistakable once you know it: everything is invalid, including customers you know are correct. A run started in that state marks your whole list wrong and queues every one of them to be written to.

Reference: My E-Invoice Admin Applet — 4. Submission, validation and e-mail (cron)

Step 4 — The question was never askable

After this step the blanks on your records will stop surprising you. The check needs all three together: identity type, identity value and tax number. If any one is empty there is nothing to ask, and the two places this happens behave in opposite ways. A bulk run treats the blank as a failure and queues that customer for a request, which is sensible. The self-service form your customer fills in does the reverse: a blank field makes it skip the check entirely and save what it was given, so a customer who filled one box has quietly cleared the other two.

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

Step 5 — Run the two-minute check before you touch anything

After this step you will never act on the wrong cause. Pick one customer you are confident about — a large corporate account whose number you have seen on their own documents — open a pool row and press Verify TIN. If it says yes, the channel is healthy and your invalid results are real: look at those records. If it says no on a customer you know is right, stop. It is the token or the board, not your data, and nothing you change today will help. Wait, verify again, and only then re-run whatever you were about to run.

Reference: My E-Invoice Admin Applet — Fields

Step 6 — Plan a campaign around the fact that nothing reports back

After this step your campaigns will be repeatable. There is no screen anywhere that tells you what a bulk run found — a customer that passed leaves no trace at all, and a customer that failed leaves only a request row. So date everything yourself. Before a run, save a list of the customers with a blank or suspect number. Verify one known-good record to prove the channel. Run it. A month later, list again and compare the two. That comparison is the only report you will get, and it is a good one, because it measures the outcome rather than the attempt.

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

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: Your suppliers are the half nobody counts · Back to the series · Play this as a presentation