請求書の明細行の計算が
抽出後に合わない理由

AIによる請求書データ抽出において、これは最も気づきにくい障害です。AIは個々のフィールドでは98%以上の精度を達成します。数量、単価、行合計を単独の値として正しく読み取ります。しかし、フィールド間の整合性は根本的に異なる課題です。「$150.00」を高い信頼度で読み取れるビジョンモデルでも、その$150.00が2行目の単価なのか、3行目の行合計なのか、セクション小計なのかを自動的に判断できません。これらの関係が崩れると、明細行の計算が合わなくなり、その誤りはフィールドごとの信頼度スコアでは見えません。

2025年のDoclingとLlamaExtractorに関する研究で、そのギャップが確認されています。整合性チェック（明細行 + 税 = 合計）は、請求書の20%で失敗しました。そのほとんどは、複雑な複数税率シナリオや非標準的なフォーマットのものでした（arXiv 2510.15727v1）。出力で数量×価格の不一致が発生している場合、該当する請求書はおそらく4つのパターンのいずれかに該当します。

▮ 原因1：AIが1行目の数量と2行目の単価をペアリングした

明細行が密集したテーブルは、行をまたぐペアリングエラーの最も一般的な原因です。請求書に15行以上の明細行があり、行区切りがなく、単に行が積み重なったテキストの場合、AIの空間認識は、ある行がどこで終わり、次の行がどこから始まるかを正確に判断する必要があります。数ピクセルのずれで、モデルがN行目の数量をN+1行目の単価と関連付けてしまう可能性があります。

行をまたぐ読み取りは、主に次の3つのシナリオで発生します。

• 行の境界線がない: 空白のみで行を区切っている請求書。AIは境界の位置を推測し、時々誤ります。
• 複数行の説明文: 商品説明が2行にわたると、後続の行が下に押し下げられます。AIは続きのテキストを新しい行としてマッピングし、後続のペアすべてをずらす可能性があります。
• テーブルヘッダーのセル結合: 結合された列ラベルを持つヘッダー行は、AIの列数検出を混乱させ、最初からテーブル構造全体の位置を誤らせる可能性があります。詳細はセル結合がテーブル抽出を破壊する仕組みをご覧ください。

発見方法: 行レベルの検証式を実行します（以下のフレームワークセクションで詳述）。行をまたぐ読み取りは特徴的なパターンを示します。一部の行は合計を過大評価し、一部は過小評価し、その誤差は小計レベルで相殺されます。

▮ 原因2：単位の混乱 — 「12」が常に12個とは限らない

請求書の明細行に「12」という数量があっても、単位が不明では曖昧です。12個なのか、12ダース（144個）なのか、12キログラムなのか、1フィートあたり3.75ドルの12リニアフィートなのか。数字自体は明確でも、AIは「12」が何を表すのかを知らなければ、単価と掛け算できません。

単位（UOM）の混乱は、2つの異なるエラーパターンを生み出します：

• 単位が別の列にある場合：一部の請求書では、数量と単価のフィールドの間に「単位」列（EA、DZN、KG、FT）があります。AIがこの列を読み取れない、または関連付けられない場合、「12 DZN」（144個×価格）を「12 EA」（12個×価格）として扱い、本来の1/12の明細合計を出力します。
• 単位が説明文に埋め込まれている場合：多くの請求書では、説明フィールド内に「12 × CASE」や「12 @ CASE PRICE」と記載されています。AIは「12」を数量列に読み取りますが、この「12」が「1ケース6個入りの12ケース」を意味することを理解する仕組みがありません。結果として、数量×単価の合計はケース倍率分だけずれます。

このエラーは、数字が内部的に整合しているように見えるため、見破りにくいものです。数量=12、単価=45.00ドル、明細合計=540.00ドル — 計算は合っています。しかし、請求書に実際には「12ダース、1ダースあたり45.00ドル」と記載されており、AIが12個として読み取った場合、合計は12倍もずれます。AIは一見もっともらしい数字を抽出したものの、たまたまビジネスの現実チェックに失敗したのです。

単位関連の抽出問題は、元のドキュメントに小数点の欠落や曖昧な通貨記号がある場合にさらに悪化します — 単価の小数点欠落は、単位の不一致を拡大させます。

発見方法：明細合計を、同じ品目の価格表または過去の平均価格と照合します。過去に1個あたり7.50ドルだった品目の単価が45.00ドルというのは危険信号です — AIが単位を「EA」と読み取ったものの、実際は「BOX（6個入り）」だった可能性があります。過去データがない請求書の場合は、数量×単価が端数のない数字で、想定価格範囲から外れている明細にフラグを立ててください。

▮ 原因3：割引前と割引後の明細金額の混同

請求書では、明細行の合計金額の表示方法に複数の慣例があります。明細行には割引前の総額を表示し、割引は請求書のフッターで適用するものもあれば、明細行に割引後の正味額を直接計算して表示し、「割引合計」を別途まとめるものもあります。AI抽出モデルは、特に列ヘッダーに単に「金額」とだけ記載されている場合、特定の請求書がどの慣例を使用しているかを判別できないことがよくあります。

抽出の混乱を引き起こすほど一般的な割引の慣例は3つあります：

• 明細割引あり、明細行は総額表示: 明細行には数量 × 定価が表示されます。割引は請求書のフッターで適用されます。AIは明細合計をそのまま抽出し、数量 × 単価と一致します。ここに不一致はありませんが、割引額は明細レベルでは見えません。
• 明細割引あり、明細行は正味額表示: 明細行には数量 × (定価 − 割引) が表示されます。単価列には依然として50.00ドルと表示されますが、明細金額は割引後の値を反映しています。数量 × 50.00ドル ≠ 明細合計となり、すべてのフィールドが正しく読み取れていても不一致が生じます。
• 同一請求書内での混在: 一部の明細行には割引があり、一部にはありません。AIはすべての行に一律の解釈を適用するため、一部の行は一致し、一部は失敗します。

見分け方: このエラーの特徴は、複数の明細行にわたって、数量 × 単価が一貫して明細合計を一定の割合だけ上回ることです。割引のある明細行で「金額 = 数量 × 単価 × 0.95」というパターンが見られ、割引のない明細行では一致する場合、請求書は明細行に正味額を表示する方式を使用しています。これらにフラグを立て、抽出エラーと決めつけずに、ベンダーの割引条件を確認してください。

▮ 原因4：税込金額と税抜金額が同一請求書に混在

VAT/GST対象地域の請求書では、同一書類に税込価格と税抜価格が混在することがよくあります。一部の明細は表示金額に税が含まれ（消費者向けやB2C販売で一般的）、他の明細は税抜金額で表示され、フッターでVATが計算されます（B2Bで標準）。すべての明細に単一の解釈を適用するAIモデルは、混在する行で不一致を生じます。

多くの請求書では、個々の明細に「税込」や「税抜」のラベルは付いていません。その区別は、顧客の種類、商品カテゴリ、管轄区域から暗黙的に決まります。これは、XeroやAutoEntryのような会計ソフトウェアでも、専用のトグルスイッチで対応しているほど微妙な点です。

このエラーを引き起こす実際のシナリオは3つあります：

• 混合供給の請求書：例えばホテルの請求書では、宿泊料金（標準税率のVAT対象）とサービス料（VAT非課税）、駐車場（軽減税率）が記載されます。各明細は、仕入先の会計システムに応じて税込または税抜で表示され、抽出対象に不整合が生じます。
• 国際請求書：米国の仕入先が英国の顧客に請求する場合、明細金額は米ドル（VATなし）で表示されますが、フッターにはリバースチャージVATの注記が適用されます。主に国内の請求書パターンで学習したAIは、非課税の明細金額を異なる方法で解釈する可能性があります。
• クレジットノートと調整：元の税込/税抜金額を参照する訂正行があると、AIがすべての行に一貫した税解釈を適用しようとして不一致が発生します。

arXivの請求書抽出調査では、一貫性の欠如は「複雑な複数税シナリオの請求書に集中している」ことが判明しました。これこそ、個々のフィールドが間違っていなくても、数量×単価≠明細合計となる、税込/税抜混在の書類です。

発見方法：同一請求書内で、不一致率が特定の税コードや商品カテゴリと相関しているか確認します。VATコード「S」（標準税率）の明細はすべて一致するのに、コード「Z」（ゼロ税率）の明細がVAT率と正確に同じ偏差を示す場合、AIがゼロ税率項目に誤った税込/税抜の前提を適用していることになります。

▮ 解決策：明細行の整合性をチェックする3層検証フレームワーク

上記4つの原因は、抽出データにそれぞれ異なる痕跡を残します。体系的な検証フレームワークがあれば、それらをすべて捉えられ、フィールド単位の信頼度スコアでは見えない問題を可視化できます。

第1層：行単位の検証式

最も手軽な包括チェックは、計算式の列を追加することです：

=ROUND(数量*単価,2)

抽出された行合計と比較し、差が0.01ドルを超える行に条件付き書式でフラグを立てます：

=ABS(ROUND(A2*B2,2)-C2)>0.01

誤差の方向と大きさから、原因を特定できます：

• 複数行で誤差が相殺される → 原因1（行またぎ読み取り）。値はすべて存在するが、ペアリングが間違っている。
• 一定の係数でずれる（例：常に0.5倍、6倍、12倍） → 原因2（単位の混同）。その係数が単位換算倍率。
• 一定の割合でずれる → 原因3（割引の混同）。その割合が割引率に一致する。
• 特定の税コードに関連してずれる → 原因4（税込み/税抜きの混同）。ずれの割合が該当する消費税率に一致する。

第2層：AIのためのフィールド関係ヒント

抽出設定時に、どのフィールドが互いに関連するかを明示することで、AIが関係性を理解しやすくなります。ImageToTable.aiのカスタム列抽出は意味的に動作します。つまり、必要な列を指定するだけで、AIが各値の意味を理解して位置を特定します。クロスフィールドのペアリング精度を向上させるには：

• 説明的な列名を使用する：「単価（1個あたり）」や「行合計（数量×単価）」とすることで、AIが単価と行合計を区別しやすくなります。
• 検証用の計算列を定義する：「行合計検証（数量×単価）」列を作成します。AIが値を抽出して計算を実行し、エクスポート後ではなく抽出時に不一致を検出します。
• 数値フィールドに書式ルールを設定する：数量は小数点がない限り整数、単価は常に小数点以下2桁と指定します。これにより、解釈の曖昧さが抑制されます。

レイヤー3：対象を絞ったスポットチェックサンプリング

計算式によるチェックを行っても、数量×単価がたまたま誤った行合計と一致する場合など、一部のエラーはすり抜けます。対象を絞ったスポットチェックサンプリングがその隙を埋めます。バッチごとに、レイヤー1でフラグが立ったすべての行、合格した行の10%（偶然の正しい合計を検出するため）、およびベンダーごとに1件の請求書（体系的な書式の癖を確認）を手動で検証します。これにより、数学的な不一致の95%以上を捕捉しつつ、手動レビューが必要なデータは15%未満に抑えられます。

▮ エスカレーションの判断基準：5%の閾値

検証フレームワークがバッチ全体の明細行の5%以上にフラグを立てた場合、問題はおそらくシステム的なものです。つまり、明細行レベルで検証計算式をいくら調整しても修正できない、フィールド間の一貫した不整合パターンが存在します。

エスカレーションが必要な3つのシナリオ：

• 単一ベンダーへの集中：フラグが立った行の70%以上が1つのベンダーからのもの。そのベンダーのレイアウトが現在のアプローチと互換性がありません。これらの請求書を事前処理するか、別のパイプラインにルーティングしてください。
• 複数税率の複雑性：3つ以上の税率、または税込・税抜が混在する請求書。最良のモデルでも、これらは20%の確率で失敗します（arXivの研究による）。抽出の修正を試みるのではなく、税務専門の買掛金担当者による手動レビューに回してください。
• 低品質のソース文書：4つのパターンすべてに同時にフラグが立つ場合、根本原因は関係性の混乱ではなく、OCRの品質低下です。まずソース品質に対処してください。小数点と通貨の抽出修正を参照。

この閾値は、チームが際限のない調整サイクルに陥るのを防ぎます。独立フィールドで98%以上、フィールド間の整合性で95%以上の抽出精度が達成できれば、ほとんどの買掛金ワークフローで実用的です。残りの5%は、完全に排除しようとするよりも、例外ルーティングで処理する方がコストが低くなります。

▮ よくある質問

数量×単価の不一致は、常に抽出エラーを意味しますか？

いいえ。一部の請求書では、明細金額が数量×単価と一致しないことがあります。これは、明細レベルでの数量割引、プロモーション価格、または明細の単価が平均値であるパッケージ契約などが原因です。不一致を抽出エラーと判断する前に、必ず元の請求書と照合してください。

明細に計算不一致がある場合、合計金額は信頼できますか？

自動的には信頼できません。原因1（行をまたぐ読み取り）が該当する場合、エラーが相殺され合計金額が正しい可能性があります。しかし、原因2～4の場合、明細金額が小計や合計の計算に使用されるため、合計金額が誤っている可能性が高いです。抽出した合計金額を支払いに使用する前に、必ず明細レベルの不一致を解決してください。

AIツールが、誤ってペアリングされたフィールドに対して99%の信頼度を報告するのはなぜですか？

信頼度スコアは個々のフィールドの読み取りやすさを測定するものであり、フィールド間の論理的な整合性を測定するものではないからです。ビジョンモデルは、ページ上の特定の位置に「$150.00」が表示されていることに99%の確信を持つことができますが、その$150.00が単価であるか明細合計であるかに関わらず、その確信度は変わりません。フィールド間の検証は、信頼度スコアでは代替できない別のステップです。

ベンダーごとに異なる単位の混乱にはどう対処すればよいですか？

抽出テンプレートに「単位」列を追加して、抽出出力を標準化してください。明確な形式指示を含めます：「同じ行から単位（EA、DZN、KG、FT、CASE、BOX）を抽出し、別の列として出力してください。」これにより、出力で単位が可視化され、AIによる自動解釈に頼るのではなく、スプレッドシートに換算ルールを組み込むことができるようになります。

▮ 買掛金管理における真実の単位は明細行

ヘッダーレベルの抽出（ベンダー名、請求書番号、合計金額）は、コモディティ化され正確になりました。品質に有意なばらつきが依然として見られる最前線は明細レベルであり、フィールド値と同様にフィールド間の関係が重要です。AIは個々の数値を正しく読み取りますが、正しい列と行への割り当ては、モデルがドキュメントのセマンティクスを理解しているかどうかに依存します。このセマンティックな理解は急速に向上していますが、フィールド間の検証を省略できるレベルにはまだ達していません。フレームワーク（計算式列＋関係性ヒント＋対象を絞ったサンプリング）は、支払いや照合に使用される抽出ワークフローに適したプロセスです。

次のバッチで計算式列を設定してください。=ROUND(数量*単価,2)と条件付き書式を追加するのに必要な5分間で、どんな信頼度スコアよりも抽出品質について多くのことがわかります。