阿联酋电子发票被拒收怎么办？错误代码、状态与修复全指南

在阿联酋开展 B2B、B2G 业务的企业，阿联酋电子发票（UAE eInvoice）必须经认证服务商（ASP）通过 Peppol 网络交换，并向联邦税务局（FTA）上报税务数据。既然发票要走网络，报错和拒收就不可避免。麻烦的是：供应商门户上只显示一个「Rejected（已拒绝）」，背后却可能是四种完全不同的问题——不同的问题，责任人和处理动作也完全不同。

本文把「阿联酋电子发票」的常见错误类型、Peppol 返回码、发票状态含义，以及「改、重试、重发还是开信用凭证」的判断逻辑讲清楚，并说明 Zoho Books 如何用一套系统完成合规。对准备出海阿联酋的企业来说，这是一份可以直接用于排查和选型的参考。

一、阿联酋电子发票被拒，可能有这四种问题

当供应商 ASP 门户把一张发票标为「已拒绝」，先别急着重发。它可能指向下面四种情形中的任意一种：

• 发票在离开你的系统前就被拦下——某个字段缺失或错误；
• 买方 ASP 无法通过校验，把发票退回；
• 发票已成功送达买方，但你的 ASP 尚未收到 FTA 对税务数据的确认；
• 买方正常收到发票后，对价格或数量提出争议。

顺序也很关键。按官方的 11 步流程，买方在第 6 步就收到发票，而 FTA 的确认在第 8、9 步才到达。发票出现在买方系统里，并不等于税务数据已经送达 FTA。其中最典型的拒收——买方 ASP 校验失败时，会向供应商 ASP 和 FTA 发送一个 negative MLS，这就是最常见的「rejected」状态。

二、看懂 Peppol 返回码：AP、AB、RE 是什么意思

阿联酋电子发票在 Peppol 网络上传输，很多 ASP 会用 OpenPeppol 的 MLS 规范返回码展示交换结果。

RE 之后，还会带一个原因码

注意：这些是网络层代码，不是阿联酋法律层面的代码。你的 ASP 还可能给出更详细的错误消息，用来定位某个 SV 或 BV 结果里究竟哪条规则失败了。

三、阿联酋电子发票最常见的错误类型

1. 结构、格式与必填字段错误

当买方 ASP 读不懂 XML 文件、缺少 PINT AE 必填字段，或单据类型与交易不匹配时，就会出现这类错误。常见原因包括：客户档案里的 TRN 写错或已过期；VAT 税务集团成员的标识误用了集团代表的 TRN 而非成员自身 TIN；买方的 ASP 还没创建参与者标识符。

有三种特殊情况使用固定地址：向尚未加入电子发票的买方开具税务发票，使用 0235:9900000098，同时另发一份 PDF 或纸质税务发票；视同供应（deemed supply），买方地址为 0235:9900000097；买方没有 Peppol ID 的出口业务，使用 0235:9900000099。

排查方法很直接：把同一份文件放进你自己的发送前校验。如果在同一处失败，问题在你的数据；如果这次通过了，说明之前很可能是 ASP 侧的临时故障。

2. 税务内容错误

这类错误的本质是数据内容问题：税务类别与供应不匹配、在免税行上计了 VAT，或者金额合计对不上。指南 v1.1 第 10.5 节列出六个税务类别：标准税率、免税、VAT 范围外、反向征税、零税率和边际利润机制。

排查时一行一行看：哪一行失败？用的是哪个类别？这个类别是否匹配实际供应？合计对不上，往往是企业内部两套系统用不同方式计算同一个总额。

四、该改、该重试、该重发，还是该开信用凭证？

正确动作取决于两个前提：发票是否已送达买方，以及金额或税务处理是否需要变更。

指南 v1.1 没有提供「发票送达后直接修改」的路径。送达之后的每一次更正，都必须生成一份新单据。阿联酋 2025 年第 243 号部长决定第 6(2) 条要求：取消、金额减少、退货和错误，都必须使用电子信用凭证。

「重试」和「重发」不是一回事

在门户里两者看起来很像，但含义不同：重试是在临时故障后再次发送同一份单据；更正后的重发则是一份新单据。建议在应收、应付工具里把它们做成两个独立动作，而不是一个「resend」按钮。上线前就与 ASP 约定重试规则：重试是否复用原发票号与标识符？ASP 如何标记重复？然后据此设计系统。

拒收后可以再发同一张电子发票吗？

可以——前提是它从未送达。如果是你的系统拦截，或买方 ASP 拒收，修正数据后重新发送即可。如果已经送达、事后发现错误，就必须开信用凭证；供应仍然成立时，再开一张新发票。

五、这些修复在真实场景中长什么样

下面几个例子做了简化，用来展示判断思路。

场景一：发送前发现的字段缺失

自己系统的校验发现，某张订阅计费发票缺少供应商营业执照号。发票根本没离开系统。补齐主数据字段后放行同一张发票——不需要信用凭证、不需要重发、也不用联系买方。

场景二：客户标识符写错

发给新客户的发票收到 negative MLS，提示「unknown participant（未知参与者）」。原因是有人手工录入了客户 TIN，错了一位数字。在主数据里修正 TIN 后重新发送即可。因为发票从未送达，无需信用凭证。

场景三：发票已送达，但没有上报确认

买方 ASP 确认送达，但你这边的 reporting MLS 迟迟不来。买方拿到的是一张有效发票，所以无需与客户沟通。由税务和系统团队请 ASP 处理上报，并登记在同一发票号下跟踪至确认。

场景四：重试导致的重复发票

ASP 在超时后重试发票，买方 ASP 把第二次尝试判为重复而拒收。事实上第一次已经送达。保留第一次送达作为有效记录，在异常队列里关闭这次重试，不要用新编号再发一次。

场景五：送达后的数量争议

所有确认都是正向的，但买方 AP 团队对某一行数量提出异议。这是商业问题：与买方确认更正，针对该行开具信用凭证（代码 381）；供应仍然成立时，按正确数量开新发票。

六、用一张表管理每一次异常

无论使用哪种系统，建议为每一次异常固定记录同样的字段，这样才能沉淀出可复用的排查经验：

七、为什么选择 Zoho Books 应对阿联酋电子发票

Zoho Books 是一款云端进销存与财务管理软件，帮助企业在一个平台上管理发票、费用、应收应付、银行业务、税务与财务报表，适合中小企业和跨国团队使用。它的价值不只是「多一个功能」，而是让你的团队少在几套系统之间来回切换、重复维护和对账——出问题时也更容易找到源头。

在阿联酋电子发票合规上，Zoho Software Trading LLC 已获得阿联酋电子发票 ASP 认证（认证编号 121988），并列入 EmaraTax 门户的 ASP 名单（服务商最新资质以阿联酋财政部公布的名单为准）。这意味着企业无需额外采购独立的电子发票平台或开发接口，直接在 Zoho Books 组织内完成 ASP 接入。

对出海阿联酋的中国企业，Zoho Books 还提供阿联酋税务原生支持（内置 VAT 计算、税务发票、FTA 申报报表、中英阿拉伯语双语发票）、多币种多实体管理（支持人民币、迪拉姆、美元等 180 种货币）、智能自动化（采购订单与发票匹配、银行对账、应收账款提醒）、移动端开票与审批，以及与 Zoho CRM、Zoho Analytics 等产品的生态集成。

需要说明的是：软件与 ASP 能力支持合规执行，但不替代企业的税务判断。企业仍需确保交易分类、税务处理和基础数据准确，并及时处理异常。只有当客户档案、税号、地址和税务分类都正确时，一套一体化系统才能真正减少报错与拒收。

文章关键词