電子インボイス連携：Peppol、XRechnung、ZUGFeRD、Factur-Xを既存システムに接続する

電子インボイス製品を買うこと自体は簡単です。問題になるのは製品ではなく、請求書を生成している12年前の受注管理システムであり、どこにも文書化されていない価格計算ロジックであり、請求番号が2019年に退職した担当者の書いたストアドプロシージャから払い出されているという事実です。

私たちが構築するのは、実際に稼働しているシステムと制度が求める形式とをつなぐコネクタです。構造化請求書の生成、検証、ネットワーク送信、受信処理、保存を、既存システムを置き換えるのではなく、そこに組み込みます。

各国の義務化と適用時期

欧州はPDF請求書から構造化された機械可読の請求書への移行を、国ごとの日程で進めています。その先には、これらを統一するEUのVAT in the Digital Age（ViDA）パッケージがあります。現在プロジェクトを動かしている期日は次のとおりです。

ドイツ：構造化電子インボイスの受信は2025年1月1日からすでに義務です。発行は、前年売上高が80万ユーロを超える事業者について2027年1月1日から、それ以外のすべての事業者について2028年1月1日から義務となります。実務上の形式はXRechnung（純粋なXML）とZUGFeRD 2.x（XMLを埋め込んだハイブリッドPDF）で、いずれもEN 16931に適合します。
フランス：受信と、大企業・中堅企業の発行が2026年9月1日から。中小企業の発行は2027年9月1日から。送信は登録プラットフォーム経由で行われ、共通のハイブリッド形式としてFactur-Xが使われます。
ベルギー：Peppol経由のB2B電子インボイスが2026年1月1日から義務化。5コーナーモデルによる電子報告が2028年に予定されています。
ポーランド：国のクリアランス基盤であるKSeF。独自のXMLスキーマと独自のスケジュールを持ちます。
イタリア：SdIとFatturaPA。2019年から稼働しており、EU域内で最も厳格なクリアランスモデルです。
スペイン：VerifactuおよびCrea y Creceによる請求義務が、地域単位のTicketBAI制度と並行して展開されています。

これら複数の国に販売しているのであれば、プロジェクトが複数あるわけではありません。1つのアーキテクチャと複数の国別アダプターがあるだけです。そう捉えるかどうかが、1本の連携で済むか5本必要になるかの分かれ目になります。

プロジェクトが行き詰まる箇所

請求データが規格の求める形で存在していない。 EN 16931は、多くのシステムがそもそも取得してこなかった項目を要求します。適切な購入者参照情報、明細単位ではなく税率単位のVAT内訳、構造化された支払条件、統制された語彙から選ぶ単位コード。手元にあるデータからこれらの項目を、今後発行するすべての請求書について決定論的に再構成すること。それがエンジニアリングの中身です。

検証エラーが事後に判明する。 拒否された請求書は、支払われない請求書です。検証は送信前に、その時点のスキーマとその時点の国別ビジネスルールに対して実行し、エラーはファイルに記録するのではなく、対処できる担当者に見える形で提示する必要があります。

受信のほうが発行より難しい。 どの企業も請求書の発行には備えますが、受信義務の開始日以降、あらゆる仕入先から適合形式で届く構造化請求書を受け入れ、1件ずつ人が開くことなく買掛管理まで流し込まなければならない、という点は見落とされがちです。

採番と冪等性。 リトライ、通信タイムアウト、プラットフォーム側の障害は日常的に起きます。異なる番号で2度送信された請求書は、ソフトウェアの問題ではなく税務の問題になります。ここは最初から正しく作る必要があります。

提供内容

アセスメントと形式の決定

通常1〜2週間の短期の作業です。請求書が実際にどのように生成されているか、どの義務がいつ御社に及ぶか、現実的な選択肢は何かを確認します。成果物は書面での推奨事項です。必要な形式はどれか、Peppolへの接続はプロバイダー経由と自社アクセスポイントのどちらが妥当か、送出元システムで何を変える必要があるか、そして費用。

市販製品に小さなアダプターを足せば足りる、という結論になることもあります。それは6か月分の請求書を出すより、最初の週にお伝えすべきことだと考えています。

請求書の生成とマッピング

御社のソースデータから必要な構文へのマッピング層を構築します。EN 16931に基づくUBLとCII、XRechnung、ZUGFeRD 2.x、Factur-X、FatturaPA、KSeF XMLに対応し、項目の導出ルールは監査担当者と経理部門のどちらも追えるように文書化します。ソースシステムが必須項目をどうしても供給できない場合は、既定値をでっち上げるのではなく、早い段階でその旨をお伝えし、データ取得の仕組みから設計します。

送信前の検証

スキーマ検証、Schematronによるビジネスルール検証、国別チェックを、社外にデータが出る前に実行します。エラーは担当者が責任を持つキューに送られ、そこに表示されるのはスタックトレースではなく、どの項目がなぜ不合格になったかを述べたメッセージです。

ネットワーク接続

Peppolアクセスポイントへの接続を、確立されたプロバイダー経由で行うか、自社で運用するか、取扱量と必要な制御の度合いに応じて選びます。クリアランスモデルを採る国については、KSeF、SdI、フランスのPDPエコシステムなど、各国プラットフォームと直接連携します。これらのプラットフォームは証明書と認証の扱いがそれぞれ異なるため、その部分も含めて対応します。

受信処理

仕入先からの請求書を受信・検証し、社内の単一の表現形式に正規化します。発注データや入荷データがある場合は突合し、買掛業務のワークフローへ引き渡します。プロジェクトの投資回収は、実はここから生まれることがほとんどです。誰も計測していなかった手入力作業がなくなるからです。

保存と監査証跡

元の構造化文書を、ドイツのGoBD、イタリアのconservazione sostitutiva、あるいは事業を行う国の同等の規則が求める形式と期間で保存します。取り出し経路は「できるはず」ではなく、実際にテストします。

連携対象システム

SAP ECCおよびS/4HANA、Microsoft Dynamics 365およびBusiness Central、Odoo、NetSuite、Sage、Infor、Xero、DATEVインターフェース、そして最も多いのは、事業運営の中核にあり、制度対応のために置き換える予定などない独自開発または大幅にカスタマイズされたシステムです。.NET、Java、PHP、Python、Node.jsで作業し、目の前にあるのがそれであれば、より古いスタックにも対応します。

マーケットプレイス、サブスクリプションプラットフォーム、あるいは請求書をプログラムで大量発行する課金基盤を運用されているのであれば、まさに私たちが想定しているケースです。請求書が御社のコードから生成される以上、コンプライアンスも御社のコードの中に置かれる必要があります。

当社が行わないこと

請求書ソフトウェアの販売は行っておらず、会計パッケージでもありません。適合請求書を作れるツールを探している小規模事業者の方であれば、製品を購入されるのが賢明です。DATEV、sevDesk、Lexwareをはじめ十数社が、この用途をきちんと満たしており、費用は連携プロジェクトのごく一部で済みます。

私たちにご相談いただきたいのは、請求書が既存の自社システムから生成されている場合、複数国のルールを併存させる必要がある場合、あるいは取扱量の関係で誰も見ていなくても動き続ける必要がある場合です。

プロジェクトの進め方

アセスメント：1〜2週間、固定価格。書面での推奨事項と費用を含む計画をお渡しして終了します。

構築：最初の1か国で通常6〜12週間。ソースデータの状態によって変わります。御社のリポジトリで、御社のブランチ運用に従い、御社のチームと一緒に作業し、テストを残して引き渡します。

パイロット：既存プロセスと並行して、限られた取引先に実際の請求書を送り、失敗率が想定水準に収まるまで運用します。

切替と稼働支援：失敗キューを監視し、担当者を明確にしたうえで、最初の月次決算と最初のVAT申告まで伴走します。本当に重要な問いが出てくるのは、この時期だからです。

準拠する規格

EN 16931とその構文バインディング（UBL 2.1、UN/CEFACT CII）、Peppol BIS Billing 3.0とPeppolの転送基盤、XRechnungとKoSITバリデーター、ZUGFeRD 2.xおよびFactur-Xの各プロファイル、FatturaPA、KSeF、そして2030年以降の姿を形づくるViDA提案。

よくあるご質問

ドイツの電子インボイス義務は、当社にはいつから適用されますか

受信義務は2025年1月1日からドイツのすべての事業者に適用されています。発行義務は、前年売上高が80万ユーロを超える場合は2027年1月1日から、それ以外は2028年1月1日からです。対象となるのは国内のB2B取引で、越境取引およびB2Cの扱いは異なるため、税務顧問に確認されることをお勧めします。

XRechnungとZUGFeRDの違いは何ですか

XRechnungは純粋なXMLで、ドイツの公共部門が定義したものであり、公的機関宛ての請求書では必須です。ZUGFeRD 2.xはハイブリッド形式で、PDF/A-3文書の中に同じ構造化データを埋め込みます。人はPDFを読み、機械はXMLを読むという構成です。いずれもEN 16931に適合します。ドイツの商取引B2Bの実務ではZUGFeRDが優勢ですが、どちらでも受け付ける買い手も多くあります。

自社でPeppolアクセスポイントを持つ必要はありますか

通常は必要ありません。多くの企業は既存のアクセスポイントプロバイダー経由で接続しており、そのほうが安価で早く済みます。自社運用が合理的なのは、取扱量が非常に多い場合、転送層まで制御する必要がある場合、あるいは他社に請求サービスを提供している場合です。

現在使っている電子インボイスベンダーと組んで作業してもらえますか

はい。むしろそれが適切な分担になることがよくあります。送信とネットワーク加盟はベンダーが担い、御社システムとベンダーAPIの間にあるものすべて（マッピング、検証、リトライ、エラー処理、突合）を私たちが構築します。

検証に通らなかった請求書はどうなりますか

どの項目がどのルールに違反したかを読める形で説明したうえで、キューに入ります。このキューは意図的に設計します。稼働直後の数か月間、システムの中で最も使われるのがこの部分であり、出来が悪いとコンプライアンスのプロジェクトが恒久的な手作業に変わってしまうからです。

同じ請求書を二重に送信しないための仕組みは

請求書のアイデンティティから導出した安定した冪等キーを、すべてのリトライを通じて引き継ぎます。加えて、何を送信したかについての正本となる送信ログを持ちます。リトライでは新しい識別子を生成せず、必ず元の識別子を再利用します。

お問い合わせ

どの国に向けて請求書を発行しているか、月あたりのおおよその件数、そして現在それを生成しているのは何かをお知らせください。どの義務がどの順番で及ぶか、そしてこれがコネクタで済む話かプロジェクトになる話かをお伝えします。

電子インボイス適合準備アセスメントのご予約は、お問い合わせフォームからご連絡ください。