把您的业务系统对接 MyInvois：电子发票集成到底涉及什么

MyInvois曾经只是悬在少数大型企业头上的合规期限。2026年这一切变化很快：强制门槛今年内已两次上调，最近一次是9月1日起提高到RM300万，而现在处于或临近强制范围内的企业，正是那些用着POS机、会计软件或自建Excel系统的企业——不是配备专职财务团队的大公司。本文将说清楚谁现在真正受影响、"把系统对接MyInvois"在实际操作中到底意味着什么、三种对接方式、电子发票实际需要包含哪些内容，以及通常要花多少钱才能做对。

对从未接触过这个话题的企业来说，层出不穷的缩写和不断变动的门槛，很容易让整件事显得比实际更复杂。拆解开来，其实就是三个问题：我的企业现在是否被强制要求这样做、"这样做"从技术上到底意味着什么，以及考虑到我们目前开票的方式，怎样做才是最合理的路径。本文将按顺序回答这三个问题。

谁现在真正需要对接MyInvois

税收局（LHDN）按年营业额分阶段推行电子发票，从营业额超过RM1亿的企业开始，逐步向下覆盖。前三个阶段——营业额超过RM1亿、RM2500万至RM1亿、RM500万至RM2500万——已全面强制执行，没有宽限期。原定面向营业额RM50万以上企业的下一阶段，2026年内两次被压缩：先是门槛提高到RM100万，随后自2026年9月1日起再度提高到RM300万，税收局表示这次调整直接豁免了约110万家微型和小型企业。目前营业额在RM300万至RM500万之间的企业属于强制范围，但处于税收局已延长至2027年底的免罚宽限期。鉴于这一门槛今年内已多次变动，请在MyInvois官方门户核实企业的当前状态，不要沿用去年的数字。

"对接系统"到MyInvois到底是什么意思

电子发票不只是生成一张看起来像发票的PDF。一旦企业进入强制范围，每一笔符合条件的交易都必须以结构化数据的形式提交给税收局的MyInvois系统，并实时通过验证，才算是合法的电子发票——买方信息、明细项目、税额拆分等一系列固定字段，都要以税收局系统能自动读取和核对的格式提交。"对接系统"意味着今天用来开票的工具——柜台的POS机、会计软件，或是定制的订单系统——要能够把这些结构化数据发送出去，并自动接收带有唯一识别码和二维码的已验证电子发票，而不是靠人工把每笔销售重新录入政府门户。

验证是实时进行的，这与大多数企业习惯的开票方式有明显不同。没有隔夜批量处理，也没有次日对账——一笔交易要么在几秒内收到税收局返回的已验证电子发票，要么被退回、需要先更正才算有效。一个只检查自身内部规则、却并未真正调用MyInvois并等待验证返回的系统，算不上在做电子发票；它充其量只是生成了一份长得像发票的文件。

三种对接方式，从最简单到最自动化

• 免费的MyInvois门户。 税收局自己的网页门户，可逐笔手动录入或批量上传发票。完全不需要开发对接，但每张发票仍须人工录入——只适合交易量确实很低的企业。
• 直连API集成。 税收局提供REST API，企业自己的会计、POS或ERP系统可直接调用，在发票生成时自动提交。这是最自动化的方式，但需要内部开发人员或能够搭建并维护该连接的供应商。
• 注册服务商提供的中间件。 目前大多数马来西亚会计和POS平台，以及不少专门的电子发票服务商，都已推出现成的中间件，介于企业现有系统和MyInvois之间——通常建立在政府认可的Peppol网络之上——负责处理提交和验证，企业无需自行开发API对接。对没有内部开发团队的大多数中小企业来说，这是介于门户手动录入和全定制API开发之间较现实的折中方案。

三种对接方式的比较

把三者放在一起比较，真正的权衡其实不是成本本身，而是企业愿意在前期投入多少工作，来换取后期更少的人工操作。

电子发票实际需要包含哪些数据

电子发票不只是一份更美观的PDF——它是一组固定的结构化字段，税收局系统会在验证前自动核对这些字段。最基本的字段包括：供应商和买方的注册信息（含双方各自的税务识别号，TIN）、每个明细项目的描述和数量、每一行的税务处理方式和金额、应付总额，以及日期和唯一的发票编号。某些交易类型——出口、自开发票、贷记或借记通知单——还会在这个基础上增加若干额外必填字段。无论用什么系统开票，都需要能够填写该交易类型所要求的每一个字段，而不只是企业目前碰巧已经记录的那些字段。这往往是梳理需求时最先暴露的差距：一台只记录散客姓名和电话号码的POS机，可能并未按电子发票要求的方式记录企业买方的完整注册信息。

这也是为什么直接照搬现有发票模板通常行不通的原因。为面向客户的PDF而设计的模板，往往缺少税收局规范要求的一两个固定字段，或者用了验证系统无法自动解析的格式来保存它们——例如用自由文本地址，而不是结构化的注册号码。把现有发票格式映射到MyInvois所要求的结构，通常才是一个对接项目里工作量更大的部分，而不是用来提交数据的那条网络连接本身。

如何为企业选择合适的对接方式

• 算清楚交易量。每周几张发票，通过门户手动录入是现实的；每天接近或超过几十张，通常就不现实了。
• 先看看现有软件是否已经提供。不少马来西亚会计和POS平台已经直接加入了MyInvois中间件——先问清楚供应商，再假设需要定制开发。
• 衡量内部开发能力。直连API是最自动化的方式，但只有在有人能搭建并维护它的情况下才划算；否则，中间件或开发合作伙伴是更现实的选择。
• 为增长做打算，而不只是当下的交易量。正在接近更高营业额阶段、或增长较快的企业，通常更应该按明年的交易量来搭建，而不是今年的。

合并电子发票的RM10,000规则

不需要为每一笔销售单独开具电子发票的企业（主要是零售和其他面向消费者的交易）通常可以把一批交易合并成一张合并电子发票，而不必逐笔开具。唯一的硬性限制是：任何单笔金额达RM10,000或以上的交易，都不能并入合并电子发票——无论企业处于哪个阶段或宽限期，该笔交易都必须在销售时单独开具电子发票。处理高价值交易的系统需要能够自动区分这两种情况，并在销售发生的当下就标记出例外情形，而不是等到月底才发现、已经来不及按时单独开具电子发票。

这一点对同时销售低价商品和偶尔出现高价商品的企业尤其重要——比如一家家具零售商，可能把大部分日常销售合并开票，但系统需要能识别出那一笔超过RM10,000门槛的定制大额订单，并按不同方式处理。

强制范围内的企业不合规会怎样

一旦企业进入强制范围，且其宽限期（如有）已结束，未能开具有效电子发票即构成《1967年所得税法令》第120(1)(d)条下的违法行为，每宗违规可处RM200至RM20,000罚款、最高六个月监禁，或两者并罚。在宽限期内，税收局表示不会因企业善意开具合并电子发票、而非逐笔开具，而对其进行处罚——但这种宽容是暂时的，不能成为把系统对接拖到最后期限才处理的理由。如果一家企业等到宽限期快结束才开始梳理对接需求，很可能没有足够时间把系统建好、测试好并修复问题，就要面对罚则生效。

常见错误

• 等到宽限期结束才开始着手。搭建并测试一套对接方案需要数周时间，而不是几天；等罚则已经生效才开始，就没有犯错的余地了。
• 以为豁免门槛是固定不变的。这个门槛2026年内已经调整过两次；营业额接近RM300万的企业应定期重新核实自己的状态，不要假设今年的数字明年依然适用。
• 没有确认现有POS或会计平台是否已自带MyInvois中间件。很多平台其实已经有了，如果明明已有现成方案却从零开发定制对接，就是在浪费预算。
• 把合并电子发票当成适用于所有销售的变通办法。它并不适用于任何单笔金额达RM10,000或以上的交易，这条规则必须由系统自动执行，而不是事后才发现。
• 没有确认POS记录的数据是否符合MyInvois的要求。如果系统没有记录企业买方的注册信息，就需要先解决这个问题，系统才能提交有效的电子发票。

Gotka Technologies 在其中的角色

决定通过MyInvois门户、直连API，还是第三方中间件对接，并根据企业实际交易量和现有工具搭建合适的方案，正是Gotka应用与系统开发服务所涵盖的系统集成工作，业务系统与集成起价RM12,000，为参考价格，会在交易量、现有软件和所需字段梳理清楚后，以书面报价确认。这个梳理需求的阶段，也正是及早发现POS目前记录的内容与MyInvois要求之间差距的时机，而不是等对接方案建好之后才发现。系统建好后，还需要一个可靠的运行环境——Gotka基于LiteSpeed服务器的云主机服务，能与企业不断成长所需的网站和邮箱一同覆盖这部分需求。想了解电子发票如何与企业其他系统配合，可参考我们关于现成软件 vs 定制系统：如何选择的指南。

本文常用术语

• MyInvois：税收局的全国性电子发票系统，会在发票成为合法电子发票之前对其进行实时验证。
• LHDN：Lembaga Hasil Dalam Negeri，即马来西亚税收局，负责管理电子发票事务。
• TIN：税务识别号，是电子发票上标识供应商和买方双方身份的必填字段。
• 合并电子发票：把一批较小的交易合并开具成一张电子发票，主要用于面向消费者的零售销售。
• Peppol：政府认可的网络，许多电子发票中间件服务商以此为基础交换发票数据。
• 中间件：介于企业现有系统和MyInvois之间的软件，自动处理提交和验证。
• 宽限期：在此期间，税收局不会因企业在强制范围内使用合并电子发票而非逐笔开具而进行处罚。
• API（应用程序接口）：企业自有软件用来直接向MyInvois提交发票的技术通道。