阿联酋增值税｜阿联酋电子发票指南更新：企业应当如何准备？

按照阿联酋财政部的定义，电子发票是由供应商开具、在供应商与买方之间以电子方式交换，并向 FTA 电子报送的结构化发票数据。

PDF、Word、图片、扫描件和普通邮件附件主要供人查看，无法直接满足结构化数据要求。

阿联酋采用基于 OpenPeppol 的分散式持续交易控制与交换模式。一张发票大致要经过 4 个环节：

1. 供应商系统生成发票数据。

2. 发送方认证服务提供商（ASP）校验并转换数据。

3. 买方 ASP 接收数据，并交付至买方系统。

4. 相关税务数据报送至 FTA 中央平台。

目前，阿联酋电子发票制度重点覆盖 B2B 和 B2G 交易，B2C 交易暂未纳入强制范围。

企业不能只根据 VAT 登记状态作出判断。按照官方指南，原则上在阿联酋开展业务的主体都应评估自身是否落入适用范围，明确排除的情形除外。

截至 2026 年 8 月，主要实施时间如下：

试点和自愿采用已于 2026 年 7 月 1 日开始。企业可以利用这一阶段提前测试系统与流程，但这不代表所有企业都需要从当日起全面上线。

传统发票首先考虑版式，电子发票更关注字段及其逻辑关系。

买卖双方标识、税务信息、币种、行项目、税率、金额合计、交易类型和引用关系，都要来自可靠的主数据，并通过 PINT AE 规则校验。

部分电子发票字段过去未必属于 VAT 发票的必填内容。企业需要逐项确认数据由哪个系统保存、由谁维护、出现错误时由谁更正。具体字段数量和版本仍应以最新官方规范为准。

ASP 可以提供合规传输和网络接入，内部数据仍需由企业整理。

ERP、会计或开票系统要生成符合要求的数据，也要接收回执、识别失败状态，并处理退回或拒收的发票。收到供应商发票后，数据还要进入审批、入账和付款流程。

完成 ASP 签约只是实施中的一个环节。系统连接、异常处理和内部流程仍需由企业完成。

企业的日常交易无法全部套用同一套开票逻辑。

预付款、贷项通知单、反向计税、进口、出口、持续供应、自开发票、VAT Group 内部交易及自由贸易区业务，都可能对应不同的税码、字段和引用关系。

这些场景如果没有提前进入系统设计和测试，上线后容易出现发票失败、对账中断或 VAT 申报数据差异。

企业收到预付款时，应根据适用的 VAT 规则开具税务发票。最终结算时，只对剩余余额开具发票，并可以引用原预付款发票，让两次开票形成完整链路。

保留款的处理有所不同。企业可以先按照扣除保留款后的当前应付金额开票。待买方根据合同承担释放和结算义务时，再对保留款单独开票。

建筑、工程、制造和长期合同需要特别留意。合同付款节点、实际开票事件和系统字段需要相互对应。

指南主要说明这些交易如何通过电子发票表达。VAT 供货时间等实体税务问题，仍需根据合同和交易事实分别判断。

根据 2025 年第 106 号内阁决定：

• 未按期实施电子发票系统或指定 ASP，每延迟 1 个月或不足 1 个月，可处以 5,000 迪拉姆罚款。

• 未按期传输电子发票或电子贷项通知单，每张可处以 100 迪拉姆罚款，每类每个日历月最高 5,000 迪拉姆。

• 未按期报告系统故障或更新登记数据，还可能面临每天 1,000 迪拉姆的罚款。

罚款之外，业务问题也会随之喷涌而出。客户无法接收或入账，付款时间可能延后；供应商发票无法进入审批系统，对账需要人工介入；开票数据与 VAT 申报数据不一致，财务团队还要重新核对。

确认各法律实体对应的上线日期，并盘点税号、业务系统和主要交易类型。不同实体不能只按集团整体收入或统一系统处理。

对照最新 PINT AE 和强制字段要求开展差距分析。每个字段都应明确数据来源、维护责任和整改方式。

沿着订单、交付、开票、审批、收付款和 VAT 申报逐步检查，同时纳入预付款、贷项通知单等特殊场景。

除了价格，还应比较 Peppol 能力、系统兼容性、数据安全、服务稳定性、错误处理方式和技术支持机制。

测试范围应覆盖发票发送与接收、FTA 报送、成功或失败回执、对账和归档。出现失败时，系统还要能够保留原因和处理记录。

企业需要明确系统故障通知、异常重传、登记信息更新、权限控制、日志保存和团队分工，并让业务、财务、税务和 IT 团队了解各自的处理节点。