What goes on an e-invoice, and who fills in each part — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for the person who has to make sure the data is right before anything is sent, and who has never seen the inside of an e-invoice. In about ten minutes you will know what the revenue board asks to be on the document, which parts BigLedger fills in from records you already keep, and which one part is genuinely yours to get right.

Step 1 — Put the field count in its place

After this step you will stop worrying about a number. The general guideline lists fifty-five data fields for an e-invoice, and twenty of them are marked optional — e-mail addresses for both parties, billing frequency and period, quantity, unit of measure, discounts, fees, rounding and the whole payment block. That leaves thirty-five that are required. The count is the least useful thing about the list, because you will never fill fifty-five boxes yourself. What matters is that the fields arrive in five blocks from five different places in your business, and each block fails in its own way. Learn the blocks and you can predict which one broke from the error message alone.

Reference: What Malaysia Requires: E-Invoicing Explained — What goes on an e-invoice

Step 2 — Fix your own company block once, properly

After this step you will understand why this block is worth an afternoon. Your side of the document carries your company’s name, tax number, registration or identity number, industry classification code, a description of your business activity, an address and a contact number. Every one of those comes from your company record, so it is typed once and then reused on every document you will ever send. That cuts both ways. Get it right and you never think about it again. Get one character wrong and every sales invoice in the company fails at once, with an error that points at the document rather than the company. Contact numbers are the quiet one: they must be between eight and twenty characters, so a field padded with the letters N slash A fails.

Reference: E-Invoice Validation Rules & Troubleshooting — Mandatory fields

Step 3 — Treat the buyer block as the real work

After this step you will know where your rejections will come from. The other side of the document needs the buyer’s name, tax number, identity type and value, address and contact number — and this is the block that produces most rejections, because it is the only one that depends on a person outside your business telling you something. On a walk-in counter sale you usually have none of it, which is exactly why consolidation exists. On a corporate sale you have to ask, and the cheapest moment to ask is at the counter. Addresses have their own floor: line one, city and state on both sides. Anything longer than the limit is quietly shortened rather than refused, so the failure you get is never about length.

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

Step 4 — Know what happens to the lines you did not fill

After this step you will know how much of a line BigLedger invents for you. Each line needs a classification code from the revenue board’s list of about forty-five, an item name, a unit price, a tax type and a tax amount. Only the item name has to be there. The others are filled before anything checks: a blank classification becomes the code for Others, a missing price or tax amount becomes zero, and the tax type is worked out from the tax amount rather than read from the item. That is generous and it is also a trap, because a line that is wrong in a defaulted field passes validation and lands in your accounts. One code to memorise: double-zero-four is reserved for consolidated e-invoices, and using it on an individual one makes the document invalid however perfect the rest of it is.

Reference: E-Invoice Validation Rules & Troubleshooting — Mandatory fields

Step 5 — Understand why an incomplete document is parked, not refused

After this step you will stop expecting an error at the till. When you finalise a sales document, nothing is sent immediately. A background check runs over the mandatory fields, and if something required is missing the document goes into a pool with the missing fields written on the row, rather than being sent and rejected. Nobody at the counter is stopped and no message appears. Read that as a deliberate choice: refusing a paying customer because their address has no state would be worse, and the correction is better done by someone with the time to do it well. The cost is that the pool is invisible unless a person opens it, which is why a month-end routine exists at all.

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

Step 6 — Find out which record the details actually came from

After this step you will stop correcting the wrong screen. The buyer’s details can live in two places: on the customer record, and in an e-invoice block typed directly onto the sales document. The document wins. If someone typed buyer details onto the document, those are what is sent, exactly as typed, and the customer record is never read. Only when both blocks on the document are empty does BigLedger go to the linked customer record, and it reads it fresh at the moment of submission. So the first question after any identity rejection is not what is wrong with the customer, it is which of the two the document used — because correcting the customer record changes nothing at all when the document carried its own block.

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

How the steps fit together

    flowchart TD
  s1["Step 1 — Put the field count in its place"]
  s2["Step 2 — Fix your own company block once, properly"]
  s3["Step 3 — Treat the buyer block as the real work"]
  s4["Step 4 — Know what happens to the lines you did not fill"]
  s5["Step 5 — Understand why an incomplete document is parked, not refused"]
  s6["Step 6 — Find out which record the details actually came from"]
  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: The customer who does not want an e-invoice, and the sale that may not be consolidated · Back to the series · Play this as a presentation