电子发票指南
通过 MyInvois 向 LHDN 申报销售、通过 PEPPOL 网络递送单据所需的一切 —— 从首次设置，到您今后每个月都要执行的周期，再到出问题时会发生什么。本节的各篇指南目前只有英文版；这一页是中文的导览。
按下 Save 之后会发生什么
几乎每个电子发票问题，最后都是关于这张图的问题。您定稿（finalise）单据的那一刻，什么都没有发送：单据被放进队列，由后台作业负责分流、提交并取回 LHDN 的答复。单据停在哪里，就告诉您要修正什么。（图中文字为英文。）
一张单据要么是被扣留的 —— 因为缺了什么而停在三个池（pool）之一 —— 要么是在途的。被扣留的单据永远不会自己移动。
开始
第一次接触电子发票？有三个术语承担了这里所有指南的大部分工作，每个都在自己的短页上解释一次（英文）：consolidated e-invoices（合并电子发票） · pools and queues（池与队列） · validation and clearance（验证与清关）。每篇两分钟，之后下面的指南就不需要再定义任何东西。
然后按这个顺序读这三篇（英文）。
LHDN 会改写它的指引，一页写成时正确的规则，在您阅读时不一定还正确。本节每一句*“规则要求什么”*都是对照某一个具体的已发布版本核对的 —— 是哪个版本、每条规则在其中的位置，以及一个三十秒的检查，看 LHDN 是否已经更新（英文）。
设置包括：
- 在 MyInvois 门户上授权 BigLedger 作为您的电子发票中介
- 为每家公司开启电子发票，在定稿任何单据之前
- 您公司自己的身份资料 —— 税号、注册号、行业代码、地址、电话
- 客户和供应商的身份：税号、身份类型和号码，以及一个标记用于电子发票的地址
- 项目上的分类代码、计量单位和税务类型
每天
设置完成后，电子发票就融入您正常的销售和采购工作：
- 照常开立销售发票和贷项通知单。
- 定稿它们。BigLedger 不在您按下 Save 的那一刻提交 —— 定稿的单据被放进队列，由后台处理器发送。Save 之后的一切都在后台发生，这就是为什么您去找的那一秒，电子发票还不在 LHDN。
- 在 Internal Submission → To IRB E-Invoice 查看昨天单据的状态。
- 修正任何标为 Invalid 的单据并重新提交。 这就是整个每日循环，而且完全是关于您开出的单据。
采购一侧不是每日任务，也不是自动的。 核对您的采购背后是否有经过验证的供应商电子发票，是一项每月工作，其中有很大的手工部分：BigLedger 可以配对通过 PEPPOL 或 OCR 电邮接收渠道到达它的供应商单据，但一张已向 LHDN 申报、却以普通 PDF 发给您的供应商电子发票，不会被这个配对程序配对 —— 自 2026 年 9 月 28 日起，BigLedger 可以把这类单据获取到 External Reception → From IRB E-Invoice（中文界面为“外部接收 → 来自 IRB 电子发票”；由一个默认定时作业完成，截至 2026 年 10 月 4 日，它还没有在任何生产租户上产生过一行），而没有任何东西会把这个画面中的单据送进配对。
每周
三个池中有两个永远不会自己清空，而且没有任何池会为其中的行计算账龄，或在某行停留太久时提醒您 —— 所以除非您去看，否则没有任何东西告诉您它们正在积满。（有一封可选的电邮：一个定时作业可以把 Individual Pool 中最近一次尝试失败的行做成 CSV 发给公司。它按租户开启，不包括那些只是从未补全的行，Single General Pool 也没有对应的电邮。请问您的 BigLedger 联系人您是否有它；不要据此做计划。）
- 打开 Individual Pool 和 Single General Pool。每一行都是一笔您尚未申报的销售。去追买方的资料，或者把它移到仍然可以申报的地方。
- 在 Batch Pool 中筛选标为 processed / failed 的行。这些行被搁浅了：每月合并只会收走未处理的行。
每月
每月 1 日到 7 日是电子发票最忙的一周：上个月的合并电子发票必须在 7 日之前到达 LHDN，而所有失败的单据都必须在那之前找出并修正。
出问题时
最常出现的问题，以及各自的处理方法：
| 情况 | 实际发生了什么 | 如何处理 |
|---|---|---|
| 买方身份被拒 | 外国客户被当作马来西亚人输入、身份证号码带着连字符保存，或注册号填错了字段 | 公司（无论马来西亚或外国）用注册号；非马来西亚籍的个人用护照；身份证号码用 12 位数字、不带连字符 —— 在客户记录上修正，而不是在电子发票上 |
| 某行因代码被拒 | 不是税率，也不是空白字段 —— 空白的分类、单位或应税类型在任何检查之前就会替您填上，所以它们都不会被报告为缺失。被拒的是一个存在但错误的代码，尤其是单独电子发票上的分类 004 | 在项目上设置真实的分类代码；绝不在合并电子发票以外使用 004。应税类型不是您在提交时设定的 —— 它由该行的税额推导出来（如何推导，英文） |
| 缺少必填字段 | 单据从未提交；它停在某个池里 | 补全买方的税号、身份和地址，然后 Save 并 Resubmit |
| 一行从昨天起就没动过 | 它在队列中，而不是在重试 —— 停滞的行不会被自动重新拾起 | 选中它并按 Submit。如果同样的行再次停滞，请提出支持请求。每个状态的含义，以及何时等待（英文） |
| 同一笔销售在 LHDN 出现两次 | 有可能，也确实会发生 —— 但重复的单据号码更常见的是一张销售发票和一张自开采购发票共用了一个号码 | 通过对账找出真正的重复，而不是看 Submission History。72 小时内您可以取消其中一张；之后就只能开贷项通知单 |
| PEPPOL 单据被接收方拒绝 | 接收方的接入点拒收了这条消息 —— 最常见的是接收方没有为该单据类型注册，或者采购订单 / 销售订单号码没有作为订单参考带到发票上 | 确认接收方的参与者 ID，确保来源单据带有它的 PO 或 SO 号码，然后从 Internal Submission → Queue 重新发送 |
| 买方说他们拒绝了一张电子发票，但什么都没变 | 在 MyInvois 门户上（而不是通过 BigLedger 的买方门户）提出的拒绝，永远不会成为 BigLedger 中的拒绝请求；只有它的日期会在 BigLedger 下一次获取该电子发票详情时，被复制到电子发票的 IRB Reject Request Date 字段 | 自己在门户上查看这张电子发票，并在这里处理。请买方使用 BigLedger 门户，那样请求会出现在您的 Rejection Requests 列表中 |
报表
有三个地方告诉您目前的状况，而它们说的不一样：
- Internal Submission → To IRB E-Invoice —— 每张电子发票一行，显示实时的 LHDN 状态（Valid、Invalid、Submitted、IN_QUEUE）。需要工作清单时导出这一个。
- Internal Submission → Submission History —— 每次提交在发送那一刻的样子的存档。它不是当前状态，所以绝不要从这里筛选您的 Invalid 清单。
- Monthly Report → Discrepancies Report —— 按公司和期间，比较您定稿的单据与记录中的电子发票。这是您自助的对账。
值得养成的合规习惯：
- 在头几个月每天关注拒绝率。
- 保持客户和供应商的税号和身份类型干净 —— 这一组字段造成了大多数拒绝。
- 每个月在合并运行之前清空 Individual Pool。
- 在 7 日之前对账，而不是之后。
相关资源
以下页面目前只有英文版。
- My E-Invoice Admin Applet —— 每个电子发票画面的字段级参考
- My E-Invoice Portal Applet —— 您的买方能看到和请求什么
- My PEPPOL Admin Applet —— PEPPOL 队列和配置
- Sales Invoice Applet —— 销售电子发票从哪里开始
- Purchase Invoice Applet —— 同一条流水线的采购一侧
- E-Invoice & PEPPOL module —— 架构视角：谁做什么、涉及哪些小程序，以及上线清单