斯洛伐克 2027 年 1 月 1 日全面转向 Peppol：定制 ERP 和 EDI 流程的电子发票

从 2027 年 1 月 1 日起，在斯洛伐克设立的增值税纳税人，不能再把一份 PDF 用邮件发给另一家斯洛伐克企业就算作发票。境内 B2B 和 B2G 发票必须是符合欧洲标准 EN 16931 的结构化 XML，经由认证服务商通过 Peppol 网络投递，财政管理局把这种服务商称为“digitálny poštár”，即数字邮差。每一家斯洛伐克公司、个体经营者和公共机构都必须能够接收这类发票，包括非增值税纳税人。

截至 2026 年 10 月初，剩下大约 90 天。

如果您使用 Pohoda、KROS、Money 或类似的套装会计软件，这基本上是厂商的事。他们正在交付 Peppol 支持，财政管理局自己的2026 年 8 月 26 日操作手册也说，大多数情况下更新现有系统就够了。安装更新，选一家服务商，和您的会计商定好日常流程。

本文写给其余所有公司：发票出自自研 ERP、深度定制或已停止支持的系统、自家产品内置的计费引擎，或者与零售客户之间的 EDIFACT 连接的公司。

法律要求什么

这项义务来自经修订的增值税法（222/2004 Z. z.，经 385/2025 Z. z. 修改）。根据财政管理局的 eFaktúra 页面和操作手册，概要如下：

• 开具。 在斯洛伐克设立的增值税纳税人，在客户为斯洛伐克应税人或任何斯洛伐克法人时，必须为境内供应以及在供应前收到的款项开具电子发票。消费者不在范围内。免征增值税的供应和简化发票（不超过 100 欧元的收据，或含增值税不超过 400 欧元的 eKasa 收据）也不在范围内。除此之外，发票金额不再影响是否适用。
• 接收。 每一个斯洛伐克应税人（无论是否为增值税纳税人）和每一个斯洛伐克法人，都必须能够通过认证服务商接收电子发票。
• 格式。 符合 EN 16931 的 XML，采用 UBL 2.1 或 CII D16B。在网络上，这意味着 Peppol BIS Billing 3.0，也就是 UBL。
• 投递。 通过认证服务商经 Peppol 投递。交易双方可以约定其他渠道，比如电子邮件或现有的 EDI 连接，但必须事先征得买方同意，发票仍必须是 EN 16931 XML，而且双方仍必须能够通过服务商联系到。
• 时限。 自供应起 15 天，与现在相同。对于经网络发送的发票，开具日期是交给服务商的那一天。
• 报送。 服务商提取税务数据并报送给财政管理局，法律认为您一旦把发票交出，报送义务即已完成。kontrolný výkaz（增值税控制报表）保留到 2030 年 7 月 1 日。
• 归档。 增值税纳税人自所属年度结束起保存 XML 十年。PDF 渲染件不是发票。
• 罚则。 根据操作手册和2026 年 9 月 15 日的常见问题解答，违反电子发票义务或发送错误数据，最高可罚款 1 万欧元，屡次违反的最高 10 万欧元。及时更正的明显错误，或可证明属于服务商一方的故障，不予处罚。

切换以纳税义务发生时点为准。如果开具发票的义务在 2026 年 12 月 31 日之前已经产生，就适用旧规则，即使款项在 2027 年支付。

有两项较小的变化容易让人措手不及。租金或租赁的付款计划表（splátkový kalendár）不再能当作汇总发票使用：每一次周期性供应都需要单独的电子发票。而仅在斯洛伐克办理了增值税登记的外国公司，在 2030 年 6 月 30 日之前不在范围内。

EDIFACT 发票不再算数

这部分冲击的是制造商和零售连锁的供应商。常见问题解答说得很直白。2027 年 1 月 1 日之后，您可以继续与客户交换 EDIFACT，但对于境内交易，EDIFACT 发票将不再符合增值税意义上的电子发票定义。用它的原话说，“vy alebo váš poskytovateľ IT služieb musí vykonať konverziu”：您或您的 IT 服务商必须把这些发票转换为 EN 16931 的 UBL 或 CII。

常见问题解答甚至指明了转换路径。CEN/TS 16931-3-4 把 EDIFACT INVOIC D16B 映射到 EN 16931 语义模型，再从那里映射到 UBL。它举的例子是：EDIFACT 的发票号码对应业务术语 BT-1，在 UBL 中对应 cbc:ID。

由此需要做两个设计选择。

在哪里转换。 要么由您的系统从生成 EDIFACT 报文的同一份数据生成 UBL，要么由您的 EDI 服务商在发出时转换。如果由服务商转换，请向他们索取校验报告，因为罚款是罚您的。

由哪个渠道承载。 如果 UBL 以 Peppol BIS 的形式经 Peppol 发送，服务商会负责报送。如果您与买方约定保留 EDI 渠道，就不会有任何自动报送，而其他所有发票仍需要一个 Peppol 端点。

这些规则涉及发票、贷项通知单和自开票发票。订单和发货通知可以保持原样。

您真正需要构建什么

对于定制系统，工作分为四块。与服务商的连接通常是最小的一块。

1. 出项：能通过校验的 UBL

把您的发票数据映射到 EN 16931 业务术语，再映射到 UBL。eFaktúra 页面发布了一份转换对照表（撰写本文时为 1.11 版），把业务术语与其背后的斯洛伐克法律条款对应起来，并在 Peppol BIS 之上加了斯洛伐克的基数规则。把它当作您的规格说明。

出问题的字段很少是那些显而易见的：

• 收票方的 DIČ。 斯洛伐克参与方在 Peppol 上以 0245:DIČ 寻址，即税务识别号，而不是 IČO，也不是 IČ DPH。已经以 9950 标识符接入 Peppol 的公司，仍需要在斯洛伐克 SMP 中做一次 0245 登记。如果您的客户主数据里只有 IČO 和 IČ DPH，那么在写代码之前，您先有一项数据工作要做。
• 增值税类别代码。 S、Z、E、AE 和 O，每个都附带 Peppol 业务规则。类别 O（不属于增值税征税范围）禁止在发票上出现增值税识别号，也不能与按标准税率征税的行出现在同一张发票上。免税原因文本（BT-120）用于免税供应；在标准税率发票上填写它，会让 XML 无效。
• 计量单位必须取自 UN/ECE 代码表，而不是自由文本。每一行都需要一个。
• 您忘掉的单据类型。 更正可以是一张贷项通知单加一张新发票，也可以是一张在 BT-25 中引用原发票的更正发票。预付款的税务凭证使用类型代码 388。自开票发票是类型 389。

发送前先按 Peppol BIS 和斯洛伐克规则校验，失败的交给能修复的人。发票一旦交出就锁定，并让重试保持幂等：同一张发票以两个编号发出两次，是税务问题。

2. 服务商连接

2026 年 10 月 1 日的名录列出了 79 家认证服务商，既有斯洛伐克本国的，也有外国的。每家都有自己的 API 和认证方式。发票传输路径上没有中央国家平台：建立这样一个平台的计划在 2024 年被放弃，发票直接在服务商之间传递。常见问题解答中的几个实用要点：

• 每个参与方 ID 只能登记一家接收服务商，但发送可以通过多家。
• 通过财政管理局门户登记接收服务商是法定要求，操作的人需要在该门户上获得代表公司行事的授权。这周就把这件事安排好。在不涉及代码的步骤里，这是最慢的一步。
• 如果收票方不在 Peppol 上，投递会失败，但您作为发送方的义务已经履行，数据也仍会被报送。您的代码必须记录这次失败并通知相关人员，而不是无休止地重试或卡住计费。

自己运营接入点意味着要通过 OpenPeppol 认证、取得财政管理局的认可，并且从 2027 年 7 月 1 日起还要有 ISO/IEC 27001。对于只发送自家发票的公司，找一家服务商才是明智的选择。

3. 进项进入应付账款

从 1 月起，您的能源供应商、电信运营商和软件供应商都会给您发 UBL。操作手册把能够接收的责任放在收票方身上：通过网络正确发送的供应商已经尽到了义务。

进项工作包括：从服务商的 API 拉取单据、校验、匹配供应商、把行映射到您的应付模型、在需要的地方匹配采购订单，并接入现有的审批流程，而法律对审批流程并无要求。您还需要按需生成 XML 的可读版本，以及十年的 XML 归档。Peppol 在这里不承载拒收消息，所以争议仍像以前一样与供应商协商解决。

4. 报送与对账

服务商生成税务数据文档并完成报送。您的任务是确保您交出去的内容是正确的，并且您的增值税申报仍然对得上账，因为 kontrolný výkaz 要一直保留到 2030 年。把服务商的消息标识符和投递状态与每张发票关联保存，这样数字对不上时，您能查出原因。

需要多长时间

财政管理局自己的估计是：如果您的软件已经接入 Peppol，激活是即时的。对于定制或复杂的解决方案，集成“môže trvať niekoľko dní až týždňov”，即需要几天到几周。

就连接本身而言，这个估计是公道的。那几周的时间都花在数据上：找到每个客户和供应商的 DIČ，为每项产品和服务确定正确的增值税类别，以及构建不依赖有人逐份打开单据的进项处理流程。

测试会比您预想的慢。由认证服务商之一 Verteco 运营的 epostari.sk 上的 Peppol 监测显示，截至 2026 年 10 月 2 日，235518 家斯洛伐克增值税纳税人中有 3332 家能够接收 Peppol 发票，约占 1.4%。它只统计增值税纳税人，并称其数字仅供参考。即便如此，如今能接收测试发票的客户也寥寥无几，而 1 月会带来大量“找不到收票方”的错误。把它们当作正常情况来处理。

90 天计划

第 1 至 2 周：盘点与决策。 列出每一个向斯洛伐克企业开具发票的系统：ERP、计费引擎、EDI 网关、销售部门某人仍在用的电子表格。对进项也做同样的盘点。检查客户和供应商主数据中 DIČ 的覆盖情况。选定服务商，办好门户授权，完成接收登记。

第 3 至 6 周：出项。 构建 UBL 映射和校验，接入服务商的测试环境，转换 EDIFACT 发票，或与 EDI 服务商商定转换方案。覆盖贷项通知单、预付款和自开票，而不只是一切顺利的路径。

第 5 至 9 周：进项。 获取、校验、供应商匹配、应付映射、渲染和归档。

第 9 至 11 周：在 2026 年内上线。 今年允许自愿使用。向已经登记的客户发送真实发票，从已经登记的供应商那里接收发票。映射错误会在这一步暴露出来，而此时它们不会造成任何代价。

第 12 至 13 周：切换。 切换要以纳税义务发生时点为准，而不是记账日期。围绕假期做好规划：12 月最后两周不是测试窗口。

如果开发赶不上，要准备退路。服务商的独立网页应用，也就是操作手册建议小企业使用的方式，足以让您在 1 月 1 日接收发票，同时把集成做完。它只是接收端的权宜之计，不是批量开具的方式。

还在变化的部分

常见问题解答提到，修订版 EN 16931 已于 2025 年 10 月获批，并表示目前还无法描述其影响；Peppol BIS 会跟随该标准。转换对照表目前是 1.11 版，常见问题解答也已多次重新发布。把映射做版本管理并集中放在一处，而不是散落在开票代码各处。

第二阶段已经在时间表上了。从 2030 年 7 月 1 日起，这项义务预计将扩展到跨境供应，开具期限缩短为 10 天，kontrolný výkaz 取消。不要把“只有斯洛伐克客户”写死在设计里。

从哪里获得帮助

我们负责在生成发票的系统与如今必须承载发票的网络之间搭建连接：UBL 映射和校验、服务商 API 集成、EDIFACT 转换，以及进入应付账款的进项处理。我们的电子发票集成服务介绍了我们的工作方式；如果真正的问题出在底层系统，请参阅 ERP 现代化。如果工作范围已经明确、您需要人手，我们也可以向现有团队派驻资深开发人员。

想聊聊您的具体情况，请写信到 office@c9group.dev。