ZATCA請求書XMLとPDFが
一致しない場合、どちらの値が優先されるか

ZATCA請求書は1つのコンテナに2つのレコードを持つ

署名済みXMLが請求書であり、PDF/A-3はそれを格納できるレンダリングです。 ZATCA（Zakat, Tax and Customs Authority）は、Phase 2のすべての請求書をZATCA UBL 2.1 XMLとして、またはそのXMLを埋め込んだPDF/A-3ファイルとして生成・保存することを義務付けています。XMLは署名される対象であり、標準請求書は買い手に届く前にZATCAによるクリアリングを受け、簡易請求書は24時間以内に報告されます。PDFは人間が読めるコピーです。

ZATCA電子インボイス詳細ガイドラインは、よくある疑問に直接答えています。納税者がPDFを送りたい場合、XMLを埋め込んだPDF/A-3が必須です。Phase 2では、通常のPDF、Wordファイル、スキャンは準拠した電子請求書とはみなされません。人間が読めるコピーもアラビア語である必要があり、追加言語は併記が認められています。そのため同じサプライヤー名がアラビア語と英語で2回登場することがあり、両者はマッチングルールにおいて互換ではありません。

UBL 2.1はそのフォーマットの基盤となるOASIS XML標準です。要素は2つの系統に分かれます。ID、IssueDate、TaxAmountなどの値にはcbc、AccountingSupplierPartyやInvoiceLineなどのコンテナにはcacを使用します。よく見るプレフィックスはエイリアスです。サプライヤーは同じ名前空間に異なるプレフィックス名を使えるため、パーサーは文字列cbc:を照合するのではなく名前空間を解決すべきです。ZATCA XML実装標準は、UBLとEN 16931の上にサウジアラビアのルールを追加しています。

PDF/A-3は、ファイルの埋め込みを許可するアーカイブ用PDFの一種です。ハイブリッド請求書は、通常の見た目のページと添付ファイルで構成されます。解析するのは添付ファイルであり、人が読むのはページです。QRは3つ目のより小さなレコードで、tag-length-valueレコードのBase64文字列であり、最大500文字です。tag 1〜5には売り手名、売り手VAT番号、タイムスタンプ、VAT込み合計、VAT合計が含まれ、tag 6〜9にはハッシュ、署名、公開鍵、そして簡易請求書ではその鍵に対するZATCAの署名が含まれます。ZATCAの電子インボイスプログラムはFatoora（فاتورة）と呼ばれています。

APの受信箱に実際に届くもの

拡張子はほとんど何も教えてくれませんが、添付ファイルの中身を見れば何を解析できるかがわかります。 サプライヤーのERPが正しいハイブリッド形式を生成しても、バイヤー側にはフラット化されたPDFが届くことがあります。調達ポータルは添付ファイルを再レンダリングし、メールゲートウェイは添付を除去し、AP担当者はファイリング前にPDFへ印刷します。受信箱の請求書は完璧に見えても、構造的には空かもしれません。ZATCAの2025年次レポートによると、年間の電子請求書発行量は80億件を超えており、混在した受信箱は例外ケースではありません。以下の4つの状態はそれぞれ異なる対応が必要です。

逆のケースも起こります。ZATCAの開発者フォーラムには、PDF/A-3上で値を画像として提供できるかというサプライヤーからのスレッドがあります。ファイルは準拠を宣言していますが、フォントがなくピクセルしかないため、文字を選択したりコピーしたりできません。その場合、埋め込まれたXMLが唯一の機械可読レイヤーとなり、OCRはデフォルトではなくフォールバックになります。フォーラムスレッドは、「PDF/A-3」がコンテナを表すのであってページの可読性を保証するものではないという有用なリマインダーです。

ファイル名ではなく添付ファイルを確認してください。PDFリーダーの添付パネルを開くか、/AFエントリを検査し、ファイルを管理された作業フォルダに抽出し、XMLとして解析できることを確認し、元のバイトはそのままにしておきます。添付が欠落、破損、またはアクセス不能な場合は、ページを使用する前にその状態を記録してください。上記の4つの状態は等価ではなく、目視確認したページを解析済みペイロードとして扱うことが、AP例外が最初に見失われるポイントです。

支払いを左右するフィールド

AP が必要とするのは、ヘッダー項目が約12、明細行ごとに5項目であり、XML はそのすべてに名前を付けています。成果物のトリアージが済めば、値がパーサー由来でもページ由来でもフィールド一覧は同じです。この表は実務用のマップであり、完全なデータディクショナリではありません。支払い、税の計上、重複チェックを左右するフィールドを残し、売り手のクリアランスにしか関係しないものは省いています。パスは Invoice ルートからの相対パスです。

このマップを使いこなすには2つのルールがあります。数量と単価も抽出する場合でも、LineExtensionAmount と PayableAmount は独立した列として抽出してください。ドキュメントにすでに記載されている値を再計算することは、存在しない差異を AP が作り出す原因になります。正規化した値の隣に生の文字列も残してください。先頭にゼロが付く請求書番号、アラビア語の法人名、Arabia Standard Time のタイムスタンプは、早い段階で型変換すると情報が失われます。アラビア語の名前は、文字が正しくても表示順が異なることがあるため、値を入力し直すのではなく、生の文字列を保持して表示方向を設定してください。ヘッダーと明細行の分割に馴染みがない場合は、請求書データ抽出の完全ガイドで一般的なモデルを解説しています。

2つのレイヤーが実際に食い違うところ

食い違いのほとんどは破損ではありません。異なるフィールドを正しく描画した2つの結果です。以下の5つのケースが、データエラーに見えて実はマッピングエラーである AP 例外の大半を占めます。

行割引は単価ではなく行の純額を変える

ZATCAの実装標準では、行の純額は（(品目純価格 ÷ 基本数量) × 請求数量）から行手当を引き、行課徴金を加えたものと定義されています。10単位、SAR 100の行にSAR 50の行手当がある場合、行の純額はSAR 950ですが、印刷された単価はSAR 100のままです。PDFに単価と行合計が表示されていても手当が表示されていない場合、ページは算術的に誤っているように見えます。しかし誤りではありません。手当はXML内のcac:InvoiceLine/cac:AllowanceChargeにあります。

APが数量と単価を抽出して行合計を計算すると、SAR 950と記載されたドキュメントに対してSAR 1,000となります。すると、本来合格すべきチェックで請求書が失敗するか、担当者が帳尻を合わせるために誤ったフィールドを調整することになります。記載された行の純額を抽出し、手当は独自の列に保持して、後で算術を再現できるようにしてください。

計算列はチェックに役立ちます。しかし、ドキュメントが記載する行の純額の代わりにはなりません。

前払いは合計を2つの数値に分割する

ZATCA自身の前払い例がこのパターンを示しています。VAT込みでSAR 230、うちSAR 104が前払い済み、支払額はSAR 126です。TaxInclusiveAmountは230、PrepaidAmountは104、PayableAmountは126です。3つとも正しく、それぞれ異なる問いに答えるものです。支払対象額はPayableAmountに、請求書価額はTaxInclusiveAmountに、前払金は独自の列にマッピングしてください。ERPに合計フィールドが1つしかない場合は、請求書価額をそこに入れ、支払額は支払スケジュールで管理してください。一方を他方で上書きすると前払いが隠れ、二重に支払うことになります。

外貨建て請求書は2つの税合計を持つ

ドキュメント通貨がSARでない場合、ZATCAはTaxCurrencyCodeをSARとし、SARでの2つ目の税合計を要求します。PDFにはドキュメント通貨のみが印刷されることがよくあります。印刷された合計を月末レートで換算するAPチームは、XML内の数値とは異なるSAR VAT額を得ることになり、その差額はVAT回収勘定に計上されます。両方の税合計を読み取り、SARの方を転記し、ドキュメント通貨の方は仕入先元帳用に保持してください。

PDFにはXMLに必須でない項目を含められる

ZATCAの標準は最低要件です。Fatoora開発者フォーラムで、あるサプライヤーがPDF/A-3に印刷された追加情報をXMLにも記載する必要があるか質問しました。回答は、データディクショナリ外の項目はXMLに必須ではないが、UBLに準拠していれば追加してもよいというものでした。発注番号、納品書参照、内部コストセンター、承認スタンプはここに含まれることが多く、ページ上にはあってもペイロードには入りません。

純粋なXMLパイプラインにとって、これはギャップです。三者照合にはPOが必要で、支払スケジュールには支払期日が必要です。XMLにはcac:OrderReferenceとcac:PaymentTermsがありますが、サプライヤーはすべての請求書でこれらを入力する義務はありません。実用的な設計は項目レベルのソース列です。税と識別情報はXMLから、業務上の文脈はページから取得し、どちらにもない場合は明示的な「存在しない」状態とします。

クレジットノートは新しいドキュメントであり、マイナスの請求書ではない

クレジットノートは請求書タイプコード381を使用し、訂正対象の請求書への請求参照を持ち、理由を記載し、通常は金額を正のままにします。方向性はドキュメントタイプが示すためです。これをマイナスの仕入請求書として記帳すると、符号が二重に反転する可能性があります。一度はタイプで、もう一度は仕訳で。その結果、残高を増やすクレジットになってしまいます。

クレジットノートを参照先の請求書と相殺し、参照が解決するか確認します。ZATCAガイドラインでは、1つのクレジットノートが複数の元請求書をテキスト範囲として参照できるため、参照は常に単一のキーとは限りません。範囲である場合は、クレジットを分割するか、サプライヤーが請求書ごとの内訳を提供するまで保留します。

以下の表は、よくあるケースをルーティングシートにまとめたものです。

QRコードは整合性チェックであり、承認証明書ではない

QRとページが一致することは、両者が同じ値から作られたことを証明するだけで、請求書が承認されたことは証明しません。tag 1〜5がコード内の唯一の業務値です。請求書番号も明細行もPOも買い手のVAT番号もありません。QRは要約であり、しかも短いものです。

受付チェックとして使うなら、tag 1〜5は依然として有用です。比較の前に正規化してください。VAT番号は数字として、タイムスタンプは瞬間として（Arabia Standard TimeとUTCは同じ瞬間を表すことがあるため）、金額は小数点以下2桁として扱います。不一致は通常、QRが別の請求書のものか、コード生成後にページが再構築されたことを意味します。どちらも止まって確認する価値があります。

tag 6〜9は目視やスマートフォンのスキャナーでは確認できません。検証には、署名済みXML、署名が計算された正確なバイト単位の形式、証明書チェーン、失効確認が必要です。9つのフィールドを表示するスキャンは、9つのフィールドを表示しただけです。署名を検証したわけではありません。

APチームはこれについて異なる説明を受けています。Fatoora開発者フォーラムで、あるAP実務者がこう書いています。「ZATCAサポートチームは、仕入先請求書のQRコードをスキャンすることが必須だと言っています。私はAccounts Payableの観点から質問しています。」コミュニティリードの回答は、スキャンは任意のチェックであり、正常に報告または承認された請求書はすでに電子インボイス要件を満たしているというものでした。同じスレッドには、ZATCAアプリはサウジアラビア国外のコードをスキャンできないことも記録されています。これは他国にあるシェアードサービスセンターにとって実務上の問題です。

実行可能な立場：QRはサンプリング管理と添付ファイルの整合性チェックとして使います。請求書ごとのゲートにせず、スキャンを承認の証拠として扱わないでください。証拠は、承認済みまたは報告済みのXMLであり、その応答とともに保持されます。

コピーされたQRは改ざんされたページに載せることができます。値を比較し、四角形を証明として扱わないでください。

例外に耐える6ステップのワークフロー

サウジの電子インボイス買掛金ワークフローは、請求書明細行ごとに1行、すべてのフィールドにソースラベル、そして誰も黙って上書きできない例外ステータスを生成する必要があります。 各ステップは意図的に退屈です。退屈であることが、6年後にも説明可能な出力を生み出します。

3人の担当者、3つの問い。AP担当者は商業的照合とサプライヤーへの問い合わせを担います。ERPまたは統合の担当者は添付ファイル、名前空間、パーサーを担います。サウジアラビアの税務リードはVATカテゴリ、クリアランス証跡、保存判断を担います。単一の「有効」フラグはこれらの答えを1つにまとめ、どのチームが対応すべきかを隠してしまいます。状態は個別に保存してください：解析済み、スキーマ失敗、値の不一致、暗号証跡未検証、AP保留、支払承認済み。

ここでビジュアル抽出ができることとできないこと

ビジュアル抽出ツールは添付ファイルではなくページを読み取るため、このワークフローではPDF側に属します。 それがImageToTable.aiの担当範囲であり、「ZATCA請求書抽出」よりも狭い役割です。それでも3つの場面で役立ちます。

1つ目はPDFにしか存在しないフィールドです。ERPがXMLを解析しても、発注番号、納品書、社内承認が記載されている唯一の場所がページである場合があります。Custom Column Extractionでは、「PO Number」「Payment Due Date」「Delivery Note」など、必要な列名を入力すると、モデルは固定座標ではなく意味によって値を探します。入力した列名は出力テーブルのヘッダーになります。

2つ目はXMLなしの例外です。サプライヤーが通常のPDFや画像のみのPDF/A-3を送付した場合、解析するものがありません。ページがソースになります。バッチ処理は混在するサプライヤーレイアウトのフォルダを1回で処理し、行を1つのスプレッドシートにマージします。これが、対応可能な例外キューと一回限りの変換の山との違いです。

3つ目はビジュアル比較です。Bboxハイライト付きのReview Modeでは、セルにカーソルを合わせるとその値を生成した元のページ上の領域が表示され、領域をクリックするとセルに戻れます。ZATCA請求書の場合、担当者はページを印刷して定規を使うことなく、印刷された支払金額とXMLの値を比較できます。AIの元の値は保持され、編集が誤っていた場合は復元できます。画像のみのスキャンや高密度のバイリンガルレイアウトには、より高いModel Tierが強力なビジョンモデルを使用します。Standardはほとんどの印刷された表をカバーしますが、難しいのは小さなアラビア語テキストと合計の上にスタンプがあるスキャン印刷物です。

制限も同様に重要です。埋め込まれたXMLを開いたり、暗号スタンプを検証したり、QRハッシュを確認したり、サプライヤーをZATCAに登録したり、何かを申請したりはしません。PDF/A-3のビジュアル抽出は、レンダリングされたページの観察であり、署名済みペイロードの解析ではありません。出力ではそのようにラベル付けしてください。ページに行の手当が記載されていなければ、観察結果もそれを省略し、ステップ4の算術チェックがその差異を捉えます。

同じ区別は他の市場にも当てはまります。日本の適格請求書制度には必須のXMLペイロードがないため、ビジュアル層が唯一のソースとなることが多く、同じ規律が日本の適格請求書にも当てはまります。ドイツの義務化では構造化ファイルが請求書となるため、ドイツのサプライヤー請求書の受付順序が変わります。両方を扱うチームには、1つのフィールドマップと2つの受付ルールが必要です。

アーカイブは抽出の一部である

スプレッドシートは請求書ではなく、PDFだけでは監査人が検証できる記録にはなりません。 サウジVAT実施規則第66条では、請求書、帳簿、記録、会計書類を、対象となる課税期間の終了から少なくとも6年間保存することが義務付けられています。資本資産の記録は第52条の調整期間に5年を加えた期間、つまり動産は11年、不動産は15年です。記録はアラビア語で、王国国内に電子的または物理的に保存し、王国国内の端末からアクセスできる必要があります。

受け取ったXML、または未加工のPDF/A-3コンテナを保存してください。添付ファイルを抽出したコピーだけでは不十分です。標準請求書のクリアランスまたは報告レスポンスも保存してください。これは請求書が受理された証拠となるためです。請求書カウンターと前回のハッシュチェーンをそのまま維持してください。欠落自体が証拠となります。修正は禁止されているため、クレジットノートは訂正対象の請求書と一緒に保存してください。

抽出記録には独自のフィールドがあります。ソースファイルのハッシュ、ソースタイプ、パーサーまたはモデルのバージョン、ルールセットのバージョン、フィールド単位のソース、正規化値、生の値、例外状態です。後でパーサーやモデルを再実行するには、同じバイト列が必要です。元のデータを正規化値で上書きすると、その行を弁護するために必要な証拠を破壊したことになります。

他のクリアランスモデルも同じ点を指摘しています。ポーランドのKSeFシステムは識別子を割り当て、これがなければ請求書は法的に存在しません。メキシコのCFDI請求書は、構造化ファイルと印刷可能な表現を組み合わせています。いずれの場合も、アーカイブは構造化された成果物と当局のレスポンスであり、PDFではありません。

よくある質問

ZATCA QRコードから明細行を抽出できますか？

いいえ。tag 1〜5には、販売者名、販売者のVAT番号、タイムスタンプ、VAT込み合計額、VAT合計額が含まれます。請求書番号、購入者識別子、明細の詳細はありません。このコードはこれら5つの値の照合に使用し、明細行テーブルの構築には使用しないでください。

すべてのPDF/A-3請求書はXMLを内包したハイブリッドですか？

いいえ。PDF/A-3は埋め込みファイルを許可するコンテナであり、サプライヤーが実際に埋め込んだこと、添付ファイルが読み取り可能であること、ページがそこから生成されたことを保証するものではありません。PDFを構造化ソースとして扱う前に、添付ファイルコレクションを開いてファイルを解析してください。

請求書に前払いが含まれる場合、どの合計額を計上しますか？

請求書価額はTaxInclusiveAmountから、支払額はPayableAmountから計上してください。PrepaidAmountは独自の列に保持し、前払い請求書にリンクさせてください。3つを1つの「合計」フィールドにまとめたり、請求書価額を支払額で上書きしたりしないでください。

PDF/A-3が法的な請求書ですか？

いいえ。署名済みXMLが請求書です。PDF/A-3はそれを内包することが許された人間可読のコピーです。標準請求書の場合、クリア済みのXMLまたはクリア済みのハイブリッドを保持し、再保存されたPDFではなくコンテナをアーカイブしてください。

ZATCA請求書にOCRを使用できますか？

はい、使用可能なXMLがない場合には使用できます。画像のみのPDF、スキャン、写真は視覚的に読み取れますが、その結果はページの観察であり、署名済みペイロードの解析ではありません。方法を記録し、同じ正規化と算術チェックを実行し、読み取れる場合はQRの5つの値を照合してください。

複数の請求書を参照するクレジットノートはどう処理しますか？

マイナスの仕入請求書ではなく、type 381とbilling referenceを持つ新しいドキュメントとして扱ってください。参照が範囲である場合は、クレジットを元の請求書に対して分割するか、サプライヤーが請求書ごとの内訳を提供するまで保留してください。修正対象の請求書と相殺し、それらと一緒にアーカイブしてください。

ImageToTable.aiは埋め込まれたUBL XMLを解析したり、QRを検証しますか？

いいえ。PDFページ、画像、スキャンを読み取り、定義した列を抽出します。印刷ページにしか存在しないフィールドも含まれます。埋め込まれたXML添付ファイルを開いたり、暗号署名を検証したり、QRハッシュを確認したり、サプライヤーをZATCAに登録したり、申告を提出したりはしません。XML解析と署名検証は、お使いのERPまたは連携レイヤーの役割です。

サウジアラビアのサプライヤー請求書はどのくらい保存する必要がありますか？

VAT実施規則のArticle 66により、対象となる課税期間の終了から少なくとも6年間です。資本資産の記録は調整期間に5年を加えた期間で、動産は11年、不動産は15年です。XMLまたは未加工のPDF/A-3コンテナ、クリアランスまたは報告の証跡、クレジットノートをまとめて保管してください。

問いに耐える行

監査に耐える請求書とは、すべての行が、その出所のフィールド、背後にある成果物、通過を許したチェックを特定できるものです。そのマップが一度できれば、PDFとXMLの不一致は謎ではなくなり、担当者のいるキューになります。