スペインの電子請求書改革、請求書を
より複雑に — 簡素化とは程遠く

1つの国に3つの電子請求書システム — しかも連携していない

「スペインが電子請求書を導入している」と聞いて、ほとんどの非スペイン企業が想定するのは、単一の国家システムです。しかし、そうではありません。スペインには、請求書の作成、署名、送信、保存を規定する3つの並行した規制枠組みが存在し、それぞれ異なる法的権限のもとで異なる目的を果たしています。

これら3つのシステムは代替関係ではありません。共存します。マドリードに拠点を置き、売上高500万ユーロの企業は、請求書ソフトウェアがレコードを生成する方法についてVerifactuに準拠し、B2B請求書の送受信方法についてCrea y Creceに準拠する必要があります。ビルバオの企業は、Verifactuの代わりにTicketBAIに準拠し、さらにB2B送信についてはCrea y Creceに準拠する必要があります。売上高1000万ユーロで既にSIIを利用している企業はVerifactuが免除されますが、Crea y Creceには準拠する必要があります。ベン図は3つの独立した円ではなく、所在地、企業規模、既存のコンプライアンス状況によって異なる重複する義務です。

Verifactu：延期を繰り返す国家規格

Verifactuは、スペインの脱税防止法（Ley 11/2021、一般税法第29.2.j条を改正）の構成要素であり、請求書発行ソフトウェアを規制します。中核要件は、スペインで請求書を発行するすべてのコンピュータシステムが、改ざん防止機能付きで暗号的に連鎖された請求書記録を生成することです。各請求書を前の請求書にリンクするデジタルフィンガープリント（ハッシュ）により、破ることのできない監査チェーンを形成します。請求書には、AEATのデータベースで検証するためのQRコードを記載する必要があります。監査証跡を残さずに請求書記録を削除・修正できるソフトウェアは禁止されています。

期限は2度延期されました。当初は2025年7月1日でしたが、まず2026年に延期され、その後、2025年12月2日のReal Decreto-Ley 15/2025により、法人は2027年1月1日、個人事業主は2027年7月1日に延期されました。ソフトウェアベンダーは2025年7月29日までに非準拠システムの販売を停止する必要がありましたが、この期限は部分的な準備状況のまま経過しました。AEATは認定ソフトウェアのリストを管理しており、2026年半ば時点で、Holded、Quipu、Billinなどの主要プラットフォームはVerifactu対応済みですが、数千の小規模な請求ツールやカスタムERPモジュールは未対応です。

Verifactuが請求書の受取人にとって意味するのは、新しい視覚的要素、すなわちQRコードです。Verifactuモード（AEATへのリアルタイム送信、任意だが推奨）では、請求書に「VeriFactu」または「Factura verificable en la sede electrónica de la AEAT」というラベルと、AEATの検証ポータルにリンクするQRコードが記載されます。非Verifactuモード（安全なローカル保存、自動送信なし）でも、請求書にはQRコードと連鎖ハッシュが記載されますが、「VeriFactu」ラベルはありません。受取人の観点からは、どちらのモードでも、Verifactu以前の請求書とは異なる外観の請求書が生成されますが、基礎となるデータ項目（NIF、課税標準、IVA、IRPF）は同じです。

TicketBAI：なぜバスク州は独自システムを構築したのか

フォラル税務当局を持つスペインの自治州（バスク州とナバラ州）は、独自の税制を管理する憲法上の権限を有しています。バスク州はこの権限を活用して、不正防止のための請求書発行システムであるTicketBAIを創設しました。これはVerifactuと概念的に類似していますが、運用上は別個のシステムです。TicketBAIは、バスク政府と協力して、3つのフォラル財務省（アラバ、ギプスコア、ビスカヤ）によって開発されました。

TicketBAIでは、発行時点での請求書データのリアルタイム送信が義務付けられています（Verifactuのように任意ではありません）。各県で実装は若干異なります。ギプスコアとアラバは、それぞれのフォラル税務当局への即時送信を要求する一方、ビスカヤ（Batuzフレームワーク下）では、指定された期間内での送信を許可し、追加の会計データ（LROE帳簿）を統合します。県税務当局のデータによると、2023年までにアラバだけでも1日あたり30万件のTicketBAI請求書を処理していました。

このフォーマットの違いは、バスク州のサプライヤーから請求書を受け取るAPチームにとって重要です。TicketBAI請求書には、TBAI識別コードと、AEATではなくフォラル税務当局の検証ポータルに誘導するQRコードが記載されています。XMLチェーンはVerifactuとは異なる署名メカニズムを使用しています。請求書のラベルは、スペイン語と併記または代わりにバスク語（Euskara）で表示される場合があります。「Guztira」（合計）、「Oinarria」（課税標準）、「BEZ」（IVA）などです。これらの違いは、コアデータフィールド（金額、税ID、税率は同じ）には影響しません。ただし、フィールド識別のためにスペイン語のラベルに依存するツールには影響します。

Crea y Crece：B2B義務化がもたらす新たな対応レイヤー

VerifactuとTicketBAIが請求ソフトウェアによる請求書生成を規制する一方、Ley Crea y Creceは企業間での請求書送信方法を規定します。同法第12条では、すべてのB2B請求書は電子形式かつ構造化データで、相互運用可能なプラットフォームエコシステムを通じて交換することが義務付けられています。施行規則であるReal Decreto 238/2026は、2026年3月24日に閣議承認され、同年3月31日にBOEで公布されました。

スケジュールは、今後発出される省令（2026年10月1日発効見込み）をトリガーとして、遵守までのカウントダウンが始まります。

• 省令発効から12ヶ月後（2027年10月見込み）： 年間売上高800万ユーロ超の事業者はB2B電子請求書の発行・受領が義務化
• 省令発効から24ヶ月後（2028年10月見込み）： 個人事業主を含むその他すべての事業者・専門職が対象
• 省令発効から36ヶ月後（2029年10月見込み）： 小規模事業者もAEATへの支払状況データ報告が義務化

許容される形式は欧州規格EN 16931に準拠し、FacturaE、UBL 2.1、またはCIIとして実装されます。注目すべきは、省令案において公共プラットフォームの主要形式がFacturaEからUBLに移行する点です。受領者は、請求書の受諾・拒否・全額または一部支払いのステータスを4暦日以内にAEATへ報告する必要があります。公共プラットフォーム（SPFE、Sistema Público de Facturación Electrónica）はAEATが運営し、相互運用可能な民間プラットフォームとともに無料で提供されます。

買掛金管理チームにとって、Crea y Creceは2つの意味を持ちます。第一に、入金請求書の形式が変わります。これまでPDFを送付していた取引先が、構造化された電子請求書を送信し始めるでしょう。第二に、そしてより問題なのは、移行期間中に形式が混在する長いテールが発生することです。一部の取引先はUBL/CIIに移行し、別の取引先はFacturaEのまま、そしてかなりの数の取引先は罰則の有無にかかわらず、従来通りの形式で送信し続けるでしょう。

APの悪夢シナリオ：3つのフォーマットすべてを受け取る場合

2027年半ばの現実的なシナリオを考えてみましょう。マドリードに拠点を置く、売上高400万ユーロの流通企業が、毎月80件の仕入先請求書を受け取ります。その仕入先は以下の通りです。

• マドリード、バルセロナ、バレンシアの35社の仕入先：すべてVerifactu準拠の請求書を発行。一部は「Verifactuモード」で、リアルタイムにAEATへ送信され、文書に「VeriFactu」ラベルが付与されます。その他は非Verifactuモードで、QRコードはあるがリアルタイムフラグはなし。請求書のレイアウトは、Holded、Quipu、Billin、Sage、FacturaDirecta、カスタムERPモジュールなど、仕入先の請求プラットフォームによって異なります。
• バスク地方（ビルバオ、サン・セバスティアン、ビトリア＝ガステイス）の12社の仕入先：すべてTBAIコード付きのTicketBAI請求書を発行。一部のラベルはバスク語。QRコードはAEATではなく、フォラル税務当局のポータルにリンク。XMLチェーンは異なるハッシュメカニズムを使用。
• 零細企業または老舗企業である8社の仕入先：更新されていないレガシーソフトウェアから、Verifactu非対応、TicketBAI非対応のPDFを引き続き発行。これらの請求書は技術的には非準拠ですが、受信箱に届き、処理する必要があります。
• EU圏内の5社の仕入先：0% IVAと「Inversión del sujeto pasivo」の注記が付いた、リバースチャージ方式の請求書を送付。これらはVerifactuにもTicketBAIにも準拠しません。
• すでにCrea y Crece B2Bに移行した20社の仕入先：4日以内に受領確認が必要な、UBLまたはFacturaE構造化請求書を送付。

APチームの受信箱には、4つのフォーマット（Verifactu、TicketBAI、レガシー、Crea y Crece B2B）、2つの税務当局の管轄、異なる視覚的レイアウトを生成する少なくとも3つのソフトウェアエコシステム、そして構造化（XML/UBL）と非構造化（PDF）のフォーマットが混在しています。チームの仕事は変わりません。NIF、課税標準、IVA内訳、IRPF源泉徴収、合計金額を会計システムに入力することです。フォーマットの断片化により、その仕事が単純に難しくなったのです。

スペインの単一の会計プラットフォームで、これら4つのフォーマットすべてをシームレスに処理できるものはありません。HoldedはFacturaEとVerifactuを認識しますが、TicketBAI XMLは処理しません。TicketBAI認定のバスクプラットフォームはTBAI請求書を処理しますが、Crea y Creceが要求する特定のUBLバリアントを処理できない場合があります。エンタープライズSIIプラットフォームはリアルタイムのAEATデータを処理しますが、零細企業からのPDFを取り込むようには設計されていません。抽出ステップ、つまり到着したフォーマットからデータを取り出す作業は、普遍的なボトルネックであり続けています。

APチームにとっての意味：フォーマットの断片化とデータ抽出

構造的な問題は、これらのシステムのいずれかが設計不良であることではありません。Verifactuのハッシュチェーンは暗号学的に堅牢です。TicketBAIのリアルタイム送信は、バスク地方でVAT詐欺を測定可能なほど削減しました。Crea y Creceの4日以内のステータス報告は、10年にわたりEU平均を上回ってきたスペインの慢性的な支払い遅延問題に対処しています。

問題は、これらすべてを受領する側の視点で設計されたシステムが存在しないことです。法律は発行者の視点で書かれました。「請求書を発行する際、コンプライアンスを満たす方法はこれです」と。受領者の視点——「80のサプライヤーが80の異なるコンプライアンス形式で請求書を送ってきた場合、データを抽出する方法はこれです」——は、市場が解決すべき実装の詳細として残されました。

これはスペインに限った話ではありません。イタリアのFatturaPA、フランスの電子請求書義務化、ドイツのViDA計画も、それぞれの国境で同様の断片化を生み出しています。スペインのケースが深刻なのは、その同時性にあります。3つの主要な改革が12ヶ月間（2027年）に集中し、サプライヤーベースの異なるセグメントに異なる時期に影響を及ぼし、3つのシステム間で統一されたフォーマット仕様が存在しないことです。

APチームの運用上の対応は、フォーマットの統一を待つことではありません。それは実現しません。対応策は、抽出ステップをコンプライアンス形式から切り離すことです。請求書の視覚的レイヤーを読み取るツールは、QRコードがAEATに向かうのか、ギプスコア県税務当局に向かうのかを気にしません。APにとって重要なフィールド——NIF、課税標準、IVA、IRPF、合計——を、どのコンプライアンス基盤が文書を生成したかに関係なく、同じ方法で読み取ります。

ソフトウェア認証の問題：取引先のツールがデータ形式を決める

VerifactuとTicketBAIの両制度において、認証ソフトウェアの使用義務は発行側にあります。受領側は取引先がどのソフトウェアを使用するかを管理できず、結果として請求書の形式も管理できません。これにより非対称性が生じます。取引先は認証済みの請求ツールを購入すれば法律に準拠でき、受領側はそのツールが生成する出力をそのまま受け入れざるを得ません。

さらに悪いことに、認証プロセス自体がまだ進行中です。AEATのVerifactu認証ソフトウェアリストは増えていますが、不完全です。一部の主要ERPベンダーは2026年初頭に認証を取得しましたが、特定業種向けの小規模なニッチツールはまだ審査中です。このギャップ期間中、取引先は「Verifactu対応」と謳いながらも、最終仕様から逸脱した出力を生成するツールを使用する可能性があります。受領側は一見準拠しているように見えても、現行基準に対する検証に失敗する書類を受け取ることになります。

罰則体系もこの非対称性を強化します。Verifactuでは、非準拠ソフトウェアを使用する事業者は会計年度ごとに最大5万ユーロの罰金、ソフトウェアベンダーは非準拠製品1つにつき年間最大15万ユーロの罰金が科せられます。非準拠の請求書を受け取ることに対する罰則はなく、発行に対する罰則のみです。コンプライアンス負担は完全に供給側にありますが、受け取ったものを処理する運用負担は完全に需要側にあります。

移行期（2026～2028年）の実践的な道筋

スペインの取引先請求書を処理するAPチームにとって、今後2年間は収束を期待するのではなく、形式の多様性を前提とした戦略が必要です。実践的な手順は以下の通りです。

1. 少なくとも2029年までは、受信箱に混在形式が届くことを受け入れる。Crea y Creceの展開は、省令が予定通り公布されたとしても、小規模取引先には2028年後半までの準拠期限が与えられ、執行は法的期限より遅れます。一部の取引先は、期限を過ぎても改革前のPDFを送り続けるでしょう。

2. 形式に依存しないデータ抽出を中心にAPワークフローを構築する。Verifactu、TicketBAI、Crea y Crece、レガシー形式に共通するのは視覚データです。NIF、金額、IVA税率、IRPF源泉徴収、日付です。レンダリングされた書類からこれらのフィールドを抽出するツール（XMLを解析したりテンプレートを照合したりしないもの）は、すべての形式で同じように機能します。これにより、請求書の種類ごとに個別の処理経路を維持する必要がなくなります。このワークフローの設定詳細については、単一請求書の場合はスペイン請求書データのExcelへの抽出、複数取引先ワークフローの場合はスペイン取引先請求書の一括処理を参照してください。

3. コンプライアンス層とデータ層を分離する。VerifactuやTicketBAIの請求書にあるQRコードは、税務検証や監査対策には有用ですが、データ入力には役立ちません。これら2つの機能を混同しないでください。コンプライアンスアーカイブ用に元の請求書ファイル（QRコードと電子署名をそのまま）を保存します。スペイン法では税務目的で4年間、商法で6年間の保存が義務付けられています。データは別途会計システムに抽出します。2つの出力は異なる目的を果たすため、互いに制約すべきではありません。

4. バスク地方の取引先は別途計画する。APボリュームにTicketBAI請求書が多く含まれる場合は、抽出ツールがバスク語のラベルを認識し、スペイン語のテキスト文字列の照合に依存しないことを確認してください。「Guztira」は合計金額として認識される必要があります。「BEZ」はIVAとして認識される必要があります。これは形式の問題ではなく、言語適応の問題です。

5. Crea y Creceのステータス報告義務を監視する。 請求書の受領・拒否・支払いステータスを4日以内に報告する義務は、大企業から順に適用され（2027年10月予定）、その後中小企業へと段階的に拡大します。これはこれまでにない新たな業務タスクです。データ抽出ワークフローと並行して、請求書受領日の追跡とステータスレポート生成のプロセス構築を開始してください。公開プラットフォーム（SPFE）が報告インターフェースを提供しますが、それを支える内部システムが必要です。

スペイン語圏市場における文書抽出の仕組みと、様々な価格帯で利用可能なツールの詳細な分析については、スペイン語圏市場向けの手頃な抽出ツールをご覧ください。EU市場間の比較については、フランスのTPE向け低予算請求書抽出をご参照ください。

よくある質問

Verifactuは電子請求書の義務化と同じですか？

いいえ。Verifactuは請求書作成ソフトウェアがどのように請求書レコードを生成・保存するかを規定するもので、ソフトウェアの完全性に関する不正防止措置です。Crea y Creceは、企業間のB2B請求書が構造化された電子形式でどのように送信されるかを規定するもので、データ交換に関する電子請求書義務化です。両者は別個の法的措置であり、期限も異なりますが、いずれも2025年から2028年の期間に施行されます。Crea y Creceの公開プラットフォームで生成された請求書は自動的にVerifactuに準拠するため、公開ソリューションの利用者は両方の義務を同時に満たせます。

受け取ったVerifactu請求書のQRコードはすべて検証する必要がありますか？

受け取った請求書のQRコードを検証する法的義務はありません。ただし、税務調査時にAEATが仕入先請求書の有効性を疑問視した場合、QRコードが唯一の防御手段となります。コードをスキャンすることで、その請求書がAEATのシステムに適切に登録され、改ざんされていないことが確認できます。高額な請求書や新しい取引先との関係においては、コンプライアンス上の保護措置としてQRコードの検証を推奨します。既存の信頼できる取引先からの日常的な請求書については、QRコードを原本とともに保管し、リアルタイムでの検証は不要です。

Verifactuの請求書を取引先から受け取ったが、その取引先はTicketBAIに対応すべき場合、どうなりますか？

バスク地方に税務上の住所がある取引先は、VerifactuではなくTicketBAIの請求書を発行する必要があります。もしVerifactu準拠の請求書を発行した場合、違反は取引先側にあります。取引先はTicketBAIの義務に違反しており、フォラル税務当局から罰則を受ける可能性があります。受領者であるあなたは、取引先のコンプライアンス違反に対して責任を負いません。請求書は通常通り処理できます。基礎となるデータ項目は構造的に同じです。ただし、取引先にその旨を伝えてください。取引先の違反は、VerifactuとTicketBAIのデータベース間の相互参照で表面化し、IVA控除が遅れる可能性があります。

Crea y Creceの下でのUBLへの移行は、AP抽出ワークフローに影響しますか？

抽出ツールがXMLを解析するのではなく、視覚的なレイヤーを読み取る場合、影響はありません。FacturaEからUBLへの移行は、基礎となるXMLスキーマを変更しますが、PDFビューアでレンダリングされる請求書の視覚的な外観は変わりません。抽出する項目（NIF、Base Imponible、IVA、IRPF、Total）は、ソースXMLがFacturaE、UBL 2.1、CIIのいずれであっても同じです。ワークフローがXML解析に依存している場合（例：FacturaEのXMLタグから直接データを抽出するスクリプト）、パーサーをUBL用に更新する必要があります。視覚的な文書からデータを抽出する場合、フォーマットの変更は無関係です。

VerifactuおよびTicketBAIの請求書でIRPF源泉徴収をどのように処理すればよいですか？

IRPF源泉徴収は、フォーマットレベルの要素ではなく、請求書のフィールドレベルの要素です。マドリードのVerifactu認定ソフトウェアで生成されたか、サン・セバスティアンのTicketBAI認定ソフトウェアで生成されたかに関わらず、IRPFの行は同じです。パーセンテージ（15%または7%）、ユーロ金額、マイナス記号です。別の列として抽出してください。バッチ集計とModelo 111との照合では、請求書のフォーマットの出所は無関係です。重要なのはIRPFの金額だけです。

改革のパラドックス

スペインの電子請求書改革は、単一の改革ではない。それは3つの改革であり、重複するタイムラインで進行し、異なる政策目標（不正防止、支払遅延削減、税の透明性）を掲げ、異なる当局（VerifactuとCrea y CreceはAEAT、TicketBAIはフォラル財務省）によって管理され、AP受信箱という一点に収束する文書を生成する。これらの改革は、紙、PDF、非構造化形式の無秩序な状態を、構造化され追跡可能なシステムに置き換えることで、スペインの請求書エコシステムに秩序をもたらすために設計された。しかし、少なくとも2029年まで続く移行期間において、彼らが生み出したものはその逆である。すなわち、より多くの形式、より多くのコンプライアンスのベクトル、そして会計ソフトがネイティブに取り込めない構造でデータが届く、より多くの方法である。このパラドックスが解消されるのは、抽出ステップを形式から分離したときだけである。ページを生成したものではなく、ページに書かれているものを読め。残りはそれに従う。