2026 马来西亚小额交易怎样做 Consolidated e-Invoice 月结
小额交易没有自动豁免。本文说明买方未索取 e-Invoice 时的每月合并流程、次月7天期限、RM10,000限制、收据状态、分行对账与逾期处理。
文章目录12 个段落
月底第一天,财务从 POS 导出两千多张收据。表格里有 RM8 的饮料,也有 RM6,800 的设备。几名顾客已经回来索取 individual e-Invoice(个别电子发票),其中一张收据被取消,另有一笔交易因买方资料错误仍未通过验证。
若财务只把所有金额加起来,再开一张 consolidated e-Invoice(合并电子发票),四类交易会一起进入 General Public。销售总额可能对得上,底下的交易状态已经错了。
小额交易的月结工作要先分流,再计算总额。金额小不会自动豁免 e-Invoice。买方没有索取、交易允许合并,而且没有被其他规则排除时,供应商才把普通收据纳入当月 consolidated。
已经有 POS 或收据明细,可以打开 Consolidated e-Invoice Monthly Close Report。工具会计算次月第七天、检查笔数和金额差异,并把个别开票、普通合并、只在宽免期适用和待查交易分开。
文章目录
- 小额交易没有统一豁免金额
- 买方没有索取 e-Invoice 时怎样处理
- 买方在同一个月回来取票怎样处理
- 次月第7天怎样计算
- 哪些交易不能放进普通 Consolidated
- Interim relaxation 怎样改变分流
- 一张还是多张 Consolidated
- 用一个分行案例完成月结演算
- 为什么每张收据都要保存状态变化
- 逾期和金额差异怎样处理
小额交易没有统一豁免金额
一笔 RM20 的门市交易没有因为金额小就离开 e-Invoice 范围。Specific Guideline v4.8 第 3.6 节提供的是合并处理方式。买方不需要 e-Invoice,供应商可以先发普通收据,月底再按规则汇总。
这项规则没有设定“低于 RM100 便不用处理”或“现金交易不用处理”。付款方式也不改变供应商的销售记录。现金、刷卡和电子钱包都要进入当月 POS 或销售账,再按买方要求与交易类别分流。
财务可先把交易放进四个工作区。
| 工作区 | 放入条件 | 月底动作 |
|---|---|---|
| Individual | 买方已经要求个别 e-Invoice,或一般规则要求逐笔开具 | 检查买方资料和验证状态 |
| 普通 Consolidated | 买方未索取,而且交易允许合并 | 纳入当月合并文件 |
| Interim-only | 只有依靠 Section 16 宽免才可合并 | 保存宽免依据和截止日 |
| 待查 | 资料不足、分行未关账或规则不清 | 先查明,不能为了赶期限硬塞 |
这四个工作区是内部管理方法,IRBM 没有要求企业使用相同名称。它的作用是让总笔数一直看得见。待查交易还没决定文件类型,仍会出现在月结差异里。
买方没有索取 e-Invoice 时怎样处理

门市可以继续向买方发普通 receipt(收据)。普通收据不需要逐笔提交 IRBM 验证。到了月底,供应商取回当月所有未开 individual 的收据,排除不能合并和仍待调查的项目,再提交 consolidated。
供应商可按以下顺序处理。
- 锁定交易月份和供应商法律实体。
- 取回所有分行、POS 和手工收据。
- 排除已开 individual、取消和退款交易。
- 检查 Table 3.6、RM10,000 与买方要求。
- 对平笔数、净额、税额和总额。
- 生成 consolidated 并提交验证。
- 保存 UUID、提交时间和构成总额的收据号码。
同一个集团使用同一套 POS 时,要先按实际供应商实体拆开。甲公司不能把乙公司的门市收入一起放进自己的 consolidated,只因为两家公司共用品牌和会计团队。
普通收据也不能在月结后消失。它说明交易日期、地点、货品与付款。consolidated 只把这批交易提交给 IRBM,无法代替每张收据的商业细节。
买方在同一个月回来取票怎样处理
买方拿到普通收据后,仍可在交易月份内向供应商要求 individual e-Invoice。指南的 Example 4 使用餐厅交易说明这条路径。顾客在七月二十一日用餐,七月二十八日才提出要求,仍在同一个月内。
供应商找到原收据、收集买方资料并开出 individual。该笔交易随后从待合并资料移出。月底 consolidated 不能再次包含同一个金额。
买方跨月才申请时,供应商可以按指南拒绝。Example 5 的交易发生在九月三十日,买方十月一日才申请。供应商已经把九月收据纳入 consolidated,因此拒绝补开。
门市应把取票截止安排写在收据、QR Code 页面或客服说明里。财务还要决定月底最后一天几点停止自动处理,以及当天收到但尚未完成验证的申请放到哪里。
一张收据的状态可能这样变化。
普通收据 → 买方同月申请 → 资料待验证 → Individual 已验证 → 从 Consolidated 排除
申请失败时,状态应停在“资料待修正”,不能直接回到普通 consolidated。买方已经提出 individual 要求,团队要知道谁联系买方和何时重提。
次月第7天怎样计算
Specific Guideline v4.8 第 3.6.2 节规定,consolidated e-Invoice 要在 month end(月末)后七个 calendar days(日历天)内提交。
一月份交易的期限落在二月七日。二月份交易落在三月七日。周末和公共假期仍属于 calendar days,企业应在内部流程预留生成文件、处理 validation error(验证错误)和重新提交的时间。
| 内部时间 | 建议工作 |
|---|---|
| 月底最后一天 | 锁定取票申请和分行收据范围 |
| 次月第1至2天 | 对平 POS、付款渠道和销售账 |
| 次月第3至4天 | 清理待查项目,生成文件并测试 |
| 次月第5至6天 | 提交、处理拒绝和重新验证 |
| 次月第7天 | 只留给最后确认,不把它当成开工日 |
这是企业内部安排,不是 IRBM 规定的固定关账日。交易量少的公司可以更快。分行多、系统常离线或需要总部批准的企业,应把收集资料的时间再提前。
Monthly Close Report 会根据交易月份自动给出日期和剩余天数。工具把 Valid 状态单独记录,因为“已经整理”和“已经通过验证”代表两个阶段。
哪些交易不能放进普通 Consolidated
一般规则先检查买方有没有索取 e-Invoice。买方已经提出要求,这笔交易要从 consolidated 工作区移出。
Table 3.6 还列出需要逐笔开具的活动。范围包括汽车销售、机票和私人包机、建造合约,以及表中列明的代理、经销商或分销商付款。电力供应、部分电讯交易和其他指定活动也有各自适用范围。
从 2026 年一月一日起,任何 single transaction(单笔交易)价值超过 RM10,000,也列入不得合并范围。指南使用 exceeding RM10,000。金额刚好 RM10,000 没有因这一项规定被禁止,RM10,000.01 则已经超过。
| 交易 | 只看普通合并规则的结果 |
|---|---|
| RM80 餐饮,买方未索取 | 可进入合并工作区 |
| RM80 餐饮,买方同月索取 | 移到 individual |
| RM10,000 一般货物,买方未索取 | 金额规则本身没有禁止合并 |
| RM10,000.01 一般货物 | 超过门槛,普通规则要求逐笔开具 |
| RM4,000 汽车销售 | 金额虽低,活动本身仍在 Table 3.6 |
某一笔交易拿不准时,可先用 Transaction Decision Workspace 检查角色、交易类别和买方要求,再决定放入哪个工作区。
Interim relaxation 怎样改变分流
Specific Guideline v4.8 第 16 节给予部分纳税人 interim relaxation period(过渡宽免期)。对年营业额或收入不超过 RM5 million,并在 2026 年一月一日或七月一日实施的纳税人,表内宽免期到 2027 年十二月三十一日。
符合条件并遵守第 16.2 节时,纳税人可以对所有活动和交易使用 consolidated,包括第 3.7 节一般禁止合并的活动。宽免期内,买方要求 individual 时,纳税人也可以按第 16.2(d) 节不提供 individual,前提是已经遵守该节的 consolidated 处理。
这项例外会改变 Table 3.6 和 RM10,000 的普通结果,因此月结表要保留 interim-only 工作区。企业应保存营业额、强制实施日期、宽免截止日和采用的指南版本。只在公司已经确认适用 Section 16 时,才把依靠宽免的交易放进去。
宽免期结束后,原本集中在 interim-only 的交易会重新分流。企业若等到最后一个月才修改 POS,汽车、大额交易和买方取票流程可能一起出问题。可以提前用正常规则跑一次影子月结,比较需要增加多少个别开票和买方资料。
一张还是多张 Consolidated
指南允许供应商采用三种方式整理收据。每张收据摘要可以成为独立 line item(明细项目),连续收据号码可以组成一个明细,企业也可以按 branch(分行)或 location(营业地点)分别提交。
MyInvois 同时设有系统容量限制。每次 submission 最多包含 100 张 e-Invoice,总大小最多 5MB,单张 e-Invoice 最大 300KB。收据量大、分行多或单张文件内容较多时,企业可以拆成数张 consolidated,再分批提交。
100 张限制针对一次 submission 内的 e-Invoice 文件数量,不代表一张 consolidated 只能有100张底层收据。采用连续编号链时,企业仍要在 Description of Product or Services 字段保留构成金额的收据 reference number(参考号码)。
Specific Guideline 的 Example 2 提供两个分行案例。Hibiscus Mart 在十月份的槟城分行有500笔交易、RM25,000,吉隆坡分行有2,000笔、RM65,000。它按分行提交两张 consolidated,并把连续收据编号链列成明细。这个案例说明分开提交不等于漏掉总部总额,总部仍应把两张验证文件与完整销售账对平。
用一个分行案例完成月结演算

以下是假设性演示,用来说明金额和状态怎样一起对平。
一家零售企业有两间分行。八月份 POS 原始资料如下。
| 项目 | 甲分行 | 乙分行 | 合计 |
|---|---|---|---|
| POS 原始交易 | 680笔,RM31,400 | 920笔,RM46,800 | 1,600笔,RM78,200 |
| 已取消交易 | 4笔,RM240 | 6笔,RM390 | 10笔,RM630 |
| Individual 已验证 | 12笔,RM3,600 | 18笔,RM5,140 | 30笔,RM8,740 |
| 依普通规则不能合并 | 1笔,RM12,500 | 0笔 | 1笔,RM12,500 |
先扣除取消交易,有效销售是 RM77,570。再扣除 individual 的 RM8,740,以及要逐笔处理的 RM12,500,普通 consolidated 候选金额为 RM56,330。
笔数也要对平。1,600笔减去10笔取消、30笔 individual 和1笔大额交易,剩下1,559笔。若文件生成后只有1,558个收据号码,财务要先找到少掉的那一笔,不能只因为 RM56,330 金额相同便提交。
金额相同仍可能有两笔互相抵消的错误。一张 RM80 收据漏掉,另一张已开 individual 的 RM80 又重复进入 consolidated,总额不会变化。笔数、收据号码和状态都要检查。
为什么每张收据都要保存状态变化
软件架构中的 event sourcing(事件溯源)会保存导致状态改变的一连串事件,而不是只保留最后结果。AWS 的事件溯源说明 强调按顺序保存变化,可以重建当前状态并保留可追溯历史。
门市不需要为此重建整套复杂系统,处理收据时却可以采用同一个记录原则。一张收据先被创建,买方随后申请 individual,资料验证失败,员工修正 TIN,最后文件通过验证。系统若只保存“已开 e-Invoice”,月底的人看不出它为什么要从 consolidated 排除,也不知道失败期间有没有被另一名员工重复处理。
从合并月结与事件记录放在一起观察,可以得到一个不同于普通对账的判断。收据在月底以前仍是一项会改变状态的工作记录,月结完成后才固定进入某一张验证文件。这个判断是基于 IRBM 的同月取票与合并流程,再结合事件溯源的状态历史形成的实务推论,不是 IRBM 对 POS 架构的要求。
企业不必保存每次鼠标点击。真正会改变税务文件结果的动作值得记录,包括买方提出要求、资料被拒绝、交易取消、UUID 生成和收据移出 consolidated。这样做也能阻止两名员工同时处理同一张收据。
逾期和金额差异怎样处理
已经超过次月第七天,而且该月仍没有 Valid consolidated e-Invoice,先确认缺口范围。不要把几个月漏报的收据放进本月 consolidated。每个月要独立处理,交易月份和构成总额的收据仍须保留。
2026 年 e-Invoice SVDP 允许符合条件的纳税人处理强制实施日起的漏交或错误资料。Monthly Close Report 发现逾期且未验证时,会提供带预设问题的 SVDP Preparation Template 入口。工具不会自动判定企业一定获得计划保护,正式处理仍要按 Specific Guideline 第 17 节核对。
金额有差异时,按顺序查四类项目。
- 取消和退款有没有仍留在销售总额
- Individual 是否已经从 consolidated 排除
- 分行或离线 POS 有没有少交一个批次
- 收据号码是否重复、中断或落在错误月份
完成后保存 POS 导出、差异清单、修正记录、验证 UUID 和批准人。下一次月结可以从上一期仍未解决的项目开始,不必重新猜测差异来自哪里。


