Nothing is rejected for a blank classification — 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 whoever at GadgetSphere owns the item master and has been told that an item without an e-invoice classification will fail at submission. It will not. In about thirteen minutes you will know exactly what happens instead, which is worse and much quieter, and you will know how to see it.

Step 1 — Put the three fields in their place

After this step you will know what you are actually setting. An item’s E-Invoice tab carries three things the tax authority asks for on every line: what kind of goods or service this is, what unit it was sold in, and what kind of tax applies. They are the item’s contribution to a document it has never heard of. Nothing about selling the item depends on them. No till refuses a sale, no invoice refuses to finalise, no report goes blank. They matter in exactly one place, weeks later, when a sales document becomes an e-invoice and a line has to be built for the regulator.

Reference: Doc Item Maintenance — E-Invoice tab

Step 2 — Learn what a blank one becomes

After this step you will stop waiting for a rejection. When a finalised document is turned into the record that goes to the regulator, the routine that builds each line finishes by filling in whatever is empty. A blank classification becomes zero-two-two, Others. A blank unit becomes H87, piece. A missing unit price becomes zero, a missing tax amount becomes zero, and the tax type is worked out from that amount: not applicable when there is no tax, sales tax when there is. None of this is a warning. None of it appears on a screen. The line is complete, the document is accepted, and the only thing wrong with it is that it describes something you did not sell.

Reference: E-Invoice Submission Mechanics — The record that goes to LHDN is not your invoice

Step 3 — See why the check that would have caught it cannot

After this step you will understand a piece of machinery that misleads almost everybody. There is a mandatory-field check, and it does divert documents into a pool with a written reason. Among the reasons it can produce are three you would expect here, in these words: item classification is missing, item tax type code is missing, e-invoice unit is missing. Those three sentences exist in the product and cannot be printed. The reason is order. The defaults are applied inside the very routine that assembles the line, and the check reads the assembled line. By the time it looks, nothing is blank. Of the five things it tests per line, only a missing item name can still divert a document.

Reference: E-Invoice Submission Mechanics — The record that goes to LHDN is not your invoice

Step 4 — Weigh how much of the base this touches

After this step you will know this is normal rather than exotic. Across every tenant on the platform, roughly one active item in six has no classification at all — around a hundred and ninety thousand of them, spread across most tenants that hold items, against nine hundred and fifty thousand that do carry one. That second number matters: this is not a measurement error, because the same query finds plenty of items properly classified. The effect is visible in what was actually sent. Nearly three million submitted e-invoice lines, in over fifty tenants, went out classified Others, and nearly six million went out in pieces. Not rejected. Sent, accepted and filed.

Reference: Doc Item Maintenance — What breaks elsewhere when an item is wrong

Step 5 — Recognise the pre-fill for what it is

After this step you will stop trusting a filled-in field. There is a second way an item ends up classified Others without anybody choosing it. Open the E-Invoice tab on an item whose classification is empty and the tab fills in zero-two-two for you, and treats that as a change you made. It is a kindness for a phone case and a falsehood for a flagship handset. It also means you cannot audit this by looking for blanks: an item that shows Others may be an item somebody classified as Others, or an item that was never classified and had a tab opened on it once.

Reference: Doc Item Maintenance — E-Invoice tab

Step 6 — Decide what this costs you, and act on it

After this step you will know why this is worth a morning. A tax document is a statement your company made. An accepted e-invoice saying that twenty-two thousand ringgit of laptops were Others, sold in pieces, is a statement you did not intend to make and did not know you had made. Nothing in the platform will ever raise it, because from the platform’s point of view everything worked. So the work is preventive, not reactive: classify the items that carry your volume, starting with the categories that account for most of your revenue, and check what was actually submitted rather than waiting for a pool to fill. The next lesson shows which of the three fields a late fix still reaches.

Reference: Doc Item Maintenance — What it will not do

How the steps fit together

    flowchart TD
  s1["Step 1 — Put the three fields in their place"]
  s2["Step 2 — Learn what a blank one becomes"]
  s3["Step 3 — See why the check that would have caught it cannot"]
  s4["Step 4 — Weigh how much of the base this touches"]
  s5["Step 5 — Recognise the pre-fill for what it is"]
  s6["Step 6 — Decide what this costs you, and act on it"]
  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: Which of the three a late fix still reaches · Back to the series · Play this as a presentation