E-Invoice Validation: Which Record and Which Address BigLedger Sends
Part 3 of LHDN rejected it — e-invoice validation rules and troubleshooting: before you correct a customer record, find out whether the e-invoice was built from it, which address went, and how a state became a code. It follows What LHDN checks, and it is also the page for naming another buyer, or another of the customer’s addresses, on one GadgetSphere sales invoice.
Correct a record before LHDN says Valid: Save and Resubmit stops working once LHDN says Valid, and from then on only a cancellation inside 72 hours or a credit note will do (Cancelling and Correcting a Validated E-Invoice).
- Which record does BigLedger actually send?
- Which address
- Another buyer, or another address, on one sales invoice
- Malaysian state codes
Which record does BigLedger actually send?
Before you go correcting a customer record, make sure it is the record the e-invoice was built from. There are two places the other party’s details can live — the customer or supplier record, and an e-invoice block typed directly onto the sales or purchase document — and the document wins.
| What is on the document | Whose details go on the e-invoice |
|---|---|
| E-invoice buyer details (on a sale) or supplier details (on a purchase) typed onto the document | Those, exactly as typed. The customer or supplier record is never read |
| That block empty, but the document’s general e-invoice counterparty block filled in | The general block on the document |
| Both blocks empty | The linked customer or supplier record, read fresh at submission time |
Whichever record is used, the other party’s name is cleaned before it goes: anything outside letters, digits, spaces and - / ( ) . , & ' is deleted, a full-width ＆ becomes &, and the result is cut at 300 characters. Your own company name is sent exactly as stored. LHDN treats a Valid e-invoice as final, so a name that went out with a character removed stays as sent — check names carrying unusual punctuation before the first submission. The apostrophe was itself stripped until July 2026, so an older Valid e-invoice for O’Brien Trading may carry OBrien Trading and is correct as far as LHDN is concerned.
Which address
If your customer has several addresses on file: BigLedger sends the first address flagged as the e-invoice address, looking in this order: shipping, then billing, then main. Flag exactly one and the guesswork disappears. If the buyer’s details were typed straight onto the sales document rather than pulled from the customer record, that typed address is used exactly as entered.
Another buyer, or another address, on one sales invoice
The buyer on an e-invoice does not have to be the customer you billed. An employee pays for a laptop his employer will claim; one company in your group buys on behalf of another; a corporate client of GadgetSphere Distribution has one account and one monthly statement, but each of its branches wants the e-invoice to carry the address of the branch that took the goods. The E-Invoice tab of a sales invoice has a button for this — and which button you get depends on one switch. You never see both.
| Button on the E-Invoice tab | What it fills | Good for |
|---|---|---|
| Select From Another Customer (the switch off, as delivered) | Copies another customer’s whole buyer identity onto this invoice: name, identity type and number, tax number, e-mail, phone, and that customer’s billing address flagged as the e-invoice address. It also sets the submission type to Individual. The account you billed, and its balance, stay as they were | A different legal buyer from the account you invoice |
| Select Einvoice Address (the switch on) | Lists this customer’s billing addresses and puts the one you click into the buyer address. Name, identity and tax number are left alone | One buyer, many sites — the branch that took the goods |
The switch is on the E-Invoice tab of the sales invoice applet’s Settings → Application Settings; on an English screen its label reads HIDE_SELECT_FROM_ANOTHER_CUSTOMER_BUTTON. Turning it on removes the one-click copy of another customer’s identity — the shortcut with the compliance risk — and the address picker that replaces it changes only where the same buyer is. It does not stop staff naming another buyer. With the switch on, the buyer name, identity type and number, tax number, SST number, e-mail and contact number are still ordinary inputs on the same tab, and typing into any of them writes the buyer block. Each of those fields has its own hide switch on the same settings tab (its label is the raw key too, such as HIDE_E_INVOICE_BUYER_NAME), and hiding a field is the only setting that takes it off the screen. None of these switches is a permission, so checking that each invoice names the right buyer stays with whoever reviews the e-invoices.
Before you rely on either button:
- Both go grey once the invoice is FINAL. The tab is not blocked and it is not a permission — the document is final. To change the buyer or the address after that, work on the e-invoice record in My E-Invoice Admin: edit the Account tab on the record (or its pool row) and use Save and Resubmit. That is refused once LHDN has validated the e-invoice; from then on it is a cancellation inside 72 hours or a credit note — Cancelling and correcting a validated e-invoice.
- The button you expect is missing? Check the switch before anything else. A business that hides Select From Another Customer gains the address picker and loses the one-click copy of another customer; the buyer fields themselves stay editable.
- The picker offers billing addresses only. A shipping address, however many you hold, is not in the list. Add the branch as a billing address on the customer record and it appears.
- A blank part of the picked address keeps what was there before. If the branch’s address has no second line, the second line already on the tab stays. Read the address back after you pick.
- The other customer needs an e-invoice billing address of its own. Select From Another Customer copies only the billing address flagged for e-invoices. If that customer has none, the address arrives empty, and with no address line 1, city or state the invoice waits in a pool instead of going to LHDN.
- A picked address travels only with a buyer block that is in use. Picking an address fills the address alone. The name and numbers you see on the tab are shown from the billed customer until you edit one of them, and until then the block holds no identity field, so the callout above applies the other way round: BigLedger sends the customer record and its flagged address instead of the one you picked. So after picking, change one buyer field and leave it — clear the e-mail, tab out, type it back, tab out — and the whole block, as shown, is saved onto the invoice. You will know it worked when the e-invoice record in My E-Invoice Admin shows the branch’s address.
Malaysian state codes
LHDN wants the state as a numeric code, not free text. BigLedger resolves what your staff typed automatically: first an exact match on the official state name, then a match after stripping punctuation, then a partial match in either direction (so “Kuala Lumpur” finds “Wilayah Persekutuan Kuala Lumpur”; text shorter than four letters is not looked for inside a longer name), and finally a list of common abbreviations.
| Code | State | Code | State |
|---|---|---|---|
| 01 | Johor | 09 | Perlis |
| 02 | Kedah | 10 | Selangor |
| 03 | Kelantan | 11 | Terengganu |
| 04 | Melaka | 12 | Sabah |
| 05 | Negeri Sembilan | 13 | Sarawak |
| 06 | Pahang | 14 | W.P. Kuala Lumpur |
| 07 | Pulau Pinang | 15 | W.P. Labuan |
| 08 | Perak | 16 | W.P. Putrajaya |
The abbreviations that resolve on their own, so you do not need to re-key them: KL, WP Kuala Lumpur, WPKL → 14 · Labuan, WP Labuan → 15 · Putrajaya, WP Putrajaya → 16 · Penang, Pinang, P. Pinang → 07 · NS, N9, N. Sembilan, Seremban → 05 · Malacca, Melacca → 04 · Trengganu, Terenganu → 11 · Johore → 01 · Selangor Darul Ehsan, Sel, S.Gor, Sgor → 10.
If none of those match, the state code goes out empty — except a state typed as NA, which is sent as typed rather than matched. The check that holds a document back for an incomplete address looks only at whether a state is typed, not whether it is recognised, so a misspelt state passes it and LHDN rejects the submission with the state-code error CV317. That — not the postcode — is the address error that actually fails a submission. The one case an empty state is accepted is the General Public party of a consolidated e-invoice — the buyer of a consolidated sale, or the supplier of a consolidated self-billed purchase — where BigLedger sends code 17 (not applicable); for everything else there is no fallback, and LHDN rejects 17 outright, for Malaysian and foreign addresses alike.
For foreign addresses the state passes through as text (or as the country code when the state is blank), and the country defaults to Malaysia if your address data does not say otherwise.
What success looks like for this part
The e-invoice record in My E-Invoice Admin shows the buyer you meant and the address you meant — the branch’s address, if you picked one — and, for a Malaysian address, its state is one of the codes in the table above rather than empty (a foreign address carries its state as text, and the General Public party of a consolidated e-invoice carries 17). When you are done, run the whole page’s success check.
Common mistakes in this part
Three of the easiest to miss are named beside the rules above: a half-filled buyer block that sends seven blank fields, a picked address that never travels because no buyer field was changed, and a misspelt state that passes BigLedger’s check and fails LHDN’s with CV317. The rest are in the table of common mistakes on the first page.
Next: Common errors and their fixes.