The address BigLedger actually sends

Play this lesson as slides — one slide per step, with the same narration. The full text of every step is on this page.

This lesson is for you if your customers’ identities are right and documents are still parking in pools. An incomplete address is another common cause, it fails quietly rather than loudly, and the field that trips people up is one nobody thinks of as difficult. About eleven minutes, after which you can look at a customer with four addresses on file and say which one the Inland Revenue Board — LHDN — is going to receive.

Step 1 — Know which address goes

After this step you will stop guessing which of a customer’s addresses is on their e-invoice. A GadgetSphere corporate customer can easily have four on file: a registered office, a billing address for their accounts department, and a shipping address for each of two sites. BigLedger does not choose by type. It sends the first address flagged as the e-invoice address, and it looks for that flag in a fixed order: shipping first, then billing, then main. So flag exactly one address, deliberately, and the guesswork disappears. The exception is the same one as always. If somebody typed an address straight onto the sales document, that typed address goes instead, exactly as entered.

Reference: E-Invoice Validation Rules & Troubleshooting — Which address

Step 2 — Know the three parts LHDN insists on

After this step you will know what makes an address complete rather than merely filled in. Three parts are mandatory on both sides of every e-invoice: address line one, a city, and a state. Line one may run to a hundred and fifty characters and the city to fifty, and anything longer is shortened silently rather than rejected, so length is not your problem. Lines two and three and the postcode are optional. What matters is the failure mode. If line one, the city or the state is missing, the document is not submitted at all. It is not rejected by the board; it parks in a pool, where nothing ages it and nothing tells you it is there.

Reference: E-Invoice Validation Rules & Troubleshooting — Addresses

Step 3 — Get the state to resolve without re-keying it

After this step you will stop rewriting state names that were already fine. The board wants the state as a numeric code, and BigLedger works it out from whatever your staff typed, in four passes: an exact match on the official name, then a match with punctuation stripped, then a partial match in either direction, so that Kuala Lumpur finds the full Wilayah Persekutuan form, and last a list of common abbreviations, which is why Penang and N9 resolve on their own. So most of the tidying people do to these fields was never needed. If nothing matches, the code is left empty and the document waits for you. There is no not-applicable fallback, and code seventeen is rejected outright.

Reference: E-Invoice Validation Rules & Troubleshooting — Malaysian state codes

Step 4 — Handle a customer outside Malaysia

After this step your Singapore and Hong Kong customers will not trip on a field designed for Malaysian states. For a foreign address the state is not resolved to a Malaysian code at all. It passes through as text, or as the country code when the state is blank, so a foreign address does not need a Malaysian state and must not be given one. What does need attention is the country itself. If your address data does not say otherwise, the country defaults to Malaysia, which is quietly wrong on a foreign customer and will look correct to anyone glancing at the record. Set the country explicitly on every address outside Malaysia.

Reference: E-Invoice Validation Rules & Troubleshooting — Malaysian state codes

Step 5 — Make the flag part of creating a customer

After this step the right address will be flagged without anyone remembering to do it. The Address tab holds as many addresses as you like, each with a type of main, billing or shipping, a receiver name, five lines, city, postcode, state, country and its own contacts. Two tenant settings control what is pre-selected on a new record: one for the default address and one for the default e-invoice address. Both are off out of the box, which means a customer created today has no e-invoice address flagged unless somebody flags it. Turn the e-invoice one on and the commonest quiet omission on a new customer stops happening.

Reference: Customer Maintenance — Applet settings

Step 6 — Check the address that is on every single e-invoice

After this step you will know where to look when everything is failing at once. Your own company’s address is the supplier address on every sales e-invoice GadgetSphere issues, from every branch, to every customer. So one bad field there is not one bad document; it is all of them. A state that will not resolve, a missing city, a contact number outside the eight-to-twenty range, and every submission for that company fails while no individual customer looks wrong at all. If the pattern you are seeing is everything rather than something, open the company record in the Organisation applet before you open a single customer.

Reference: Organization — Company E-Invoice tab

How the steps fit together

    flowchart TD
  s1["Step 1 — Know which address goes"]
  s2["Step 2 — Know the three parts LHDN insists on"]
  s3["Step 3 — Get the state to resolve without re-keying it"]
  s4["Step 4 — Handle a customer outside Malaysia"]
  s5["Step 5 — Make the flag part of creating a customer"]
  s6["Step 6 — Check the address that is on every single e-invoice"]
  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 lesson: Make a broken record impossible to save · Back to the course