VERI*FACTU 与定制开票软件：西班牙在 2027 年 1 月 1 日前要求什么

在 2027 年 1 月 1 日之前，西班牙所有申报企业所得税（Impuesto sobre Sociedades）并使用软件开票的公司，都必须改用已按 Real Decreto 1007/2023 改造的软件。每张发票都会生成一条经哈希处理、与上一条相链接的记录，外加一个客户可以向税务局核验的二维码。范围内的其他所有人（主要是自雇人士）的期限是 2027 年 7 月 1 日。

如果您的发票出自商业软件包，这基本上是厂商的事。如果出自别人为您编写的软件，或您自己团队编写的软件，那就是您的事。您要改代码，还要签署声明其合规的那份声明书。

时间节点，以及两次推迟

这已经是第三套日期了，所以抱有一些怀疑是合理的。

• Real Decreto 1007/2023 原本给企业的期限是 2025 年 7 月 1 日。
• 2025 年 4 月 1 日的 Real Decreto 254/2025，把期限改为：企业所得税申报方 2026 年 1 月 1 日，其余 2026 年 7 月 1 日。原因很具体：技术命令 Orden HAC/1177/2024 直到 2024 年 10 月 28 日才发布。
• 2025 年 12 月 2 日的 Real Decreto-ley 15/2025，把两个日期都推迟了一年。其文本刊登在 BOE 上，议会在当月就予以确认。

西班牙税务局（AEAT）关于延期的说明于 2026 年 3 月 26 日更新，措辞毫不含糊：“las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027.”（申报企业所得税的实体须在 2027 年 1 月 1 日前完成开票软件系统的改造，其余纳税义务人须在 2027 年 7 月 1 日前完成。）

还会再推迟吗？截至 2026 年 10 月，没有任何官方信息这么说。第一次推迟有技术原因，而这个原因已经不存在了。AEAT 的提交服务自 2025 年 4 月 23 日起已投入生产，而自 2025 年 7 月 29 日起，软件厂商只能提供已改造的系统。押注第三次推迟是赌博，不是计划。

您适用哪个日期？ SL 或 SA 申报 Impuesto sobre Sociedades，所以运行自有 ERP 的公司几乎肯定适用 2027 年 1 月 1 日。离现在不到三个月。7 月的日期是给自雇人士和范围内其他纳税人的。

谁在范围内，谁不在

AEAT 的适用范围常见问题把它归结为四个否定条件。如果您不是完全手工开票、不在 SII 中（无论是强制还是自愿）、税务住所不在巴斯克地区或纳瓦拉，并且没有获得豁免裁定，那么您就在范围内。

实践中的排除情形：

• SII 申报方。 Suministro Inmediato de Información（即时信息报送）对营业额超过 600 万欧元的公司、增值税集团和每月增值税退税登记（REDEME）中的企业是强制的，其他企业可以选择加入。AEAT 说得很直白：“El ámbito subjetivo de ambos proyectos es excluyente.”（两个项目的适用主体互相排斥。）如果您转入 SII，就不再发送 VERI*FACTU 记录，也不再打印二维码。
• 巴斯克地区和纳瓦拉。 税务住所在这些地区的企业，受地方特别税务机关（foral）及其自有规则管辖，而不受 RD 1007/2023 约束。
• 纯手工开票。 纸质发票簿不在范围内。仅用于录入、打印和保存发票的电子表格也不在范围内；但如果它还生成您的增值税账簿，就在范围内。

在西班牙设有常设机构的外国公司也在范围内。

如果您用商业软件包开票（A3、Sage、Holded 之类），厂商就是生产者，必须交付已改造的版本并附上它自己的声明书。更新软件，确认声明书在，您就可以不用往下读了。

本文写给其余的公司：定制 ERP、十五年前写的 Access、Delphi 或 FileMaker 程序，或者您自己网络平台里的计费模块。

您的公司就是生产者

该条例第 13.1 条通过 declaración responsable（责任声明）把认证义务放在系统生产者身上。AEAT 的认证常见问题直接回答了自研的情形：“Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo.”（每个运行中的系统都必须具备由其生产者以责任声明方式出具的认证；如果软件由企业自行开发，则应由该企业自行认证。）

这在实践中意味着：

• 没有外部审计。 AEAT 称之为生产者的“auto-certificación”（自我认证）。没有人会事先批准您的系统。您签字，您负责。
• 外包方以产品形式为您开发的扩展，由外包方认证该扩展。 如果是您自己开发的，就由您认证。
• 声明书必须在系统内部的每个版本中都能看到，同时在系统外部也能独立于产品获取。
• 其内容是固定的，由 Orden HAC/1177/2024 第 15 条规定：包括系统的名称、标识符和版本、其组成部分、是否只能以 VERI*FACTU 模式运行、生产者的名称、NIF 和地址，以及签署的日期和地点等。

最棘手的是作者多年前就已离职的程序。仍然必须有人来制作改造后的版本并为它签字。在开工之前，以书面形式确定这个人是谁。

对已认证的商业产品进行定制，只有在改动触及条例要求的实现方式时，才需要另行出具声明书。在生产者控制之外所做、可能改变这些要求的修改，不合规。

利害关系由《税务总法》第 201 bis 条规定：生产不符合要求的系统，每个财政年度、每种系统类型处以 15 万欧元的固定罚款；持有应认证而未认证的系统，或持有被篡改的系统，每个财政年度处以 5 万欧元罚款。自建系统会适用哪一项，请向您的税务顾问确认。两个数字都不小。

软件必须做到什么

每张发票一条记录，在开具的那一刻生成

第 9.1 条要求系统生成一条 registro de facturación de alta（开票登记记录），“de forma simultánea o inmediatamente anterior a la expedición de cada factura”（与每张发票的开具同时或紧接在其之前）。作废的发票要生成一条注销记录（registro de anulación）。

第 10 条列出了记录的内容：开票方 NIF 和名称、必要时的收票方、系列和编号、开具日期和交易日期、发票类型、所更正发票的详情、描述、总额、增值税制度、计税基础、税率和税额、免税或不征税原因、系统及其生产者的身份，以及精确到秒的时间戳。

在老系统中，工作量就藏在这里：

• 增值税汇总往往在打印时才计算，从未保存。它们必须在开具的那一刻就作为数据存在。
• “开具”往往只是打印一份报表。 必须有一个明确的时点，让草稿变成发票，记录就在这个时点生成。
• 重复使用编号的做法到此为止。 删除一张发票再重用它的编号，这是很多小系统的习惯，现在行不通了：AEAT 会以“Registro de facturación duplicado”（开票记录重复）为由拒收第二条记录。在生产环境中开具的测试发票就是真实发票，必须注销。
• 任何人都不能编辑记录。 AEAT 的常见问题解答指出，直接修改已开具记录的数据库不得成为一项被允许的操作。如果员工现在用 SQL 修正发票，这种做法必须停止。更正要通过更正发票（rectificativa）进行。

哈希链

每条记录都带有上一条记录的系列、编号和日期，以及其哈希值（huella）的一部分。算法是 SHA-256，确切的字段和拼接方式见 AEAT 的技术文档，其中还有记录设计、XSD 模式、WSDL 以及校验和错误目录。

在生成新记录之前，系统必须检查上一条记录是否正确链接，且其时间戳不晚于当前时间一分钟以上。记录按发票开具的顺序生成。

这在架构上会带来后果。每个安装实例都需要一个唯一的、串行化的记录生成点。两台 Web 服务器在没有协调的情况下往同一条链上追加记录，会把链弄断。AEAT 接受混合架构，比如由中央后台生成记录、POS 终端接收记录，但链本身只能存在于一个地方。

每个系统由纳税人的 NIF、一个两字符的系统 ID 和一个永不重复的安装编号来标识，即使同一软件在同一台机器上重新安装，编号也不能重复。

发票上的二维码

每张发票都带有一个符合 ISO/IEC 18004 的二维码，尺寸在 30x30 mm 到 40x40 mm 之间，纠错等级为 M。它编码一个 URL，其中包含开票方的 NIF、系列和编号、开具日期和总额，客户可以凭此向 AEAT 核验。在 VERI*FACTU 模式下，发票上还要注明“VERI*FACTU”或“Factura verificable en la sede electrónica de la AEAT”（可在 AEAT 电子办事处核验的发票）。

对老旧软件来说，这意味着要改造发票模板（Access 报表、FileMaker 布局、PDF 生成器），并给一套从来没有二维码功能的技术栈加上二维码库。

两种模式：VERI*FACTU 或非 VERI*FACTU

VERI*FACTU 模式。 系统在生成每条记录时自动发送给 AEAT。作为交换，记录只需哈希，不需要电子签名，记录由 AEAT 保存，而且只以这种模式运行的系统不需要事件日志。您需要一个对接 AEAT 已发布服务的 SOAP 客户端、一张合格电子证书，以及一个在连接失败时使用的队列。AEAT 的开发者常见问题把中断视为事件处理：记录在队列中等待并重试，开票照常进行。

非 VERI*FACTU 模式。 记录保留在您这里，每条都必须用合格证书签名（XAdES Enveloped，ETSI EN 319 132）。系统还必须保存一份经签名的事件日志，涵盖该模式的启动与停止、异常检查及其结果、备份恢复和导出，并且运行期间至少每六小时生成一次汇总事件；AEAT 要求时，系统必须交出记录。

对于定制系统，只支持 VERI*FACTU 通常是工作量更小的方案。没有签名基础设施，没有事件日志，没有异常检测工具。同时提供两种模式的系统，则要把这些全部实现。

在 2027 年 1 月 1 日之前能完成的计划

从 10 月初算起，企业所得税申报方大约有十三周。下面是行得通的顺序。

1. 第 1 周：盘点。 列出所有开具发票的系统：ERP、网店的计费模块、订阅脚本、柜台终端。确认您不在 SII 中，也不受地方特别税制管辖。
2. 第 1 至 2 周：决定谁签字、用哪种模式。 为每个系统指定生产者。除非有理由，否则只用 VERI*FACTU。确保公司的合格证书已经存在并有人负责，因为 AEAT 的开发者常见问题指出，没有证书系统就无法运行。
3. 第 2 至 4 周：数据差距分析。 把系统保存的内容与第 10 条和 AEAT 的记录设计对照。缺失的增值税汇总、发票类型代码和更正引用会在这一步暴露出来。
4. 第 3 至 8 周：开发。 开具时生成记录、哈希链及其检查、不可篡改的存储、注销、每个模板上的二维码，以及带重试队列的提交客户端。取消对已开具记录的直接编辑。
5. 第 6 至 10 周：测试。 先在 AEAT 的测试环境中进行，然后发送真实记录。AEAT 把您截止日期之前的这段时间视为测试期，在此期间您可以停止发送并退回到其他系统。在编写注销和更正流程之前，先读开发者常见问题：大多数边界情况那里都有。
6. 第 9 至 12 周：声明与培训。 撰写 declaración responsable，在应用内外都展示出来，并记录版本。告诉财务部门：编号永不重用，错误一律通过更正发票修正。
7. 12 月中旬：上线。 写着“antes del 1 de enero”（1 月 1 日之前）的截止日期，不是上线日期。提前两周上线，让最初的问题在还有时间处理的时候暴露出来。

对于 2027 年 7 月 1 日这个日期，计划相同，只是余地更大。1 月就开始，不要等到 5 月。

有两种替代重建的方案值得认真权衡。AEAT 接受混合架构，所以您的 ERP 可以继续准备发票数据，由一个单独的组件（买来的或自建的）生成记录、二维码并完成提交，前提是声明书涵盖了各部分如何配合。另外，如果那套老程序每月只开几张发票，AEAT 面向小企业的免费开票应用或一个标准软件包，可能比改造它更省钱。

从哪里获得帮助

我们改造企业已经在运行的开票代码，包括较老的技术栈：记录生成、哈希链、模板上的二维码以及 AEAT 提交客户端，并留下测试。我们的电子发票集成服务覆盖开发工作；如果已经没人知道那套老程序如何运作，就从遗留系统维护开始。

如果您适用 2027 年 1 月 1 日这个日期，又使用定制系统，请写信到 office@c9group.dev。我们是工程师，不是税务顾问：适用范围和责任问题属于您的税务顾问，我们按照他们给出的答复来构建。