VERI*FACTUと独自開発の請求ソフトウェア：2027年1月1日までにスペインが求めること

セロ・デ・サン・イシドロから見たマドリードの屋根と教会のドーム

2027年1月1日より前に、スペインで法人税（Impuesto sobre Sociedades）を申告し、ソフトウェアで請求書を発行しているすべての会社は、Real Decreto 1007/2023に対応したソフトウェアを使っていなければなりません。すべての請求書に、直前の記録と連鎖するハッシュ付きの記録と、顧客が税務当局に照会できるQRコードが付きます。対象となるそれ以外の者、主に個人事業主の期限は2027年7月1日です。

請求書が市販のパッケージから出ているなら、これは大部分がベンダーの仕事です。誰かが御社のために書いたソフトウェア、あるいは自社のチームが書いたソフトウェアから出ているなら、御社の仕事です。コードを変更し、準拠していると宣言する書面に署名するのも御社です。

日程と2度の延期

今回は3度目の日程なので、多少疑ってかかるのも無理はありません。

Real Decreto 1007/2023 は当初、事業者に2025年7月1日までの期限を与えていました。
2025年4月1日の Real Decreto 254/2025 が、これを法人税の申告者は2026年1月1日、それ以外は2026年7月1日に移しました。理由は具体的で、技術的な省令であるOrden HAC/1177/2024の公布が2024年10月28日までずれ込んだためです。
2025年12月2日の Real Decreto-ley 15/2025 が、両方の日付を1年ずつ動かしました。本文はBOEに掲載されており、議会は同じ月にこれを承認しています。

2026年3月26日に更新されたAEAT（スペイン税務当局）の延長に関するお知らせは、曖昧さのない書き方をしています。「las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027.」

また動く可能性はあるでしょうか。2026年10月時点で、そう示す公式の情報はありません。最初の延期には技術的な原因があり、その原因はもう存在しません。AEATの送信サービスは2025年4月23日から本番稼働しており、2025年7月29日以降、ソフトウェアベンダーは対応済みのシステムしか提供できなくなっています。3度目の延期を前提にするのは、計画ではなく賭けです。

自社の期限はどちらか。 SLやSAはImpuesto sobre Sociedadesを申告するので、自社のERPを動かしている会社はほぼ確実に2027年1月1日組です。残りは3か月を切っています。7月の期限は、個人事業主と対象となるその他の納税者のためのものです。

対象になる者、ならない者

AEATの適用範囲に関するFAQは、これを4つの否定条件にまとめています。請求書を手作業だけで発行しておらず、SIIに（義務としても任意でも）加入しておらず、税務上の住所がバスク州やナバラ州になく、適用除外の裁定も受けていないなら、対象です。

実務上の除外は次のとおりです。

SIIの対象者。 Suministro Inmediato de Información（SII）は、売上高600万ユーロ超の会社、VATグループ、毎月のVAT還付登録簿（REDEME）に登録した事業者には義務で、それ以外の事業者も任意で加入できます。AEATの言い方は明快です。「El ámbito subjetivo de ambos proyectos es excluyente.」SIIに移れば、VERI*FACTUの記録の送信もQRコードの印字も不要になります。
バスク州とナバラ州。 税務上の住所がこれらの地域にある事業者は、RD 1007/2023ではなく、各地域の税務当局とその独自のルールに従います。
完全な手作業による請求。 紙の請求書帳は対象外です。請求書を入力、印刷、保管するためだけに使うスプレッドシートも対象外ですが、VATの帳簿まで作っているものは対象です。

外国企業も、スペインに恒久的施設を持っていれば対象になります。

市販のパッケージ（A3、Sage、Holdedなど）で請求しているなら、ベンダーが製作者であり、独自の宣言書を付けた対応版を提供しなければなりません。アップデートし、宣言書があることを確認すれば、この先を読む必要はありません。

この記事はそれ以外の会社のためのものです。独自開発のERP、15年前に書かれたAccess、Delphi、FileMakerのプログラム、あるいは自社のWebプラットフォームに組み込まれた請求モジュールなどです。

製作者は御社自身

規則の第13条第1項は、認証の責任をシステムの製作者に負わせており、その方法はdeclaración responsable（責任宣言書）です。AEATの認証に関するFAQは、社内開発のケースに直接答えています。「Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo.」

実務上の意味は次のとおりです。

外部監査はありません。 AEATは、これを製作者による「auto-certificación」（自己認証）と呼んでいます。事前にシステムを承認してくれる人はいません。自社で署名し、その責任を負います。
外部の業者が拡張機能を製品として作った場合は、その業者がその拡張機能を認証します。 自社で作ったなら、自社が認証します。
宣言書はシステムの中で、すべてのバージョンにおいて見えなければならず、 製品とは独立に、システムの外からも参照できなければなりません。
記載内容は決まっています。 Orden HAC/1177/2024の第15条が定めており、システムの名称、識別子、バージョン、構成要素、VERI*FACTUモード専用かどうか、製作者の名称、NIF、住所、署名の日付と場所などが含まれます。

厄介なのは、作者が何年も前に辞めたプログラムです。それでも誰かが対応版を作り、署名しなければなりません。作業を始める前に、それが誰なのかを書面で決めておいてください。

認証済みの市販製品をカスタマイズした場合、別の宣言書が必要になるのは、その変更が規則の要件の実装方法に関わるときだけです。製作者の管理外で行われ、要件の実装を変えうる改変は、準拠していないことになります。

何が懸かっているかは、一般税法第201条の2が定めています。要件を満たさないシステムを製作した場合は、会計年度ごと、システムの種類ごとに15万ユーロの定額の罰金です。認証されているべきなのにされていないシステム、または改変されたシステムを保有している場合は、会計年度ごとに5万ユーロです。自社開発のシステムにどちらが適用されるかは、税務アドバイザーに確認すべき問題です。どちらの金額も小さくはありません。

ソフトウェアがしなければならないこと

発行の時点で、すべての請求書に記録を作る

第9条第1項は、システムが registro de facturación de alta（発行記録）を「de forma simultánea o inmediatamente anterior a la expedición de cada factura」生成することを求めています。無効にした請求書には、取消記録（registro de anulación）を作ります。

第10条は、記録に含まれる内容を列挙しています。発行者のNIFと名称、必要な場合は受領者、シリーズと番号、発行日と取引日、請求書の種別、訂正対象の請求書があればその詳細、内容の説明、合計額、VATの制度、課税標準、税率と税額、非課税または課税対象外の理由、システムとその製作者の識別情報、そして秒単位のタイムスタンプです。

古いシステムでは、作業はここに隠れています。

VATの内訳は印刷時に計算されることが多く、 保存されていません。発行の時点でデータとして存在していなければなりません。
「発行」が帳票を印刷するだけ、ということがよくあります。 下書きが請求書になる明確な時点が必要で、記録はそのときに作られます。
番号の再利用はもうできません。 請求書を削除してその番号を使い回すのは小さなシステムでよくある習慣ですが、これからは通りません。AEATは2件目の記録を「Registro de facturación duplicado.」として差し戻します。本番環境で発行したテスト請求書も本物の請求書であり、取り消さなければなりません。
誰も記録を編集しません。 AEATのFAQは、発行済み記録のデータベースを直接変更することを、許される操作にしてはならないとしています。いま担当者がSQLで請求書を直しているなら、それは終わりです。訂正は訂正請求書で行います。

ハッシュチェーン

各記録は、直前の記録のシリーズ、番号、日付と、そのハッシュ（huella）の一部を持ちます。アルゴリズムはSHA-256で、対象となる項目と連結の正確な方法は、AEATの技術文書に記録の設計、XSDスキーマ、WSDL、検証とエラーの一覧とともに載っています。

新しい記録を生成する前に、システムは直前の記録が正しく連鎖していること、そしてそのタイムスタンプが現在時刻より1分を超えて先になっていないことを確認しなければなりません。記録は請求書を発行した順に生成されます。

これはアーキテクチャに影響します。各導入環境には、記録を作る直列化された場所が1か所だけ必要です。2台のWebサーバーが連携せずに同じチェーンに追記すれば、チェーンは壊れます。AEATは、中央のバックオフィスから記録を受け取るPOS端末のような混成構成も認めていますが、チェーンそのものは1か所にあります。

各システムは、納税者のNIF、2文字のシステムID、そして同じソフトウェアを同じマシンに再インストールした場合でも二度と繰り返してはならない導入番号で識別されます。

請求書のQRコード

すべての請求書には、ISO/IEC 18004に従ったQRコードを、30x30mmから40x40mmの大きさで、誤り訂正レベルMで載せます。QRコードには、発行者のNIF、シリーズと番号、発行日、合計額を含むURLが入っており、顧客はこれでAEATに照会できます。VERI*FACTUモードでは、請求書に「VERI*FACTU」または「Factura verificable en la sede electrónica de la AEAT」とも記載します。

レガシーなソフトウェアにとっては、請求書のテンプレート（Accessの帳票、FileMakerのレイアウト、PDF生成機能）を作り直し、QRライブラリなど一度も使ったことのない技術スタックにそれを加えることを意味します。

2つのモード：VERI*FACTUか、そうでないか

VERI*FACTUモード。 システムは、生成したすべての記録をその都度、自動的にAEATへ送ります。その代わり、記録にはハッシュが必要ですが電子署名は不要で、記録はAEATが保管し、このモードでしか動かないシステムにはイベントログも要りません。必要なのは、AEATが公開しているサービスに対するSOAPクライアント、適格電子証明書、そして接続に失敗したときのキューです。AEATの開発者向けFAQは、障害をインシデントとして扱っています。記録はキューで待機して再送され、請求業務はそのまま続けられます。

非VERI*FACTUモード。 記録は自社で保管し、各記録に適格証明書で署名（XAdES Enveloped、ETSI EN 319 132）しなければなりません。システムは署名付きのイベントログも保持しなければならず、このモードでの起動と停止、異常検知とその結果、バックアップからの復元とエクスポートを記録し、稼働6時間ごとに少なくとも1回は要約イベントを残します。さらに、AEATから求められたら記録を提出しなければなりません。

独自開発のシステムなら、通常はVERI*FACTU専用のほうが構築範囲は小さくなります。署名の基盤も、イベントログも、異常検知のツールも要りません。両方のモードを提供するシステムは、そのすべてを実装しなければなりません。

2027年1月1日に間に合う計画

10月初めから数えると、法人税の申告者に残されているのは約13週間です。うまくいく順番は次のとおりです。

第1週：棚卸し。 請求書を発行するシステムをすべて洗い出します。ERP、Webショップの請求モジュール、サブスクリプションのスクリプト、店頭の端末などです。SIIの対象でも、地域独自のルールの対象でもないことを確認します。
第1週から第2週：誰が署名し、どのモードにするかを決める。 システムごとに製作者を指名します。特別な理由がない限り、VERI*FACTU専用を選びます。会社の適格証明書が存在し、管理する担当者がいることを確かめてください。AEATの開発者向けFAQが指摘するとおり、証明書がなければシステムは動きません。
第2週から第4週：データのギャップ分析。 システムが保存しているものを、第10条とAEATの記録設計と比べます。VATの内訳、請求書種別のコード、訂正の参照情報が欠けていることがここで分かります。
第3週から第8週：構築。 発行時の記録生成、チェーンとその検査、改変できない保存、取消し、すべてのテンプレートへのQR、再送キュー付きの送信クライアントです。発行済み記録の直接編集はできないようにします。
第6週から第10週：テスト。 AEATのテスト環境から始め、その後に本物の記録を送ります。AEATは期限までの期間をテスト期間として扱い、その間は送信をやめて別のシステムに戻すこともできます。取消しと訂正の処理を書く前に、開発者向けFAQを読んでください。例外的なケースのほとんどが扱われています。
第9週から第12週：宣言と教育。 declaración responsableを作成し、アプリケーションの中と外で表示できるようにし、バージョンを記録します。経理部門には、番号は決して再利用しないこと、誤りは訂正請求書で直すことを伝えます。
12月半ば：稼働開始。 「antes del 1 de enero」と書かれた期限は、稼働開始日ではありません。2週間早く稼働させ、最初の問題がまだ時間のあるうちに表に出るようにします。

2027年7月1日が期限の場合も、余裕が大きいだけで同じ計画が当てはまります。5月ではなく1月に始めてください。

作り直す以外の選択肢も2つあり、率直に比較する価値があります。AEATは混成のアーキテクチャを認めているので、ERPには請求データの作成を続けさせ、購入または構築した別のコンポーネントで記録、QR、送信を生成する形にもできます。ただし、各部分がどう組み合わさるかを宣言書でカバーする必要があります。また、古いプログラムが発行する請求書が月に数通程度なら、AEATが小規模事業者向けに提供している無料の請求アプリケーションや標準パッケージのほうが、改修するより安く済むかもしれません。

ご相談先

当社は、企業がすでに運用している請求処理のコードを、古い技術スタックも含めて改修しています。記録の生成、ハッシュチェーン、既存テンプレートへのQRの追加、AEATへの送信クライアントを実装し、テストも残します。構築については電子インボイス連携サービスをご覧ください。古いプログラムの仕組みを知る人がもう社内にいない場合は、レガシーシステムの保守から始めます。

期限が2027年1月1日で、独自開発のシステムをお使いなら、office@c9group.devまでご連絡ください。当社は税務アドバイザーではなくエンジニアです。適用範囲と責任に関する問いは御社の税務アドバイザーに委ね、当社はその回答に沿って構築します。