捷克 EET 2.0 自 2027 年 1 月 1 日起实施：定制 POS 和自助终端软件必须做什么

捷克的销售记录制度回来了。总统彼得·帕维尔于 2026 年 9 月 17 日签署了 EET 2.0 法案，财政管理局的公告对日期说得很清楚：记录销售的义务自 2027 年 1 月 1 日起开始。它覆盖企业与客户之间的接触式付款，包括所有现金付款。现金、银行卡、手机还是二维码都一样：只要客户当面付款或在您的经营场所内付款，这笔销售就会在发生时报送给税务机关。

对大多数小商户来说，这意味着一次厂商更新或一个免费的国家网页应用。对于运行自有收银软件、自助服务终端或员工在店内随身携带的收款应用的连锁企业来说，这是一个集成项目，剩下大约 90 天。本文写给后者。

与第一代 EET 相比有什么变化

最初的 EET 于 2022 年废止。EET 2.0 保留了核心思路（每一笔符合条件的销售都在线发送，并由国家确认），同时去掉了大量负担：

• 最少的数据。 旧系统要按增值税税率拆分每笔销售。EET 2.0 只发送一个含增值税的总额，不论税率如何。
• 没有出具收据的义务。 企业不再需要为 EET 目的出具收据，确认码也不必出现在收据上。
• 范围更窄。 只记录客户与企业之间的接触式付款；旧系统覆盖的付款范围更广。
• 免费的国家方案。 MOJE eet，一个面向最小型企业的网页应用，另有一个名为 EET OFF 的退出选项，供部分定额纳税的个体经营者使用。

技术上的变化比这份清单显示的更大。传输方式是熟悉的：与以前一样，基于 HTTPS 的 SOAP 1.1，带 WS-Security 签名。报文则不一样了。新接口是 4.1 版，旧接口是 3.1 版，规范指出 2026 年的变更“与先前的系统不兼容”。开发者研讨会演示文稿列出了被删除的 BKP 安全码、简化模式标志和增值税项目。旧的 EET 代码只能作为底层通信的参考，仅此而已。

适用范围

关于谁必须记录销售的官方页面设定了三个条件：付款是接触式付款或任何现金付款，属于经营收入，且不适用任何豁免。

接触式付款是指：要么在与您或您员工的当面接触中发生，要么在您的经营场所或车辆内、与商品或服务相关地发生。研讨会演示文稿直接说明，第二条规则针对的是自助结账和自助经营场所。您店内的自助终端在范围内，尽管没有任何员工经手这笔交易。现金一律要记录，即使不在您的经营场所内，但由邮政服务代收的货到付款除外。

付款方式无关紧要。现金、银行卡、二维码、在销售点完成的银行转账或直接借记、加密资产、礼品卡、餐券和预付卡都在列。

远程付款不在范围内：通过支付网关付款的网店，或客户在自己办公室支付的发票。关键在于钱实际上是怎么流动的，而不是发票上怎么写。如果客户在柜台用卡支付 200 克朗，第二天在家通过转账支付剩余的 800 克朗，那么只有这 200 克朗需要记录。

本身构成经营场所的自动售货机（官方举的例子是咖啡机）豁免，经营场所之外记录不切实际的自助摊位也豁免。豁免清单还包括公共机构、银行、博彩和能源等。

谁可以跳过大部分内容

微型企业可以使用 MOJE eet，它将于 2026 年 12 月 1 日上线。6 月的开发者研讨会把它定位为面向最多两个登记单元、两名员工的企业。第一档定额纳税、收入不超过 100 万克朗的个体经营者，可以通过 EET OFF 选择退出。

使用主流 POS 产品的企业应该会从厂商那里得到更新。问清楚更新何时发布、系统中断时会怎样，然后在税务门户中完成登记并安装证书。

其他所有企业请继续往下读：自研或定制的收银软件、自己开发的自助终端、员工收款应用，或者一笔付款可能属于两家公司的集团。

需要构建什么

所有资料都在开发者文档页面上：接口说明（英文版不具约束力）、XSD 和 WSDL、已签名请求的样例，以及测试环境（playground）证书。

登记单元和设备 ID

每条报文都带有一个登记单元 ID。您在税务门户 DIS+ 中创建单元（一家门店、一个流动摊位、一辆送货车），系统为每个单元分配一个编号。连锁企业可以批量导入单元，变更须在 15 天内报告。您的 POS 需要维护一份从每个站点到其单元 ID 的映射，外加一个在单元内唯一、最多 20 个字符的设备 ID。

证书

定制系统通常在这里耽误时间。证书办理流程列出了各个步骤：

• 密钥对由 EET 证书颁发机构生成，而不是在您的设备上生成。您下载一个受密码保护的 PKCS#12 文件，在您确认下载之前都可以获取，最长 30 天。
• 为了照顾老旧的收银机，该文件使用了过时的 3DES 加密。文档提醒，如果不启用 legacy provider，它可能无法在 OpenSSL 3 上加载，并建议重新封装，或把密钥移入密钥保管库。
• 证书有效期为一年。一张证书可以供一台或多台设备使用；签发多少张由您决定。
• 续期可以通过 REST API 自动化：用待续期的证书签署一个短时有效的 JWT，然后轮询请求、下载、确认。证书颁发机构建议在到期前两到三周续期。证书一旦过期，API 途径即告关闭，只能由人手工续期。
• 保护私钥是纳税人的法定义务。一个密钥文件被复制到四十台收银机上，迟早会被吊销。

数据报文

报文头包含每次尝试新生成的 UUID、发送时间、首次尝试标志和一个可选的验证标志。数据部分包含纳税人的 EIČ、单元 ID、设备 ID、一个序列号（最多 25 个字符，在每个单元和设备内唯一）、带时区偏移的销售时间，以及以克朗计、精确到两位小数的总额。两个可选金额字段用于预付充值和消费扣款；另有两个字段用于代表另一纳税人进行记录。

记录实际收到的金额：一张 78.90 的账单用现金支付并舍入为 79，就记为 79.00；同一张账单用卡支付，就记为 78.90。部分用餐券、部分用卡支付的账单，是一条记录总额的报文。

签名与发送

每条报文都在 WS-Security 头中用 XML Signature 签名：排他式规范化、SHA-256 摘要、RSA-SHA256，证书以 BinarySecurityToken 形式附上，并且只对 SOAP 正文签名。不要加入 Timestamp 或 WS-Addressing 之类的额外头：超过 12 kB 的报文会被拒绝，而看起来像攻击的报文可能根本得不到响应。TLS 1.2 或更高版本是强制要求，客户端必须验证服务器证书。生产环境使用 DNS 负载均衡，所以每次连接都要重新解析主机名，而不是固定 IP。

自 1.2 版起，该端点支持 CORS，所以基于浏览器的 POS 可以直接调用它。在任何人写那段 JavaScript 之前，先决定私钥放在哪里。

响应、中断和 48 小时规则

有效的报文会收到一个同步回复，其中包含一个由税务机关签名的 39 个字符的确认码（POK）。验证这个签名，并把 POK 与销售记录一起保存。无效的报文会收到一个错误代码；-1 表示临时故障，稍后重新发送即可。较小的问题以警告形式返回，其中一种是销售时间比服务器时钟超前两个小时以上。自助终端的时钟会漂移。要做时间同步。

响应超时由您自己设置，不得少于两秒。如果在时限内没有收到 POK，这笔销售就进入队列。根据研讨会演示文稿，重试时沿用原始正文，换上新的报文头：新的 UUID、首次尝试标志设为 false、新的发送时间、原始的销售时间。连接一恢复就立即发送，最迟不晚于销售后 48 小时。过了 48 小时，义务也不会消失：迟发的报文仍然欠着。

因此，队列必须在重启后依然存在，并在 48 小时到期之前很早就发出告警。还有一个陷阱：如果证书在销售记录排队期间过期，这些记录必须用当前有效的证书签名。

退款、更正和重复

退款或撤销是一条新的报文，金额为负数，日期为当前时间，且不与原始记录关联。更正可以是一次撤销加一条正确的报文，也可以是一条差额报文。重复记录通过六个字段识别（EIČ、单元、设备、序列号、销售时间和总额），所以用同一正文重试是安全的。而重新生成序列号的重试，就是第二笔销售。

收据

比第一代 EET 的工作量少：不需要为 EET 目的出具收据，POK 也不必出现在收据上。删除所有在收到 POK 之前阻止打印的代码。在您依照消费者保护法出具收据的场合，让 EET 序列号与收据编号保持一致；规范指出，实践中两者通常是相同的。

连锁企业会遇到的边界情况

• 预付卡、手环和电子钱包：充值和每一次消费都要记录，并填写额外的金额字段。
• 一笔付款，两个纳税人：演示文稿中加油站的例子（代表另一家公司销售的燃油，以及以自己名义销售的咖啡）需要两条报文，各自携带对应纳税人的数据。

时间表

• 2026 年 6 月 5 日： 发布技术文档。
• 2026 年 7 月 1 日： 测试环境开放。在 7 月 26 日至 8 月 26 日期间，它处理了来自 624 个客户端 IP 地址的 170389 笔测试交易，其中 94.6% 处理成功。
• 2026 年 11 月 1 日： DIS+ 中开通 EET、登记单元和生产证书。
• 2026 年 12 月 1 日： MOJE eet 上线。
• 2027 年 1 月 1 日： 义务对所有人同时开始，不分阶段。

官方时间表把 1 月称为试点月，随后又补充说那时已经是正式记录。较早的一份公告曾把试点描述为自愿参加。在这一点澄清之前，请按从 1 月 1 日起发送真实报文来规划。

还剩一个形式上的步骤：9 月 22 日宣布签署时，在《法律汇编》上的公布仍有待完成。这是例行程序。

90 天计划

10 月：界定范围与开发。

1. 列出每一个发生收款的点：收银台、自助终端、手持设备、在店内付款的桌边点餐流程、收取现金的自有司机。把每一个点分配给一个纳税人和一个未来的登记单元。
2. 选定架构：在每台设备上签名，还是运行一个为所有设备签名并排队的服务。系统两种都接受。对连锁企业来说，集中式通常更好：一个密钥存储、一个队列、一个监控点。
3. 用共享的测试证书，在测试环境中构建报文生成器、签名器和队列。在 CI 中用 XSD 校验每一条报文。

11 月：生产凭证。

4. 从 11 月 1 日起，在 DIS+ 中开通 EET，创建单元（数量多的话批量导入），并签发生产证书。把证书放进密钥保管库，而不是 U 盘里。
5. 规范规定，2026 年 11 月 1 日是生产环境中最早有效的销售日期。用真实证书发送验证模式的报文：它们能测试整条链路，而不会记录一笔销售。
6. 完成退款、预付流程、证书续期以及基于队列积压时长的告警。

12 月：演练。

7. 在一个站点上线。在午餐高峰时拔掉网线，然后观察队列如何排空。
8. 用签名器对您最繁忙的时段做负载测试。
9. 在圣诞高峰之前冻结变更。告诉员工系统中断是什么样子；如果队列运转正常，他们什么都不用做。

1 月：试点月。

10. 每天对账。把您的 POS 合计与 DIS+ 中的汇总金额进行比较，您还可以在 DIS+ 中申请一份包含每一个 POK 的详细 CSV 导出。

从哪里获得帮助

我们构建和改造 POS 集成：报文生成器和签名器、中断队列、证书存储和续期、单元映射，以及与 DIS+ 的对账。如果收银软件已经老旧、作者也早已离开，这项工作就从我们的遗留系统维护服务开始。如果您自己的团队了解系统，只是在 1 月之前人手不够，我们可以为团队补充开发人员。

如果您在捷克运营自己的收银台或自助终端，却还没有向测试环境发送过一条报文，请写信到 office@c9group.dev。