Malaysia E-Invoice readiness is often treated as an API project. In practice, integration only works when the finance data underneath it is clean enough to trust. If names, registration numbers, TIN, item classification, tax rules, and approval ownership are inconsistent, the ERP will send problems faster than people can fix them.

The LHDN phased mandate has shifted master data from a back-office concern to a board-level compliance exposure. Every rejected MyInvois submission is visible to the tax authority, traceable to a specific document, and counted against your filing record. Most of those rejections do not come from the integration layer at all. They come from sales, finance, and procurement maintaining three slightly different versions of the same customer, supplier, or item record, and discovering the drift only when LHDN sends the validation error back.

Use this checklist before integration starts.
  • Confirm who owns customer, supplier, item, and tax master data.
  • Define which fields are mandatory before invoice creation.
  • Validate changes with approval, not informal spreadsheet updates.
  • Prepare exception handling for rejected or incomplete records.

Customer Master Data

Customer records drive invoice identity. Each customer should have a clear registered name, business registration number, TIN, address, contact information, SST or tax status where applicable, and default payment or billing terms. The customer record is what LHDN sees first; if the name does not match SSM and the TIN does not validate, the submission stops there.

Mandatory fields before activation

  • Registered legal name exactly as filed with SSM or the relevant authority.
  • Business Registration Number (new and old format where transition still applies).
  • TIN issued by LHDN, validated against the MyInvois directory before first use.
  • SST registration number and status flag, where the customer is SST-registered.
  • Registered address, billing address, and shipping address, separated cleanly.
  • Authorised billing contact name, email, and phone for E-Invoice delivery.
  • Default currency, payment terms, and credit limit aligned to the signed agreement.

Control questions

  • Who can create or edit customer records?
  • What documents must be attached before a customer is considered active?
  • Which fields are locked after the first validated invoice?
  • How are branch addresses and billing addresses handled?

Common failure modes

  • Sales creates a duplicate customer to push an urgent quote, splitting the AR ledger.
  • TIN is captured as free text and never validated, surfacing only on rejection.
  • Branch entities are merged under one parent record, breaking consolidation reports.

Supplier Master Data

Supplier data matters for self-billed invoices, claims, purchasing, and audit. Treat supplier records with the same discipline as customer records. A supplier record should not be created casually just to clear one transaction, because self-billed scenarios require the same TIN, SST, and identity completeness on the supplier side that LHDN expects on the buyer side.

Mandatory fields before activation

  • Supplier category, with a clear distinction between corporate, individual, foreign, and government entities.
  • Registered name, Business Registration Number, and TIN validated against MyInvois.
  • SST registration number where applicable, and a flag for self-billed eligibility.
  • Bank account details with named beneficiary matching the registered entity.
  • Supporting documents: SSM extract, SST certificate, bank confirmation, signed vendor form.
Recommended ERP control

Require supplier category, registration number, tax details, bank details, supporting document, and maker-checker approval before the supplier can be used in finance documents.

TIN validation flow

On supplier or customer creation, the ERP should call the MyInvois TIN lookup before the record can be saved as Active. Failed validations route to a pending queue owned by finance, not to a silent override by the requester.

Item and Service Classification

Many finance teams underestimate product and service master data. E-Invoice requires invoice lines to be meaningful, not just free text. Item descriptions, service categories, units, tax handling, and classification logic should be reviewed before rollout. MyInvois expects a valid LHDN classification code on every line, and that mapping must live in the item master, not in the head of one accountant.

Mandatory fields per item

  • Item or service code, with a controlled naming convention and no free-text duplicates.
  • LHDN classification code mapped at the item level, reviewed by finance.
  • Unit of measure aligned to the MyInvois accepted list.
  • Default tax treatment: SST taxable, exempt, zero-rated, or out of scope.
  • Revenue or cost account mapping so the GL impact is deterministic.

Validation rules

  • Standardize recurring service descriptions.
  • Separate taxable, exempt, and special handling items.
  • Map project claims, deposits, retention, reimbursements, and service charges clearly.
  • Prevent users from bypassing controlled item lists with unreviewed manual descriptions.

Tax, Approval, and Exception Ownership

Good master data still needs ownership. Someone must decide what happens when a customer has no TIN, when a supplier record is incomplete, when a classification is uncertain, or when a submitted document is rejected. Without named owners and a defined SLA, every rejection becomes an email chain instead of a controlled correction.

Minimum workflow ownership

  • Finance owns invoice readiness and submission status.
  • Sales or operations owns customer source information.
  • Procurement owns supplier onboarding documents.
  • Management approves exceptional changes that affect tax or payment risk.
Customer record locking after first invoice

Once a customer has a validated MyInvois submission, the ERP should lock identity fields (legal name, BRN, TIN, SST status). Further changes require a controlled change request with finance approval, so historic invoices remain reconcilable.

Rejection-handling workflow

Every LHDN rejection should auto-create a task assigned to the named owner of the failing data domain, with a 48-hour SLA, root cause logged, and a re-submission audit trail attached to the original document.

Before You Connect to MyInvois

Run sample documents through the workflow before connecting live integration. The goal is not only to submit successfully, but to prove the team knows what to do when a submission fails, who is paged, and how the corrected document gets back out the door within the LHDN 72-hour validation window.

Pre go-live test cases

  • Standard tax invoice to an SST-registered corporate customer.
  • Tax invoice to an individual buyer without a TIN, using the consolidated route.
  • Credit note against a previously validated invoice, with reference linkage intact.
  • Project progress claim with retention and deposit lines mapped correctly.
  • Self-billed invoice to a foreign or non-registered supplier.
  • Cancellation within the 72-hour window and a correction after the window closes.
  • Deliberate rejection scenario: invalid TIN, missing classification, wrong tax code.
  • Bulk submission day-end run, with reconciliation back to the GL.
A clean MyInvois integration starts with clean ERP ownership. Master data is not admin work; it is the control layer that determines whether E-Invoice operations stay reliable. For the CFO, the question is simple: when LHDN sends back a rejection at month-end close, does your finance team already know who fixes it, in which system, and by when. If the answer is yes, you are ready to integrate. If not, fix the master data first.