What goes on the e-invoice record, and where each field comes from

“The repair line charges service tax and the cable line says 2.5 metres. Why does LHDN’s copy say Sales Tax and 2?” Because LHDN never receives your document as you keyed it. BigLedger builds a separate e-invoice record from it (Submission mechanics), and while it builds and sends that record it works several fields out again by its own rules and fills some blanks without a message. The item and the customer hold what you chose; the record holds what is sent, except the quantity, whose fraction is dropped only as the document leaves. This page is for whoever sets up the master data, and whoever is asked why LHDN’s copy differs from the invoice.

One invoice, four quiet changes. GadgetSphere sells two packs of three USB-C cables, 2.5 metres of network cable and a repair service on one invoice. LHDN is told 6 cables, in the item’s base unit; 2 metres, because a fraction is dropped as it is sent; the repair, a line that charges service tax, as Sales Tax unless its item or the line says 02; and, for any line with no classification code on the line or its item, 022 Others. Each rule is below, with what to check.

Which of your records the buyer’s details come from, and which of its addresses, is a job of its own: Validation: Which Record Is Sent.

Countries, states and postcodes — where the country on the e-invoice comes from

The Country and State drop-downs on a customer, supplier or company address come from one list that BigLedger maintains, the same for everyone. You pick from it; you cannot add a country, rename one or change a country’s states from any screen in your tenant — that is a request to BigLedger. City and postcode are typed, not picked. (A separate city-and-postcode list exists, but it serves the online store’s shipping-address form and the membership and seller search filters, not your customer, supplier or company records.)

The country code LHDN receives does not come from that list. A customer or supplier address keeps the country’s name (the company record keeps the three-letter code, so your own side is exact). When the e-invoice record is built, BigLedger converts what the address holds into LHDN’s three-letter code with its own built-in table, in this order: a three-letter code if that is what the field holds, an exact country name, a short list of common alternatives (UK, US, South Korea, Viet Nam), then a partial name match. The result — the three-letter code and the state code worked out from it — is written onto the e-invoice record, so that record is where you check it.

A country it cannot recognise is sent as Malaysia, and nothing tells you. Singapura, SG and U.S.A. are all read as Malaysia, and so are the few names in the list spelt with an accented letter (Réunion, Curaçao). A partial match can also pick the wrong country: the list’s Democratic Republic of the Congo resolves to the Republic of the Congo. Once an address is treated as Malaysian, its state is matched against Malaysia’s states — so the tell is a state-code problem on a party who is not in Malaysia at all. Look at the country on the e-invoice record first.

Two more things change quietly on the way. The postcode is cut to five characters, so a Singapore supplier’s six-digit postcode reaches LHDN as its first five digits. Accented letters are dropped from every address line — é disappears rather than becoming e. If GadgetSphere Distribution raises self-billed e-invoices for its Singapore and Hong Kong distributors, pick those suppliers’ countries from the drop-down rather than importing typed text, and open the first submitted record for each of them to confirm the country reads SGP or HKG.

Which tax type each line reports

LHDN wants a tax type on every line, from its own list of six: 01 Sales Tax, 02 Service Tax, 03 Tourism Tax, 04 High-Value Goods Tax, 05 Sales Tax on Low Value Goods and 06 Not Applicable. BigLedger ships exactly those six, and no screen adds to the list or edits it.

You choose a tax type in several places: on an item’s E-Invoice tab, as a category default in Doc Item Maintenance, when you correct a line in the batch pool, and in an item import. The document line has its own E-Invoice Tax Type Code picker, offering the same six and pre-filled from the item.

Then the line’s tax amount has the last word. When the finalised document becomes an e-invoice record, each line is settled like this:

The line has…	LHDN is told
no tax, or a tax amount of zero	06 Not Applicable — whatever type was chosen
tax, and no type or 06	01 Sales Tax
tax, and any other type	the type chosen

Two consequences are worth planning for. A line that charges service tax is reported as Sales Tax unless its item (or the line) says 02 — so GadgetSphere’s installation and repair items, which carry service tax, need 02 set on them. And an item set to 02 that is sold on an untaxed line goes as 06: that is the rule working, not a fault to chase.

An exemption is not a tax type in this list. LHDN’s exemption category is sent only when the line carries Tax Exemption Details and a Tax Exemption Amount — BigLedger then adds a second tax breakdown for the exemption beside the line’s own tax type, which is settled by the table above as usual. To check what went, read the tax type on the e-invoice record’s lines, not on the item: the item holds what you chose, and the record holds what was sent.

Which unit each line reports

LHDN wants a unit-of-measure code on every line, from its own list of about two thousand — H87 piece, XUN unit, SET set, KGM kilogram, MTR metre. Four things decide what it receives, and only the first is on a screen you would normally look at.

The item’s E-Invoice tab sets the code. When you add an item to a sales invoice, the line’s E-Invoice UOM is copied from the E-Invoice tab of the item in Doc Item Maintenance. The codes you pick there, and on each Multi UOM row, come from a copy of LHDN’s list built into the screen.

Selling in a bigger unit does not change it. GadgetSphere sells USB-C cables singly and in packs of three. Put two packs on an invoice and the line’s selling unit becomes Pack, but its E-Invoice UOM stays the item’s own code. The line has its own E-Invoice UOM picker, which offers the item’s code and each Multi UOM row’s code — and choosing the pack’s code there is the one way to get this wrong.

The quantity LHDN receives is always in the item’s base unit. Those two packs go as 6, whatever unit the line was sold in, and the unit price goes per cable to match. So the item’s base-unit code is the one that makes the line true: 6 pieces is right, 6 packs is what LHDN is told if somebody picks the pack’s code on the line. Leave the line on the item’s own code.

The quantity is sent as a whole number, and any fraction is dropped. A reel of network cable sold as 2.5 metres goes to LHDN as 2; half a metre goes as 0. The line’s amounts are sent exactly, so LHDN holds a line whose quantity times unit price does not make its total. Nothing warns you, and the e-invoice record in BigLedger still shows 2.5 — the cut happens as the document is sent. If you sell anything by weight or length, open one validated e-invoice in LHDN’s MyInvois portal and compare its quantity with your invoice before you rely on it.

A blank code is filled in for you. A line with no E-Invoice UOM is sent as H87 piece, without a message, before any check looks for it. A consolidated e-invoice sets its own units: one line per source document goes as H87 piece, one line per branch range as XUN unit.

BigLedger keeps a second copy of LHDN’s list, and only an import reads it. That copy is empty until BigLedger fills it from LHDN’s published list — there is no screen for it. Its one job is to check the e-invoice UOM column of an item import, and a code it cannot find is dropped without a message: the item is saved with no e-invoice unit, and so goes to LHDN as H87 piece. Before an item import that carries e-invoice units, ask BigLedger to load the list into your tenant, or set the units on screen after the import and check a few items.

The classification code, and what a blank becomes

LHDN wants a classification code on every line. The code on the line wins, then the item’s at the moment the e-invoice is built; with neither, the line goes to LHDN as 022 Others, and a line with no e-invoice unit as H87 piece. A consolidated e-invoice always says 004. So a wrong or missing code is found by an auditor, not by BigLedger: spot-check a submitted e-invoice’s lines once after setup.

The record says what you meant — a five-minute check

Run it once after setup, and again after any item import:

Country. Open the first submitted record for each foreign customer or supplier and confirm the country reads its own code (SGP, HKG), not Malaysia.
Tax type. For a taxed line of a service item, read the tax type on the submitted record’s line, not on the item: it should say 02.
Quantity. If you sell by weight or length, open one validated e-invoice in LHDN’s MyInvois portal and compare its quantity with your invoice.
Classification. On one submitted record, look for lines at 022 Others that should carry a real code.