Your e-Invoices May Have Started Failing on 15 August. Here Is What Changed, and What Lands on 23 October.

On 15 August 2026, HASiL switched on a set of field validation rules in the MyInvois Production environment. Submissions that do not meet them, in HASiL’s own words, “may fail to process.”

Those rules were not new. They had been running in the Sandbox environment since 15 December 2025, and their move to Production had been postponed indefinitely. A release note dated 3 July 2026 quietly lifted that postponement and set the date.

If your e-Invoice submissions have started behaving differently in the past few days, or your finance team has been chasing rejections nobody can explain, start here.

This piece covers three things: what went live on 15 August, what lands on 23 October, and the penalty-free disclosure programme HASiL has opened for businesses that find they have a problem.

First, this is no longer a large-company issue

It is worth restating who this applies to, because the mental model from 2024 has not caught up.

The e-Invoice Guideline, Version 4.7, issued under section 134A of the Income Tax Act 1967, sets out the mandatory implementation timeline:

The final band came in on 1 January 2026. Every turnover band is now live. A business turning over RM2 million is in exactly the same validation regime as one turning over RM200 million, and the rules below apply to it in exactly the same way.

What went live on 15 August 2026

Ten field validations moved into Production. Read this list against your own integration:

1. Date fields must use the format YYYY-MM-DD. Entries such as “N/A” are not permitted.
2. Supplier’s Bank Account number must not exceed 150 characters.
3. e-Invoice Code or Number must not exceed 50 characters.
4. Authorisation Number for Certified Exporter must not exceed 300 characters.
5. Incoterms must not exceed 3 characters.
6. Frequency of Billing must not exceed 50 characters.
7. Unit of Measurement must follow the published unit code list.
8. Supplier’s Business Activity Description must not exceed 300 characters.
9. Payment Terms must not exceed 300 characters.
10. PrePayment Reference Number must not exceed 150 characters.

The first of these is the one most likely to bite. Systems that write “N/A”, a blank placeholder, or a locally formatted date into a date field will now fail, and plenty of accounting systems do exactly that when a field is genuinely not applicable.

The character limits look generous until you find the one place your system concatenates a description or pushes a full payment-terms paragraph into a field designed for a short code.

What HASiL says happens. “Submissions that do not meet the validation criteria may fail to process.” That is the full stated consequence. The release states no penalty, no fine, and no offence attached to a failed submission.

Six more rules that carry no date

Under the same 3 July release note sits a second, separate block of field rules:

• State Code must follow the published list for Malaysia, and must not exceed 50 characters for non-Malaysia entries
• Shipping Postcode must not exceed 5 characters for Malaysia, 50 for non-Malaysia
• Country Code must follow the published list
• Payment Mode must follow the published list
• Tax Type Code must follow the published list
• Currency Code must follow the published list

Note the difference carefully. The 15 August date attaches to the ten rules above. This second block carries no stated deployment date at all. The release simply says to ensure systems comply.

The practical reading is to treat these as live and get them right, because there is no upside in being non-compliant with a published rule. But if you are building an internal compliance calendar, do not write 15 August against these six. That date is not in the source.

The one that is actually still ahead of you: 23 October 2026

This is the deadline worth putting in the calendar today, because it has not happened yet.

A release note dated 6 August 2026 introduces a maximum length of 26 digits for all monetary amount fields. HASiL is explicit that the SDK previously specified no limit for amount values, so this is a new constraint rather than a clarification of an old one.

Invoice-level fields affected: PrePayment Amount, Total Excluding Tax, Total Including Tax, Total Payable Amount, Total Net Amount, Total Discount Value, Total Fee or Charge Amount, Total Tax Amount, Rounding Amount, Total Taxable Amount Per Tax Type, Total Tax Amount Per Tax Type, Amount Exempted from Tax, Invoice Additional Discount Amount, Invoice Additional Fee Amount, and Details of other charges.

Line-item-level fields affected: Unit Price, Tax Rate, Tax Amount, Amount Exempted from Tax, Subtotal, Total Excluding Tax, Discount Amount, and Fee or Charge Amount.

One oddity worth flagging to whoever maintains your integration: Tax Rate appears in a list the release itself describes as monetary amount fields. A tax rate is not a monetary amount. The release does not explain the inclusion, so treat the field as in scope and size it accordingly rather than assuming it was listed in error.

The same release also caps ID Type: PASSPORT at 12 characters.

What HASiL says happens. “Submissions that do not meet the validation criteria may be rejected.” Note the change in language from the August set, which said submissions “may fail to process.” The release states no penalty and no offence for either.

The date. “These changes will take effect in the Production environment on 23 October 2026.”

Twenty-six digits sounds impossible to breach until you consider two cases: a system that pads amounts, and a system that has been quietly writing full floating-point representations into amount fields. On the second point, a separate rule already in force since 30 April 2026 states that scientific notation is not supported in any amount field and that all amounts must be plain numbers with an optional decimal point. If your system has been getting away with either behaviour, 23 October is when it stops.

Also already in force: TIN and BRN validation since 1 August

A release note dated 12 June 2026 introduced Taxpayer Identification Number and Business Registration Number validation on the Validate Taxpayer’s TIN API, effective 1 August 2026.

The system change is small. The operational burden is not, and it does not fall on your IT team. HASiL’s stated advice is to obtain updated and accurate BRN information from buyers, and to remind buyers to update their own BRN records with HASiL so that what they give you matches what HASiL holds.

In practice that is a customer data exercise, owned by finance or sales, not a development task. If your buyer master data was assembled before this mattered, it is worth a pass now.

The disclosure programme: no penalty, and a capital allowance sweetener

On 7 July 2026, following an announcement by the Prime Minister and Finance Minister in the Dewan Rakyat the same day, HASiL introduced the e-Invoice Special Voluntary Disclosure Programme. Its Malay name is Program Khas Pengakuan Sukarela (PKPS) e-Invois, and you will see both used. The media release reference is HASiL/2026/07/07-36.

It runs until 31 December 2027. The release states no separate commencement date beyond its own date of 7 July 2026.

Who it is offered to. Three categories, quoted in substance from the release:

1. Taxpayers who implemented e-Invoice according to the prescribed timeline, but did not fully submit e-Invoices for certain transactions.
2. Taxpayers who submitted e-Invoices, but with errors or with information that does not comply with the prescribed specifications and conditions.
3. Taxpayers who did not submit e-Invoices at all for any period from their mandatory implementation date.

Category 2 is the one that connects directly to everything above. If the 15 August validations have been rejecting your submissions, or you discover a field problem when you check your amount fields ahead of 23 October, you are describing category 2.

The relief. HASiL states the programme lets taxpayers come forward voluntarily, update their information and correct their e-Invoice issuance without being subject to any penalty.

The part most coverage will miss. Separately from the disclosure relief, the release states that as encouragement to taxpayers who fully comply with e-Invoice implementation, the government has agreed to accelerate a tax incentive by allowing a full capital allowance claim within one year for expenditure on acquiring ICT equipment, and for the cost of developing or modifying computer software used for e-Invoice implementation.

Read that carefully, because the two things are not the same. The no-penalty relief is for those disclosing under the programme. The accelerated capital allowance is framed for taxpayers who fully comply, not specifically for programme participants. If you have spent money on systems or software to get e-Invoice working, that is worth raising with your tax agent.

How you disclose. Through submitting the e-Invoices themselves. HASiL has released two SDK document versions to support it, SVDP 1.2 without a digital signature and SVDP 1.3 with one, usable only during the programme’s effective period. Batch upload users need the updated template first. All existing validation rules continue to apply, and the release requires that the disclosure be correct and in order per the General and Specific e-Invoice Guidelines.

What the release does not state. It gives no application form, no separate approval step and no case-by-case assessment process. For the capital allowance it states no year of assessment, no conditions and no reference to a gazette order. If your position turns on either point, ask HASiL rather than inferring. The e-Invoice help desk is 03-8682 8000, stated as a 24 hour line, and general queries go to myinvois@hasil.gov.my.

One documentation quirk worth knowing. The SDK release note tells taxpayers to consult the e-Invoice Guideline and the Specific Guidelines for “the applicable requirements and procedures under e-Invoice SVDP”. Both current versions, 4.7 and 4.8, each dated 7 July 2026, contain no SVDP-specific provisions. The programme’s terms are in the media release, not the guidelines. If you go looking in the guidelines and find nothing, that is why.

What to do this week

Check whether you broke on 15 August. Pull your submission failures from 15 August onward and compare the failure reasons against the ten fields. Date-format failures are the most likely and the easiest to miss, because a system that has always written “N/A” will keep doing so silently.

Size your amount fields before 23 October. Twenty-six digits, every field on both lists. This is a schema question, and it takes a developer minutes to check and potentially days to fix. Ask now, not in October.

Check your passport field. Twelve characters, effective 23 October. If you invoice individuals identified by passport, some of your stored values may be longer.

Run a pass over buyer BRN data. TIN and BRN validation has been live since 1 August. Mismatches between what your buyer gave you and what HASiL holds will surface as failures, and fixing them means going back to the customer.

If you find a gap, the disclosure programme is open until 31 December 2027 and carries no penalty. Category 2, submitted but non-compliant, covers most validation failures. Separately, ask your tax agent about the accelerated capital allowance on ICT equipment and e-Invoice software costs, which is a live claim whether or not you disclose.

Sources: MyInvois SDK 1.0 Release page, release notes dated 3 July, 8 July and 6 August 2026; HASiL media release HASiL/2026/07/07-36 dated 7 July 2026, Program Khas Pengakuan Sukarela (PKPS) e-Invois; e-Invoice Guideline Version 4.7 and e-Invoice Specific Guideline Version 4.8, both dated 7 July 2026. All retrieved 18 August 2026. This article is general information current as at that date and is not tax or legal advice. The SDK release notes and both guidelines are versioned and revised without notice, so confirm the live position on sdk.myinvois.hasil.gov.my and hasil.gov.my before acting on any date or field rule here.