Tag: 1. Tax

The e-Invoicing Guidelines in Malaysia are a comprehensive framework designed to modernise and streamline the invoicing process across various transactions, enhancing efficiency and tax compliance.

The guidelines cover myriad transactions and touch upon the specific income types exempted from the e-invoicing system.

For directors who have entered into a contract for services with a company, issuing an e-invoice for any income received is mandatory, reflecting the transaction’s commercial nature.

Conversely, directors’ fees from a service contract viewed as employment income are currently exempt from the e-invoicing requirement.

This distinction underscores the importance of understanding the nature of the contractual relationship and the corresponding e-invoicing obligations.

Taxpayers, especially those in directorial positions, are advised to stay informed about their e-invoicing responsibilities and any potential changes to exemptions, as guidelines are subject to periodic reviews and updates by the relevant authorities.

🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻

马来西亚电子发票指南是一个全面的框架，旨在更新和简化各种交易的发票开具流程，提高效率和税务合规性。

在其涵盖的众多交易中，该指南还涉及电子发票系统豁免的特定收入类型。

对于已与公司签订服务合同的董事，必须为收到的任何收入开具电子发票，以反映交易的商业性质。

相反，董事从雇佣合同中获得的酬金被视为就业收入，目前则不受电子发票要求的限制。

这种区别强调了了解合同关系性质和相应电子发票义务的重要性。

建议纳税人，特别是那些担任董事职务的纳税人，需要了解他们的电子发票责任以及豁免方面的任何潜在变化，因为有关当局会定期审查和更新准则。

Referring to Section 2.4.5 of the e-Invoice Guideline Version 2.3:

“If the Supplier did not accept the request for rejection initiated by the Buyer (or did not proceed to cancel the said e-Invoice), no cancellation would be allowed after the 72 hours have elapsed.

Any amendment thereon would require issuing a new e-invoice (e.g., credit note, debit note or refund note e-invoice).”

根据电子发票指南第2.4.5节：

“供应商没有接受买方发起的拒绝请求（或未取消该电子发票），在72小时过去后将不允许取消。

此后的任何修改都需要发行新的电子发票（例如，贷项通知、借项通知或退款通知电子发票）。 ”

2.3.2 Step 1 – Creation and Submission

The change from “Batch Generation” to “Batch Upload” and from “defined layout file” to “pre-defined Microsoft Excel spreadsheet” in section 2.3.2 is likely to provide more clarity and specificity on the batch submission process via the MyInvois Portal.

📌 Batch Generation:

✅ This term is a bit vague and could be interpreted differently.

✅ It doesn’t specify the method or format for generating batches of e-invoices.

📌 Batch Upload:

✅ “Upload” is a more specific term that clearly indicates the action of transferring a file/data from the user’s system to the MyInvois Portal.

✅ It removes any ambiguity and makes it evident that batches of e-invoices are submitted to the portal through a file upload process.

📌 Defined Layout File:

✅ “Layout file” is a generic term that could refer to various file formats or structures.

✅ It lacks specificity on the exact file type and format expected for batch submissions.

📌 Pre-defined Microsoft Excel Spreadsheet:

✅ By explicitly mentioning “Microsoft Excel spreadsheet”, it provides clear guidance on the specific file format that is accepted for batch uploads.

✅ “Pre-defined” indicates that there is a predefined template or structure that users must follow when preparing the Excel file.

✅ This level of detail helps users understand exactly what is required for batch uploads, reducing confusion and ensuring compliance with the expected file format.

So, in essence, the changes were likely made to:

1) Use more precise terminology that accurately reflects the process (“Upload” instead of “Generate”).

2) Provide clear and specific information about the accepted file format (Microsoft Excel spreadsheet instead of a generic “layout file”).

3) Indicate that there is a predefined template/structure to follow for batch uploads (pre-defined Excel spreadsheet).

By making these changes, the guideline aims to give taxpayers and users more explicit and unambiguous instructions on correctly preparing and submitting batches of e-Invoices via the MyInvois Portal, minimising potential confusion or errors in the process.

将第 2.3.2 节中的 “批量生成 “改为 “批量上传”，并将 “设定的版式文件 “改为 “预 定义的 Microsoft Excel 电子表格”，可能会使通过 MyInvois 门户网站进行批量提交的 流程更加清晰和具体。

📌 批量生成：

✅ 这个术语有点模糊，可以有不同的解释。

✅ 它没有说明生成成批电子发票的方法或格式。

📌 批量上传：

✅ “上传”是一个更具体的术语，它明确指出了将文件/数据从用户系统传输到 MyInvois 门户网站的操作。

✅ 它消除了任何歧义，并清楚地表明电子发票批次是通过文件上传流程提交到门户网站的。

📌 设定的版式文件：

✅ ”设定文件” 是一个通用术语，可以指各种文件格式或结构。

✅ 它没有具体说明批量提交所需的确切文件类型和格式。

📌 预先设定的 Microsoft Excel 电子表格：

✅ 通过明确提及 “Microsoft Excel 电子表格”，为批量上传所接受的特定文件格式提供了明确的指导。

✅ “预先设定”表示用户在准备 Excel 文件时必须遵循预定义的模板或结构。

✅ 这种详细程度有助于用户准确了解批量上传的要求，减少混乱并确保符合预期的文件格式。

因此，从本质上讲，这些更改可能是为了

1) 使用更精确的术语，准确反映流程（用 “上传 “代替 “生成”）。

2) 提供有关可接受的文件格式的明确而具体的信息（Microsoft Excel 电子表格，而不是通用的 “设定的版式文件”）。

3) 说明批量上传有预定义模板/结构可循（预先设定 Excel 电子表格）。

通过这些改动，该指南旨在为纳税人和用户提供更清晰明确的指导，说明如何通过 MyInvois 门户网站正确准备和提交电子发票批次，最大限度地减少过程中可能出现的混乱或错误。

2.3.3 Step 2 – e-Invoice Validation

The change in section 2.3.3 between versions 2.2 and 2.3 is:

Version 2.2:

“The validated e-Invoice will include, the IRBM Unique Identifier Number, date and time of validation, and validation link.”

Version 2.3:

“The IRBM Unique Identifier Number, date and time of validation, and validation link will be assigned to the validated e-Invoice.”

So the change is from stating that the validated e-invoice “will include” those details to saying they “will be assigned to” the validated e-invoice.

This is a minor phrasing change, but it slightly alters the meaning. Version 2.3 clarifies that the IRBM Unique Identifier Number, date/time, and validation link are assigned or added to the e-invoice upon validation rather than already included in the original e-invoice submitted.

The rationale could be to make it clear that these validation-related details are dynamically assigned by IRBM during the validation process rather than being pre-existing elements in the e-Invoice created by the supplier.

在 2.3.3 节中，2.2 版和 2.3 版之间的变化如下：

版本 2.2：

“经过验证的电子发票将包括 IRBM 唯一标识符编号、验证日期和时间以及验证链接。

版本 2.3：

“IRBM 唯一标识符号码、验证日期和时间以及验证链接将分配给已验证的电子发票”。

因此，这一改动是将 “将包括 “验证过的电子发票的细节改为 “将分配给 “验证过的电子发票。

这只是措辞上的微小改动，但却略微改变了含义。2.3 版明确指出，IRBM 唯一标识符号码、日期/时间和验证链接将在验证时分配或添加到电子发票中，而不是已经包含在提交的原始电子发票中。

这样做的理由可能是为了明确这些与验证有关的细节是由 IRBM 在验证过程中动态分配的，而不是供应商创建的电子发票中预先存在的元素。

🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻

The Inland Revenue Board of Malaysia (IRBM) has expanded the scope of e-invoicing to include additional document types beyond the initial Invoice, Credit Note, Debit Note, and Refund Note.

This extension aims to provide comprehensive coverage and facilitate seamless e-invoicing operations across various business scenarios.

In addition to the existing document types, businesses can now leverage the following e-Invoice formats within the MyInvois System:

1. Self-Billed Invoice

2. Self-Billed Credit Note

3. Self-Billed Debit Note

4. Self-Billed Refund Note

These new document types cater to specific situations where the Buyer assumes the role of the Supplier and issues self-billed e-invoices, as outlined in Section 8 of the e-invoice Specific Guideline.

By incorporating these additional formats, the MyInvois System empowers businesses with greater flexibility and compliance across diverse transaction scenarios.

Self-Billed Invoice

There are certain circumstances where another party (other than the Supplier) will be allowed to issue a self-billed e-Invoice.

Kindly refer to Section 8 of the e-Invoice Specific Guideline where self-billed e-Invoice will be allowed.

Self-Billed Invoice refers to the initial self-billed e-Invoice that will be issued by the Buyer.

Self-Billed Credit Note

Self-Billed Credit Note is issued by Buyers to correct errors, apply discounts, or account for returns in a previously issued Self-Billed e-Invoice with the purpose of reducing the value of the original Self-Billed e-Invoice.

This is used in situations where the reduction of the original Self-Billed e-Invoice does not involve return of monies to the Buyer.

Self-Billed Debit Note

Self-Billed Debit Note is the document issued by Buyers to indicate additional charges on a previously issued Self-Billed e-Invoice.

Self-Billed Refund Note

Self-Billed Refund Note is the document issued by Buyers to confirm the refund of the Buyer’s payment. This is used in situations where there is a return of monies to the Buyer.

🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻

马来西亚税务局（IRBM）扩大了电子发票的范围，除最初的发票、贷方凭证、借方凭证和退款凭证外，还增加了其他文件类型。

这一扩展旨在提供全面的覆盖范围，并促进各种业务情况下的无缝电子发票操作。

除了现有的文件类型，企业现在还可以在 MyInvois 系统中使用以下电子发票格式：

1. 自开发票

2. 自开贷记凭证

3. 自开借记凭证

4. 自开退款凭证

这些新文件类型适用于买方扮演供应商角色并开具自开票电子发票的特定情况，如电子发票特定指南第 8 节所述。

通过纳入这些附加格式，MyInvois 系统为企业在各种交易场景中提供了更大的灵活性和合规性。

自开发票

在某些情况下，允许另一方（供应商除外）开具自开电子发票。

请参阅《电子发票具体指引》第 8 节中允许开具自开电子发票的内容。

自开贷方凭证 

买方开出 “自开贷方凭证 “是为了纠正之前开出的 “自开电子发票 “中的错误、应用折扣或说明退货情况，目的是减少原始 “自开电子发票 “的价值。

在减少原始自开电子发票金额不涉及向买方退还款项的情况下使用。

自开借方凭证

自开借方凭证是买方开出的单据，用于注明先前开出的自开电子发票上的额外费用。

自开退款凭证

自开退款凭证是由买家开出的文件，用于确认买家付款的退款。用于向买方退还款项的情况。

The “Classification Code” is a mandatory field in e-Invoices that categorizes the nature of the transaction or the types of products/services involved.

IRBM requires this code to facilitate the analysis and monitoring of various transactions for tax purposes.

The classification codes cover a wide range of items and scenarios, from common expenses like medical treatments and educational fees to specific transactions like consignment sales, self-billed invoices for imports/exports, and even categories like breastfeeding equipment or sports-related purchases.

By requiring businesses to assign the appropriate classification code, IRBM can gain valuable insights into spending patterns, identify potential areas of tax leakage or non-compliance, and make informed decisions regarding tax policies and administration.

For taxpayers, using the correct classification code ensures accurate reporting and compliance with e-invoicing requirements while enabling IRBM to streamline its processes and enhance tax collection and monitoring efficiency.

Therefore, taxpayers must familiarise themselves with the classification codes and select the most relevant option that accurately represents the nature of their transaction. This ensures compliance and contributes to the effectiveness of IRBM’s tax administration efforts.

🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻

“类别代码” (Classification Code) 是电子发票中的必填字段，用于对交易性质或所涉及的产品/服务类型进行分类。

IRBM 要求使用该代码，以便于分析和监控各种交易的税务目的。

类别代码涵盖广泛的项目和情况，从医疗和教育费用等常见支出，到寄售、进口/出口自开票等特定交易，甚至哺乳设备或体育相关采购等类别。

通过要求企业指定适当的分类代码，IRBM 可以深入了解消费模式，识别潜在的漏税或不合规领域，并就税收政策和管理做出明智决策。

对纳税人而言，使用正确的类别代码可确保准确报告和遵守电子发票要求，同时还能使 IRBM 简化流程，提高税收征管和监控的整体效率。

因此，纳税人必须熟悉分类代码，并选择最相关的选项，以准确反映其交易的性质。这不仅能确保纳税人遵守规定，还有助于提高 IRBM 税收管理工作的效率。

⚠️ 2.4.3 Step 2 – e-Invoice Validation

The change in section 2.4.3 between versions 2.2 and 2.3 is related to how the details of the API response after successful e-invoice validation are presented.

Version 2.2:

“Once validated by the MyInvois System (which is done in near real-time), the Supplier or technology provider (if the Supplier utilises a technology provider) will receive an API response with the following information:

(a) the IRBM Unique Identifier Number from IRBM;

(b) date and time of validation, and

(c) validation link,

via API.”

Version 2.3:

“Once validated (which is done in near real-time), the Supplier or technology provider (if the Supplier utilises a technology provider) will receive an API response which contains the following:

(a) the IRBM Unique Identifier Number from IRBM;

(b) date and time of validation, and

(c) information to form validation link (please refer to Get Recent Documents / Get Document / Get Documents Details in the SDK for guidance),

via API.”

The changes are:

1. Removed “with the following information” after “API response”.

2. Changed “validation link” to “information to form validation link (please refer to Get Recent Documents / Get Document / Get Documents Details in the SDK for guidance)”.

The rationale for these changes could be:

1. Removing “with the following information” makes the sentence more concise.

2. Changing “validation link” to “information to form validation link” clarifies that the API response does not directly provide the complete validation link, but rather the necessary information to construct the validation link.

3. The addition “(please refer to Get Recent Documents / Get Document / Get Documents Details in the SDK for guidance)” provides users with a reference to the specific SDK sections that will guide them on how to use the information provided in the API response to properly form the validation link.

This change aims to provide more precise information about the API response content and direct users to the relevant SDK documentation for guidance on constructing the validation link using the information received.

Overall, it clarifies that the API response gives the necessary pieces of information, but users need to refer to the SDK for specific instructions on how to utilise that information to build the complete validation link URL or endpoint.

第 2.4.3 节中 2.2 版和 2.3 版之间的改动涉及如何显示电子发票验证成功后的 API 响应详情。

版本 2.2：

“一旦通过 MyInvois 系统验证（几乎实时完成），供应商或技术提供商（如果供应商使用技术提供商）将收到包含以下信息的 API 响应：

(a) 来自IRBM的IRBM唯一识别码；

(b) 验证日期和时间，以及

(c) 验证链接;

通过应用程序接口（API）”。

2.3 版：

“一旦验证（近乎实时验证），供应商或技术提供商（如果供应商使用技术提供商）将收到包含以下内容的 API 响应：

(a) 来自 IRBM 的 IRBM 唯一标识符编号；

(b) 验证日期和时间；以及

(c) 形成验证链接的信息（请参阅 SDK 中的获取最新文件/获取文件/获取文件详细信息以获得指导）、

通过应用程序接口（API）”。

更改内容如下

1. 删除了 “API 响应 “后的 “以及以下信息”。

2. 将 “验证链接 “改为 “表单验证链接的信息（请参阅 SDK 中的获取最新文档/获取文档/获取文档详细信息以获得指导）”。

这些更改的理由可能是

1. 删除 “以及以下信息 “使句子更简洁。

2. 将 “验证链接 “改为 “形成验证链接的信息”，说明 API 响应并不直接提供完整的验证链接，而是提供构建验证链接的必要信息。

3. 增加”（请参阅 SDK 中的 “获取最新文档”/”获取文档”/”获取文档详细信息”，以获得指导）”，为用户提供 SDK 具体章节的参考，指导他们如何使用 API 响应中提供的信息来正确形成验证链接。

这一改动旨在提供有关 API 响应内容的更精确信息，并引导用户查看相关 SDK 文档，以获得使用收到的信息构建验证链接的指导。

总的来说，它说明了 API 响应提供了必要的信息，但用户需要参考 SDK 以获取具体说明，了解如何利用这些信息来构建完整的验证链接 URL 或端点。

⚠️ 2.4.4 Step 3 – Notification

The removal of the full paragraph explaining the Notification API details in section 2.4.4 could be due to a few potential reasons:

1. Simplification:

The paragraph provided quite detailed information about how the Notification API works, automatically triggering notifications to suppliers and buyers upon e-Invoice validation, and facilitating communication.

Removing this level of technical detail may have been done to simplify the guideline and make it more concise, especially if these specifics are already covered in the separate API documentation (SDK).

2. Avoiding redundancy:

If the Notification API functionality and workflow are already comprehensively documented in the Software Development Kit (SDK) or other technical resources provided to API users, the guideline may have aimed to avoid redundancy by simply referring API users to those dedicated resources.

3. Keeping the guideline focused:

The e-invoice Guideline is intended to provide an overview of the e-invoicing process, requirements, and timelines for taxpayers.

Removing granular API details could be a way to keep the guideline focused on the broader e-Invoicing aspects, rather than delving too deeply into API-specific technicalities.

Overall, the removal of this paragraph could be aimed at streamlining the guideline, avoiding redundancy with dedicated API documentation, maintaining a broader focus on e-Invoicing essentials, and allowing for potential future changes or updates to the Notification API without creating inconsistencies within the guideline itself.

删除第 2.4.4 节中解释通知 API 详情的完整段落可能有几个原因：

1. 简化：

该段提供了相当详细的信息，说明通知应用程序接口如何工作，如何在电子发票验证后自动触发通知供应商和买方，以及如何促进沟通。

删除这一级别的技术细节可能是为了简化指南，使其更加简洁，尤其是如果这些具体内容已在单独的 API 文档（SDK）中涵盖。

2. 避免冗余：

如果向 API 用户提供的软件开发工具包 (SDK) 或其他技术资源中已经全面记录了通知 API 的功能和工作流程，则该指南的目的可能是避免冗余，只需将 API 用户引向这些专用资源即可。

3. 使指南重点突出：

电子发票指南旨在为纳税人提供有关电子发票流程、要求和时限的概述。

删除细粒度的 API 细节可使指南侧重于更广泛的电子发票方面，而不是过于深入地探讨 API 的具体技术问题。

总体而言，删除该段的目的可能是简化指南，避免专用 API 文档的冗余，保持对电子发票基本要素的更广泛关注，并允许未来对通知 API 进行可能的更改或更新，而不会造成指南本身的不一致。

🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻🌻

The removal of “Scholarship” from the list of exemptions in Section 1.6.8 of the e-Invoice Guideline Version 2.3 indicates that scholarships will now require the issuance of e-Invoices.

Potential Rationale:

The rationale for removing the scholarship exemption is to leverage the benefits of the e-invoicing system.

This system ensures better transparency and documentation of scholarship payments/disbursements, which can lead to more efficient financial management and reduced administrative burden.

By requiring e-invoices for scholarships, the issuing institutions (universities, organisations, etc.) must generate validated self-billed e-invoices for the scholarship amounts paid to students/recipients.

This allows for:

1) Proper recording and tracking of scholarship payments in the e-invoicing system.

2) Validation and authentication of scholarship e-invoices by IRBM.

3) Easier reporting and documentation for both the issuer and recipient.

4) Alignment with the overall move towards comprehensive e-Invoicing adoption.

e-Invoicing Impact:

1) Institutions/organisations issuing scholarships will now need to ensure their processes are updated to generate and issue self-billed e-Invoices for scholarship payments.

2) Students/recipients of scholarships should be prepared to receive self-billed e-Invoices instead of traditional documentation.

3) The self-billed e-Invoices received can serve as valid proof of scholarship income for students/recipients for tax purposes or other documentation needs.

4) Issuing institutions may need to make system changes, update templates, train staff, etc., to facilitate self-billed e-Invoice generation for scholarships.

5) There could be an initial transition period where some scholarship payments may still be documented through traditional means until the e-Invoicing process is fully adopted.

In summary, the removal of the scholarship exemption brings scholarship payments into the scope of e-Invoicing requirements, likely to improve transparency, documentation, and aligned with the overall digitalization of tax administration processes.

Here’s how the self-billed e-Invoicing process would work for scholarships:

For institutions/organisations issuing scholarships to students who do not run a business, the e-Invoicing process should be:

1) The institution/organisation would issue a self-billed e-Invoice treating the student as the “Supplier”.

2) In the self-billed e-Invoice, the student’s personal details (name, address, identification number) would go in the “Supplier” fields.

3) And the institution’s own details would go in the “Buyer” fields.

4) The description on the self-billed e-Invoice would be something like “Scholarship to [Student Name]”

5) The institution is essentially self-billing an e-invoice as if they are the “Buyer” by paying the scholarship amount to the “Supplier” (student).

《电子发票指南 2.3 版》第 1.6.8 节的豁免清单中删除了 “奖学金”，这表明奖学 金现在需要开具电子发票。

潜在理由：

取消奖学金豁免的理由是为了充分利用电子发票系统的优势。

该系统可确保奖学金支付/拨付的透明度更高，文件更完备，从而提高财务管理效率，减轻行政负担。

通过要求提供奖学金电子发票，发放机构（大学、组织等）必须为支付给学生/受助人的奖学金金额生成经过验证的自行开具的电子发票。

这样可以:

1) 在电子发票系统中正确记录和跟踪奖学金的支付情况。

2) IRBM 对奖学金电子发票进行验证和认证。

3) 为发放者和接受者提供更简便的报告和文件。

4) 与全面采用电子发票的整体行动保持一致。

电子发票的影响：

1) 发放奖学金的机构/组织现在需要确保更新其流程，以生成和开具自行开具的奖学金电子发票 （self-billed e-invoice）。

2) 奖学金的学生/受益人应准备好接收自行开具的电子发票（self-billed e-invoice），而不是传统的文件。

3) 学生/奖学金获得者收到的自行开具的电子发票（self-billed e-invoice）可作为奖学金收入的有效证明，用于纳税或其他文件需要。

4) 发放机构可能需要更改系统、更新模板、培训员工等，以方便为奖学金生成自开电子发票（self-billed e-invoice）。

5) 在完全采用电子发票程序之前，可能会有一个初始过渡期，在此期间，一些奖学金付款可能仍通过传统方式记录。

总之，取消奖学金豁免将奖学金支付纳入电子发票要求的范围，可能会提高透明度，改善文件记录，并与税收管理流程的整体数字化保持一致。

以下是奖学金自行开具电子发票（self-billed e-invoice）的流程：

对于向不经营企业的学生发放奖学金的机构/组织，电子发票开具流程应为：

1）机构/组织将开具自开票电子发票（self-billed e-invoice），将学生视为 “供应商”。

2）在自开电子发票（self-billed e-invoice）中，学生的个人资料（姓名、地址、身份证号码）将填入 “供应商 “栏。

3）机构的详细资料将填入 “买方 “字段。

4）自行开具的电子发票（self-billed e-invoice）上的描述应类似于 “给 [学生姓名] 的奖学金”。

5）从本质上讲，该机构是在向 “供应商”（学生）支付奖学金金额，从而以 “买方 “身份自行开具电子发票（self-billed e-invoice）。