Recording a business transaction into the financial accounts of an organization is one of the main objectives of the invoice. According to financial accounting best practice and TAX rules every Taxable person shall keep accounts in sufficient detail for TAX to be applied and its application checked by the tax authorities. For that reason, an invoice shall provide for the information at document and line level that enables booking on both the debit and the credit side.

This process forms part of the Buyer’s internal business controls. The invoice shall refer to an authentic commercial transaction. Support for invoice verification is a key function of an invoice. The invoice should provide sufficient information to look up relevant existing documentation, electronic or paper, for example, and as applicable:

An invoice should also contain sufficient information that allows the received invoice to be transferred to a responsible authority, person or department, for verification and approval.

Companies audit themselves as means of internal control or they may be audited by external parties as part of a legal obligation. Accounting is a regular, ongoing process whereas an audit is a separate review process to ensure that the accounting has been carried out correctly. The auditing process places certain information requirements on an invoice. These requirements are mainly related to enable verification of authenticity and integrity of the accounting transaction.

Invoices, conformant to this PEPPOL BIS support the auditing process by providing sufficient information for:

The invoice is used to carry Tax related information from the Seller to the Buyer to enable the Buyer and Seller to correctly handle Tax booking and reporting. An invoice should contain sufficient information to enable the Buyer and any auditor to determine whether the invoice is correct from a Tax point of view.

The invoice shall allow the determination of the Tax regime, the calculation and description of the tax, in accordance with the relevant legislation.

An invoice represents a claim for payment. The issuance of an invoice may take place either before or after the payment is carried out. When an invoice is issued before payment it represents a request to the Buyer to pay, in which case the invoice commonly contains information that enables the Buyer, in the role of a debtor, to correctly initiate the transfer of the payment, unless that information is already agreed in prior contracts or by means of payment instructions separately lodged with the Buyer.

If an invoice is issued after payment, such as when the order process included payment instructions or when paying with a credit card, online or telephonic purchases, the invoice may contain information about the payment made in order to facilitate invoice to payment reconciliation on the Buyer side. An invoice may be partially paid before issuing such as when a pre-payment is made to confirm an order.

Invoices, conformant with this specification should identify the means of payment for settlement of the invoice and clearly state what payment amount is requested. They should provide necessary details to support bank transfers. Payments by means of Credit Transfer, Direct debit, and Payment Card are in scope.

The Malaysian government, through its national digitalisation agenda outlined in the 12th Malaysia Plan (RMK-12) and the National e-Commerce Strategic Roadmap (NESR 2.0), aims to expand the digital economy through enhanced B2B trading. The Government has identified e-Invoicing as the catalyst to encourage businesses to go through digitalisation transformation.

In Malaysia, e-Invoicing is being implemented with two distinct yet complementing components; One is for business digitalisation and the other is for tax compliance. To encourage business adoption of e-Invoicing, MDEC has been mandated to play the role as Malaysia’s Peppol Authority, where MDEC will be accrediting Peppol service providers and Peppol-ready solution providers, specifying local requirements and technical standards, governing the overall Malaysian Peppol framework compliance, and promoting business adoption of e-Invoicing in Malaysia.

The Malaysian Government has announced during the retabled Budget 2023 that the Inland Revenue Board of Malaysia (IRBM) will implement e-Invoicing for tax reporting purposes in phases, starting from 1 June 2024 to 1 January 2027 for targeted taxpayers. Note that the timeline has been revised to 1 August 2024 (implementation target date for taxpayers with an annual turnover or revenue of more than RM100 million) to 1 July 2025 (implementation target date for all other taxpayers) pursuant to the recent Budget 2024 announcement. The IRBM plays a crucial role in the country’s fiscal policies, revenue collection, and the enforcement of tax laws.

To improve tax compliance of individuals and businesses, taxpayers are required to submit their invoices for tax reporting purposes to IRBM’s MyInvois System. The transmission can be done through two (2) channels, namely the IRBM’s MyInvois Portal or through the published Application Programming Interface (API). Individual taxpayers and businesses that are not using an accounting software or Enterprise Resource Planning (ERP) software can submit their invoices through the IRBM’s MyInvois Portal, while businesses with ERP and/or accounting software may opt to submit their e-invoice through the IRBM’s MyInvois Portal or API.

The government has mandated MDEC to implement e-Invoicing for business digitalisation (B2B), using the Peppol framework. The Peppol framework, being the most widely implemented e-invoicing framework globally, consists of technical specifications applicable to existing eProcurement solutions or ERP systems, enabling systematic interoperability between disparate systems across businesses and facilitating seamless e-invoice exchange.

To abide by the IRBM’s tax reporting requirements, Corner 2 SPs in the Peppol Network will submit only the required IRBM fields (e-Invoice for tax reporting purposes) contained in the commercial e-invoice sent by suppliers through the IRBM MyInvois Portal or APIs. Once the e-Invoice for tax reporting purposes have been returned validated by the IRBM, Corner 2 SPs will combine the original commercial e-invoice together with the IRBM’s validated e-Invoice (for tax reporting purposes) for transmission to Corner 3 SPs. Corner 3 SPs will then transmit the full e-Invoice to the customer to complete the transaction. The process can be seen in Figure 1.5.2.

IRBM has published a list of required fields for every taxpayer to submit to IRBM for tax reporting purposes. The fields can be found in Chapter 3: Tax Information.

Under a self-billing arrangement, the Buyer assumes the role of the Supplier to issue and submit a self-billed e-Invoice to IRBM for validation, where the validated self-billed e-Invoice would serve as a proof of expense for tax purposes. As the Peppol e-Invoicing framework is B2B-focused, the self-billing e-Invoicing process may occur in the following scenario: • Transactions which involve Foreign Suppliers who do not use Malaysia’s MyInvois System; and • Other circumstances where another party (other than the Supplier) will be allowed to issue self-billed e-Invoice on behalf of the Supplier, subject to the conditions as may be determined by the Director General of IRBM.

Seller is mandatory information and provided in element cac:AccountingSupplierParty

Buyer is mandatory information and provided in element cac:AccountingCustomerParty

Payment receiver is optional information. If this information is not supplied, the seller is the payment receiver. When payee information is sent this is indicating that a factoring situation is being documented.

To reflect the assignment of an Invoice to a factor there is a need to:

Tax representative party for the seller is relevant for sellers delivering goods and services in a country without having a permanent establishment in that country. In such cases information on the tax representative shall be included in the invoice.

The purchase order reference is a conditional business term. If the customer has issued a purchase order should be referenced by providing its identifier in the resulting invoice, otherwise the Buyer reference should be used (see Buyer reference).

If the purchase order is referenced at the invoice header level, the order reference element on line level can be used to state the relevant line numbers in the order .

A sales order is issued by the seller, confirming the sale of specified products and may be provided in the invoice.

The buyer reference, known as Your ref, is conditional. An invoice shall have either the buyer reference or the order reference (see Purchase order and sales order reference)

The element is used for the reference of who ordered the products/services. Example being the name of the person ordering, employee number or a code identifying this person or department/group. Your ref is often used for internal routing at recipient, and hence it is important to fill this element with the correct values according to the need of the recipient.

If neither buyer reference nor a reference to an order is supplied by the customer, the name of the person ordering or appointed for the customer can be supplied in buyer reference if known by the supplier.

The invoiced object identifier is the identifier for an object on which the invoice is based, given by the Seller. Examples may be a subscription number, telephone number, meter point, vehicle, person etc., as applicable.

If it is not clear to the receiver what scheme is used for the identifier, an optional scheme identifier attribute should be used, that shall be chosen from the Invoiced object identifier scheme code list.

The invoiced object reference is provided by using the element cac:AdditionalDocumentReference with the document type code = 130

To reference or match an invoice to a purchase contract, the contract number could be specified like this:

To identify the call for tender or lot the invoice relates to, use the 'OriginatorDocumentReference'. The identifier is, in most cases, the Procurement Procedure Identifier.

The project reference is optional to use, and is sent in an invoice in the element cac:ProjectReference/cbc:ID. In a credit note, this element does not exist, and project reference is sent by using the element cac:AdditionalDocumentReference[cbc:DocumentTypeCode='50']/cbc:ID.

A credit note or negative invoice can refer to one or more initial invoice(s). This is done in the business group BG-3 Preceding invoice reference, providing the invoice number and issue date. The issue date shall be provided in case the preceding invoice reference is not unique.

In case correction applies to a large number of invoices, the invoicing period (BG-14), as necessary combined with a clarifying invoice note (IBT-22), may instead be given at document level.

An invoice may contain a supportive document as informative. Examples of such documents may be work reports, certificates or other documents that relate to the purchase or the invoiced items. A supportive document can be attached to the invoice in two ways: by providing a direct hyperlink through which the document can be downloaded or by embedding the document into the invoice. A compliant receiver is required to be able to receive an attached supportive document and, in case of embedded files, to convert it into a file but he is not required to handle the content of that file since it is only provided as informative.

When attaching a document using an uri the hyperlink shall point directly to the file that is to be downloaded.

An embedded document is contained in the invoice as binary object using base64 encoding and shall be supplemented with information about the name of the document file and a mime code indicating the type of the file. This allows the receiver to convert the binary code into a file that has the same name as the original file and allows him to associate the received file to a suitable application for viewing its content. The set of allowed codes for the file type (mime code) is limited to types that can be opened with applications that are commonly used and available.

As is with other file types, when an attached file is an XML file the receiver is expected to be able to receive and convert the binary object into an XML file but the sender can not expect the receiver to view or process the content of that XML file. Any further handling of an embedded XML file attachment is optional for the receiver.

If payment is made by credit transfer, the Payment account identifier (IBT-84) is mandatory

Examples of codes for payment by credit transfer are:

If the Buyer had opted to pay by using a payment card such as a credit or debit card, information on the Primary Account Number (PAN) shall be present in the invoice.

Examples of codes for payment by card are:

If payment is made by the GIRO-system (direct debit)

PaymentTerms/Note can be used to indicated additional information about payment date.

If payment is made by DuitNow

PaymentTerms/Note can be used to indicated additional information about payment date.

If payment is made by FPX

PaymentTerms/Note can be used to indicated additional information about payment date.

If payment is made by JomPay

PaymentTerms/Note can be used to indicated additional information about payment date.

If payment is made by MyDebit

PaymentTerms/Note can be used to indicated additional information about payment date.

RENTAS stands for Real Time Electronic Transfer of Funds and Securities.

If payment is made by MyDebit

PaymentTerms/Note can be used to indicated additional information about payment date.

TT is an electronic method of transferring funds used primarily for overseas wire transactions.

If payment is made by TT

PaymentTerms/Note can be used to indicated additional information about payment date.

In an invoice line the seller item identifier, the buyer item identifier and the standard item identifier can be provided. For sellers and buyers item identifiers, no scheme attribute is used, whilst the schemeID is mandatory for the standard item identification, and must be from the ISO 6523 ICD list.

Several different item classification codes can be provided per invoice line, and the codes must be from one of the classification schemes in code list UNCL7143.

The Seller TAX identifier (ibt-031) / (ibt-032) should be used for these purposes:

Where the business is not registered for SST, input NA.

The Buyer tax identifier (ibt-048) should be used for the Buyer’s SST registration number (e.g., B01-2345-67891012). Where the Buyer is not registered for SST, Seller to input NA.

A MY e-Invoice can have variations (e.g. some items subject to varying SST rates while others exempt from SST, some items subject to a percentage tax rate while others subject to a fixed tax amount). This can be handled at line item level and document level, depending on exempted products.

Each document level charge or allowance must have a document level allowance tax category code (ibt-095) or a document level charge tax category code (ibt-102), and for all tax categories other than 'O' (outside the scope of tax) the tax rate shall be provided.

Note that sales tax and service tax invoice requirements listed below are non-exhaustive and may be subject to change. In the event of any conflict or ambiguity, latest tax legislation and guidance from the Royal Malaysian Customs Department (RMCD) should take precedence. For more information on SST invoice requirements, please refer to RMCD guidance at https://mysst.customs.gov.my/GeneralGuide.

Every person registered for service tax has a statutory obligation to issue an invoice for any provision of taxable services, unless approval by the Director General to not issue an invoice is obtained. The invoice issued must comply with the following requirements:

Note that TTx invoice requirements listed below are non-exhaustive and may be subject to change. In the event of any conflict or ambiguity, latest tax legislation and guidance from the Royal Malaysian Customs Department (RMCD) should take precedence. For more information on TTx invoice requirements, please refer to RMCD guidance at https://www.myttx.customs.gov.my/legislation-guides-forms/.

Every operator registered for TTx is statutorily obligated to issue an invoice, receipt or other document (other document includes local order and statement of account) to the tourist in respect of the accommodation provided. The invoice issued must comply with the following requirements:

Formulas for the calculations of totals are as follows:

The following elements show the legal monetary totals for an invoice or credit note

Allowance and charge on document- and line level consists of elements carrying information on the allowance/charge base amount and the allowance/charge percentage. These are, if present in the invoice instance, used for calculating the allowance/charge amount.

If base amount is present, the percentage shall also be present, and if percentage is present, the base amount shall also be present, and the calculation of the amount shall be:

A maximum of two digits are allowed for the following amounts in an invoice.

The tax rate and tax category tax amount shall be zero for tax categories that are not subject to tax (i.e. O - ‘Outside scope of tax’ or E - ‘Exempt from tax’). A MY invoice may include a mixture of different tax categories, e.g. some invoice items are subject to general rate (i.e. tax category code is "T" with applicable tax rate or tax amount), while other items may be tax exempt (i.e. tax category code is "E", tax rate is 0%).

MY e-Invoices that contain amounts with a tax category of 'O' (Outside the scope of tax):

One Tax breakdown (ibg-23) shall be provided for each distinct combination of Tax category code and Tax rate found in either the line tax information or the Document level allowance or charge. For each distinct combination of tax category code and tax rate the calculations are:

UBL example of calculations of Tax Breakdown

Incorrect tax amounts can be amended by cancelling the invoice (through a Credit Note or negative invoice) and issuing a new invoice with the correct tax, or issuing a new invoice that effectively cancels the prior and charges the correct tax amount. See example below of an invoice which has previously been issued with an incorrect tax category (e.g. ‘E’ Exempt from tax when it should have been ‘T’ Teneral rate) – a subsequent invoice could be issued with a line reversing the incorrect charge and tax and adding a line with the correct values:

UBL example of calculations for amending tax amounts:

Arithmetic calculation forms part of IRBM’s e-Invoice validation criteria. IRBM will check and verify that the numerical values within the invoice (e.g. totals, subtotals and taxes are mathematically accurate). For more information on IRBM’s calculation validation criteria, please refer to the latest IRBM e-Invoice Guideline and Specific Guideline: https://www.hasil.gov.my/en/e-invoice/guidelines/.

All messages contains Business process type (IBT-23) and Specification identifier (IBT-24). Business process type (IBT-23) identifies what business process a given message is part of, and Specification identifier (IBT-24) identifies the kind of message and the rules applied.

Profiles are connected to one business process, and may contain multiple document types. Valid document instances shall contain corresponding Business process type (IBT-23) and Specification identifier (IBT-24).

In the table below you will find the values to be used as the specification identifier (IBT-24) and the business process type (IBT-23) for this profile

In the customization element the specialization is a short id that indentifies the specialization. As example my-1 is for the Malaysian self billing invoice, where -1 is a versioning number for the specialization.

Prior to 15 May 2025, exact match receiving capabilities will continue to use the busdox-docid-qns Document Type Identifier scheme. After 15 May 2025, exact match receiving capabilities will migrate to using the peppol-doctype-wildcard Document Type Identifier scheme, in accordance with the Peppol Policy for use of identifiers v4.3.0 migration plan.

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO15000, Annex A.

The different semantic data types are described in the tables below, where various features such as attributes, format, and decimals as well as the basic type are defined for each semantic data type. They are based on {ISO15000}.

When used in an instance of an invoice, each data element will contain data. In the below tables this is identified as the “content”. Whenever a business term is used this term shall always have content and therefore the content is always mandatory.