MyInvois TIN and BRN Validation: What Landed on 1 August 2026, and What Lands Next
TIN and Business Registration Number validation went live in MyInvois on 1 August 2026. If your buyer master data in Malaysia still carries a supplier's old-format registration number, or a BRN that was never updated with HASiL, the validation call for that buyer does not return a clean result.
The fix is data housekeeping, not software. You can do most of it this week with a spreadsheet and MyTax.
Two more MyInvois changes are already dated. Enhanced field validation reaches the production environment on 15 August 2026, and new limits on amount fields take effect on 23 October 2026. This covers what the LHDN source documents actually say about each one, and two widely repeated claims about 1 August that they do not support.
Sorting out compliance deadlines and wondering what else your contracts oblige you to carry?
Most of our enquiries start with a requirement someone else set. If a client contract, landlord or tender is asking your business for cover, we can tell you in one conversation what it means. See SME business insurance.
Key Facts: MyInvois TIN and BRN Validation
What happened on 1 August 2026? HASiL introduced TIN and BRN validation, implemented on the Validate Taxpayer's TIN API. That endpoint is the check an ERP or middleware system calls to confirm a buyer's identity before an invoice is issued.
Who needs to act on it? Any Malaysian business already issuing e-Invoices, plus the software houses and middleware vendors that run MyInvois integrations for them. The work sits in buyer and supplier master data, not in code.
What decides whether a buyer record passes? Whether the TIN and the identity number you hold for that buyer match what HASiL holds. The MyInvois SDK advises taxpayers to obtain updated BRN information from buyers and to remind buyers to update their latest BRN information with HASiL.
What is coming next? Enhanced field validation moves to the production environment on 15 August 2026. Separately, amount fields get a maximum length of 26 digits from 23 October 2026.
Is e-Invoicing required in Malaysia? Yes, by statute, above a turnover threshold. Taxpayers with annual turnover or revenue below RM1,000,000 are exempted from issuing e-Invoices under the LHDN e-Invoice Guideline (Version 4.7), 7 July 2026, and may participate voluntarily. Our e-invoicing compliance guide for Malaysian SMEs covers the wider obligation.
Last verified: 13 August 2026. Checked against the MyInvois SDK 1.0 release notes including the entries dated 12 June, 3 July and 6 August 2026, the e-Invoice Guideline (Version 4.7) and e-Invoice Specific Guideline (Version 4.8) both issued 7 July 2026, and the LHDN e-Invoice General FAQs updated 5 May 2026.
What LHDN actually said about 1 August 2026
The source is a single release note in the MyInvois SDK 1.0 documentation, dated 12 June 2026. It reads:
"To enhance data accuracy and quality, HASiL will introduce Taxpayer Identification Number (TIN) and Business Registration Number (BRN) validation starting 1 August 2026."
Source: MyInvois SDK 1.0 release notes, HASiL, 12 June 2026. The same note says the validation "will be implemented for the Validate Taxpayer's TIN API" and asks taxpayers to obtain updated and accurate BRN information from buyers. No later release note defers or changes it.
That endpoint already documents what a failed lookup looks like. The Validate Taxpayer's TIN API specification returns a 404 when the "TIN and ID combination cannot be found or are considered invalid", and accepts NRIC, passport, BRN or army number as the identity type.
Two claims are circulating that the release note does not make. The table below sets the source text against them, because the gap is where the bad advice is coming from.
| Circulating claim | What the HASiL source says |
|---|---|
| "LHDN will validate TIN and BRN as a matched pair" | The note announces TIN and BRN validation on one API. It does not describe pair-matching logic. |
| "A legacy-format BRN returns a 404 and blocks e-Invoice submission" | The 404 is the documented response of the Validate Taxpayer's TIN API to an invalid TIN and ID combination. The note says nothing about document submission being blocked. |
Treat the distinction as practical, not pedantic. A failure at the validation call is caught by your integration before an invoice is raised, which is a support ticket. A failure at submission is a rejected document with a tax consequence attached, which is a different problem, and nobody should be told it is happening until HASiL says so.
Three MyInvois dates, and they are not the same change
The 1 August change is regularly merged with two separate items in the same SDK release notes. They have different scopes, different dates and different owners inside your business.
| Date | Change | What it touches |
|---|---|---|
| 1 August 2026 | TIN and BRN validation introduced. Announced 12 June 2026 | The Validate Taxpayer's TIN API. Your buyer and supplier master data. |
| 15 August 2026 | Enhanced field validation deployed to production. Date set 3 July 2026 | Document field formats: dates, character limits for bank accounts, invoice codes, authorisation numbers, incoterms, billing frequency, units of measurement, business descriptions, payment terms and prepayment references. |
| 23 October 2026 | Amount field length limit. Announced 6 August 2026 | All amount fields get a maximum length of 26 digits. The same note sets a 12-character limit where the ID type is PASSPORT. |
If your vendor has told you "everything changed on 1 August", ask which of the three they mean. The 15 August item is a document schema matter that lands on whoever builds your submission payload, and it is the more likely source of rejected documents in the second half of August. The October item is a field length change that most businesses will never notice, because very few invoices carry a 26-digit amount, but an integrator should still read it.
How to check a registration number
The number HASiL expects is the one currently registered against that taxpayer, and for most Malaysian companies that is the 12-digit format SSM introduced on 11 October 2019. A company incorporated before that date has both: the old number and a new 12-digit equivalent, shown together during the transition, as set out in the SSM announcement on the new registration number format.
Emerge Insurtech (Malaysia) Sdn. Bhd. is a plain example: 202101001225 in the current format, 1401523D in the old one. Both identify the same company, and only one of them is the number a modern system should be storing.
The sequence below is ordered by how much of your data it fixes per hour spent.
| Step | Action | Who does it |
|---|---|---|
| 1 | Confirm your own TIN and registration number as HASiL holds them, through your MyTax profile. | Finance or the person who files |
| 2 | Export every buyer record that carries a registration number. Sort by format and isolate anything that is not 12 digits. | Whoever administers the accounting system |
| 3 | Ask those buyers for their current number, and ask them to confirm HASiL has it. The SDK note puts this obligation on you, not on them. | Account or relationship owner |
| 4 | Run the corrected records through the Validate Taxpayer's TIN API in your integration and log every non-200 response. | Your ERP vendor or integrator |
| 5 | Cache the validated results. The API documentation warns that excessive calls can trigger throttling. | Your ERP vendor or integrator |
Building MyInvois integrations for other companies?
Then the penalty exposure below is a professional liability question, and it belongs in your contract before it belongs in a policy. We work with Malaysian technology and professional services firms on exactly this. Start with professional indemnity insurance or tell us what the contract says.
Where your business sits in the e-Invoice timeline
Half the confusion about August comes from businesses that are not certain they are in scope at all. The table below is the timeline as published in the LHDN e-Invoice Guideline (Version 4.7), 7 July 2026.
| Annual turnover | Mandatory from | Position now |
|---|---|---|
| More than RM100 million | 1 August 2024 | In force |
| RM25 million to RM100 million | 1 January 2025 | In force |
| RM5 million to RM25 million | 1 July 2025 | In force |
| Up to RM5 million | 1 January 2026 | In force, interim relaxation to 31 December 2027 |
| Below RM1,000,000 | Not applicable | Exempted from issuing e-Invoices, voluntary participation allowed |
Two details in Version 4.7 get missed. Businesses that commenced operations between 2023 and 2025 with turnover of RM1,000,000 or more come into scope from 1 July 2026, which is a separate cohort from the turnover bands above. And the phase once pencilled in for the RM500,000 to RM1,000,000 band does not appear in the current timeline at all: the RM1,000,000 exemption replaced it.
On the relaxation, the LHDN e-Invoice General FAQs, updated 5 May 2026, put the interim relaxation window for the up-to-RM5-million band at "Until 31 December 2027", covering both the 1 January 2026 and 1 July 2026 cohorts. Vendor pages still showing that window closing in 2026 are working from an older document. The mechanics of the relaxation itself sit in Section 16 of the e-Invoice Specific Guideline (Version 4.8), issued 7 July 2026.
One caution on the exemption. The threshold has moved more than once since December 2025, so read "below RM1,000,000 is exempt" as the position under Version 4.7 and not as a permanent settlement. Anyone building a three-year plan on it should check the guideline version each year. The same habit applies to the other compliance deadline most Malaysian SMEs are tracking this year, which our PDPA compliance checklist sets out.
If you build MyInvois integrations for other people
No Malaysian rule requires a business to carry insurance because of e-invoicing, and anyone telling you otherwise is selling something. The exposure here is one step across, and it is contractual.
The statutory penalty falls on the taxpayer. Section 120(1)(d), Income Tax Act 1967, RM200 to RM20,000 per instance, applies per non-compliant instance rather than per year, which is what makes it uncomfortable for a business issuing volume.
Now put that next to a services agreement. A Malaysian software house, ERP reseller or middleware vendor contracts to build and maintain a client's MyInvois integration. If that integration fails and the client incurs penalties, the client's first move is the indemnity clause in your contract, not the tax code.
That is a professional liability question rather than a cyber one, and the answer usually lives in the agreement you already signed. Read the limitation of liability, the indemnity, and whether either carves out statutory fines and penalties. Do that before you look at cover, because the contract determines what cover would even need to respond to. If you want the background first, we have written it up for IT consultants and software companies and for SaaS startups.
FAQ
What changed in MyInvois on 1 August 2026?
HASiL introduced Taxpayer Identification Number and Business Registration Number validation, implemented on the Validate Taxpayer's TIN API. This was announced in the MyInvois SDK 1.0 release notes on 12 June 2026, and no later release note defers or changes it. The release note asks taxpayers to obtain updated BRN information from buyers and to remind buyers to update their latest BRN details with HASiL.
Will a wrong BRN block my e-Invoice from being submitted?
The HASiL release note does not say that. It states that the validation is implemented for the Validate Taxpayer's TIN API, which is the pre-issuance check, and the published specification for that API returns a 404 when a TIN and ID combination cannot be found or is considered invalid. Anyone claiming submission itself is blocked is going beyond the source document.
Is my company exempt from e-Invoicing in Malaysia?
Taxpayers with annual turnover or revenue below RM1,000,000 are exempted from issuing e-Invoices under the LHDN e-Invoice Guideline (Version 4.7), 7 July 2026, and may take part voluntarily. Above that, the turnover bands in the guideline apply. The threshold has changed more than once since December 2025, so check the current guideline version rather than a summary.
What is the difference between the 1 August and 15 August 2026 changes?
1 August 2026 is TIN and BRN validation on the Validate Taxpayer's TIN API, which is a master data issue. 15 August 2026 is the production deployment of enhanced field validation covering date formats, character limits for bank accounts and standardised codes, which is a document schema issue. Both appear in the MyInvois SDK 1.0 release notes and they affect different parts of an integration.
What is changing in MyInvois on 23 October 2026?
A release note dated 6 August 2026 sets a maximum length of 26 digits for all amount fields, taking effect in the production environment on 23 October 2026. The same note specifies a 12-character limit where the identity type is PASSPORT. This is a field length change for whoever builds your submission payload, and most businesses will never hit either limit.
When does the penalty-free period for smaller businesses end?
The LHDN e-Invoice General FAQs updated 5 May 2026 put the interim relaxation for the up-to-RM5-million band at "Until 31 December 2027", covering both the 1 January 2026 and 1 July 2026 implementation cohorts. Section 16 of the e-Invoice Specific Guideline (Version 4.8), issued 7 July 2026, sets out the treatment during that period. Pages showing this window ending in 2026 are out of date.
What penalty applies for non-compliance with e-Invoicing?
Section 120(1)(d), Income Tax Act 1967, RM200 to RM20,000 per instance. It is assessed per non-compliant instance, which is the detail that matters for a business issuing high invoice volumes. The penalty falls on the taxpayer, not on a software vendor, although a services contract can shift the cost commercially.
Does e-invoicing create an insurance requirement in Malaysia?
No. No Malaysian statute or LHDN guideline requires a business to carry insurance because it issues e-Invoices. Where a real exposure exists it is contractual: a vendor that agrees to build or maintain someone else's MyInvois integration may have accepted liability for that client's losses under the services agreement.
Contingent Conclusion
The 1 August change was small, and the reporting around it was not. Read the release note, fix the buyer records that are wrong, and ignore the two claims the source does not support. Then put 15 August and 23 October in the calendar, because those are the ones still ahead of you.
The part worth a second look is contractual. If your business has signed an agreement to build or run someone else's compliance systems, you have taken on a portion of their regulatory risk, and that transfer happened when the contract was signed rather than when something failed.
Contingent helps Malaysian businesses get the cover their contracts and landlords require. Whether you're comparing options or checking whether your existing policy actually does what the contract asks, we can help. See SME business insurance to start.
Get a quote · or WhatsApp us directly
Published by Contingent, the commercial insurance brand of Emerge Insurtech (Malaysia) Sdn. Bhd.
Disclaimer: This article provides general guidance based on publicly available regulatory information as of 13 August 2026. Regulations may be amended. Always verify current requirements with the relevant authority or qualified professionals before making compliance decisions.
