The Inland Revenue Boards new and updated guidelines on e-Invoices and the Software Development Kit

On 9 February 2024, the Inland Revenue Board of Malaysia (IRBM) published on its website the following documents, which can be accessed via the following link:

• e-Invoice Guideline (Version 2.2) *
• e-Invoice Specific Guideline (Version 2.0) *
• Software Development Kit

* These Guidelines are issued under Section 134A of the Income Tax Act 1967..

The updated e-Invoice Guideline (Version 2.2) replaces the earlier e-Invoice Guideline (Version 2.1).

In this Tax Alert, we  cover some of the key changes made to the e-Invoice Guideline (Version 2.1) following our EY Tax Alert Special Edition No. 4/2023 issued on 6 October 2023, which discussed the key changes made to the e-Invoice Guideline (Version 2.0) previously issued on 29 September 2023.

Some of the key changes made to the e-Invoice Guideline are outlined below.

1.    Paragraph 1.5 (page 13) – e-Invoice Implementation Timeline

The following mandatory e-Invoice implementation timelines were updated in the e-Invoice Guideline (Version 2.1):

Since taxpayers are required to implement e-Invoices based on their respective timelines, some taxpayers may still receive normal receipts in situations where the suppliers do not yet need to implement e-Invoicing.

2.    Paragraph 1.6.1 (page 16) – Exemptions from implementing e-Invoices

“Individual who is not conducting business” has been added to the list of persons who are currently exempted from issuing e-Invoices (including issuance of self-billed e-Invoices).

3.    Paragraph 1.6.5 (page 17)

When transacting with persons listed under Section 1.6.1(e), (f), (g), (h), (i) and (j) of the e-invoice Guideline version 2.2, suppliers are allowed to insert a “General TIN” from Appendix 1 of the e-invoice Specific Guidelines, as the buyer’s Tax Identification Number (“TIN”). The persons listed under Section 1.6.1(e), (f), (g), (h), (i) and (j) are as follows:

• Government
• State government and state authority
• Government authority
• Local authority
• Statutory authority and statutory body
• Facilities provided by the above government, authority or body (e.g., hospitals, clinics, multipurpose halls)

e-Invoice model via the MyInvois Portal

4.    Paragraph 2.3.2 (page 23)

The IRBM has clarified that the supplier is responsible, to the extent possible, to ensure the accuracy of the information in the e-Invoice that is submitted to the IRBM for validation.

5.    Paragraph 2.3.3 (page 23)

Apart from a validated e-Invoice, the supplier will also receive a visual representation of the validated e-Invoice in PDF format from the IRBM, via the MyInvois Portal.

6.    Paragraph 2.3.5 (page 25)

The visual representation of the validated e-Invoice generated from MyInvois Portal will include a QR code. The QR code can be used to validate the existence and status of the e-Invoice via the MyInvois Portal.

7.    Paragraph 2.3.6 (page 26)

After the e-Invoice is validated by the IRBM, both the supplier and the buyer have the right to cancel or reject the e-Invoice. This can be done via the MyInvois Portal within 72 hours from the time of validation. The IRBM has clarified that the 72-hour timeframe is provided for the convenience of both the supplier and the buyer. However, if the supplier chooses not to use the cancellation / rejection function, the supplier can still make adjustments by issuing a credit note / debit note / refund note e-Invoice.

e-Invoice model via the Application Programming Interface (API)

8.    The following terminology, amongst others, has been updated:

9.    Paragraph 2.4 (page 29)

Taxpayers who choose to submit e-Invoices to IRBM directly may transmit e-Invoices via the API. The Software Development Kit (SDK) includes the API integration and configuration guide as well as the API endpoints.

The IRBM has clarified that the XML and JSON file formats will be supported for e-Invoice submissions, while adhering to the data structure of the Universal Business Language Version 2.1 (“UBL2.1”).

10.    Paragraph 2.4.5 (page 33)

Upon validation of the e-Invoice, the supplier is obligated to share the validated e-Invoice with the buyer. If the supplier shares the visual representation of the validated e-Invoice with the buyer, the supplier needs to ensure that the QR code is embedded therein. The QR code can be used to validate the existence and status of the e-Invoice through the MyInvois Portal.

11.    Paragraph 2.4.6 (page 35)

Similar to paragraph 2.3.6 (page 26), after the e-Invoice has been validated by the IRBM, both the supplier and the buyer have the right to cancel or reject the e-Invoice via the API within 72 hours from the time of validation. The IRBM has clarified that the 72-hour timeframe is provided for the convenience of both the supplier and the buyer. However, if the supplier chooses not to use the cancellation / rejection function, the supplier can still make any adjustments by issuing a credit note / debit note / refund note e-Invoice.

Appendix 1 – List of required fields for e-Invoice

In the e-Invoice Guideline (Version 2.2), the number of data fields for an e-Invoice has increased from the earlier 51 data fields to 55 data fields, which are grouped into eight categories. The following are the additional mandatory and optional data fields:

• Additional mandatory data field
  • Total payable amount (item 40)
• Additional optional data fields
  • Total net amount (item 39)
  • Rounding amount (item 41)
  • Total taxable amount per tax type (item 42)
  • Fee / charge rate (item 47)
  • Fee / charge amount (item 48)

The following mandatory data fields have been removed:

• Date and time of validation [item 23 in Appendix 1 of the e-Invoice Guideline (Version 2.1)]
  
• IRBM unique identifier number [item 29 in Appendix 1 of the e-Invoice Guideline (Version 2.1)]

Apart from the above, the descriptions of some of the data fields for an e-Invoice have been updated.  Some of the updated descriptions are set out below (see bold font):

Appendix 2 – List of mandatory and optional fields under annexure to the e-Invoice

The descriptions of the following mandatory data fields to be included in the Annexure to the e-Invoice have been updated (see bold font): 

The updated e-Invoice Specific Guideline (Version 2.0) replaces the earlier e-Invoice Specific Guideline (Version 1.1).

Some of the key changes made to the e-Invoice Specific Guideline (Version 2.0) are outlined below:-

1.    Transactions with buyers

Paragraph 3.5.4 (page 12) – Where the buyer requires an e-Invoice

As part of the concession provided by the IRBM in facilitating an efficient process in issuing e-Invoices and easing the burden of individual buyers in providing their Tax Identification Number (“TIN”) and identification number details, the Malaysian individual buyer may provide his/her MyTentera identification number instead of his/her MyKad identification number.

For non-Malaysian individual buyers who do not have TIN assigned by IRBM, the supplier may use the general TIN as listed in Appendix 1 of the e-Invoice Specific Guideline (i.e. EI00000000020) together with either the buyer’s passport, MyPR or MyKAS identification number.

Paragraph 3.6.3 (page 18) – Where the buyer does not require an e-Invoice

For consolidated e-Invoices, the IRBM has amended the consolidated e-Invoice methods as follows:

(a)   The summary of each receipt is presented as a separate line item in the consolidated e-Invoice.

(b)  The lists of receipts (i.e., continuous receipt numbers) are presented as line items. If there is a break in the chain of receipt numbers, the next chain shall be included as a new line item.

(c)   Each branch / location will submit a consolidated e-Invoice adopting either method (a) or method (b) above for the receipts issued by the said branch / location.

The supplier is allowed to adopt one or a combination of the above methods.

Paragraph 3.6.4 (page 18) – Self-billed e-Invoices

The IRBM has clarified that the consolidation of e-Invoices does not apply to self-billed e-Invoices.

Paragraphs 3.7.5 and 3.7.6 (page 30)

When transacting with persons listed under Section 1.6.1(e), (f), (g), (h), (i) and (j) of the e-invoice Guideline version 2.2, suppliers are allowed to insert a “General TIN” from Appendix 1 of the e-invoice Specific Guidelines, as the buyer’s TIN. The persons listed under Section 1.6.1(e), (f), (g), (h), (i) and (j) are as follows:

• Government
• State government and state authority
• Government authority
• Local authority
• Statutory authority and statutory body
•  Facilities provided by the above government, authority or body (e.g., hospitals, clinics, multipurpose halls)

Where e-Invoices are issued to persons exempted under Paragraph 1.6.1 of the e-Invoice Guideline (Version 2.2), the supplier is required to maintain supporting documents to substantiate that the e-Invoices are related to exempted persons.

2.    Statements or bills on a periodic basis

Item 2 in Table 4.1 (page 41)

In addition to the Malaysian business buyer’s TIN, the supplier is also required to insert the business registration number of the Malaysian business buyer.

For foreign business buyers, the supplier shall insert the foreign business buyer’s TIN and business registration number, if it is available.  If such information is not available, the supplier shall insert EI00000000020 as the foreign business buyer’s TIN and “NA” for the foreign business buyer’s business registration number.

3.    Employment perquisites and benefits

Certain expenses incurred by employees on behalf of employers

Paragraph 6.5(a) (page 56) and Paragraph 7.4(a) (page 57)

Due to the potential challenges in obtaining e-Invoices issued in the name of the employer, as part of the concessions provided by the IRBM, to substantiate the proof of expense for tax purposes businesses are allowed to use e-Invoices issued in the name of the employee or the existing supporting documents issued by the supplier.

4.    Self-billed e-Invoices

Paragraph 8.3 (page 59)

Self-billed e-Invoices will also be allowed for the following transactions:

• Payments / credits to taxpayers recorded in statements / bills issued on a periodic basis (e.g., rebates)
  
• Interest payments

Table 8.2 (pages 63 and 64)

The additional information which are required to be included in the self-billed e-Invoice are as follows:

• Supplier’s Malaysia Standard Industrial Classification (“MSIC”) code, where applicable. If such information is not available or not provided, the buyer shall insert “00000”.
  
• Supplier’s business activity description, where applicable. If such information is not available or not provided, the buyer shall insert “NA”.

5.    Transactions which involve payments (whether in monetary form or otherwise) to agents, dealers or distributors (“ADDs”)

Paragraph 9 (page 65) – Issuance of self-billed e-Invoices for payments to ADDs

The updated Specific Guideline states that this applies to payments and incentives (whether monetary or otherwise) received by ADDs.

6.    Cross border transactions

Paragraph 10.4.7 (page 74), paragraph 10.4.8 (page 74) and paragraph 10.4.9 (page 75)

Where service tax is applicable on imported taxable services, the taxpayer is required to include the service tax amount in the self-billed e-Invoice. In addition, the self-billed e-Invoice should be issued either upon payment made by the Malaysian purchaser or upon receiving the invoice from the foreign supplier, whichever is earlier.

With regard to the importation of goods, the Malaysian purchaser is required to issue the self-billed e-Invoice upon obtaining customs clearance.

7.    Currency exchange rate

Paragraph 13.3 (page 93)

When issuing e-Invoices for transactions conducted in foreign currencies, the supplier may choose to submit the e-Invoice in one of the following ways:

• in the relevant foreign currency together with the applicable currency exchange rate, without the RM equivalent;
• in the relevant foreign currency and the applicable RM equivalent, without the currency exchange rate; or
• in the relevant foreign currency, with the applicable RM equivalent together with the currency exchange rate.

8.    e-commerce transactions (pages 94 – 108)

The e-Invoice Specific Guideline provides additional guidance in relation to e-commerce transactions. The contents therein are similar to the Frequently Asked Questions (“FAQs”) for the e-commerce industry (updated on 22 December 2023) issued by the IRBM.

The Specific Guideline describes the e-Invoice process flow between the e-commerce platform provider, the merchant, the service provider (e.g., logistic services) and the purchaser.

In an e-commerce transaction, the e-commerce platform provider is responsible to issue either an e-Invoice (upon request by the purchaser) or receipt (if the purchaser did not request an e-Invoice) to the purchaser.

For transactions where purchasers did not request e-Invoices, the e-commence platform provider is allowed to aggregate such transactions (except certain transactions / activities where consolidated e-Invoices are not permitted) on a monthly basis and submit the consolidated e-Invoice to the IRBM within seven calendar days after the month end.

In addition, the e-commerce platform provider is required to issue a self-billed e-Invoice to the merchant and / or the service provider in relation to the transaction concluded on the e-commerce platform. The e-commerce platform provider (i.e., the buyer) will assume the role of the supplier to issue a self-billed e-Invoice.

Apart from the above, certain charges will be imposed by the e-commerce platform provider to the merchant and / or service provider, for the use of the platform. In this regard, the e-commerce platform provider is responsible to issue an e-Invoice to the merchant and / or service provider.        

Understanding IRBM’s SDK: Key highlight and takeaways.

On 9 February 2024, the IRBM unveiled the pivotal final component of the e-Invoicing framework: The beta version of the SDK. This document is comprehensive and serves as a blueprint to provide taxpayers with a better understanding of the IRBM e-Invoice platform and an integrated API, which will empower taxpayers to automate their invoicing processes and drive digitalization by enabling a seamless connection with IRBM.

Key Highlights (Beta)

If you haven’t explored IRBM’s SDK website yet, here is a summary.

1.    IRBM’s API

Describes the Platform’s operability- the SDK defines two distinct categories of API functionalities:

(a)   Platform API: Provides fundamental operations including authentications, document retrievals, and notifications.

(b)  e-invoice API: Furnishes essential functions for the submission, validation, rejection, and cancellation of e-invoice documents.

The SDK outlines the input/output parameters and response messages per API function, and uniquely by the identified eight e-Invoice document types:

(a)   invoices, credit notes, debit notes, refund notes.

(b)  Self-billed invoices, Self-billed credit notes, Self-billed debit notes, Self-billed refund notes.

This includes a detailed breakdown of the data structures, schema requirements and expected codes for the XML/JSON file types to allow seamless integration between the taxpayer’s systems and IRBM’s e-Invoice platform.

2.    Data management

The IRBM e-invoice Guideline[s] dated 9 February 2024 outlines some field-movements, which are reflected in the SDK:

(a)   37 mandatory data fields

(b)  18 optional data fields

(c)   12 annexure data fields

The SDK further describes the dataset breakdown into 107 elements through the UBL Schema Mapping. One such example is the “Buyer’s address” being mapped to seven elements in alignment with the XML/JSON format.

SDK also lists the pre-defined data values for fields such as Malaysian Standard Industry Classification, Country and Currency (Refer to the code tables).

3.    Digital signatures and security

The IRBM no longer plans to issue taxpayers with “Issuer’s Digital Signatures”. Thus, moving forward, taxpayers are required to enlist the services of vendors offering digital certification. This goes hand-in- hand with security considerations as organisations are bound by the Personal Data Protection Act 2010 and related regulations. Thus, taxpayers must consider the legal implications of collecting and storing the data required for e-invoicing.

4.    Throttling and rate limiting

Another crucial consideration is throttling or rate limiting, which plays a significant role in managing system loads. It is worth noting that specific e-invoice API functions are subject to throttling and rate limiting rules. Currently, not all the APIs have the rate defined, except for the “Search Document API”, which imposes a throttling limit set at one request every two seconds.

In relation to this, we also note that the “Search Document API” rules apply to taxpayers and not according to the system. While further clarification and details are expected, organisations with multiple invoicing systems which intend to utilize the abovementioned API should carefully consider their approach, factoring in this requirement.

5.    API testing

The IRBM has given guidance to taxpayers interested in initiating the testing of API calls through the Postman platform. This initiative encourages taxpayers to conduct simulations and implement the necessary adjustments ahead of the 1 August 2024 go-live date, to ensure their readiness and a smooth transition to the direct API integration.

6.    Validation rules

The SDK describes the seven validation categories on the e-Invoice platform, which developers will need to take note of while designing their interface. With the inherent nature of API calls, taxpayer systems must be equipped to handle errors effectively when transmitting data across the various API functions described. Taxpayers should implement robust processes to promptly address all errors encountered, whether they pertain to data structure discrepancies, infra disruptions or data validation issues.

Our key takeaways

Considering the new information provided in the SDK, here are a few considerations for you to take into account:

(a)   IRBM’s API: The IRBM has provided taxpayers and organisations with an array of functions to efficiently communicate with IRBM’s e-invoice system. Organisations must consider their business processes and systems to design the integration workflow accordingly.

(b)  Data management: It is vital for taxpayers leveraging IRBM’s API to undertake the exercise of diligently mapping their data fields. Failure to do so could result in a heightened risk of rejections during the IRBM’s e-invoice validation process, potentially disrupting business processes.

(c)   Digital signatures and security: Organisations should be proactive and start enquiring about digital certifications and available service providers, while waiting for the IRBM’s further guidance.

(d)  Throttling and rate limiting: It remains unclear what rules the IRBM will set for the other API functions available to taxpayers. Thus, during the implementation stage, organisations will have to be ready for further rate-limiting measures and ensure that these requirements are factored into their business and IT processes to prevent backlogs and delays, which could jeopardize operational effectiveness.

(e)   API testing: Organizations must acknowledge the dynamic nature of the guidelines and the SDK and be ready to accommodate further revisions as they implement their API solutions. Note: At the point of writing- IRBM’s sandbox has not yet been released to the public. Therefore, the guidelines shared on the Postman platform serves as reference to help organisations understand the API schema as they design their system changes.

(f)    Error handling and reconciliation: Organisations will need to consider reformed reconciliation procedures to ensure their new e-invoicing error handling processes are streamlined and not left as an afterthought.

Final note

While it may seem that we have come a long way in understanding e-Invoicing, at the current stage, given the scale, complexity, and transformative nature of our national e-invoice program, it is imperative for organisations to remain focused and agile, and collaborate closely with the IRBM to achieve a successful outcome.