チェコのEET 2.0、2027年1月1日開始：独自のPOSとキオスクのソフトウェアがすべきこと

レストランのテーブルで、携帯型カード端末に差し込まれた決済カード

チェコの売上記録制度が戻ってきます。ペトル・パヴェル大統領は2026年9月17日にEET 2.0法に署名し、財務行政庁の発表は日付をはっきり示しています。売上を記録する義務は 2027年1月1日 に始まります。対象は事業者と顧客の間の対面での支払で、現金はすべて含まれます。現金、カード、スマートフォン、QRコードのいずれでも、顧客が対面で、または自社の店舗内で支払えば、その売上はその場で税務当局に送られます。

ほとんどの小規模事業者にとって、これはベンダーのアップデートか、国の無料Webアプリで済む話です。自社開発のレジソフトウェア、セルフサービスのキオスク、店内でスタッフが持ち歩く決済アプリを運用しているチェーンにとっては、残り約90日の連携プロジェクトです。この記事はそうしたチェーンのためのものです。

最初のEETから何が変わったか

最初のEETは2022年に廃止されました。EET 2.0は中心となる考え方（対象となる売上をそれぞれオンラインで送り、国が受領を確認する）を維持しつつ、負担を大きく減らしています。

最小限のデータ。 旧制度では売上をVAT税率ごとに分けていました。EET 2.0は、税率にかかわらずVAT込みの合計を1つ送ります。
レシートの義務なし。 EETのためにレシートを発行する必要はなくなり、受領確認コードをレシートに載せる必要もありません。
より狭い対象範囲。 記録するのは顧客と事業者の間の対面での支払だけです。旧制度はより広い範囲の支払を対象にしていました。
国の無料の選択肢。 最小規模の事業者向けのWebアプリMOJE eetと、一部の定額課税の個人事業主向けの適用除外の仕組みEET OFFがあります。

技術的な変更は、この一覧が示すより大きなものです。通信方式はおなじみのもので、以前と同じくWS-Securityの署名付きでHTTPS上のSOAP 1.1を使います。メッセージは違います。新しいインターフェースはバージョン4.1で、旧インターフェースは3.1でした。仕様書は、2026年の変更が「以前のシステムとは互換性がない」としています。開発者向けセミナーの資料は、BKPセキュリティコード、簡易モードのフラグ、VATの項目が削除されたと挙げています。旧EETのコードは、通信まわりの参考にはなりますが、それ以上のものではありません。

対象範囲

売上を記録しなければならない者に関する公式ページは、3つの条件を挙げています。支払が対面での支払であるか、あらゆる現金での支払であること、事業所得であること、そして適用除外に当たらないことです。

対面での支払とは、自社または自社のスタッフとの直接の接触の中で行われるか、物品やサービスに関連して自社の店舗内や車両内で行われる支払です。セミナーの資料は、2つ目のルールがセルフレジとセルフサービスの店舗を対象にしていると明言しています。店舗内のキオスクは、従業員が取引に一切関わらなくても対象です。現金は、店舗の外であっても常に記録の対象です。ただし、郵便事業者が回収する代金引換は除きます。

支払方法は関係ありません。現金、カード、QRコード、販売の場で行う銀行振込や口座引落し、暗号資産、ギフトカード、食事券、プリペイドカードがすべて挙げられています。

離れた場所からの支払は対象外です。決済ゲートウェイで支払われるECサイトや、顧客がオフィスから支払う請求書などです。重要なのは、請求書に何と書いてあるかではなく、お金が実際にどう動いたかです。顧客がカウンターで200コルナをカードで支払い、残りの800コルナを翌日に自宅から振り込んだ場合、記録するのは200コルナだけです。

それ自体が店舗にあたる自動販売機（公式の例はコーヒーの自動販売機です）は適用除外で、記録が現実的でない店舗外のセルフサービスの売り場も同様です。適用除外の一覧には、ほかにも公的機関、銀行、賭博、エネルギーなどが含まれています。

大部分を省略できる事業者

零細事業者は、2026年12月1日に始まるMOJE eetを使えます。6月の開発者向けセミナーは、登録ユニットが2つまで、従業員が2人までの事業者を対象として紹介していました。所得が100万コルナまでの第1区分の定額課税の個人事業主は、EET OFFで適用除外を選べます。

主要なPOS製品を使っている事業者は、ベンダーからアップデートを受け取るはずです。いつ提供されるか、障害時にどうなるかを尋ね、税務ポータルで登録して証明書をインストールしてください。

それ以外のすべての事業者は、読み進めてください。自社開発またはカスタマイズしたレジソフトウェア、自社で作ったキオスク、スタッフ用の決済アプリを運用している事業者や、1つの支払が2つの会社に属しうるグループです。

構築すべきもの

必要なものはすべて開発者向け文書のページにあります。インターフェースの説明書（英語版は拘束力を持ちません）、XSDとWSDL、署名済みリクエストのサンプル、プレイグラウンド用の証明書です。

登録ユニットとデバイスID

すべてのメッセージには登録ユニットのIDが入ります。ユニット（店舗、移動販売の屋台、配送車両）は税務ポータルDIS+で作成し、システムがそれぞれに番号を割り当てます。チェーンはユニットを一括でインポートでき、変更は15日以内に届け出なければなりません。POSには、各拠点からユニットIDへの対応表を保守する仕組みと、ユニット内で一意な最大20文字のデバイスIDが必要です。

証明書

独自システムが時間を取られやすいのはここです。証明書の手続きが手順を定めています。

鍵ペアは、自社のデバイスではなくEETの認証局が生成します。パスワードで保護されたPKCS#12ファイルをダウンロードする形で、ダウンロードを確認するまで、最長で30日間取得できます。
このファイルは、古いレジのために従来の3DES暗号を使っています。文書は、legacyプロバイダーなしではOpenSSL 3で読み込めない場合があると警告しており、包み直すか、鍵をボールトに移すことを勧めています。
証明書の有効期間は1年です。1つの証明書を1台のデバイスにも複数のデバイスにも使えます。いくつ発行するかは自社が決めます。
更新はREST APIで自動化できます。更新対象の証明書で署名した短命のJWTを使い、その後リクエストをポーリングし、ダウンロードし、受領を確認します。認証局は、期限切れの2週間から3週間前に更新することを勧めています。証明書がいったん期限切れになるとAPIの経路は閉じられ、誰かが手作業で更新することになります。
秘密鍵を保護することは、納税者の法的な義務です。1つの鍵ファイルを40台のレジにコピーすれば、いずれ失効させる羽目になります。

データメッセージ

ヘッダーには、送信の試行ごとに新しいUUID、送信時刻、初回送信のフラグ、任意の検証用フラグが入ります。データ部分には、納税者のEIČ、ユニットID、デバイスID、連番（最大25文字で、ユニットとデバイスごとに一意）、タイムゾーンのオフセット付きの売上時刻、そして小数点以下ちょうど2桁のCZK建ての合計が入ります。任意の金額項目が2つあり、プリペイドのチャージと利用に使います。さらに2つの項目が、他の納税者に代わって記録する場合に使われます。

実際に受け取った額を記録します。78.90の会計を現金で79に丸めて受け取ったなら79.00、同じ会計をカードで受け取ったなら78.90です。一部を食事券、一部をカードで支払った会計は、合計額で1つのメッセージにします。

署名と送信

各メッセージは、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は一時的な障害を意味するので、後で送り直します。より小さな問題は警告として返り、その1つは売上時刻がサーバーの時計より2時間以上進んでいる場合です。キオスクの時計はずれていきます。同期させてください。

応答のタイムアウトは自社で決めますが、2秒以上にしなければなりません。時間内にPOKが届かなければ、その売上はキューに入ります。セミナーの資料によれば、再送では元のボディを使い、ヘッダーだけを新しくします。新しいUUID、falseにした初回送信フラグ、新しい送信時刻、そして元の売上時刻です。接続が戻り次第送信し、遅くとも売上から48時間以内に送ります。48時間を過ぎても義務は消えません。遅れたメッセージも送らなければなりません。

したがって、キューは再起動を経ても残り、48時間が来るよりずっと前にアラートを出さなければなりません。もう1つの落とし穴があります。売上が送信待ちの間に証明書が期限切れになった場合、それらは現在有効な証明書で署名し直さなければなりません。

返金、訂正、重複

返金や取消しは、マイナスの金額を持つ新しいメッセージで、現在の日時を付け、元の売上とは紐づけません。訂正は、取消しの後に正しいメッセージを送るか、差額のメッセージを1つ送るかのどちらかです。重複は6つの項目（EIČ、ユニット、デバイス、連番、売上時刻、合計）で検出されるので、同じボディでの再送は安全です。連番を生成し直した再送は、2件目の売上になります。

レシート

最初のEETより作業は少なくて済みます。EETのためのレシートは不要で、POKをレシートに載せる必要もありません。POKが届くまで印刷を止めておくコードは取り除いてください。消費者保護法に基づいてレシートを発行する場合は、EETの連番をレシート番号と揃えておきます。仕様書は、実務上は通常2つが一致すると述べています。

チェーンがぶつかる例外的なケース

プリペイドカード、リストバンド、ウォレット：チャージとすべての利用を記録し、追加の金額項目を設定します。
1つの支払に2つの納税者：資料にあるガソリンスタンドの例（燃料は他社に代わって販売し、コーヒーは自社の勘定で販売する）では、それぞれの納税者のデータを持つ2つのメッセージが必要です。

スケジュール

2026年6月5日： 技術文書の公開。
2026年7月1日： プレイグラウンドの開設。7月26日から8月26日までの間に、624のクライアントIPアドレスから170,389件のテスト取引を処理し、そのうち94.6%が正常に処理されました。
2026年11月1日： DIS+でのEET、登録ユニット、本番用証明書の提供開始。
2026年12月1日： MOJE eetの提供開始。
2027年1月1日： 段階導入なしに、すべての事業者に同時に義務が始まります。

公式のスケジュールは1月をパイロット月と呼びつつ、それがすでに通常の記録になると付け加えています。以前の発表は、パイロットを任意のものとしていました。これがはっきりするまでは、1月1日から本物のメッセージを送る前提で計画してください。

形式上の手続きが1つ残っています。9月22日に署名が発表された時点では、法令集（Sbírka zákonů）への掲載はまだでした。これは通常の手続きです。

90日計画

10月：範囲の確定と構築。

お金がやり取りされる場所をすべて洗い出します。レジ、キオスク、ハンディ端末、店内で支払うテーブルオーダーの流れ、現金を回収する自社の配送員です。それぞれを納税者と、今後作る登録ユニットに割り当てます。
アーキテクチャを選びます。各デバイスで署名するか、すべてのデバイスのために署名とキューを担う1つのサービスを動かすかです。システムはどちらも受け付けます。チェーンなら、たいてい集中型が勝ちます。鍵の保管場所が1つ、キューが1つ、監視する場所が1つで済むからです。
共有のテスト用証明書を使い、プレイグラウンドに対してメッセージの組み立て、署名、キューを構築します。CIで、すべてのメッセージをXSDで検証します。

11月：本番の認証情報。

11月1日から、DIS+でEETを有効にし、ユニットを作成し（数が多ければ一括インポートで）、本番用証明書を発行します。証明書はUSBメモリではなくボールトに置きます。
仕様書は、本番環境で有効な売上日の最も早い日を2026年11月1日としています。本物の証明書で検証モードのメッセージを送ってください。売上を記録せずに、経路全体をテストできます。
返金、プリペイドの流れ、証明書の更新、キューの滞留時間に対するアラートを仕上げます。

12月：予行演習。

1つの拠点に展開します。昼のピーク時にネットワークケーブルを抜き、その後キューが送り切られるのを確認します。
最も忙しい1時間分の負荷を、署名の仕組みに通してテストします。
クリスマスのピーク前に変更を凍結します。障害がどう見えるかをスタッフに伝えておきます。キューが正しく動いていれば、スタッフは何もする必要がありません。

1月：パイロット月。

毎日照合します。POSの合計とDIS+の集計額を比べます。DIS+では、すべてのPOKを含む詳細なCSVのエクスポートも請求できます。

ご相談先

当社は、POSの連携を構築し、改修しています。メッセージの組み立てと署名、障害時のキュー、証明書の保管と更新、ユニットの対応表、そしてDIS+との照合です。レジのソフトウェアが古く、作者がもういない場合は、レガシーシステムの保守サービスからその作業を始めます。自社のチームがシステムを理解していても1月までに人手が足りないなら、開発者を追加することもできます。

チェコで自社のレジやキオスクを運用していて、まだプレイグラウンドにメッセージを送ったことがないなら、office@c9group.devまでご連絡ください。