スロバキアは2027年1月1日にPeppolへ：独自ERPとEDIの流れのための電子インボイス対応

ブラチスラバの中央広場に建つ旧市庁舎

2027年1月1日から、スロバキアに拠点を置くVAT納税義務者は、ほかのスロバキア企業にPDFをメールで送って請求書とすることができなくなります。国内のB2BとB2Gの請求書は、欧州規格EN 16931に沿った構造化XMLでなければならず、認定プロバイダーを通じてPeppolネットワークで届けられます。財務行政庁はこのプロバイダーを「digitálny poštár」（デジタル郵便配達人）と呼んでいます。スロバキアのすべての会社、個人事業主、公的機関は、VAT納税義務者でなくても、これを受信できなければなりません。

2026年10月初めの時点で、残りは約90日です。

Pohoda、KROS、Moneyなどのパッケージ会計ソフトを使っているなら、これは主にベンダーの仕事です。ベンダーはPeppol対応を提供しており、財務行政庁自身の2026年8月26日付マニュアルも、ほとんどの場合は既存システムのアップデートで足りるとしています。アップデートを入れ、プロバイダーを選び、会計担当者と運用を決めてください。

この記事は、それ以外のすべての企業のためのものです。請求書を自社開発のERP、大きくカスタマイズしたシステムやサポートが終了したシステム、自社製品に組み込まれた請求エンジン、あるいは小売の顧客とのEDIFACT連携から出している企業です。

法律が求めること

義務の根拠は、改正後のVAT法（222/2004 Z. z.、385/2025 Z. z.による改正）です。財務行政庁のeFaktúraのページとマニュアルに基づいて概要をまとめます。

発行。 スロバキアに拠点を置くVAT納税義務者は、顧客がスロバキアの課税事業者、またはスロバキアの法人である場合、国内の供給と供給前に受け取った支払について、電子インボイスを発行しなければなりません。消費者は対象外です。VAT免税の供給と簡易請求書（100ユーロまでのレシート、またはVAT込み400ユーロまでのeKasaのレシート）も対象外です。それ以外では、請求金額はもう関係ありません。
受信。 スロバキアのすべての課税事業者（VAT納税義務者かどうかを問わない）とすべての法人は、認定プロバイダーを通じて電子インボイスを受信できなければなりません。
フォーマット。 EN 16931に準拠したXMLで、UBL 2.1またはCII D16Bです。ネットワーク上では、UBLであるPeppol BIS Billing 3.0を意味します。
配信。 認定プロバイダーを通じてPeppolで届けます。当事者はメールや既存のEDI連携など別の経路で合意することもできますが、それには買い手の事前の同意が必要で、請求書は引き続きEN 16931のXMLでなければならず、双方がプロバイダー経由でも到達可能でなければなりません。
時期。 現在と同じく供給から15日以内です。ネットワークで送る請求書の発行日は、プロバイダーに引き渡した日です。
報告。 プロバイダーが税務データを抽出して財務行政庁に報告し、法律上は請求書を引き渡した時点で自社の報告義務が果たされたものとして扱われます。kontrolný výkaz（VAT管理報告書）は2030年7月1日まで残ります。
保存。 VAT納税義務者は、XMLを対象年の末から10年間保存します。PDFに表示したものは請求書ではありません。
罰則。 マニュアルと2026年9月15日付のFAQによれば、電子インボイスの義務に違反した場合や誤ったデータを送った場合は最大1万ユーロ、繰り返し違反した場合は最大10万ユーロの罰金が科されることがあります。速やかに訂正した明白な誤りや、プロバイダー側の障害であることを証明できる場合は、罰則の対象になりません。

切り替えは課税時点に従います。請求書を発行する義務が2026年12月31日までに生じたなら、支払が2027年であっても旧ルールが適用されます。

見落とされやすい小さな変更が2つあります。賃料やリースの支払予定表（splátkový kalendár）は、もうまとめ請求書としては機能しません。繰り返し行われる供給のそれぞれに、個別の電子インボイスが必要です。そして、スロバキアでVAT登録をしているだけの外国企業は、2030年6月30日まで対象外のままです。

EDIFACTの請求書は数に入らなくなる

製造業者や小売チェーンへの納入業者を直撃するのがこの部分です。FAQははっきり書いています。2027年1月1日以降も顧客とのEDIFACTのやり取りは続けられますが、国内取引については、EDIFACTの請求書はVAT上の電子インボイスの定義をもう満たしません。FAQの言葉では「vy alebo váš poskytovateľ IT služieb musí vykonať konverziu」、つまり自社またはITサービス事業者が、それらの請求書をEN 16931のUBLまたはCIIに変換しなければなりません。

FAQは変換の経路まで示しています。CEN/TS 16931-3-4がEDIFACT INVOIC D16BをEN 16931の意味モデルに対応づけており、そこからUBLに対応づけます。FAQの例では、EDIFACTの請求書番号がビジネス用語BT-1になり、それがUBLのcbc:IDになります。

ここから2つの設計上の選択が生じます。

どこで変換するか。 EDIFACTのメッセージの元になるのと同じデータから自社システムがUBLを生成するか、EDIサービス事業者が送信の途中で変換するかです。事業者に任せるなら、検証レポートを求めてください。罰金を科されるのは自社だからです。

どの経路で運ぶか。 UBLをPeppol BISとしてPeppolで送れば、プロバイダーが報告します。買い手との合意でEDIの経路を続けるなら、自動的には何も報告されず、それ以外のすべてのためにPeppolのエンドポイントも引き続き必要です。

ルールが対象とするのは、請求書、クレジットノート、自己請求書です。注文書や出荷案内はそのままで構いません。

実際に構築すべきもの

独自システムの場合、作業は4つに分かれます。プロバイダーとの接続は、たいてい一番小さな部分です。

1. 送信：検証を通るUBL

請求データをEN 16931のビジネス用語に対応づけ、さらにUBLに対応づけます。eFaktúraのページでは、ビジネス用語をその根拠となるスロバキア法の条項に対応づけ、Peppol BISの上にスロバキア独自の出現回数の制約を加えた転記表のスプレッドシート（執筆時点ではバージョン1.11）が公開されています。これを仕様書として扱ってください。

問題を起こす項目は、目に付きやすいものとは限りません。

受領者のDIČ。 Peppol上のスロバキアの参加者は、IČOでもIČ DPHでもなく、納税者番号であるDIČを使って0245:DIČで宛先指定されます。すでに9950の識別子でPeppolに参加している会社も、スロバキアのSMPに0245で登録する必要があります。顧客マスタにIČOとIČ DPHしかないなら、コードの仕事の前にデータの仕事があります。
VAT区分コード。 S、Z、E、AE、Oの5つで、それぞれにPeppolの業務ルールが付いています。区分O（VATの対象外）では請求書にVAT識別子を載せることが禁じられ、標準税率の明細行と同じ請求書に載せることもできません。非課税理由のテキスト（BT-120）は非課税の供給のためのもので、標準税率の請求書に入れるとXMLが無効になります。
単位。 自由テキストではなく、UN/ECEのコードリストから選びます。すべての明細行に必要です。
忘れていた文書種別。 訂正は、クレジットノートと新しい請求書の組み合わせか、BT-25で元の請求書を参照する訂正請求書で行います。前払いのための税務文書は種別コード388、自己請求書は389です。

送る前にPeppol BISとスロバキアのルールで検証し、不合格になったものは直せる人に回してください。引き渡した請求書はロックし、再送は冪等にします。同じ請求書が2つの番号で2回送られれば、税務の問題になります。

2. プロバイダーとの接続

2026年10月1日付の登録簿には、国内外の認定プロバイダー79社が載っています。それぞれが独自のAPIと認証方式を持っています。請求書の経路に国の中央プラットフォームはありません。その計画は2024年に取りやめになり、請求書はプロバイダー同士の間で直接やり取りされます。FAQから実務上の要点を挙げます。

受信用のプロバイダーは、参加者IDごとに1社しか登録できませんが、送信は複数のプロバイダーを通じて行えます。
受信用のプロバイダーを財務行政庁のポータルで登録することは法的な要件であり、登録を行う人には、そのポータル上で会社を代理する権限が必要です。今週のうちに手配してください。コードが関わらない作業の中で、一番時間がかかるのがこれです。
受領者がPeppolに参加していなければ配信は失敗しますが、送り手としての義務は果たされており、データは報告されます。コードはその失敗を記録して誰かに知らせなければならず、延々と再送したり請求処理を止めたりしてはいけません。

自社でアクセスポイントを運用するには、OpenPeppolの認定、財務行政庁の認可、そして2027年7月1日からはISO/IEC 27001が必要です。自社の請求書を送るだけの会社なら、プロバイダーを使うのが賢明です。

3. 買掛金への受信

1月からは、電力会社、通信事業者、ソフトウェアベンダーがUBLを送ってきます。マニュアルは、受信できる状態にしておく責任を受領者に負わせています。ネットワークを通じて正しく送った仕入先は、自分の役割を果たしたことになります。

受信の作業は、プロバイダーのAPIから文書を取得し、検証し、仕入先を照合し、明細行を自社の買掛金のモデルに対応づけ、発注書との照合を行っているならそれも行い、既存の承認ワークフロー（法律はこれには触れていません）に流すことです。求めに応じてXMLを読める形で表示する機能と、10年間のXMLのアーカイブも必要です。ここでのPeppolには差し戻しのメッセージがないので、争いはこれまでどおり仕入先と直接解決します。

4. 報告と照合

税務データの文書を作り、報告するのはプロバイダーです。自社の仕事は、引き渡すものが正しいことと、VATの申告が引き続き照合できることを確かめることです。kontrolný výkazは2030年まで続くからです。プロバイダーのメッセージ識別子と配信ステータスを各請求書に紐づけて保存し、数字が合わないときに原因を調べられるようにしてください。

どのくらいかかるか

財務行政庁自身の見積もりでは、ソフトウェアがすでにPeppolに接続されていれば、有効化はすぐに済みます。独自の、あるいは複雑なソリューションの場合、連携は「môže trvať niekoľko dní až týždňov」、つまり数日から数週間かかることがあります。

接続そのものについては妥当な見積もりです。週単位の時間はデータに費やされます。すべての顧客と仕入先のDIČを調べ、すべての商品とサービスのVAT区分を正しくし、誰かが文書を1通ずつ開かなくても済む受信処理を作ることです。

テストは思ったより時間がかかります。認定プロバイダーの1社でもあるVertecoが運営するepostari.skのPeppolモニターによれば、2026年10月2日時点でPeppolの請求書を受信できるスロバキアのVAT納税義務者は、23万5,518社のうち3,332社で、約1.4%でした。対象はVAT納税義務者だけで、モニター自身も数字は参考値だとしています。それでも、いまテスト請求書を受け取れる顧客はわずかで、1月には「受領者が見つからない」というエラーが大量に出るはずです。これは通常のケースとして扱ってください。

90日計画

第1週から第2週：棚卸しと決定。 スロバキアの事業者に請求書を発行するすべてのシステムを洗い出します。ERP、請求エンジン、EDIゲートウェイ、営業の誰かがまだ使っているスプレッドシートです。受信についても同じことをします。顧客と仕入先のマスタデータでDIČがどこまで揃っているかを確認します。プロバイダーを選び、ポータルの代理権限を整え、受信の登録をします。

第3週から第6週：送信。 UBLのマッピングと検証を構築し、プロバイダーのテスト環境に接続し、EDIFACTの請求書を変換するか、EDI事業者と変換について合意します。正常系だけでなく、クレジットノート、前払い、自己請求も扱います。

第5週から第9週：受信。 取得、検証、仕入先の照合、買掛金への対応づけ、表示、アーカイブです。

第9週から第11週：2026年中に本番稼働。 今年は任意での利用が認められています。すでに登録している顧客に本物の請求書を送り、登録済みの仕入先から受け取ります。マッピングの誤りが表に出るのはここで、この時点ならまだ費用はかかりません。

第12週から第13週：切り替え。 切り替えの基準は、計上日ではなく課税時点にします。休暇を考慮して計画してください。12月の最後の2週間は、テストに使える期間ではありません。

構築が間に合わない場合に備えて、代替手段を用意しておいてください。マニュアルが小規模事業者向けに勧めている選択肢である、プロバイダーの単体のWebアプリケーションがあれば、連携の完成を待つ間も1月1日に請求書を受け取れます。これは受信のための一時しのぎであって、大量に発行する手段ではありません。

まだ動いていること

FAQは、2025年10月に承認された改訂版EN 16931に触れ、その影響はまだ説明できないとしています。Peppol BISはこの規格に追随します。転記表のスプレッドシートはバージョン1.11で、FAQは何度も改訂されています。マッピングはバージョン管理して1か所にまとめ、請求処理のコードのあちこちに散らばらないようにしてください。

第2段階もすでに日程に入っています。2030年7月1日からは、義務が国境を越える供給にも広がり、発行期限が10日に短くなり、kontrolný výkazが廃止される見込みです。「スロバキアの顧客だけ」という前提を設計に固定しないでください。

ご相談先

当社は、請求書を作るシステムと、これからそれを運ぶことになるネットワークとの接続を構築しています。UBLのマッピングと検証、プロバイダーのAPIとの連携、EDIFACTの変換、買掛金への受信処理です。当社の仕事の進め方は電子インボイス連携サービスでご説明しています。本当の問題がその下にあるシステムなら、ERPモダナイゼーションをご覧ください。作業範囲が決まっていて人手が必要なら、既存のチームに経験豊富な開発者を参加させることもできます。

現在の構成についてご相談になりたい場合は、office@c9group.devまでご連絡ください。