Tag: Year 2024

⚠️ 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）。

The change from “real-time or near real-time validation” to “near real-time validation” seems to be providing more flexibility and clarity on the timing of the e-Invoice validation process.

“Near real-time validation” implies that the validation happens very quickly after submission but not necessarily instantaneously.

从 “实时或近实时验证 “到 “近实时验证 “的变化似乎为电子发票验证过程的时间安排提供了更大的灵活性和清晰度。

“近实时验证 “意味着验证在提交后很快进行，但不一定是即时进行。

By changing it to “near real-time validation”, it opens up the possibility that the validation could happen either:

1) In real-time – meaning instantaneously or with an imperceptible delay upon submission of the e-Invoice.

2) Or in near real-time – meaning with a slight delay, but still very quickly after submission.

The key impact and reason for this change is to account for the fact that while the system aims for real-time validation, there may be instances where due to high volumes or other factors, the validation may not be truly instantaneous but still extremely fast (near real-time).

This phrasing provides more accurate expectations and covers both the ideal real-time scenario as well as any instances where there is a slight delay but still very rapid validation occurring.

It gives the e-Invoicing system a bit more flexibility in terms of managing volumes and loads, while still committing to a highly efficient and prompt validation process – either real-time or as close to real-time as possible.

So in summary, it is a minor change to set appropriate expectations and provide a small buffer, in case rare scenarios arise where validations cannot be precisely real-time but still occur almost instantaneously after submission.

从 “实时或近实时验证 “到 “近实时验证 “的变化似乎为电子发票验证过程的时间安排提供了更大的灵活性和清晰度。

“近实时验证 “意味着验证在提交后很快进行，但不一定是即时进行。

将其改为 “近乎实时验证 “后，验证就有可能在以下两种情况下进行：

1) 实时–即在提交电子发票时立即进行或有不易察觉的延迟。

2) 或接近实时–即在提交后稍有延迟，但仍然很快。

这一改动的主要影响和原因是，虽然系统的目标是实时验证，但在某些情况下，由于工作量大或其他因素，验证可能无法真正做到即时，但仍然非常快（接近实时）。

这种措辞提供了更准确的预期，既包括理想的实时情况，也包括稍有延迟但仍能快速验证的任何情况。

它使电子发票系统在管理数量和负载方面有了更大的灵活性，同时仍致力于高效、迅速的验证过程–实时或尽可能接近实时。

因此，总的来说，这只是一个小的改动，目的是设定适当的期望值，并提供一个小的缓冲区，以防出现无法精确实时验证但在提交后仍几乎即时验证的罕见情况。

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

Based on the comparison between the e-Invoice Specific Guideline Version 2.0 and Version 2.1, one of the key changes is Section 3.6.4, a new addition stating that to improve the MyInvois System’s performance, there are limitations on the maximum size (5MB) and number (100) of e-Invoices per submission and the maximum size per e-Invoice (300KB) for the submission of the consolidated e-Invoices.

Suppliers can split receipts into several consolidated e-Invoices to meet these requirements.

根据电子发票具体指南 2.0 版和 2.1 版的比较，其中一个主要变化是第 3.6.4 节新增加的内容，即为了提高 MyInvois 系统的性能，对每次提交的合并电子发票的最大大小（5MB）和数量（100）以及每张电子发票的最大大小（300KB）都有限制。

供应商可将收据分拆为多份合并电子发票，以满足这些要求。

Below is a structured outline for e-commerce transactions, specifically focusing on the issuance of e-invoices by e-commerce platform providers, as per the E-INVOICE SPECIFIC GUIDELINE (VERSION 2.0).

以下是根据《电子发票专用指南》（2.0 版）编写的电子商务交易结构大纲，特别侧重于电子商务平台提供商开具电子发票。

E-Commerce Transactions & E-Invoice Issuance

电子商务交易与电子发票开具

🔴 Part 1: Introduction to E-Commerce Transactions

Definition: E-commerce transactions refer to the sale or purchase of goods or services conducted over a platform designed specifically for order placement or receipt. Notably, the actual payment and delivery of goods or services may not be conducted online.

Participants: These transactions can involve a variety of parties including businesses, households, individuals, governments, and other organisations.

第 1 部分：电子商务交易简介

定义： 电子商务交易是指通过专门为下订单或接收订单而设计的平台进行商品或服务的销售或购买。值得注意的是，实际付款和货物或服务的交付可能不在网上进行。

参与者： 这些交易可能涉及企业、家庭、个人、政府和其他组织等各方。

🔴 Part 2: Role of E-Commerce Platform Providers

Key Responsibility: E-commerce platform providers are tasked with issuing invoices, bills, or receipts to record transactions.

Upon implementing e-invoicing, they must issue either an e-invoice upon the purchaser’s request or a receipt if no e-invoice is requested.

第 2 部分：电子商务平台提供商的作用

主要责任： 电子商务平台提供商的任务是开具发票、账单或收据以记录交易。

在实施电子发票后，他们必须根据购买者的要求开具电子发票，如果没有要求开具电子发票，则必须开具收据。

🔴 Part 3: E-Invoice Issuance Process

Process Overview: Merchants or service providers on the e-commerce platform are not required to issue e-invoices or receipts directly to purchasers.

This responsibility falls on the e-commerce platform providers.

Required Information: The e-Invoice must include specific data fields as outlined in Appendices 1 and 2 of the e-Invoice Guideline, ensuring comprehensive transaction details.

第 3 部分：电子发票开具流程

流程概述： 电子商务平台上的商家或服务提供商无需直接向购买者开具电子发票或收据。

这一责任由电子商务平台提供商承担。

所需信息： 电子发票必须包括《电子发票指南》附录 1 和附录 2 中列出的特定数据字段，确保提供全面的交易详情。

🔴 Part 4: Consolidated E-Invoice

Special Consideration: For consolidated e-invoices, e-commerce platform providers must complete the required fields and certain transaction details, as the guideline specifies.

第 4 部分：合并电子发票

特别注意事项：对于合并电子发票，电子商务平台提供商必须填写必填字段和某些交易详情、 特别注意事项：对于合并电子发票，电子商务平台提供商必须填写指引中规定的必填项和某些交易细节。

🔴 Part 5: e-commerce transactions between platform providers and merchants or service providers

The process involves the e-commerce platform provider issuing self-billed e-invoices to the merchant or service provider upon the conclusion of a sale or transaction on the platform.

This is a critical aspect concerning the financial transactions and record-keeping between the two parties involved.

Upon concluding a sale or transaction on the e-commerce platform, the merchant and/or service provider is eligible to receive payment from the e-commerce platform provider for the goods sold and/or services performed.

In this scenario, the e-commerce platform provider assumes the role of the buyer, and the merchant or service provider assumes the role of the supplier.

The e-commerce platform provider is then responsible for issuing a self-billed e-invoice to the merchant and/or service provider for all transactions concluded on the e-commerce platform.

For the issuance of these self-billed e-Invoices, the e-commerce platform provider must input specific details such as the merchant or service provider’s business or residential address, contact number, and, where available, email address. If such information is unavailable or not provided, the platform provider must input “NA” in the respective fields.

This structured approach to issuing self-billed e-invoices facilitates a clear and transparent financial relationship between e-commerce platform providers and merchants or service providers, ensuring that all transactions are properly documented in compliance with relevant guidelines and regulations.

第 5 部分：平台提供商与商家或服务提供商之间的电子商务交易

这一过程涉及电子商务平台提供商在平台上完成销售或交易后向商户或服务提供商开具自开电子发票。

这是一个关键环节，因为它关系到所涉双方之间的金融交易和记录保存。

在电子商务平台上完成销售或交易后，商家和/或服务提供商有资格从电子商务平台提供商处收到所售商品和/或所提供服务的付款。

在这种情况下，电子商务平台提供商扮演买方角色，商家或服务提供商扮演供货方角色。

然后，电子商务平台提供商负责就电子商务平台上达成的所有交易向商家和/或服务提供商开具自开电子发票。

为开具这些自开电子发票，电子商务平台提供商必须输入具体信息，如商家或服务提供商的营业地址或住宅地址、联系电话以及电子邮件地址（如有）。如果没有或未提供这些信息，平台提供商必须在相应字段中输入 “NA”。

这种结构化的电子发票开具方式有助于电子商务平台提供商与商家或服务提供商之间建立清晰透明的财务关系，确保所有交易都有适当的文件记录，符合相关准则和规定。

🔴 Part 6: Issuance of e-Invoice from e-commerce platform provider to Merchant and/or Service Provider

Furthermore, e-commerce platform providers also charge merchants and/or service providers for using the platform.

Upon implementing an e-invoice, the e-commerce platform provider is responsible for issuing an e-invoice for the charges imposed on the merchant and/or service provider for using the platform.

This ensures that all financial transactions and charges associated with using the e-commerce platform are accurately documented and invoiced.

第 6 部分：电子商务平台提供商向商家和/或服务提供商开具电子发票

此外，电子商务平台提供商还向商户和/或服务提供商收取平台使用费。

实施电子发票后，电子商务平台提供商负责就商家和/或服务提供商使用平台的费用开具电子发票。

这可确保与使用电子商务平台相关的所有金融交易和费用都有准确的记录和发票。

Based on the guidelines and the scenario provided (Example 1), it appears that issuing a refund note e-Invoice by Mr. Jamal to document the refunded amount for the faulty chairs directly addresses the situation without the need for a separate credit note.

The refund note e-Invoice serves the dual purpose of documenting the refund and making the necessary adjustment to the original transaction value.

In this context, the refund note e-Invoice effectively reduces the value of the original e-Invoice by the amount refunded for the returned goods.

This approach simplifies the process by directly adjusting the original transaction’s value to reflect the return and refund in a single step.

Therefore, issuing a separate credit note before the refund note e-Invoice would not be necessary unless there was a specific requirement or scenario not covered in the provided example.

The key distinction here is that the refund note e-Invoice is used when there is an actual return of monies to the buyer, as opposed to a credit note which is typically used to adjust the value of transactions without a direct refund.

Since the scenario explicitly involves a refund for the faulty chairs, the use of a refund note e-Invoice is appropriate and aligns with the guidelines for handling such transactions.

However, most accounting software may require the taxpayer to issue a credit note first, subsequently followed by a refund note if the buyer requests for a refund, even though issuing a separate credit note before the refund note e-Invoice would not be necessary based on the e-Invoicing guidelines.

根据电子发票指南和里面所提供的例子（例子1）， Jamal 先生开具退款单电子发票 (Refund Note e-invoice) 来记录故障椅子的退款金额似乎可以直接解决这种情况，而无需单独开具贷记凭证 (Credit Note)。

退款凭证电子发票 (Refund Note e-invoice) 在这里，具有双重用途，既可记录退款，又可对原始交易价值进行必要的调整。

在这种情况下，退款通知单电子发票可有效地将原始电子发票的价值减去退回货物的退款金额。

这种方法简化了流程，只需一步即可直接调整原始交易价值，以反映退货和退款情况。

因此，除非有特殊要求或示例中未涉及的情况，否则没有必要在退款单电子发票之前单独开具贷方通知单。

这里的关键区别在于，退款凭证电子发票 (Refund Note e-invoice) 用于向买方实际退还款项，而贷记通知单 (Credit Note) 通常用于调整交易价值，不直接退款。

由于这种情况明确涉及对故障椅子的退款，因此使用退款通知单电子发票是合适的，也符合处理此类交易的指南。

然而，大多数会计软件可能会要求纳税人先开具贷记凭证 (Credit Note)，然后在买方要求退款时再开具退款凭证电子发票 (Refund Note e-invoice) ，尽管根据电子发票指南，在开具退款凭证电子发票 (Refund Note e-invoice) 之前是没有必要开具单独的贷记通知单 (Credit Note)。

This question about e-invoices is one that many people want to know: Can self-billed e-invoices be consolidated?

The E-INVOICE SPECIFIC GUIDELINE (VERSION 2.1) answers but needs to say how to do it. I believe the SDK will explain it.

My view is, the primary reason for permitting consolidation in these specific circumstances could be to provide flexibility to taxpayers and reduce the administrative burden of submitting self-billed e-Invoices for validation on a day-to-day basis. Instead, taxpayers can consolidate these transactions and submit a consolidated self-billed e-invoice once a month.

However, it’s crucial to note that while the consolidated self-billed e-Invoice may be submitted to the LHDN on a monthly basis, it is likely that LHDN will still require taxpayers to include all the relevant details of the individual transactions in the consolidated e-Invoice. This would ensure that LHDN has access to the necessary information for each transaction, even if they are consolidated into a single e-invoice.

By providing these details in the consolidated self-billed e-invoice, taxpayers would maintain transparency and enable the tax authorities to verify the accuracy of the consolidated amount and cross-reference it with other available information.

It’s important to wait for more announcements and clarifications from LHDN regarding the specific requirements and format for consolidated self-billed e-invoices.

Once LHDN provides more detailed guidelines, taxpayers will have a clearer understanding of the information they need to include in these consolidated e-invoices and can ensure compliance accordingly.

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

这个有关电子发票的问题，很多人都想知道：那就是就是 self-billed e-invoice 可以 consolidate?

E-INVOICE SPECIFIC GUIDELINE (VERSION 2.1) 给出了答案，但是具体怎样操作，却没说。相信应该会在 SDK 说明。

我认为，允许在这些特定情况下合并交易的主要原因可能是为纳税人提供灵活性，并减轻日常提交自行开具的电子发票 (self-billed e-invoices) 以进行验证的行政负担。相反，纳税人可以合并这些交易，每月提交一次合并的自开票电子发票。

不过，值得注意的是，虽然纳税人可每月向税务局提交合并开具的电子发票，但税务局可能仍会要求纳税人在合并电子发票中提供个别交易的所有相关细节。此举可确保食环署能取得每宗交易的所需资料，即使这些交易已合并成单一的电子发票。

通过在合并自开票电子发票中提供这些详细信息，纳税人将保持透明度，并使税务局能够核实合并金额的准确性，并与其他可用信息相互参照。

关于合并自开票电子发票的具体要求和格式，重要的是等待 LHDN 的进一步公告和澄清。

一旦 LHDN 提供更详细的指南，纳税人就能更清楚地了解他们需要在这些合并电子发票中包含的信息，并确保遵守相应的规定。