2026 MyInvois Portal 还是 API 软件|用 6 个工作量判断
免费的 MyInvois Portal 已支持 Batch Upload,付费 API 软件也不一定自动省事。本文用单据来源、修正、月结、人员与三年成本,帮助 SME 选择合适的 e-Invoice 提交方式。
文章目录16 个段落
前两天,一名在 Subang 做 IT 外包和系统对接的朋友接到几通类似的电话。老板一开口就问,LHDN 已经提供免费的 MyInvois Portal,公司为什么还要花钱买软件或连接 API。
有一家公司随后让会计用 Portal 试开几张单。前几张 B2B e-Invoice 没有问题,到了门市月结、Self-billed 和退货修正时,工作才变复杂。客户资料来自 Excel,销售记录在另一套系统,原单 UUID 又要从验证记录找回来。老板看到的是“免费提交”,会计承担的是资料整理、核对和修正。
这也不代表公司一定要买付费软件。LHDN 目前的 MyInvois Portal 可以提交、查看、拒绝、取消和打印文件,也有 Batch Upload(批量上传)。每月只有少量交易、资料来源单一的企业,完全可以先用免费方案。判断重点是每个月有多少资料要搬动、多少例外要处理,以及谁来承担这些动作。
本文目录
- 先分清 Portal、Batch Upload 与 API
- 用 6 个工作量判断
- 两种方式目前能做什么
- 用三个企业情境选择
- 72 小时修正怎样影响选择
- 三年成本应该怎样计算
- 供应商现场要演示哪些动作
- 免费与付费都要安排资料保存
- 系统选择会暴露工作分配问题
- 签约或启用前检查
先分清 Portal、Batch Upload 与 API

企业不是只在“手动开票”和“全自动软件”之间二选一。实际至少有三种工作方式。
| 工作方式 | 资料怎样进入 MyInvois | 较适合的情况 |
|---|---|---|
| Portal 逐笔输入 | 人员登入 Portal 后建立文件 | 单据少、客户与项目简单、没有现成系统整合 |
| Portal Batch Upload | 按官方 Excel 格式整理多张文件后上传 | 已有结构化资料,但暂时不需要实时连接 API |
| ERP、会计软件或 POS 通过 API 提交 | 业务系统生成资料并送到 MyInvois | 单据来自多个业务流程、数量较多或需要减少重复录入 |
LHDN 的 Portal FAQ 明确说明,Batch Upload 可以使用预设 Excel 表格一次上传多张 e-Invoice。旧文把 Portal 写成只能逐张手打,已经不符合当前功能。
API 也不等于开票全程无人处理。系统仍要取得正确的客户资料、交易分类、税务字段和原始单据。验证失败后,还要有人看错误信息并修正。软件能减少搬资料,无法替企业决定一笔付款属于普通 e-Invoice、Self-billed 还是员工报销。
用 6 个工作量判断
先拿最近三个月的真实记录,不要只看销售人员准备好的演示公司。把下面六项填出来。
- 每月要提交多少张 individual、consolidated 与 Self-billed 文件。
- 资料来自会计软件、POS、电商平台、项目表格,还是纸本收据。
- 每个月有多少退货、折让、买方拒绝和资料更正。
- 有多少分行、收银员、销售人员和财务人员参与开票。
- 客户、商品和供应商资料是否已经在现有系统内维护。
- 月结时要怎样核对销售、收据、验证状态与总账。
总张数只是其中一项。每月 80 张同格式顾问费,可能比 30 张来自门市、海外采购和平台结算的文件容易处理。老板若只设“超过 30 张就买软件”这种门槛,很难估到修正和对账时间。
可以先做一周记录。财务每次为了 e-Invoice 下载、复制、查 TIN、重填或追问资料时,记下分钟数和发生原因。这个数字会比软件报价单上的“自动化”更接近公司实际成本。
两种方式目前能做什么
| 比较项目 | MyInvois Portal | API 软件或现有系统整合 |
|---|---|---|
| 使用费 | LHDN 免费提供 | 视供应商、模块、用户和维护方案而定 |
| 逐笔开票 | 支持 | 一般支持,实际界面由供应商决定 |
| 批量处理 | 支持官方 Batch Upload | 可由系统批量生成与提交,能力视产品而定 |
| 客户与商品资料 | 人员输入或放进上传模板 | 可从现有主资料带入,前提是资料已整理正确 |
| 验证失败 | 人员在 Portal 查看与修正 | 可在软件显示或建立处理队列,须现场测试 |
| 原单与调整文件关联 | 可在 Portal 操作 | 软件可设计关联流程,不能假设每款都一样 |
| 多门店与电商资料 | 需要先汇总成可提交格式 | 可从 POS 或平台整合,取决于连接范围 |
| 更新责任 | 企业跟随官方模板与 Portal 变化 | 供应商更新软件,企业仍要测试和确认 |
| 资料查询 | Portal 搜索范围受当前功能条件限制 | 本地查询范围由软件与企业保存政策决定 |
Portal FAQ 目前说明,“Search All Documents”每次筛选的日期范围不能超过 31 天,查询日期须在过去两年内;Documents 菜单一次可导出 100 份文件。这是查询与导出条件,不能直接写成 LHDN 两年后一定删除所有资料。
付费软件也不能默认承诺七年完整保存。企业要在合同里确认保存内容、期限、导出格式、终止订阅后的取回方式,以及供应商停业时怎样交还资料。
用三个企业情境选择
以下情境是演示,不代表每家公司都要采用同一方案。
情境一 每月 12 张顾问费发票
一名顾问每月向固定客户开 12 张 B2B e-Invoice,没有 POS,也很少退货。客户资料变动不大,开票由本人处理。
这类业务可先使用 MyInvois Portal。顾问把客户资料清单和服务分类整理好,每月安排固定时段提交并下载验证文件。购买完整会计系统节省的时间,可能暂时抵不过订阅与设置费用。
若顾问后来聘请员工、项目增加或需要连接收款和账务,再重新测算,不必在实施第一天一次买齐所有模块。
情境二 两间门店加一个仓库
零售商有两间门店,每天产生收据,也有承包商要求 individual e-Invoice。仓库会退货给供应商,公司还要处理外国软件订阅的 Self-billed。
Portal 仍然能提交文件,困难会出现在资料来源。门店收据、客户要求、退货和海外付款若分别放在四张表,会计要在月结重新组合。企业应先测试现有 POS 能否导出所需字段,Batch Upload 是否能承接,或 API 连接是否可以减少重复整理。
选择付费系统时,要现场跑一整个月结流程。只看销售员开出一张漂亮发票,无法判断系统怎样处理漏掉的 receipt reference、失败验证和 Credit Note。
情境三 批发公司已有成熟 ERP
批发公司已经在 ERP 维护客户、商品、税务和信用条款,每月开出数千张单据。人员若把同一批资料再复制进 Portal,会形成第二套记录。
这类企业通常更有理由评估 API。目标是让经过业务批准的资料从 ERP 进入 MyInvois,再把 UUID、验证状态和错误记录带回原系统。实施成本会较高,还要安排测试环境、权限、日志和失败重试。
企业也可以先让一小组交易走 API,其余留在现有流程。正式切换前要确认同一张交易不会被 Portal 与 API 重复提交。
72 小时修正怎样影响选择
e-Invoice 经过验证后,买方拒绝与供应商取消都有 72 小时窗口。超过窗口后,错误通常要用 Credit Note、Debit Note 或 Refund Note 处理。这个规则同时影响 Portal 和 API,不能写成 Portal 才有的限制。
系统选择时,财务要测试四件事。
- 谁会收到验证、拒绝或取消通知。
- 原始 UUID 在哪里查看,能否回到销售或付款记录。
- 超过 72 小时后,调整文件怎样引用原单。
- 会计分录、库存和客户余额是否同步更新。
付费软件若能找回原单并自动带入资料,可以减少手工查找。企业仍要确认调整金额、原因和批准人。按钮叫做“Issue CN”不代表系统已经替会计判断该用 Credit Note 还是 Refund Note。
三年成本应该怎样计算
以下数字只用于演示计算,不是市场报价。
| 成本项目 | Portal 为主 | API 软件方案 |
|---|---|---|
| 首年设置与培训 | RM800 | RM5,000 |
| 年度订阅与支援 | RM0 | RM2,400 |
| 每月整理与提交工时 | 18 小时 | 6 小时 |
| 内部工时成本 | RM25 一小时 | RM25 一小时 |
Portal 方案三年演示成本为 RM800 加上 18 小时乘 RM25,再乘 36 个月,合计 RM17,000。API 方案为 RM5,000 加上三年订阅 RM7,200,再加 6 小时乘 RM25 和 36 个月,合计 RM17,600。
两个方案只差 RM600,结论很容易被条件改变。若 Portal 每月只用 8 小时,它会明显较便宜。若 API 把每月处理时间降到 3 小时,或减少月结加班和重复错误,付费方案可能更合适。
公司应把数据清理、迁移、培训、额外用户、POS 接口、云端托管、支援、升级和退出费用放入同一张表。Madani Digital Grant 若适用,也要等正式批准与付款条件确认后再计算,不能先把补助从报价里扣掉。
供应商现场要演示哪些动作

准备一组去除敏感资料的真实交易,让 Portal 操作人员和软件供应商完成同样的八项动作。
- 开一张本地 B2B e-Invoice。
- 导入一批不同客户资料并处理一个错误 TIN。
- 汇总门市收据,并保留 receipt reference。
- 向外国供应商开一张 Self-billed e-Invoice。
- 在 72 小时内取消一张错误文件。
- 超过窗口后建立一张调整文件并引用原 UUID。
- 找出一笔验证失败,说明由谁修正和重提。
- 导出一个月份的交易、状态和支持文件。
记录每一步花多少时间、需要切换多少页面、资料在哪一刻重复输入。若供应商只愿意用预设样本,不愿导入公司的字段和交易组合,报价前还不能确定迁移难度。
五款常见产品的公开功能与 Madani panel 核对方法,可参考 AutoCount、SQL、Xero、Bukku 与 Million 对照。那篇负责比较具体产品,本文只解决 Portal、Batch Upload 和 API 三种工作方式怎样选。
免费与付费都要安排资料保存
LHDN Portal 方便企业查询和打印,企业仍应建立自己的保存流程。付费系统同样需要。每月关账时,可以把以下资料放入受控资料夹。
- 原始销售、采购或付款文件。
- 提交用的 Excel、XML 或 JSON 文件。
- UUID、验证日期与当前状态。
- 可视版本或公司实际分享给交易对方的文件。
- Credit Note、Debit Note、Refund Note 与原单关系。
- 验证失败和修正记录。
- 合同、订单、交付、报销与付款证明。
保存多久、保存哪一种格式,应按适用税务和公司记录要求向会计师或税务代理确认。系统合同还要写清企业能否随时批量导出,而非只能在订阅期间逐张打开。
系统选择会暴露工作分配问题
从 Subang 朋友接到的几通电话来看,我的判断是,企业争论 Portal 或 API 时,经常还没决定谁维护客户资料、谁处理失败记录、谁批准调整文件。这个判断根据 Portal 当前功能、API 工作方式和真实月结动作整理,属于实务解读,不是 LHDN 条文原文。
若责任没有写清,Portal 会把问题集中到会计身上,API 则会把同一问题藏进接口队列。企业可以在选系统前完成一次端到端演练,让销售、门店、采购和财务各自操作自己的步骤。演练中出现的追问、等待和重复输入,会直接显示软件需要解决什么。
系统最后只负责执行已经定义的流程。公司连客户资料由谁确认都没有答案时,买一套功能更多的软件,只会增加设置项目。
签约或启用前检查
- 已用最近三个月资料统计文件数量和类型。
- 已记录资料来源、人工搬运时间和常见错误。
- 已测试 Portal 的逐笔与 Batch Upload,而非只听旧经验。
- 已用公司真实交易让软件供应商演示八项动作。
- 已计算三年设置、订阅、接口、培训、支援和内部工时。
- 已确认 72 小时内外的修正流程。
- 已写明验证失败、客户资料和调整文件的负责人。
- 已确认资料导出、保存与终止订阅后的取回方式。
- 已避免 Portal 与 API 对同一交易重复提交。
交易少而稳定,可以先从 Portal 开始。资料来源多、重复录入重或已有成熟 ERP,再评估 Batch Upload 或 API。三个月后用实际工时复算一次,选择会比任何固定的“单量门槛”可靠。
延伸阅读
- 2026 马来西亚 e-Invoice 完整指南
- 五款 e-Invoice 软件公开功能对照
- RM10,000 Consolidated 限制
- 零售与 F&B Walk-in Customer 处理
- SME e-Invoice 检查清单


