发布 更新

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

企业比较 Portal、批量上传与 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 个工作量判断

先拿最近三个月的真实记录,不要只看销售人员准备好的演示公司。把下面六项填出来。

  1. 每月要提交多少张 individual、consolidated 与 Self-billed 文件。
  2. 资料来自会计软件、POS、电商平台、项目表格,还是纸本收据。
  3. 每个月有多少退货、折让、买方拒绝和资料更正。
  4. 有多少分行、收银员、销售人员和财务人员参与开票。
  5. 客户、商品和供应商资料是否已经在现有系统内维护。
  6. 月结时要怎样核对销售、收据、验证状态与总账。

总张数只是其中一项。每月 80 张同格式顾问费,可能比 30 张来自门市、海外采购和平台结算的文件容易处理。老板若只设“超过 30 张就买软件”这种门槛,很难估到修正和对账时间。

可以先做一周记录。财务每次为了 e-Invoice 下载、复制、查 TIN、重填或追问资料时,记下分钟数和发生原因。这个数字会比软件报价单上的“自动化”更接近公司实际成本。

两种方式目前能做什么

比较项目MyInvois PortalAPI 软件或现有系统整合
使用费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 软件方案
首年设置与培训RM800RM5,000
年度订阅与支援RM0RM2,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 操作人员和软件供应商完成同样的八项动作。

  1. 开一张本地 B2B e-Invoice。
  2. 导入一批不同客户资料并处理一个错误 TIN。
  3. 汇总门市收据,并保留 receipt reference。
  4. 向外国供应商开一张 Self-billed e-Invoice。
  5. 在 72 小时内取消一张错误文件。
  6. 超过窗口后建立一张调整文件并引用原 UUID。
  7. 找出一笔验证失败,说明由谁修正和重提。
  8. 导出一个月份的交易、状态和支持文件。

记录每一步花多少时间、需要切换多少页面、资料在哪一刻重复输入。若供应商只愿意用预设样本,不愿导入公司的字段和交易组合,报价前还不能确定迁移难度。

五款常见产品的公开功能与 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。三个月后用实际工时复算一次,选择会比任何固定的“单量门槛”可靠。

延伸阅读

主要资料来源