KSeF ポーランドの電子インボイス、2026年2月義務化：導入・コンプライアンス・EC統合ガイド

1. KSeF(Krajowy System e-Faktur)とは何か、なぜ存在するのか

KSeF — Krajowy System e-Faktur(国家電子インボイス制度)— は、ポーランド国家が中央集権的に運営するインボイス検証プラットフォームです。運用上は、財務省(Ministerstwo Finansow)がksef.podatki.gov.plでホストするREST APIとWebポータルです。ポーランドの納税者が発行するすべての構造化インボイス(faktura ustrukturyzowana)は、FA(2) XML文書としてKSeFにアップロードされ、公式のXSDスキーマに対して検証され、タイムスタンプが付与され、固有の10文字のKSeF識別子(例:7A3D-19F0)が割り当てられ、少なくとも10年間中央登録簿に保存されます。

法的な観点では、KSeFは改正されたUstawa o podatku od towarow i uslug(ポーランドVAT法、Ustawa o VAT)により導入され、財務省のKSeF政令(Rozporzadzenie Ministra Finansow w sprawie KSeF)で詳細が定められています。2022年1月1日以降は任意適用ですが、2026年中に2段階で義務化され、ポーランド企業間の従来のPDFインボイスの流れをすべて置き換えます。

なぜポーランドはKSeFを構築したのか

財務省は、2021年にKSeFが初めて発表された際、3つの明確な目標を掲げました。VATギャップの縮小(ポーランドのVATギャップ(luka VAT)は、SAF-Tと分割納付制度のおかげで、2015年の25%超から2024年には約7〜9%まで縮小しました。KSeFはカルーセル詐欺や消失業者詐欺を構造的に困難にします)。行政上の摩擦の削減(KSeFインボイスは登録された瞬間に購入者に配送されたものとみなされます — PDFメールも確認受領書も不要で、KSeFのタイムスタンプが法的な配送日となります)。そしてEU ViDAとの整合(2024年の「デジタル時代のVAT」パッケージは、2030年までに単一市場全体で構造化電子インボイスを義務付けています。ポーランドは早期採用者であり、KSeFは最小限のアーキテクチャ変更でViDAに接続される予定です)。

KSeFは誰が運営し、誰が対象となるのか

KSeFは、財務省のIT部門(Departament Informatyzacji Ministerstwa Finansow)がKAS(Krajowa Administracja Skarbowa)とともに構築・運営しています。義務化日以降、すべての活動中のポーランドVAT納税者が対象となります。個人事業主(JDG)、有限責任会社(sp. z o.o.)、ポーランドVATに登録された外国企業、およびJPK_V7Mを申告する大企業です。Allegro、Amazon.pl、Empik、Ceneo、Morele.net、Erliのマーケットプレイス販売者も例外ではありません。

2. 2026年2月1日 — 義務化日(2024年から延期)

当初の計画と延期

2023年の当初の電子インボイス法では、B2BとB2Gの統一開始日として2024年7月1日が設定されていました。2024年1月、財務省は負荷テストでスケーラビリティと信頼性の問題が判明したことを受け、本番KSeF APIの外部監査を委託しました。2024年1月19日、財務省は2024年7月の期限を延期すると発表し、その後、2026年に固定された新しい導入カレンダーが公表されました。

2026年導入カレンダー

財務省は、2026年第1四半期に緩やかな適用移行期間を設けるとしています。KSeF送信の遅延・未実施に対する制裁は、少なくとも2026年7月1日までは裁量的に適用されます。2026年後半からは、Ustawa o VATに基づく完全な罰則スケジュールが猶予なく適用されます。

紙とPDFのインボイスはどうなるのか

義務化日以降、紙またはPDFのインボイスはポーランドにおいて法的に有効なB2Bインボイスではなくなります。構造化KSeFインボイスの代わりにこれをポーランドの法人購入者に発行すると、第9章で説明する罰則制度がトリガーされます。例外は次のとおりです。B2C取引(paragonyは引き続きレジスターおよび任意のe-Paragonを経由し、消費者から要求されたインボイスは引き続きKSeFを経由します)、国境を越えたインボイス(海外のVAT顧客向け。理事会指令2006/112/ECに基づく標準的なEU VATインボイス規則が適用され、輸出用にはPDFが引き続き有効です)、および不可抗力オフラインモード(API停止中にKSeF外で発行されたインボイスを、1営業日の猶予期間内に遡及的にアップロード)。

3. FA(2)スキーマ — XMLインボイス形式

FA(1)からFA(2)への変更点

FA(2)スキーマは、2026年から義務付けられる第2世代の構造化インボイスXML形式です。FA(1)(2022年から2024年半ばまでの任意適用フェーズ)に取って代わるもので、ksef.podatki.gov.pl上でXSDとして公開され、送信のたびにサーバー側で検証されます。

FA(1)と比較したFA(2)の主な変更点:より厳格なNIP検証(受取人NIP、10桁、Biala ListaおよびVIESに対してリアルタイムで検証)、新しいマーケットプレイス関連フィールド(P_RodzajFaktury、P_KSeF、P_TerminPlatnosciが販売チャネルにとって必須に)、強化されたFaKorygujacaブロック(修正インボイスはNrFaKorygowanejで元のインボイスの10文字のKSeF識別子を参照)、通貨+為替レート(Waluta / KursWalutyが販売前営業日のNBP参照レートに対して検証)、およびMPP分割納付フラグ(附属書15のカテゴリで15,000PLNを超えるインボイスに必須)。

FA(2) XMLインボイスの構造

最小構成のFA(2)文書には、Naglowek(スキーマバージョンを含むヘッダー)、Podmiot1ブロック(販売者のNIP、名称、KodKraju=PLを含む住所)、Podmiot2ブロック(購入者のNIPと名称)、および通貨コード(KodWaluty=PLN)、発行日(P_1)、インボイス番号(P_2)、税抜/VAT/税込合計(P_13_1、P_14_1、P_15)、インボイス種別(RodzajFaktury)、商品説明(P_7)・数量(P_8B)・単価(P_9A)・行税抜額(P_11)・VAT率(P_12)を含む1つ以上のFaWiersz明細行を含むFaブロックが含まれます。

名前付き要素はすべてFA(2) XSDによって強制されます。NIPの形式不正、WariantFormularzaの欠落、または公式セット(0、5、8、23、zw、np、oo)外のP_12 VAT率がある場合、KSeF APIは4xxの構造化エラーレスポンスで文書を拒否します。ZunaproのKSeFコネクタは、受信したマーケットプレイス注文からFA(2)文書を自動的に構築・検証・送信します — 販売者による手動のXSD作業は不要です。

FA(2)のバージョン管理とスキーマ更新

財務省は、FA(2)スキーマを1-0E、1-1Eといった形式でバージョン管理しています。スキーマの変更は、公式のDziennik Urzedowy Ministra Finansowで少なくとも3か月の導入期間をもって告知されます。本番用XSDはcrd.gov.pl/wzor/下でホストされています。KSeFトラフィックを扱う統合プラットフォームは、これらのバージョンを追跡する必要があります。古いスキーマに基づいて構築されたFA(2)文書は、たとえビジネスデータが正しくても拒否されます。

4. NIP-VAT受取人識別

NIP — ポーランドの納税者識別番号

NIP(Numer Identyfikacji Podatkowej)は、企業登録時に管轄の税務署が発行する、ポーランドの10桁の納税者番号です。すべての活動中のVAT納税者はNIPを保有しており、ポーランドVATに登録された外国企業は、EU域内取引のために国コードが接頭辞として付されたNIP(例:PL5252344078)を受け取ります。NIPは、FA(2)インボイス上の当事者を識別する主要な識別子です。

リアルタイム検証 — Biala ListaとVIES

KSeF APIは、すべてのB2Bインボイスに対して3つのオンラインチェックを実行します。Biala Lista(wykaz-podatnikow.mf.gov.pl上のVAT納税者ホワイトリスト — NIPはインボイス日付時点で存在し、有効である必要があります)、名称照合(NazwaはBiala Listaの記録と合理的に一致する必要があります。現在、実質的な不一致はソフトな警告にとどまりますが、2026年後半からは拒否対象となります)、およびVIES(受取人が外国のEU VAT番号を保有するEU域内B2B取引の場合)です。

マーケットプレイス注文 → NIPの取得

マーケットプレイスのチェックアウト時における購入者のNIP取得方法:Allegroは、注文が法人購入としてフラグ付けされた際にbuyer.company.taxIdでNIPを公開します。Amazon.plの法人購入者は、SP-APIのBuyerInfo.BuyerTaxInfoオブジェクトを通じてNIPを渡します。Empik / Ceneo / Morele / Erliは、それぞれ注文JSONに「Faktura na firme」フラグとNIPフィールドを公開しています。Shopify / WooCommerce / PrestaShop / BigCommerceを使った自社ショップのチェックアウトでは、「VATインボイス(NIP)」チェックボックスを追加してください。ポーランド市場向けテーマにはすでにこのウィジェットが搭載されています。

Zunaproは、すべてのマーケットプレイス注文のWebhookペイロードから購入者のNIPを取り込み、Biala Listaに対して事前検証し、送信するFA(2)のPodmiot2 → NIPに組み込みます。NIPが一致しない、または欠落している場合、インボイス送信前にパネル内アラートがトリガーされるため、KSeFの拒否を後追いするのではなく、注文レベルでデータ品質を修正できます。

5. B2G向けPEF(Platforma Elektronicznego Fakturowania)

PEFとは何か、どこに位置づけられるか

PEF — Platforma Elektronicznego Fakturowania(電子インボイスプラットフォーム) — は、2019年に開始され、開発技術省(Ministerstwo Rozwoju i Technologii)が運営する、ポーランドの既存のB2G(企業対政府)電子インボイスプラットフォームです。PEFは、公共調達における電子インボイスに関するEU指令2014/55/EUを実施するために構築されました。すべてのポーランドの公共セクター購買者(中央政府、地方自治体、病院、学校)は、公共調達契約についてPEFを通じて構造化電子インボイスを受け取ることが義務付けられています。

PEFとKSeF:共存モデル

2026年によくある疑問は、KSeFが義務化された際にPEFがなくなるのかどうかです。答えは、PEFは引き続き運用される、です。両プラットフォームは明確な役割分担のもとで併存します。

• PEF — EUのPeppolネットワークを通じた国境を越えたB2Gを含む、B2Gインボイスの搬送・ルーティング層。公共調達のワークフロー(注文 → インボイス → 支払い → アーカイブ)向けに最適化されています。
• KSeF — ポーランドの納税者が発行するすべてのB2BおよびB2Gインボイスの税務検証・登録層。財務省が構造化データの受け手となります。
• B2Gの統合フロー — ポーランドの企業がポーランドの公的購買者に請求する場合、配送のためにPEF経由でインボイスを発行し、VAT申告のために並行してKSeFにコピーが登録されます。財務省は、販売者が二重に送信する必要がないよう、自動的なPEF↔KSeF照合の構築を約束しています。

PEFの使用が義務付けられているのは誰か

すべてのポーランドの公共セクター発注機関は、PEFインボイスを受け取る義務を負っています。供給業者(ポーランド企業・外国企業を問わず)は、EUのしきい値(現在、中央政府向けの物品/サービスで14万ユーロ、地方向けで21万5000ユーロ)を超える調達について公的購買者に請求する場合、PEFインボイスを発行する義務があります。これらのしきい値未満では、PEFの利用は任意ですが推奨されています。PEFへのログインには、ePUAP、適格電子署名、または専用のPEFトークンを使用します。

PEFの技術スタック

• トランスポート — AS4(Applicability Statement 4)。安全な文書交換のためにPeppolが使用するOASIS標準です。
• 文書形式 — 国境を越えた取引には主にPeppol BIS Billing 3.0(UBL 2.1構文)、純粋な国内ポーランドB2Gインボイスには国家PEFスキーマが使用されます。
• 識別 — Peppolアドレス帳における参加者ID。ポーランドの公的購買者のPeppol IDは、0190スキームでエンコードされたそのNIPです。
• 運営者 — PEFは無料の省庁運営プラットフォームとして提供されるほか、任意で認定されたPeppolアクセスポイント(Comarch、Sage、Edicomなど)経由でも利用できます。

6. ePUAP + APIによる認証

3つの認証方式

KSeFは、それぞれ異なる運用パターンに適した3つの認証メカニズムをサポートしています。

1. 適格電子署名(kwalifikowany podpis elektroniczny) — ポーランドの適格トラストサービスプロバイダー(KIR Szafir、CenCert、Certum、EuroCert)が発行する個人証明書。会計士や、少量のインボイスを手動で発行する個人納税者に最も一般的です。
2. ePUAP経由のトラステッドプロファイル(Profil Zaufany) — PESEL番号に紐づき、オンラインバンキング経由で本人確認される、無料の政府発行電子IDです。ポーランド国民に普遍的に利用可能で、中小企業の標準的な認証方式です。
3. 適格電子シール(kwalifikowana pieczec elektroniczna) — 自動化システムが法人を代表してFA(2)文書に署名できるようにする、企業レベルの証明書です。マーケットプレイスおよびERP統合における唯一の実用的な方式です。

ePUAP — ポーランドのトラステッドプロファイル

ePUAP(Elektroniczna Platforma Uslug Administracji Publicznej、電子行政サービスプラットフォーム)は、epuap.gov.plでホストされ、デジタル問題省傘下のCentralny Osrodek Informatyki(COI)が運営する、ポーランドの中央電子政府ゲートウェイです。ePUAPを通じて発行されるProfil Zaufany(トラステッドプロファイル)は、ポーランドの電子IDの要であり、納税申告、CEIDGを通じた個人事業の登録、行政との契約の署名に使用され、2022年からはKSeF統合の初回認証にも使用されています。

マーケットプレイス販売者の典型的なフローは次のとおりです。企業の代表者(KRSで適切な権限を持つ取締役会メンバーまたは代理人)が、ePUAP経由で一度KSeFポータルにログインし、適格シールに紐づくAPIトークンを生成し、Zunapro(または他の統合業者)を「osoba uprawniona」(権限を持つ者)として承認します。それ以降、すべてのFA(2)送信は自動化されます。

KSeF APIの概要

KSeF APIは、JSON-over-HTTPSのRESTサービスです。主なエンドポイント:POST /api/online/Session/InitTokenはトークンと署名付きチャレンジを通じて認証済みセッションを開きます。POST /api/online/Invoice/SendはBase64エンコードされたFA(2) XML文書を送信し、処理参照を返します。GET /api/online/Invoice/Status/{ref}は成功時に10文字のKSeF識別子を返します。POST /api/online/Query/Invoice/Syncは取引相手のインボイスをダウンロードします。POST /api/online/Session/Terminateはセッションを終了します。

APIには、サンドボックス(ksef-test.mf.gov.pl)環境と本番(ksef.mf.gov.pl)環境の両方があります。通常のワークロードに対してはレート制限に余裕がありますが、突発的なマーケットプレイストラフィックは送信をバッチ処理すべきです。

認可モデル — 誰が誰の代理として署名できるか

KSeFは「osoby uprawnione」モデルを使用しています。あるNIPに対するすべての操作は、KSeFポータルまたはAPI経由で権限を付与された、認可された人物によって実行されます。役割には、Wlasciciel(所有者、全権限)、Faktury sprzedaz(発行インボイスの発行)、Faktury zakup(受信インボイスのダウンロード)、Nadawanie uprawnien(権限管理)が含まれます。

マーケットプレイス販売者は、通常、自社のNIPに限定した「Faktury sprzedaz」権限をZunaproに付与し、任意で受信照合のための「Faktury zakup」も付与します。販売者は所有者の役割を保持し、いつでもアクセスを取り消すことができます。

7. 主要なポーランドソフトウェア(Comarch、Sage、Symfonia)との統合

ポーランドのERP・会計ソフトウェアの状況

ポーランドの中小企業や大企業は、独特なERP・会計プラットフォームのセットを使用しており、そのほとんどが2024年から2026年にかけてKSeFコネクタを搭載しています。マーケットプレイス販売者は通常、主要な台帳として、あるいはマーケットプレイスデータの下流の利用者として、これらのシステムのいずれかをすでにスタックに組み込んでいます。以下は主要なプレーヤーと、それぞれがKSeFをどのように扱うかです。

ZunaproはERPの構図にどう位置づけられるか

Zunaproは、ERPの代替ではなく、Allegro / Amazon.pl / Empik / Ceneo / Morele.net / Erliとお客様の会計基盤との間のマーケットプレイスオーケストレーション層です。KSeFフローは2通りの方法で運用されます。Zunapro発行(ZunaproがFA(2)を構築・署名・送信し、インボイスと10文字のKSeF識別子をERPに戻します)またはERP発行(Zunaproが注文をComarch / Sage / Symfonia / Insert / Enova / iFirmaにストリーミングし、それぞれのコネクタを通じてFA(2)を発行します)です。いずれの構成でも、完全なKSeFカバレッジが実現します。

よくある統合上の落とし穴

• スキーマのずれ — ERPは、財務省のFA(2)スキーマから1リリース遅れることがあります。四半期末前に有効なXSDバージョンを相互確認してください。
• NIPの正規化 — マーケットプレイスはさまざまな形式でNIPを送信します(525-23-44-078、PL5252344078、単純な数字)。10桁に正規化してください。
• 事務所レベルのスケーリング — ある事務所が50件のNIPに対してKSeFを管理している場合、NIPごとのWeb UIではなく、KSeFポータルの一括承認フローを使用してください。
• サンドボックスの混入 — 本番用の適格シールをサンドボックスで絶対に使用しないでください。ksef-test.mf.gov.pl用に専用のテストシールを発行してください。

8. 国境を越えた電子インボイス — PEF経由のPeppol UBL

国境を越えた取引の課題

ドイツの購入者に請求するポーランドのマーケットプレイス販売者、ポーランドの公立病院に請求するチェコの再販業者、フランスへB2B販売するポーランドの輸出業者 — これらはいずれも、KSeFによって直接処理されるものではありません。KSeFは国家検証制度であり、国境を越えたB2Bインボイスは引き続き、理事会指令2006/112/ECに基づく標準的なEU VATインボイス規則に従います。PDFおよびEDIは輸出に関して引き続き受理されます — ただし1つ重要な例外があります。国境を越えたB2Gです。

Peppol — EUの国境を越えたバックボーン

Peppol(Pan-European Public Procurement Online)は、OpenPeppol協会が管理する、構造化ビジネス文書を交換するためのEU全域の標準ベースのネットワークです。すべてのEU加盟国は、指令2014/55/EUを実施するために、Peppolを自国の公共調達インフラに統合しています。文書形式:Peppol BIS Billing 3.0仕様でラップされたUBL 2.1(Universal Business Language)。トランスポート:4コーナーモデル(送信者 → 送信者のアクセスポイント → 受信者のアクセスポイント → 受信者)経由のAS4。

PEFはポーランドのB2GをどうPeppolに接続するか

PEF(第5章参照)は、ポーランドからPeppolネットワークへのゲートウェイです。ドイツの公立病院に請求するポーランドの供給業者の場合:供給業者は自社のERPでPeppol BIS Billing 3.0(UBL 2.1)インボイスを構築し、PEF(供給業者側のPeppolアクセスポイント)にアップロードします。PEFはAS4経由でドイツの受信者のアクセスポイントにルーティングし、そのアクセスポイントが病院の会計システムにインボイスを配送します。PEFは取引を記録し、ポーランドのVAT申告のために並行してKSeFにコピーが登録されます。

Peppol BIS Billing 3.0とFA(2):フィールドマッピング

Peppol UBLとFA(2)は異なるXML文法ですが、その背後にあるインボイスデータは同じです。販売者・購入者のNIPはcac:AccountingSupplierParty / AccountingCustomerParty / cbc:CompanyIDにマッピングされます。Fa/P_2はcbc:IDに、Fa/P_1発行日はcbc:IssueDateに、KodWalutyはcbc:DocumentCurrencyCodeに、FaWiersz/P_7はcac:InvoiceLine/cac:Item/cbc:Nameに、P_12 VAT率はcac:ClassifiedTaxCategory/cbc:Percentに、Fa/P_15税込合計はcbc:PayableAmountにマッピングされます。

現代の統合プラットフォーム(Zunaproを含む)は、インボイスデータを標準的な内部モデルで保持し、同じソースからKSeF用のFA(2)と国境を越えたB2G用のPeppol UBLの両方を出力します。販売者が手作業でXMLを書く必要はありません。

EU ViDA — KSeFの次に来るもの

2024年後半に合意されたEUの「デジタル時代のVAT」(ViDA)パッケージは、2030年7月までにEU域内のB2B取引について構造化電子インボイスとほぼリアルタイムのデジタル報告要件(DRR)を義務付けています。ViDAのデータモデルは明示的にPeppolに沿ったものです。ポーランドのKSeFスタック — FA(2)とPEF/Peppolルーティング — は、最小限のアーキテクチャ変更でViDAに接続できる位置にあります。財務省は、規制が発効する際にはFA(3)スキーマがViDAの必須フィールドを取り込むことになると示しています。

9. 罰則 — VAT額の最大100%

法的根拠

KSeFを使用しなかった場合の罰則は、改正されたUstawa o VAT、具体的には2023年の電子インボイス法により導入され、KSeF政令で詳細が定められた新しい条項に定められています。財務省は2026年第1四半期の緩やかな適用移行期間を通知していますが、2026年7月1日からは猶予なく完全な罰則制度が適用されます。

罰則の一覧表

違反	罰則	下限
KSeFが義務付けられている場合にKSeF外でインボイスを発行	インボイスのVAT額の最大100%	インボイス1件あたり最低1,000PLN
不可抗力によるオフライン発行後、規制期限内にKSeFへ未送信	インボイス税込額の最大18.7%	インボイス1件あたり最低1,000PLN
重大な誤りのあるインボイスをKSeF経由で発行(NIP誤り、MPPフラグ欠落など)	Kodeks karny skarbowy(財政刑法典)に基づく標準的なVAT誤り罰則	KKS第56条に基づく日割り罰金(kary dzienne)
発行済みインボイスをJPK_V7Mに未記録	過少申告税額の最大20%	VAT法第112b条に基づく

実例 — マーケットプレイスシナリオ

あるポーランドの電子機器販売者が、月間200件のAllegro B2B注文を出荷しており、平均税込1,500PLN、VAT23%(1件あたりVAT約280PLN)とします。KSeFが義務付けられているにもかかわらず、この販売者がPDFのみを継続した場合:理論上の最大罰則は200 × 280PLN = 月56,000PLNのVAT額ベースの罰金、実務上の下限は200 × 1,000PLN = 月200,000PLNの1件あたり最低罰金(いずれか高い方が適用されます)。さらに、JPK_V7Mの不一致や、購入者の仕入VAT控除権の喪失も加わります。KSeFを適切に導入するコストは、コンプライアンス違反によるリスクエクスポージャーのごく一部に過ぎません。

防御戦略と緩和策

オフラインモードの証拠 — 障害によりKSeF送信が妨げられた場合はAPIレスポンスログを保持し、猶予期間内(現在1営業日)に遡及的にアップロードしてください。Czynny zal — KKS第16条に基づくポーランドの自主申告手続きは、KASが監査を開始する前に納税者が自発的にコンプライアンス違反を開示した場合、刑事税務責任を消滅させることができます。監査証跡 — KSeF識別子はコンプライアンスの正式な証拠です。Zunaproが注文詳細で行っているように、注文とともに保存してください。

10. EC + KSeFコンプライアンス — マーケットプレイス実践ガイド

マーケットプレイスの現実

ポーランドのマーケットプレイス — Allegro(顧客2,200万人超)、Amazon.pl(400万人超)、Empik(プレミアム150万人超)、Ceneo(訪問者1,900万人超)、Morele.net(800万人超)、Erli(400万人超) — は、2026年に合計で月間3,000万件超の注文を処理しており、その中の無視できない割合が「faktura na firme」としてフラグ付けされています。マーケットプレイスの取引量では手動でのKSeF発行は不可能であり、統合を自動化する必要があります。

5ステップのマーケットプレイスKSeFフロー

1. 注文の取り込み — Zunaproが注文Webhookを受信します(「faktura na firme」が選択されていればNIPを含む)。
2. NIP検証 — Biala Listaの照会。無効な場合はパネル内アラートによるソフトフェイルとなります。
3. FA(2)の構築 — 標準化された注文データを、有効なXSDバージョンに沿ってFA(2) XMLとしてレンダリングします。
4. KSeFへの送信 — FA(2)はBase64エンコードされ、販売者の適格シールで署名され、APIに送信されます。10文字のKSeF識別子はポーリングによって取得されます。
5. 結果の書き戻し — KSeF識別子はマーケットプレイスの注文に書き戻され、購入者にはダウンロード可能なインボイスとして表示され、JPK_V7Mのために販売者のERPに送信されます。

マーケットプレイス固有の注意点

• Allegro — 購入者のNIPは、注文が「Faktura VAT」モードに切り替えられた後にのみ届きます。出荷後に切り替えられた場合、販売者は15日以内にインボイスをKSeFに遡及登録する必要があります。
• Amazon.pl — Amazon Businessのインボイスは、Vendor Centralについては事前にAmazonが発行します。Seller Central / サードパーティ販売者は、自社の納税者プロファイルを通じて自身のインボイスを発行します。
• Empik / Ceneo / Morele / Erli — 各マーケットプレイスは、同様の「Faktura na firme」フラグとNIPフィールドを公開しています。購入者がアカウント内でインボイスを確認できるよう、KSeFタグ付けを注文詳細に反映する必要があります。Ceneo CPCは、販売者自身のネットショップで請求を継続し、そこではKSeFロジックがチェックアウト統合内に存在します。

国境を越えたマーケットプレイス注文

ドイツの消費者にAllegroの注文を発送するポーランドの販売者は、B2C遠隔販売にあたります(PDFは有効で、VATはOSSで処理されます)。ドイツの法人購入者にPan-EU FBAで発送するポーランドの販売者は、EU域内B2Bにあたります(標準的なEU VAT規則が適用され、KSeFは対象外です)。逆のケース — 外国の販売者がAllegro経由でポーランドの企業に請求する場合 — は、外国の販売者がポーランドVATに登録されていれば、KSeFがトリガーされます。

報告と照合

すべてのKSeFインボイスは、月次のJPK_V7M申告を通じて自動的に検出可能ですが、販売者は依然として監査や購入者からの苦情に対応するため、注文からインボイス、KSeF識別子までの追跡可能性が必要です。Zunaproのコンプライアンス台帳は、マーケットプレイス注文ごとに次を保存します。マーケットプレイス注文ID、完全なFA(2) XMLペイロード、KSeF参照番号、10文字のKSeF識別子とタイムスタンプ、購入者NIPとBiala Listaの照会結果、JPK_V7Mの明細行参照、および修正インボイスチェーン。

コンプライアンススタックの概要

層	標準・システム	役割
国内B2Bインボイス	KSeF(FA(2) XML)	必須検証、10文字ID、アーカイブ
国内B2Gインボイス	PEF + 並行KSeF	PEF経由の配送、KSeFへの登録
国境を越えたB2G	Peppol BIS Billing 3.0(UBL 2.1)	EU全域の公共セクター電子インボイス
国境を越えたB2B	EU VAT規則(指令2006/112/EC)	標準的なEUインボイス。PDFが有効
B2Cレシート	レジスター + e-Paragon	消費者向けレシート。要求時にKSeF
認証	ePUAP / 適格署名 / シール	KSeFおよびPEF向けの本人確認
VAT申告	JPK_V7M(SAF-T)	月次ファイル。KSeFから供給

法的枠組み — Ustawa o VATとKSeF政令

Ustawa o VAT — ポーランドVAT法

Ustawa z dnia 11 marca 2004 r. o podatku od towarow i uslug(Ustawa o VAT)は、ポーランドにおけるVATを規律する主要な法律です。KSeFの義務は、2023年の電子インボイス法(Ustawa z dnia 16 czerwca 2023 r. o zmianie ustawy o podatku od towarow i uslug oraz niektorych innych ustaw、Dz.U. 2023 poz. 1598)によって同法に挿入されました。関連する条項は、構造化インボイス(faktura ustrukturyzowana)の定義、KSeF使用義務、API停止時のオフラインモード、および罰則の一覧をカバーしています。

KSeF政令

詳細な技術規則 — FA(2)スキーマのバージョン、API認証、オフラインモードの猶予期間、一括承認フロー — は、財務省のKSeF政令(Rozporzadzenie Ministra Finansow w sprawie korzystania z Krajowego Systemu e-Faktur)に定められており、Dziennik Urzedowy Ministra Finansowで公表され、定期的に更新されます。

関連するポーランド税法とEU層

• Kodeks karny skarbowy(KKS) — 第56条および第62条は、インボイス関連の違反と日割り罰金(kary dzienne)制度をカバーしています。
• Ordynacja podatkowaおよびKKS第16条 — 「czynny zal」(能動的悔悟)による自主申告は、正しく適用されれば責任を消滅させます。
• JPK政令 — KSeFが供給するJPK_V7M SAF-Tファイルの構造を定めています。
• Ustawa o KAS — KASの執行権限と照合能力を定義しています。
• 理事会指令2006/112/EC — EU VAT指令。インボイス内容の基礎規則です。
• 指令2014/55/EU — 公共調達における電子インボイスの義務化(PEFの根拠)。
• EU ViDAパッケージ — 2024年合意。2030年までにEU域内B2Bの構造化電子インボイスを義務化。KSeF/PEFはこれに整合しています。

KSeF対応への準備方法 — 2026年ステップバイステップガイド

1. 義務化日を確認する

• 2026年の売上高がVAT抜きで2億PLN超 — 2026年2月1日から義務化。
• 2026年の売上高がVAT抜きで2億PLN以下 — 2026年4月1日から義務化。
• 任意適用のオプトインは、活動中のVAT納税者であればいつでも利用可能です。

2. 認証スタックを準備する

• KIR Szafir、Certum、CenCert、またはEuroCertを通じて、法人向けの適格電子シールを発行(または更新)します。
• 初回認証のために、少なくとも1名の取締役会メンバーがePUAP経由で有効なProfil Zaufanyを保有していることを確認します。
• KSeFの「wlasciciel」役割を保有する自然人と、「Faktury sprzedaz」/「Faktury zakup」代理人として承認される人物を特定します。

3. KSeFポータルに登録する

1. ePUAPトラステッドプロファイルでksef.podatki.gov.plにログインします。
2. 会社のNIPを確認し、会計士・統合業者・ERPシステムに承認役割を割り当てます。
3. KSeF APIトークンを生成します。発行のみが必要な場合は「Faktury sprzedaz」の範囲で、完全な双方向フローには「Faktury zakup」に加えて「Faktury sprzedaz」の範囲で生成します。
4. トークンはプラットフォームのシークレット管理システムに保存してください — ソースコード管理には絶対に含めないでください。

4. FA(2)生成を設定する

1. 商品カタログのVAT率を、FA(2)で許可されているセット(0、5、8、23、zw、np、oo)にマッピングします。
2. インボイシングエンジンが、WariantFormularza、KodWaluty、Adres/KodKrajuを含む、FA(2)で必須のすべてのフィールドを出力することを確認します。
3. 本番送信の前に、サンプル文書を公式のXSDに対して検証します。
4. ksef-test.mf.gov.plでエンドツーエンドのテストケースを実行します。標準的なB2Bインボイス、修正インボイス(faktura korygujaca)、リバースチャージインボイス(mechanizm odwrotnego obciazenia)、MPPフラグ付きインボイスなどです。

5. Zunaproを通じてマーケットプレイスをKSeFに接続する

1. Zunaproにサインインし、ポーランド会計モジュールを開きます。
2. KSeFロールを接続 — APIトークンを貼り付け、適格シール証明書をアップロードします。
3. マーケットプレイスを接続 — Allegro、Amazon.pl、Empik、Ceneo、Morele.net、Erli — を標準のマーケットプレイスタイル経由で接続します。
4. 注文をFA(2)にマッピング — 標準スキーマにはワンクリックマッピング、上級ユーザーはマーケットプレイスごとのオーバーライドを調整できます。
5. 本番稼働 — 初回同期で、保留中のすべてのB2B注文について遡及的にインボイスを発行し、その後は注文の到着に応じてライブインボイスがストリーミングされます。

KSeF FAQ — 2026年版