フェーズ1とフェーズ2は別種の課題です
フェーズ1(発行段階)で求められたのは、QR コードと所定の項目を備えた構造化電子インボイスでした。要件を満たす書類を作成できる請求システムであれば対応でき、データが社外に出ることもありませんでした。フェーズ2(統合段階)はまったく別種の作業です。発行するすべてのインボイスについてシステムが ZATCA のプラットフォームと通信し、税務当局から応答が返ってきます。
多くのチームがつまずくのは、まさにこの一点の変化です。フェーズ1の実装は書類フォーマットの問題でした。フェーズ2の実装は、暗号鍵、有効期限のある証明書、そしてレジ担当者と印刷されたインボイスとの間に入り込む外部依存を抱えた、可用性が決定的に重要なシステム連携です。
クリアランスとレポーティングは別の流れです
標準税務インボイス(事業者間取引の書類)はクリアランスの対象です。買い手に渡す前にインボイスを ZATCA に提出し、ZATCA が承認して署名済みの写しを返した時点で、初めて法的に有効な税務インボイスとなります。クリアランスに失敗した場合、インボイスはまだ存在しないことになります。
簡易税務インボイス(一般的な消費者向けの POS レシート)はレポーティングの対象です。レシートはその場で発行して手渡し、その後、公表された期限内に ZATCA へ報告します。顧客がネットワークの応答を待つことはありません。
実務上の帰結として、POS と B2B 請求では障害時の動作を変える必要があります。店舗のレジは接続が切れても販売を続け、後で照合しなければなりません。B2B インボイスは、クリアランスが完了するまで発行済みとして扱ってはなりません。
暗号化の構成要素とその順序
統合作業の大半は、認証情報を順番に揃えていく作業です。各ステップは前のステップに依存しており、どこでも導入が止まる可能性があります。
- デバイスごと、または請求単位ごとに生成する鍵ペアと証明書署名要求(CSR)。VAT 登録情報を ZATCA が指定するとおりの項目に正確に記載します。
- その CSR を ZATCA ポータルのワンタイムパスワードとともに提出して取得するコンプライアンス証明書。OTP の有効期間が短いため、最も失敗の多いステップです。
- コンプライアンスチェック。発行予定のすべての種類について、サンプルのインボイス、クレジットノート、デビットノートが受理されて初めて次に進めます。
- 本番用証明書。実際に本番の書類に署名するのはこの証明書であり、有効期限が来るずっと前から誰かが責任を持って管理しなければなりません。
インボイス自体に含めなければならないもの
提出する書類は PDF ではなく UBL 2.1 形式の XML です。その中に、インボイスを検証可能にする要素が含まれます。直前のインボイスの暗号ハッシュ(書類同士を連鎖させ、削除や挿入を検出可能にするもの)、デジタル署名、そして販売者名、VAT 番号、タイムスタンプ、合計額、VAT 額、署名データを所定のバイナリ形式で格納した QR コードです。
人が読める出力も依然として重要です。買い手は保管できる書類を求めるため、多くの実装では署名済み XML を埋め込んだ PDF/A-3 を作成し、人が読めて機械でも検証できる一つのファイルにしています。
設計段階で備えるべき障害パターン
本番環境でこれを運用したことのあるシステムは、どれも同じ短いリストに直面しています。いずれも後から直すバグではなく、設計上の判断事項です。
- ZATCA に接続できない、または応答が遅い。簡易インボイスはキューに入れて後で報告すべきですが、標準インボイスはそのまま発行することはできません。レジ担当者の画面に何を表示するかを、事前に決めておいてください。
- 証明書の有効期限切れ。更新はインシデント対応ではなく、計画された運用業務です。本番用証明書が失効すると、インボイス発行が完全に止まります。
- ERP では許容されるが ZATCA では認められない項目によるインボイスの却下。特殊な数量単位や、XML マッピングで表現できない形でモデル化された値引き行・配送料行などが該当します。
- バックアップからの復元やデータベースの手作業による修正の後にハッシュチェーンが途切れ、以降のすべてのインボイスがその問題を引き継ぐ。
ベンダーに確認すべきこと
「準拠しています」と言うのは簡単です。役に立つのは具体的な質問です。サンドボックスではなく本番環境で、どの書類種別のクリアランスとレポーティングを実績として通していますか。ZATCA がタイムアウトしたとき、その販売はどうなりますか。証明書は誰が更新し、何がその人に通知しますか。解約する場合、署名済み XML とハッシュチェーンをエクスポートできますか。フェーズ2を実際に運用してきたベンダーなら、具体的な答えを持っているはずです。どの項目も、いずれかの時点で丸一日を費やす原因になってきたからです。
よくある質問
ZATCA のフェーズ1とフェーズ2の違いは何ですか?
フェーズ1(発行段階)で求められたのは、QR コードと所定の項目を備えた構造化電子インボイスであり、データが社外に出ることはありませんでした。フェーズ2(統合段階)は別種の作業で、発行するすべてのインボイスについてシステムが ZATCA のプラットフォームと通信し、税務当局が応答します。フェーズ1は書類フォーマットの問題であり、フェーズ2は暗号鍵、有効期限のある証明書、そしてレジ担当者と印刷されたインボイスの間に入る外部依存を伴う、可用性が決定的に重要なシステム連携です。
フェーズ2におけるクリアランスとレポーティングの違いは何ですか?
標準税務インボイス(事業者間取引の書類)はクリアランスの対象で、買い手に渡す前に ZATCA に提出し、ZATCA が承認して署名済みの写しを返した時点で初めて法的に有効な税務インボイスとなります。簡易税務インボイス(一般的な POS レシート)はレポーティングの対象で、レシートをその場で発行して手渡し、その後、公表された期限内に ZATCA へ報告します。顧客がネットワークの応答を待つことはありません。
ZATCA に接続できない、または応答が遅いとき、レジではどうなりますか?
二つの流れでは障害時に必要な動作が異なり、これは後から直すバグではなく設計上の判断事項です。簡易インボイスはキューに入れて後で報告すべきであり、そうすれば店舗のレジは接続が切れても販売を続け、後で照合できます。標準インボイスはそのまま発行することができないため、レジ担当者の画面に何を表示するかを事前に決めておいてください。
フェーズ2のインボイスには実際に何を含める必要がありますか?
提出する書類は PDF ではなく UBL 2.1 形式の XML です。その中には、直前のインボイスの暗号ハッシュ(書類を連鎖させ、削除や挿入を検出可能にするもの)、デジタル署名、そして販売者名、VAT 番号、タイムスタンプ、合計額、VAT 額、署名データを所定のバイナリ形式で格納した QR コードが含まれます。買い手は保管できる書類も求めるため、多くの実装では署名済み XML を埋め込んだ PDF/A-3 を作成しています。
フェーズ2の連携について、ベンダーに何を確認すべきですか?
「準拠しています」と言うのは簡単なので、質問は具体的にしてください。サンドボックスではなく本番環境で、どの書類種別のクリアランスとレポーティングを通していますか。ZATCA がタイムアウトしたとき、その販売はどうなりますか。本番用証明書は誰が更新し、失効前に何がその人に通知しますか。解約する場合、署名済み XML とハッシュチェーンをエクスポートできますか。
このガイドは一般的な情報であり、税務・会計・法律上の助言ではありません。規則は国によって異なり、変更されることがあります。行動する前に、所管の税務当局または専門家に最新の状況をご確認ください。
単一のワークスペースで業務を運営する準備はできていますか?