MyInvois SDK Validation Change 24 Oct 2026: What to Fix

From 24 October 2026, the MyInvois system of Lembaga Hasil Dalam Negeri Malaysia (LHDN, the Inland Revenue Board of Malaysia) enforces two new validation limits in its Production environment: every monetary amount field in a submitted e-invoice is capped at 26 digits, and any identifier submitted with ID Type PASSPORT is capped at 12 characters. The rule comes from the MyInvois Software Development Kit (SDK) 1.0 release note dated 6 August 2026. A submission that breaches either limit can be marked Invalid, which means no validated e-invoice exists for that transaction.

This article is for the people who own a live MyInvois integration: in-house application programming interface (API) teams, enterprise resource planning (ERP) and accounting-software vendors, and the finance or IT leads who sign off on their releases. It maps the 23 named amount fields to their Universal Business Language (UBL) paths, explains what a rejection looks like, sets out a preprod test sequence, and confirms what MyInvois portal users need to do, which is nothing.

Verified against the MyInvois SDK 1.0 release notes (entries dated 30 April, 6 August and 25 September 2026), the e-Invoice General Guideline v4.8 (30 August 2026), the e-Invoice Specific Guideline v4.9 (7 September 2026) and the LHDN e-Invoice General FAQs (4 September 2026) on 6 October 2026.

What Changes in MyInvois on 24 October 2026

The 6 August 2026 entry on the SDK 1.0 Release page states that “all amount fields will be updated to have a maximum length of 26 digits” and that taxpayers “are required to comply with the character limit for ID Type: PASSPORT, which is 12 characters.” The entry says these changes “will take effect in the Production environment on 24 October 2026.” No new fields or document types are introduced. The change is a tightening of validation on data you already send.

The 24 October date is the latest in a series of 2026 validation changes, and integrators should keep the dates separate. Our LHDN e-invoice implementation update changelog tracks each of them.

The TIN and BRN change is covered in our article on the TIN and BRN validation that went live on 1 August 2026. The 24 October change is narrower than its predecessors, but it touches the one part of an invoice that every ERP calculates rather than copies: money.

Also on 24 October: error-reference links and two API parameters

A second SDK entry, dated 25 September 2026, goes to Production on the same day. It adds validator-specific error-reference pages with common error codes, causes and recommended resolutions for eight validators: Structure, Core Fields, Signature, Taxpayer, Referenced Documents, Code, Duplicate Document and Currency. The standard error response adds direct links to those pages in API validation responses. The same entry adds an optional classification-code filter to the Search Documents API and an optional version-number parameter to the Get Document and Get Document Details responses. (MyInvois SDK 1.0 release note, 25 September 2026) None of these is a new validation rule, but the error links change what your logs capture from 24 October.

The 23 Amount Fields, Mapped to UBL

The release note lists the affected fields by their business names. The Invoice v1.1 document specification gives the Universal Business Language (UBL) XML paths. The table below joins the two, so a developer can grep an outbound payload rather than guess.

Three things follow from this table.

• Most invoice-level totals already carry a 26-character maximum in the specification. If your integration has been live since 2024 or 2025 and passing, your totals are probably compliant already. The exposure sits in the six line-level fields with no stated length: Unit Price, Subtotal, Tax Rate, Tax Amount, Discount Amount and Fee / Charge Amount.
• Tax Rate is on LHDN’s list even though it is a percentage, not an amount. A rate serialised with many decimal places (for example, a computed effective rate) is the kind of value that trips a length check.
• The JSON document format follows the same structure, so the same audit applies whether you submit XML or JSON. In enterprise ERP integrations JomeInvoice has executed, the length problem rarely comes from the invoice total. It comes from a line-level unit price or discount computed in a wide decimal type and serialised without rounding. Since 30 April 2026, the same values must also be written as plain numbers: LHDN does not accept scientific notation in any amount field, so a serialiser that emits “1.5E7” already fails.

E-Invoice Middleware for Enterprise

Does your integration already enforce the 24 October field limits?

Book a migration assessment. We audit your current MyInvois pipe against the SDK 1.0 rules.

Book a Demo Sign Up Free

PDPA Compliant  ·  ISO 9001  ·  ISO 20000-1  ·  ISO 27001  ·  MySTI Certified  ·  STI202501062

The PASSPORT 12-Character Rule

The 12-character limit applies wherever a party is identified with schemeID PASSPORT: the supplier, the buyer, and the shipping recipient in the Invoice v1.1 specification. The specification already defines PASSPORT as “VARCHAR (12 CHAR)”, alongside National Registration Identity Card (NRIC) and ARMY at 12 characters and BRN at 20. From 24 October, that documented maximum becomes an enforced validation.

The exposure is data hygiene rather than schema. Passport numbers arrive from sales teams, e-commerce checkouts, and hotel property-management systems as free text, often with a country prefix, spaces, or a trailing issue code. Three checks resolve most of it:

• Strip whitespace and punctuation before the value enters the buyer record, not at submission time.
• Reject or route for review any passport value longer than 12 characters at data capture.
• Keep the passport even when the buyer has no Malaysian TIN. A non-Malaysian buyer without a TIN is identified with the general TIN EI00000000020 plus the passport number, so the passport is still required and must fit 12 characters. MyPR and MyKAS holders are the exception: they are identified like Malaysian individuals, with EI00000000010 when only the ID number is given. (e-Invoice Specific Guideline v4.9, 7 September 2026, Table 10.2 and Appendix 1) Our guide to the general TIN codes for e-invoices in Malaysia lists each code and when it applies.

What an e-Invoice Validation Rejection Looks Like

Validation in MyInvois happens in two stages, and the 24 October rule can surface in either. Understanding the sequence is what turns a vague fear of rejection into a monitorable event.

Stage one is synchronous. The Submit Documents API runs what LHDN calls a “minimal set of validations” on structure and document type, returns HTTP 202, and hands back a submissionUID with two lists: acceptedDocuments and rejectedDocuments. The specification is explicit that “the process of validation is not complete when result is returned.”

Stage two is asynchronous. Your system polls Get Submission or Get Document Details, and each document moves from Submitted to Valid or Invalid (Cancelled is the fourth status). An Invalid document carries a validationResults object with one entry per validation step, each with a name, a status, and, where it failed, an error object.

The standard error response is the same shape everywhere: propertyName, propertyPath (for example a JSON path to the offending element), errorCode, a human-readable error in English, errorMS in Bahasa Malaysia, and an optional innerError array. From 24 October, validation responses also carry direct links to the SDK error-reference page for the failing validator, which makes a length failure easier to classify in your logs.

Why an Invalid document is a compliance event

Two consequences make this a compliance event rather than an IT ticket:

• An Invalid document has no validated status, so for the transaction concerned no e-invoice has been issued. Failure to issue an e-invoice is an offence under Section 120(1)(d) of the Income Tax Act 1967, punishable by a fine of RM200 to RM20,000 for each non-compliance, imprisonment of up to six months, or both. (LHDN e-Invoice General FAQs, 4 September 2026, Q41) Our guide to LHDN e-invoice penalties in Malaysia sets out how the offence is counted. At 10,000 invoices a month, a systematic length error in one line-level field is not one offence; it is a batch of them.
• Fixing an Invalid document means correcting the source data and resubmitting as a new document. The 72-hour cancellation window applies to validated documents, so a validated-then-wrong invoice and an Invalid one follow different recovery paths. (LHDN e-Invoice General FAQs, 4 September 2026, Q47–Q48; e-Invoice General Guideline v4.8, §2.3.6 and §2.4.5) Our guide on how to amend or cancel an e-invoice in Malaysia covers the validated-document path.

LHDN states that validation is done in near real-time, generally in less than two seconds. (LHDN e-Invoice General FAQs, 4 September 2026, Q42) The API contract is still asynchronous: Submit returns before validation completes, which is why a polling loop with exception handling, not a fire-and-forget POST, is the baseline for submitting e-invoices via the MyInvois API.

How to Test the New Validation in the Preprod Environment

LHDN’s Sandbox, referred to as Preprod, is the environment for this work. The SDK FAQ lists the portal at preprod.myinvois.hasil.gov.my and the API and identity service at preprod-api.myinvois.hasil.gov.my. Our guide to the MyInvois portal testing environment covers registration. The 6 August release note gives only the Production date, so confirm how Preprod behaves before relying on a passing test.

Step 1: Register the ERP system in Preprod

Register the company in the pre-production portal, then register the ERP or middleware system to obtain a Client ID and Client Secret. Use a dedicated Preprod credential set; never point a production credential at the sandbox.

Step 2: Build a boundary test set

Create at least seven test documents: an invoice with every amount field at exactly 26 digits, one with a line-level Unit Price at 27 digits, one with a Tax Rate carrying eight decimal places, one with an amount written in scientific notation, one with a PASSPORT ID of exactly 12 characters, one at 13 characters, and one control document that passes today. Include both XML and JSON if you support both formats.

Step 3: Submit and poll to a terminal status

Submit each document through the e-invoice API Malaysia endpoint in Preprod, capture the submissionUID, and poll Get Document Details until every document reaches Valid or Invalid. Log the full validationResults object, not just the status.

Step 4: Record the error signature

For each Invalid document, record propertyPath, errorCode, the error text and, once available, the error-reference link. This becomes the alert rule in production monitoring: any document whose validation steps include that signature pages the integration owner.

Step 5: Fix at source and regression-test

Where a boundary document fails, fix the rounding or truncation in the ERP mapping layer, not in a post-processing patch, then re-run the full set plus a sample of last month’s real invoices replayed into Preprod.

Who Has Nothing to Do: MyInvois Portal Users

Taxpayers who key invoices directly into the MyInvois portal have no system change to make. The portal is LHDN’s own front end; whatever it accepts on 24 October is, by definition, what Production validates. The one caution is for portal users who upload the Batch Upload spreadsheet template: the values in that file are still your data, so keep amounts within 26 digits and passport numbers within 12 characters in the spreadsheet itself.

For everyone else, the question is not whether the rule applies but which layer of the stack owns the fix. Our overview of e-invoice integration models in Malaysia sets out the four options and who carries change absorption in each.

Before 24 October: Checklist for Integrators and Software Vendors

Work back from the date. LHDN gave integrators eleven weeks between the 6 August release note and the 24 October Production date.

1. Inventory every field in the table above in your outbound mapping, XML and JSON.
2. Check the data type and scale of each source column in the ERP or accounting database.
3. Add a serialisation rule that rounds and truncates to the SDK limit, in plain numeric format, before the document is signed.
4. Add a hard validation on PASSPORT length at buyer-record creation.
5. Run the Preprod boundary set in Step 2 and archive the results.
6. Add production monitoring for the recorded error signature and for any rise in Invalid counts after 24 October.
7. Schedule a release window before 24 October and a hypercare window covering the first month-end after it.

If a third party runs your integration, the vendor-evaluation question is simple: ask who owned each of the 2026 validation changes in the table above, and how many of your developer hours each one consumed. A provider that surfaced the 1 August TIN and BRN change, the 15 August format change, and the 24 October length change as work for your team is not absorbing e-invoice compliance; it is forwarding it. LHDN is clear that the responsibility to comply remains with the company when a provider is appointed (LHDN e-Invoice General FAQs, 4 September 2026, Q30), as our guide on whether a business can outsource e-invoice submission to a third-party service provider explains.

How JomeInvoice Absorbs the SDK Change for You

JomeInvoice is Malaysian e-invoicing middleware that sits between your ERP, point-of-sale (POS), or accounting system and MyInvois. The SDK change lands on our side of that line. Amount serialisation, identifier hygiene, and the validation-step monitoring described above are maintained by JomeInvoice across every client at once, so your ERP mapping does not change when LHDN publishes a release note. Middleware cannot repair master data, so passport values that are wrong at source still need correcting in the buyer record. The rejection error-code guide in our product documentation explains each failure category and the resubmission path.

• Reconciliation is built in: your ERP state and the LHDN-validated state stay synchronised, so an Invalid document is visible in your dashboard, not discovered at audit.
• The integration is custom-built to your existing system over an API or secure file transfer protocol (SFTP) feed. SAP, Oracle NetSuite, and Microsoft Dynamics 365 are the core ERPs in our enterprise client base.
• JomeInvoice is headquartered in Kuala Lumpur and backed by AGMO Holdings Berhad, is ISO 9001, ISO 20000-1 and ISO 27001 certified, hosts data onshore on Amazon Web Services (AWS) Malaysia, and offers support in Bahasa Malaysia, English, and Mandarin with a direct LHDN escalation path.

Enterprise go-live is typically four to eight weeks, subject to change where more complicated or customised solutions are needed. The enterprise e-invoicing solution page sets out the architecture; a migration assessment maps your current pipe against the SDK 1.0 rules and defines the timeline.

E-Invoice Middleware for Enterprise

Let SDK changes land on our side, not in your sprint backlog.

JomeInvoice absorbs MyInvois validation changes below your ERP line. ISO 27001-certified, Malaysian team, direct LHDN escalation.

Book a Demo Sign Up Free

PDPA Compliant  ·  ISO 9001  ·  ISO 20000-1  ·  ISO 27001  ·  MySTI Certified  ·  STI202501062

Disclaimer: This article is for general informational purposes only and does not constitute legal or tax advice. LHDN guidelines are subject to updates. Always refer to the latest official LHDN e-Invoice Guidelines at myinvois.hasil.gov.my and consult a qualified tax professional for advice specific to your business.

Frequently Asked Questions

What changes in MyInvois on 24 October 2026?

Two validation limits take effect in Production: all monetary amount fields are capped at 26 digits, and identifiers with ID Type PASSPORT are capped at 12 characters. [LHDN, MyInvois SDK 1.0 release note, 6 August 2026] No new fields or document types are introduced.

Will existing e-invoices be rejected after 24 October 2026?

No. Documents already validated keep their status. The rule applies to submissions made from 24 October 2026; a new document that breaches either limit can be marked Invalid.

Does the SDK validation change affect MyInvois portal users?

No. Portal users have no system change to make, because the portal is LHDN’s own interface. Batch Upload users should keep spreadsheet values within the same limits.

What is the 26-digit amount limit exactly?

The maximum length of every monetary amount field in a submission, at invoice and line level, is 26 digits. Neither the release note nor the Invoice v1.1 specification defines whether the decimal separator counts, so treat 26 as the total serialised length.

How do I test the new validation in the preprod environment?

Register your system at preprod.myinvois.hasil.gov.my, submit boundary documents (26 and 27 digits; 12 and 13 characters) through preprod-api.myinvois.hasil.gov.my, poll Get Document Details, and record the error signature of any Invalid result.

What is the validation time for an e-invoice in MyInvois?

Near real-time, generally less than two seconds, according to LHDN. [LHDN e-Invoice General FAQs, 4 September 2026, Q42] The API is asynchronous, so your system still polls until the document is Valid or Invalid.

What does “State Code 17 should be used for Consolidated invoice only” mean?

The message means State Code 17 is reserved. Since 30 April 2026 it may be used only for consolidated e-invoices issued in Malaysia or for transactions outside Malaysia. Use the state code for the actual address otherwise. [LHDN, MyInvois SDK 1.0 release note, 30 April 2026]

Does e-invoice middleware remove the need to change my ERP for this?

It depends on which layer owns serialisation. Where the middleware owns serialisation and validation, the 26-digit and 12-character rules are enforced in the middleware layer and the ERP mapping stays unchanged. Passport values that are wrong at source still need correcting in the buyer record.

Last updated: 6 October 2026 | Written by Yinn Sheng Ng, Head of Marketing

References

• Inland Revenue Board of Malaysia, MyInvois SDK 1.0 Release notes (entries dated 30 April, 6 August and 25 September 2026): https://sdk.myinvois.hasil.gov.my/sdk-1-0-release/
• Inland Revenue Board of Malaysia, MyInvois SDK Invoice v1.1 document specification: https://sdk.myinvois.hasil.gov.my/documents/invoice-v1-1/
• Inland Revenue Board of Malaysia, MyInvois SDK Submit Documents API: https://sdk.myinvois.hasil.gov.my/einvoicingapi/02-submit-documents/
• Inland Revenue Board of Malaysia, MyInvois SDK Get Document Details API: https://sdk.myinvois.hasil.gov.my/einvoicingapi/08-get-document-details/
• Inland Revenue Board of Malaysia, MyInvois SDK Standard Error Response: https://sdk.myinvois.hasil.gov.my/standard-error-response/
• Inland Revenue Board of Malaysia, MyInvois SDK FAQ (Sandbox environment): https://sdk.myinvois.hasil.gov.my/faq/
• Inland Revenue Board of Malaysia, e-Invoice General Guideline Version 4.8 (30 August 2026): https://www.hasil.gov.my/wp-content/uploads/IRBM-e-Invoice-Guideline.pdf
• Inland Revenue Board of Malaysia, e-Invoice Specific Guideline Version 4.9 (7 September 2026): https://www.hasil.gov.my/wp-content/uploads/IRBM-e-Invoice-Specific-Guideline.pdf
• Inland Revenue Board of Malaysia, e-Invoice General FAQs (updated 4 September 2026): https://www.hasil.gov.my/wp-content/uploads/lhdnm-e-invoice-general-faqs.pdf
• Income Tax Act 1967 (Act 53), consolidated PDF, Section 120(1)(d): https://hasil.gov.my/wp-content/uploads/20240521-akta-cukai-pendapatan-1967-akta-53.pdf