August 1 LHDN API Update: Everything Businesses Need to Know

From 1 August 2026, HASiL’s MyInvois system will apply stricter checks to buyer information used in automated e-Invoicing. For business buyers, MyInvois will validate the buyer’s Tax Identification Number (TIN) together with its Business Registration Number (BRN). Both details must match the taxpayer record held by HASiL.

This matters for businesses using accounting software, ERP systems, POS platforms or custom e-Invoice integrations. An old or incorrect registration number could stop a buyer record from passing validation and delay invoice processing.

Here is what is changing and what businesses should clean up before the deadline.

What Is Changing on 1 August 2026?

MyInvois will check the buyer’s TIN and identification details as one matching set.

The Validate Taxpayer’s TIN API uses three main details:

• TIN
• Identification type
• Identification value

For an SSM-registered company, the identification type is normally BRN, while the identification value is the company registration number.

A successful match returns an HTTP 200 response. If the information cannot be matched, the API may return an HTTP 404 response.

HASiL has advised businesses to collect accurate registration numbers from buyers and ask them to update outdated details where necessary. 

Does Every Buyer Need a 12-Digit BRN?

SSM-registered companies, businesses and limited liability partnerships should generally use the newer 12-digit registration number.

SSM introduced the 12-digit registration format in October 2019. During the transition, both the new and old registration numbers were often displayed together.

For example: 201901000005 (1312525-A)

Government agencies, associations and professional bodies may use identification numbers issued by other authorities. Hence, your system should therefore apply the correct format based on the buyer’s entity type. 

What Does a 404 Error Mean?

A 404 from the Validate Taxpayer’s TIN API means the submitted TIN and identification details could not be matched.

It does not automatically mean that an e-Invoice has already been submitted and rejected.

The validation API may be used when:

• A new buyer account is created
• A customer updates its details
• An old buyer record is reviewed
• An invoice reaches a pre-submission check

The error should therefore be treated as a buyer data validation failure.

Response	What It Usually Means	What To Do
HTTP 200	Buyer details matched	Save the result and continue
HTTP 400	Request details may be incomplete or wrongly formatted	Check the API request
HTTP 404	TIN and identification details did not match	Review the buyer record
Authentication error	Token or access issue	Check the system connection

Passing this check only confirms that the buyer’s identification details match. The e-Invoice must still be submitted and pass MyInvois document checks. 

How Should You Clean Your Buyer Master Data For LHDN API?

The following is a recommended operational workflow rather than a prescribed HASiL procedure, it will save you A LOT of time.

Start with active corporate customers and work through the records that matter most to daily billing.

Step 1: Check Your Own Business Details

Before reviewing customers, confirm that your own business information is correct.

Check your:

• Registered business name
• TIN
• BRN
• Business address
• SSM registration details

If HASiL holds outdated information, use the relevant official update or customer support channel and provide the documents requested.

Updating the information inside your accounting software does not automatically update HASiL’s records.

Step 2: Export Your Active Buyer List

Create a list of business customers who have purchased from you recently.

The list should include:

• Registered business name
• TIN
• Identification type
• BRN
• Billing email
• Account owner
• Date last updated
• Validation status

Start with customers that generate the most invoices or revenue. These accounts are more likely to cause disruption if their details fail validation.

Step 3: Flag Suspicious Records

Look for buyer records with:

• Missing TINs or BRNs
• Old-format SSM numbers
• BRNs that are not 12 digits for SSM-registered buyers
• Duplicate customer accounts
• Different TINs linked to the same company name
• Personal identification numbers saved for a company
• Different information across your CRM and accounting system

A basic system check can find obvious formatting issues. It cannot confirm that a number belongs to the correct company.

Step 4: Ask Buyers To Confirm Their Details

Contact buyers whose records appear incomplete or outdated.

Ask them to confirm:

• Registered business name
• TIN
• Identification type
• Current 12-digit SSM registration number, where applicable
• Registered address
• e-Invoice contact person

Keep the request simple. Avoid collecting unnecessary company or personal documents.

Step 5: Validate the TIN and BRN Together

Do not only check whether the TIN exists.

The important test is whether the TIN matches the submitted identification type and registration number.

If validation fails, hold the buyer record for review rather than repeatedly submitting the same information.

Step 6: Save the Validation Result

Once a buyer passes validation, record the result in your system.

Useful fields include:

• Validation status
• Date validated
• TIN used
• Identification type
• Identification value
• Staff member or system responsible
• Date for the next review

This creates a clear record for finance teams and makes future troubleshooting easier.

Should You Validate Every Buyer Before Every Invoice?

No. HASiL recommends storing successful validation results instead of repeatedly calling the API for the same buyer.

Calling the validation API before every invoice could slow down your workflow and increase the risk of API throttling.

A buyer should usually be validated when:

• The customer account is created
• The buyer changes its TIN or BRN
• The legal business name changes
• A previous validation fails
• The record has not been reviewed for a long time

Your ERP or accounting system can store the successful validation status and recheck the buyer when important details change.

HASiL does not describe a reusable approval token. Businesses should store the validation result and the details that were checked. 

How Should Your System Handle Failed Validation?

A failed validation should create a clear task for staff instead of disappearing into an error log.

A workflow could:

1. Pause the affected invoice.
2. Show which buyer details failed.
3. Send the case to the finance or customer-data team.
4. Contact the buyer for corrected information.
5. Update and revalidate the record.
6. Continue the invoice after a successful match.

Your system should also separate buyer data errors from temporary service or login problems. Not every failed API request means the customer information is wrong.

What Happens After the August 1 Update?

Ten enhanced field-validation rules are scheduled to be enforced in the MyInvois production environment from 15 August 2026.

The affected fields are:

• Date fields, which must use a valid YYYY-MM-DD format
• Supplier’s bank-account number, limited to 150 characters
• e-Invoice Code/Number, limited to 50 characters
• Authorisation Number for Certified Exporter, limited to 300 characters
• Incoterms, limited to three characters
• Frequency of Billing, limited to 50 characters
• Unit of Measurement, which must use an accepted unit code
• Supplier’s Business Activity Description, limited to 300 characters
• Payment Terms, limited to 300 characters
• PrePayment Reference Number, limited to 150 characters

Businesses should therefore review both buyer records and invoice field formatting before August. 

Preparing for the August 1 LHDN API Update

The August 1 LHDN API update makes accurate buyer data a more important part of e-Invoice processing.

A valid TIN may still fail validation if it is paired with an old BRN, the wrong company or an incorrect identification type. Businesses should review active buyer accounts, collect updated details and store successful validation results before the stricter checks begin.

At Accounting.my, we help businesses prepare their systems for LHDN e-Invoicing, including API setup, data mapping, testing and tax-related configuration. 

We can also review your current workflow and help reduce the risk of validation errors disrupting invoice issuance.

Disclaimer: This article is for general information only and does not constitute tax, legal or system-integration advice. Requirements and API behaviour may change, so businesses should refer to the latest HASiL and MyInvois documentation.