日本請求書データ抽出の完全ガイド
買掛金管理と税務申告のための

日本の請求書が他と違う理由 — 抽出において重要な点

日本の請求書は、欧米の抽出ツールが解析するよう訓練されていないフィールド構造を持っています。米国やEUの請求書は、ヘッダーから明細行、合計、支払期日へと流れ、買掛金ワークフローをカバーするのに通常4～6の抽出列で十分です。日本の請求書は、合計額の下にまったく別のセクション、つまり支払指示ブロックを追加します。これは、買い手にどの銀行に送金すべきか、どの決済日慣行が支払期日を制御するか、そして税務署に差し引くべき金額があるかどうかを伝えます。文書を上から下に読み、「請求書番号」と「合計」を探すだけの汎用抽出エンジンは、このセクション全体をスキップするか、さらに悪いことに、4つの別々の銀行フィールドを1つの文字化けしたテキスト文字列に連結してしまいます。

2023年10月以降、この問題には構造的な側面に加えてコンプライアンスの側面があります。インボイス制度（正式には適格請求書等保存方式）は、消費税法第57条の2に基づき、仕入税額控除の請求をサポートするすべての請求書に6つの必須項目を義務付けています。そのうちの3つ — 登録番号、税率別の税額合計、税率区分の内訳 — は、制度開始前には必須項目として存在していませんでした。2025年3月時点で、国税庁は約461万の適格請求書発行事業者を報告しています。そのすべてが、すべての請求書にT+13桁の登録番号を含めなければなりません。その番号がない場合、買い手の仕入税額控除は減額されます — 80%控除可能からゼロへと段階的に移行する経過措置に従います。

したがって、抽出の課題は単に日本語のテキストを読むことではありません。それは、APと税務にとって重要な列であるフィールドスキーマが、抽出ツールが期待するように構築されたスキーマとは異なる文書を読むことです。解決策はカスタム列抽出です。APスプレッドシートと日本のビジネスロジックに一致する列名を使用して出力スキーマを自分で定義し、AIに各フィールドが何を意味するかを理解させることで — 特定のサプライヤーの請求書テンプレート上の位置ではなく — 各フィールドを特定させます。同じ列スキーマは、大手商社のERP生成PDF、地元のサービスプロバイダーのWordテンプレートを印刷してスキャンしたもの、または手書きフォームのモバイル写真のいずれであっても機能します。各列定義がどうあるべきか、そして日本の慣習を捉える推論ロジックの書き方については、ステップバイステップの日本請求書抽出チュートリアルを参照してください。このチュートリアルでは、25の列を一度定義し、すべてのサプライヤーで再利用する方法を説明しています。

このガイドの残りの部分では、それらの各列が何を抽出する必要があるか、そして日本の請求書に固有のフィールド — 振込先の銀行詳細、締日の決済慣行、源泉徴収、および複数税率の消費税 — が、列定義から支払バッチ出力、消費税申告書の提出に至るまで、抽出ワークフロー全体をどのように形成するかを説明します。

請求書のフィールド構造

日本の請求書には、4つの論理ゾーンがあります。最初の2つ（ヘッダーと明細行）は、世界中の請求書に共通するものです。残りの2つ（税務・コンプライアンス、支払い・銀行）は、フィールドスキーマが欧米の抽出エンジンが想定するものと異なる部分です。以下は、APチームが多様な仕入先からの請求書を処理する際に遭遇するすべてのフィールドを、ゾーンごとに整理したものです。

この構造は推測ではない—内閣府による適格請求書制度の公式概要には6つの必須項目が列挙されている。しかし、データ抽出の課題は必須項目にとどまらない。最も多くの経理担当者の手作業時間を消費する項目—振込先、支払条件の解析、源泉徴収—は、法的要件ではなく慣行によって含まれている。これらこそが、日本の請求書処理を欧米のそれと構造的に異なるものにし、汎用的な抽出が最初に破綻するポイントである。手作業による抽出のコストを理解するには、日本の中小企業における手作業による請求書処理のコスト分析で、典型的な月末締めにおける1サイクルあたりの労務コストを円単位で詳述している。

中核となる抽出の洞察：日本の請求書は、日本語が書かれた英語の請求書ではない。異なるフィールドスキーマを持つ文書であり、抽出列の定義はそのスキーマを反映していなければならない。反映しなければ、出力はAPチームが使い物になるように再入力しなければならないデータの表にすぎなくなる。

振込先：なぜ1つのテキストブロックではなく、4つの個別の銀行フィールドが必要か

銀行振込詳細ブロックは、日本のAP業務において最も反復的なデータ入力作業である。仕入先からの請求書には、銀行名、支店名、預金種目、口座番号という4つのラベル付きフィールドが記載されており、AP担当者はインターネットバンキング画面を開き、請求書ごとにそれらを1つずつ入力する。同じ4つの値は、すでに会計ソフトの仕入先マスターに存在している。月末に30枚の請求書が届くと、APチームはそれら4つのフィールドを30回再入力することになる。これは、何ら新しい情報を追加することなく、既存のマスターデータをある画面から別の画面に複製するだけの、120件もの個別入力作業である。

ほとんどの汎用抽出ツールは、米国やEUの請求書データセットで学習されている。そこでは「支払方法」は「電信送金」や「ACH」といった単一のフィールドであり、請求書に銀行ルーティング情報が構造化されたフィールドセットとして存在するという概念がない。このようなツールに請求書を投入すると、銀行詳細ブロックはスキップされるか、1つの非構造化テキストフィールドに連結される。APチームは結局、PDFを開いて各フィールドをコピー＆ペーストしなければならない。

この抽出アプローチでは、振込先ブロックを4つの専用列に分割する。各列は1つのフィールドを独立して取得し、推論列を使用してゆうちょ銀行の変換を処理する。ゆうちょ銀行の口座システムは、商業銀行の振込システムで必要とされる7桁の振込口座番号とは異なる、記号-番号のペアを使用する。推論列（AIが文書のコンテキストに基づいて値を計算する列であり、ページ上に印刷された値を見つけるのではない）が、抽出中にこの変換を処理する。振込口座番号（銀行名に「ゆうちょ」が含まれる場合、記号-番号ペアをゆうちょ銀行変換ルールに従い7桁形式に変換する。それ以外の場合は口座番号を出力する）。この列定義は一度設定すれば、すべてのバッチに適用される。

4つの構造化された銀行列は、単なる組織上の便宜ではない。これらは支払バッチファイルへの入力データであり、ここで全銀フォーマットがワークフローに登場する。バッチ処理ガイドでは、完全なチェーンについて説明している。30枚の請求書を1つのバッチで処理 → 振込先銀行詳細が個別の列に抽出 → 出力が銀行で受け入れ可能な支払バッチファイルにフォーマットされる。この抽出は単に入力を節約するだけではない。抽出によって入力された銀行フィールドが、そのまま銀行のアップロード画面で取り込まれる銀行フィールドとなる、データパイプラインを構築するのである。

支払条件: 会計期間を決定する締日

日本の支払条件は、APチームが一目で理解できるコンパクトな構文ですが、一般的な抽出処理では不透明なテキストとして扱われます。「20日締翌月末払い」は、請求期間が毎月20日に締め切られ、支払いが翌月末までに行われることを意味します。この文字列には、締日（20）と支払いラグ（1ヶ月）という2つの計算可能な値がエンコードされています。「月末締翌々月末払い」は建設業や製造業で一般的で、月末締め、翌々月末までに支払い（ラグ：2ヶ月）を意味します。

締日は運用上のものであり、単なる装飾ではありません。20日締めの条件で3月18日付の請求書は3月の請求期間に該当します。支払いは4月末、経費は3月31日に決算が締まる場合、当期に属します。同じ条件で3月22日付の請求書は4月の請求期間に該当します。支払いは5月末、経費は翌期に属します。会計年度の分類を決定するのは、請求書の発行日でもカレンダーの月末でもなく、締日なのです。締日支払期限分析では、30の仕入先がそれぞれ異なる締日を使用する場合に、締日の慣行がキャッシュフロー予測にどのような影響を及ぼすか、その全容を解説しています。

計算列 — AIが抽出時に定義された計算式を用いて値を算出する列 — は、支払条件を構造化フィールドに分割します。締日（支払条件から解析：「20日締」→20、「月末締」→31、「10日締」→10）および支払ラグ月数（支払条件から解析：「翌月末払い」→1、「翌々月末払い」→2）。これら2つの列は、実際の支払期日を計算するスプレッドシートの計算式で使用されます。出力スプレッドシートの「支払期日」列は、手入力されたものではなく、フリーテキストフィールドから抽出されたものでもなく、請求書の発行日と解析された条件から導出されます。この日付列はキャッシュフロー予測と支払バッチスケジュールの両方に供給され、どちらもそれをエンコードしたテキスト文字列ではなく、実際のカレンダー日付を必要とします。

源泉徴収区分: 支払者が支払前に源泉徴収をしなければならないケース

日本の源泉徴収制度では、支払先が特定の職業に該当する場合、支払者に源泉徴収義務が生じます。税理士、公認会計士、弁護士、司法書士、デザイナー、著作家など、所得税法第204条に定められた職業は、支払金額の10.21%が源泉徴収の対象となります。支払者は源泉徴収額を差し引いた残りの89.79%を支払先に支払い、差し引いた所得税を税務署に納付します。

該当する職業からの請求書には、通常、源泉徴収に関する記載があります。「源泉徴収額」として差引額が明記されているか、「源泉徴収あり」といった区分表示がされています。源泉徴収のある請求書は買掛金の支払計算に影響します。正味支払額は請求書合計額から源泉徴収額を差し引いた額となり、税務署への納付義務に対応する別途の負債計上が必要です。抽出時に源泉徴収情報を取得できない場合、買掛金チームは該当する請求書を個別に確認し、手動で控除額を計算して支払額を調整する必要があります。この作業を60件の請求書で行うと、多大な時間を要します。

源泉徴収区分（請求書に源泉徴収の記載があるか確認。該当する職業で源泉徴収ありの場合は「該当」、それ以外は「非該当」と出力） という列を定義することで、どの請求書に源泉徴収が必要かを自動判定できます。さらに、正味支払額（源泉徴収該当の場合：合計額×0.8979、非該当の場合：合計額） という計算列を設定すれば、実際の振込額を直接算出できます。これにより、支払バッチファイルには請求書合計額ではなく正しい振込額が含まれ、買掛金チームが該当請求書ごとに個別計算する手間が省けます。

インボイス番号: T+13の登録番号とその存在理由

適格請求書等保存方式における登録番号（インボイス登録番号）は、「T」を冠した13桁の番号です（例：T1234567890123）。登録を受けた適格請求書発行事業者（QII）は、国税庁からこの番号を付与され、買い手が消費税の仕入税額控除を受けるために使用するすべての請求書に記載する義務があります。国税庁は適格請求書発行事業者の公的登録簿を公開しており、買掛金管理チームはそこで登録番号を確認できます。

この登録番号により、2023年10月以前には存在しなかった、請求書ごとの新たな確認手順が生まれました。請求書を受け取った買掛金担当者は、T番号（ヘッダー、フッター、余白、社判の横の細かい文字、または振込先情報の近くのテキストブロックに埋め込まれている場合があります）を見つけ出し、それが正しい仕入先のものであることを確認する必要があります。番号がない場合、または国税庁の登録簿と一致しない場合、その取引における買い手の仕入税額控除は、経過措置に基づき減額されます（2026年9月までは80%控除可能、2029年9月までは50%、その後はゼロ）。日本の適格請求書データ抽出の完全ガイドでは、6つの必須項目、経過措置のスケジュール、抽出したT番号を国税庁の登録簿と一列で照合する方法など、コンプライアンス対応の請求書の全体像を詳しく解説しています。

抽出ワークフローにおいて、登録番号の列は定義が簡単です。AIが文書を読み取り、ページ上のどこにあってもT+13のパターンを識別し、その列に値を入力します。課題は抽出そのものではなく、配置のばらつきにあります。仕入先ごとにT番号の位置が異なります。登録番号が固定された領域にあることを前提とするテンプレートベースのツールは、仕入先がフッターに配置した場合に見逃します。セマンティック抽出（フィールドの位置ではなく、その意味を理解して特定する方法）は、位置に関係なく捉えることができます。この原則は請求書のすべての項目に適用され、30の異なるレイアウトを持つ30の仕入先に対して、単一の列スキーマで対応できる理由です。

消費税: 確定申告のための複数税率抽出

日本の消費税制度は、10％の標準税率（ほとんどの商品・サービスが対象）と8％の軽減税率（食品、非アルコール飲料、週2回以上発行の購読新聞が対象）の2つの税率を使用する。適格請求書には、税率区分ごとに課税標準額と税額をそれぞれ記載し、端数は1円未満切り捨てとする必要がある。両方の税率を混在させた単一の合計額は、インボイス制度の下では不適格となる。

抽出の課題は分類である。複数税率の明細行を含む請求書（10％の事務用品と8％の包装飲料）では、各行を正しい税率区分に割り当て、税率別の小計が供給者の記載額と照合できるようにする必要がある。もし供給者が誤って10％の品目を8％の欄にまとめてしまった場合、買い手の消費税申告で仕入税額控除を過大に計上することになる。国税庁のデータ突合エンジンは、意図的な虚偽申告と供給者の過誤に依拠した場合を区別しない。

推論列が抽出時に税率分類を処理する: 税率（品目説明から: 食品・飲料（アルコール・外食を除く）→ 8％軽減税率; 標準的な商品・サービス → 10％標準税率; 明示的に輸出関連 → 非課税）。AIが各明細行の説明を読み取り、日本の複数税率ルールを適用して税率列を設定する。2つの計算列が税率別の小計を計算する — 10％小計（税率 = 10％の明細金額の合計） および 8％小計（税率 = 8％の明細金額の合計） — これらは請求書に記載された各税率区分の小計と直接比較できる。

消費税データは、抽出されたスプレッドシートから消費税申告への入力データとして流れ込む — 10％の課税売上高、10％の税額、8％の課税売上高、8％の税額。抽出出力が各明細を元の段階で分類していれば、税務申告作成者は分類を検証するだけで、ゼロから分類を行う必要はない。消費税データ入力ミスに関する一般的なガイドでは、抽出段階ではなく手動で税率分類を行った場合に税額差異を引き起こす具体的なミスについて説明している。

抽出ワークフロー：PDFから支払い準備完了のスプレッドシートへ

手作業による請求書からスプレッドシートへの転記を置き換えるワークフローは、一度定義すれば、すべての仕入先、すべての請求書フォーマット、そしてその後の毎月の月末バッチに適用されます。これは仕入先ごとの設定プロセスではありません。列スキーマは、誰が送信したかに関係なく、APチームが請求書から必要とするものを取得します。AIが各ドキュメントを読み取り、スキーマに入力し、出力は毎回同じ列に配置されます。

月末APのためのバッチ処理

30～50の国内仕入先から購入する日本の企業における月末APでは、3つのチャネルで仕入先請求書を受け取ります。請求書ソフトを使用する企業からのメールPDF、仕入先ポータル（大手商社やメーカーの場合）からダウンロードしたPDF、そして郵送で届きスキャンまたは撮影された紙の請求書です。これら3つのチャネルはすべて、月の同じ週に同じデスクに集約され、同じAP処理サイクルに投入されます。

バッチ処理とは、これらの請求書すべてを、ソースチャネル、仕入先、レイアウトに関係なく、単一のジョブとして処理することを意味します。列スキーマはバッチ内のすべてのドキュメントに適用されます。出力は、各行が1つの請求書、各列が1つの抽出フィールドである1つのスプレッドシートです。3つのチャネルと20～30の異なる請求システムから届いた30～50の請求書が、統一された構造を持つ単一のファイルに集約されます。

バッチ処理によって変わる3つの運用上の判断事項：

APチームは再入力から検証へと業務を移行します。抽出処理がスプレッドシートを生成するため、AP担当者の仕事は、フラグが立った項目（ツールが低信頼度とマークしたT番号、不自然に読める銀行支店名、間違っているように見える計算上の支払いラグなど）について列をスキャンすることであり、データをゼロから作成することではありません。検証にはバッチあたり数分かかります。作成（各PDFを開き、適切なフィールドを見つけ、別の画面に入力する）には数時間かかります。

スプレッドシートは、3つの下流システムにとって単一の信頼できる情報源となります。会計ソフトウェアは仕訳データを取得します。銀行システムは支払いバッチデータを取得します。税務申告は消費税の控除対象データを取得します。3つのシステムが、3つの別々の手動入力作業ではなく、同じ抽出データに依存する場合、あるシステムでの不一致は抽出出力にまで遡ることができ、3つの独立したデータ入力作業のうちの1つでのタイプミスに起因するものではありません。

同じカラムスキーマが翌月もそのまま使える。仕入先が請求書のレイアウトを変更するかもしれない。新しい仕入先が追加されるかもしれない。各フィールドの意味（出現位置ではない）で定義されたスキーマは、更新する必要がない。バッチ処理ガイドでは、振込明細、源泉徴収計算、支払日ごとにグループ化された支払スケジュールを含む30枚の請求書の例を解説している。

全銀フォーマット：スプレッドシートの列から銀行が受け付ける一括支払ファイルへ

全銀フォーマットは、全国銀行資金決済ネットワークが標準化した固定長ファイル形式である。これにより、企業はインターネットバンキング画面で1件ずつ入力する代わりに、複数の振込を1回のアップロードで一括送信できる。主要な日本の銀行はすべて、FB（ファームバンキング）サービスを通じてこの形式での一括振込を受け付けている。

この形式は1行120バイト、Shift-JISエンコードで、4つのレコード種別から構成される：

抽出から全銀フォーマットへの接続は、ファイル変換ではなくデータパイプラインである。抽出結果には、銀行名、支店名、預金種目、口座番号、口座名義人、支払額がそれぞれ別のカラムとして含まれる。これらのカラムが、全銀ファイルの各データレコードを構成するフィールドにそのまま対応する。銀行コード（4桁）と支店コード（3桁） — 請求書に記載されたテキスト名とは異なる全銀フォーマット用の数値識別子 — は、APチームが一度だけメンテナンスするルックアップテーブル（仕入先の銀行名・支店名から全銀銀行コード・支店コードへのマッピング）で解決できる。

計算列は、抽出時にこのルックアップを実行できます：全銀銀行コード（銀行名マッピングテーブルからのルックアップ）。列の出力には、請求書に表示される銀行名ではなく、全銀データレコードに使用可能な数値の銀行コードが含まれます。スプレッドシートから全銀形式への変換（抽出出力列から固定長120バイト形式への変換）は、スプレッドシートの数式や簡単なスクリプトで実行できます。抽出は本来の目的である、列に構造化データを生成することを行います。支払バッチ生成は、これらの列を入力として消費します。

全国銀行資金決済ネットワークは、正式な全銀システム仕様書を公開しています（PDF）。各銀行は、自社のFBアップロード形式仕様（特定の文字エンコーディング（JISまたはShift-JIS）、フィールドのパディングルール（数値フィールドは右詰めゼロ埋め、名称フィールドは左詰めスペース埋め）、空白が許可されるフィールドなど）を公開しています。抽出出力はフォーマット非依存であり、列を生成します。APチームまたはスクリプトが、それらの列を会社が使用する銀行の全銀仕様にフォーマットします。

構造化抽出によるインボイス制度コンプライアンス

適格請求書等保存方式により、すべてのAPチームがすべての仕入先請求書に対して実行しなければならない、3つの新しいコンプライアンス検証ステップが生まれました：

1. 登録番号の検証 — 請求書に記載されたT+13桁の番号が仕入先に属し、国税庁の公的登録簿と一致し、失効または取消されていないことを確認します。
2. 税率区分の分離 — 請求書が8%軽減税率対象品目と10%標準税率対象品目を正しく分離し、税率グループごとの小計と税額が算術的に正しいこと（課税標準×税率、端数切り捨て）を確認します。
3. 経過措置に基づく仕入税額控除の計算 — 登録されていない仕入先からの請求書について、経過措置スケジュールに従って仕入税額控除を計算します（2026年9月までは80%控除可能、2029年9月までは50%、その後はゼロ）。

このシステム以前は、AP担当者は2つのこと（請求書合計が正しいか、仕入先がマスターファイルに存在するか）を検証していました。現在、担当者は請求書ごとにさらに3つのコンプライアンス項目を検証する必要があります。月末に30～50枚の請求書を処理する場合、2023年10月以前には存在しなかった90～150もの追加検証チェックが発生します。2023年のインボイス制度改正により経理処理が困難になった理由の分析では、改正前と改正後の検証チェックリストの変更点を詳述しています。

構造化抽出は、これらのチェックの機械的な部分を吸収します。登録番号用の列により、単一列のルックアップで国税庁の登録簿と照合可能になります。税率グループごとの小計用の計算列により、仕入先の提示額と直接比較できます。仕入先のインボイス制度登録状況を示す列は、経過措置に基づく仕入税額控除の計算が必要かどうかを示します。APチームは依然として検証を行いますが、その検証とは、電卓で税率グループの計算を行うのではなく、抽出データをスプレッドシート上のソースデータと比較することを意味します。日本の適格請求書抽出に関する完全ガイドでは、登録番号のクロスチェック、税率区分の計算、経過措置に基づく仕入税額控除の計算といった検証ワークフローを詳細に説明しています。

記事の関連性：日本請求書クラスターの全体像

本ガイドは、日本請求書（請求書）の抽出をあらゆる角度からカバーする6つの記事からなるクラスターのハブ記事です。各記事は独立した内容でありながら、クラスター全体で文脈を補完します。以下がその構成です。

関連する2つの記事は、日本請求書クラスターを超え、請求書と抽出ロジックを共有する隣接文書タイプを扱います。

よくある質問

AI抽出は、スマートフォンで撮影した日本の請求書データを読み取れますか？

はい、可能です。基盤となる視覚言語モデルは、画像をテキスト優先のOCRとしてではなく、視覚入力として処理します。オフィスの照明下で多少のパースペクティブの歪みがある状態で撮影された紙の請求書の写真も、有効な入力となります。AIは、完全にフラットベッドスキャンされた文書を必要とするのではなく、フィールドの見た目と意味を理解することでフィールドを読み取ります。サプライヤーのERPが生成したPDFで動作するのと同じカラムスキーマが、小規模サービスプロバイダーからの手書き請求書の写真でも動作します。なぜなら、抽出はフィールドの位置ではなく、フィールドの識別情報を読み取るからです。

請求書の支払条件文字列が通常と異なる形式の場合、どうなりますか？

「20日締」→締日20、「月末締」→締日31といった標準パターンをカバーする解析ロジックを定義した計算列が対応します。非標準の条件（「15日締翌々月20日払い」や全く異なる表現）の場合、抽出では支払条件列に元のテキストを出力し、計算列は手動レビュー対象としてフラグを立てます。買掛金チームは、30件中1～2件のフラグ付き行を確認するだけで済み、全請求書の支払条件を手作業で解析する必要はありません。計算列のロジックを拡張して新しいパターンに対応するにつれ、フラグ付き行の数は減少します。

ゆうちょ銀行の口座番号は正しく抽出されますか？

はい、銀行名をゆうちょ銀行と検出し、ゆうちょ銀行の記号-番号から7桁の振込口座番号への変換ルールを抽出時に適用する推論列により対応します。出力には、元の口座参照（請求書との照合用）と、変換後の振込口座番号（支払バッチ作成用）の両方が含まれます。変換ルールはゆうちょ銀行のウェブサイトで公開されています。

10%と8%の消費税項目が混在する請求書はどのように抽出されますか？

推論列が各明細の説明を読み取り、日本の消費税区分（外食を除く飲食料品→8%軽減、その他ほとんどの商品・サービス→10%標準）に基づいて8%軽減または10%標準に分類します。計算列が各税率区分の小計を算出します。買掛金チームは、仕入先の記載小計と分類結果を照合します——これは分類ではなく比較のステップです。仕入先が軽減税率対象品目を明示しない請求書の場合、推論による分類が、各請求書PDFを開き直さずに仕入先の合計額が正しいかを検証する唯一の方法です。

このガイドと適格請求書抽出ガイドの違いは何ですか？

適格請求書抽出ガイドは、インボイス制度における適格請求書の6つの必須項目、経過措置による仕入税額控除のスケジュール、国税庁の登録番号検証プロセス、手書きや縦書き請求書の特有の課題に焦点を当てています。本ガイドはより広範な請求書抽出の全体像——買掛金チームが直面するすべての項目、抽出から支払、税務処理までの完全なパイプライン、そして適格請求書ガイドでは扱わない全銀フォーマット連携——をカバーします。コンプライアンスに特化した詳細は適格請求書ガイドをご参照ください。本ガイドはエンドツーエンドのプロセスを理解するためのものです。

日本の請求書から明細行（ヘッダー合計だけでなく）を抽出できますか？

はい。本ガイドで説明するカラムスキーマには、ヘッダーおよびフッターフィールドに加えて、明細行レベルのカラム（品名、数量、単位、単価、金額）が含まれています。各明細行は出力スプレッドシートの1行になり、ヘッダーフィールド（請求書番号、仕入先、発行日）が各行に繰り返されるため、すべての明細行を元の請求書にトレースできます。この構造により、請求書合計だけでなく個々の明細行を比較する必要がある三者照合（発注書→納品書→請求書）をサポートします。