AIで請求書の内容を読み取り一覧化する方法

請求書をAIで一覧にするときは、PDFから文字を読み取る工程、必要な項目へ分類する工程、金額・日付を原本と照合する工程を分けます。「請求書を表にして」と一度頼むだけでは、書式が違う書類で列がずれたり、税込・税抜・税額を取り違えたりする可能性があります。読めた項目をそのまま会計データにせず、元ファイルへ戻って重要項目を確認し、一覧で再利用できる状態にして初めて完了です。

まず出力列と原本管理を決める

処理の前に、後工程が必要とする項目と、元証憑へ戻るための識別子を決めます。すべての請求書に同じ項目があるとは限らないので、空欄を推測で埋めず「記載なし」「読取不能」「確認待ち」を分けます。

表は横にスクロールできます

Field	入れる情報	確認上の注意
source_file / page	元PDFのファイル名・ページ	抽出結果から原本へ戻れる
supplier_name	発行元の名称	住所や振込先から推測しない
invoice_number	請求書番号	記載がない場合は空欄・状態で区別
invoice_date / due_date	発行日・支払期日	日付形式を統一し、読み違いを確認
subtotal / tax / total	小計・税額・合計	税込・税抜と通貨を区別
currency	通貨	金額の記号だけで確定しない
review_status	未確認・確認済み・修正	自動抽出と人の確認を分離

どの列が業務上必要か、税計算の扱いは会計担当・既存ルールに合わせます。ここで独自の税務判断を作らず、AIへ制度解釈を任せないでください。支払先口座など高リスク情報を保存する場合は、閲覧権限、保管場所、保存期間を社内ルールに合わせます。

OCRと項目抽出は違う

OCRは画像やPDF内の文字を読み取る処理です。Field extractionは、読み取った文字のどれが請求日・取引先・合計額に当たるかを分類します。請求書の見た目から数値を読めても、それが小計か総額か、複数通貨のどれかは書面の構造を見て判断する必要があります。

Google Cloud Document AIのInvoice Parserは、請求書からinvoice number、supplier、請求金額、税額、発行日、期日、明細などを抽出するプロセッサとして案内されています。一方、現行の公式Processor listにあるInvoice Parserの対応言語一覧には日本語が含まれていません。Form Parserや別の一般OCRに日本語対応があっても、それはInvoice Parserの日本語請求書抽出が正式対応していることを意味しません。日本語処理が必要なら、対象プロセッサとversionのlanguage listを個別に確認し、サンプルで精度を検証してください。

少量処理を始める流れ

1. 扱ってよいサンプル請求書を選ぶ。顧客や口座等の機密を含む場合は、外部AIへの送信許可と契約を確認する。

2. 先に出力Schemaを定義し、金額・日付・税額・通貨を別列にする。

3. PDFのページ数、傾き、解像度、文字のかすれを確認し、読みやすい入力を用意する。

4. OCR結果と項目抽出結果を分けて保存する。

5. 合計、税額、取引先、期日などの重要項目を原本の該当箇所と照合する。

6. 読めない項目は「要確認」とし、空欄をAIに補完させない。

7. 重複検査後、承認済みの行だけ一覧へ確定する。

この手順は特定サービスを利用した実測結果ではありません。使うOCRやAIサービス、ファイル形式、言語対応によって操作画面や出力Schemaは変わるため、実際の管理画面・API仕様に合わせて調整します。

抽出結果を照合するChecklist

表は横にスクロールできます

項目	原本で見る場所	PASS条件	FAIL時
取引先	発行者欄・登録済み取引先表	表記と登録先を確認	別名候補を照合
請求書番号	番号欄	文字・桁・記号が一致	原本拡大、手入力確認
日付	発行日・支払期日欄	年月日と列が一致	形式を変え再確認
金額	合計・税額・小計の欄	税区分と通貨が一致	3項目を別々に照合
明細	明細表	行数・単位・小計が一致	ページごとに確認
source link	元PDF	一覧行から原本を開ける	登録前に修復
状態	review_status	人が確認したときだけ確認済み	保留に戻す

数値の桁区切り、小数点、マイナス、括弧、複数ページの続きを注意して見ます。スキャン画像では文字と罫線が接触したり、薄い印影で文字が隠れたりします。高額、支払期日が近い、複数通貨、修正請求などのケースは、通常サンプルより慎重にreviewする条件としてワークフローに明記します。

読み取りに失敗した書類を保留する

抽出結果に値がないときは、請求書に記載がない、OCRが読めない、対応外の言語・形式、出力Schemaが不足している、のどれかを区別します。空欄一つだけでは理由が分かりません。review_statusへ未確認理由を持ち、原本を拡大する、別のOCRを検討する、手入力する、担当者へ差し戻すなど、事前に決めた経路へ送ります。数値を周囲の記載から推測して補完しないでください。

同じ書類でも文字埋め込みPDFとスキャン画像では処理が異なることがあります。元PDFからテキストをコピーできるか、ページごとに画像品質が違うか、表の罫線や複数段組があるかを確認します。処理前後のファイル形式、Processor ID、version、設定を残しておけば、変化の原因を追いやすくなります。ただし、これらの項目は使う製品の正式なAPIや管理環境で確認できる範囲に限り、仮の設定名を作らないでください。

重複と一覧化を検査する

請求書番号だけが一意とは限りません。取引先、請求書番号、発行日、通貨、合計額など、組織のデータ上で確認できるKeyを使い、同じ書類を二重登録していないか調べます。番号が空欄なら別の識別手順を定義し、AIに適当な番号を作らせません。

AIの表をCSVやSheetsへ移す前に、各行にsource_fileとreview_statusを保ちます。集計や支払データへ接続する場合、未確認の行が自動的に合算・処理されないよう、承認済みレコードだけを対象にします。抽出の成功と業務処理の承認は別工程です。

計算・重複照合の具体例

請求書の小計・税・合計は、AIの抽出列をそのまま合算するのではなく、書面内の合計と突き合わせます。例として、各明細の数量×単価を合計して小計欄と照合し、税額欄と総額欄を別々に確認します。丸め、割引、送料、複数税率など書類に記載された条件がある場合、単純な一致式だけでは差が出る可能性があります。会計上の処理ルールは社内の担当者が確認し、AIへ税務判断を作らせません。

重複候補を探すときも、キーを一つの列へ無理に押し込まず、取引先と番号、日付、通貨、金額などを個別に保持します。候補行が一致した場合は、自動削除せず元ファイルを開いて同一書類か確かめます。訂正・再発行・分割請求があると、同じ番号や金額が別の意味を持つことがあります。

件数を増やす前のPilot

最初の数件は、書式の異なる請求書を含めて処理し、どの項目がよく読め、どの条件で人の修正が増えるかを記録します。書式が一つだけの成功をすべての請求書へ一般化しません。読取率や処理時間を外部へ報告する場合も、件数、書式、言語、評価方法、誤りの定義を測定してからにします。

表は横にスクロールできます

Sample	言語・形式	未確認/誤読Field	修正者	原本照合	次の判断
1	PDF/画像/スキャン	＿＿＿	＿＿＿	PASS/FAIL	Schema修正
2	異なる書式	＿＿＿	＿＿＿	PASS/FAIL	追加試験
3	複数ページ	＿＿＿	＿＿＿	PASS/FAIL	手動工程が必要
4	文字が薄い/表が複雑	＿＿＿	＿＿＿	PASS/FAIL	再スキャン・保留

この記録から、対象の入力形式・言語で安全に一覧化できる範囲を決めます。誤読の傾向が不明な場合は対象範囲を広げず、人の確認を継続します。

項目の誤りを発見したら、抽出した値だけを上書きするのではなく、原本・修正値・修正者・確認日を追える形にします。金額を修正した際は合計列や重複判定へ反映されたかも確認し、古い抽出値を残したまま二つの値が混在しないよう、レビュー済みの状態を明確にします。\n\n## AIものさしの判断

請求書一覧化では「文字が読めたか」より、「重要Fieldが原本へ追跡でき、未確認を未確認として保留し、二重登録なく次工程へ渡せるか」を完了条件にします。日本語請求書を扱う際は製品名だけで言語対応を判断せず、利用するProcessorの公式対応言語、version、入力条件を確認します。会計・支払処理へ流す前に、人が照合・承認する段階を残してください。

保留行を一覧へ混ぜず、原本確認が終わったあとに確定データへ移します。