AIで請求書から支払期日を抽出する方法｜読み取りミスも確認

請求書から支払期日を抽出する場合、OCRが返した日付をそのまま支払登録へ流さず、請求書番号・取引先・金額と結び付けて原本を確認します。明記された期日、支払条件から人が算出した期日、社内承認期限は別の値として扱います。抽出成功は請求書の真正性や支払承認を意味しません。

抽出Schemaを分ける

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

Field	保存する値	QA
supplier	取引先名と識別子	登録済み取引先と照合
invoice_number	請求書番号	重複・桁違いを確認
invoice_date	発行日	元表記と照合
due_date_text	原文に記載された期日	ページ・field位置を保存
due_date_normalized	正規化した日付	locale、year、format
due_date_calculated	支払条件からの算出日	rule、起算日、承認者
amount / currency	合計と通貨	税額・小計との整合
source / confidence	OCR根拠とsystem metadata	confidenceは承認ではない

「支払期日」fieldが複数ある場合は、ページ上のlabel、注記、取引先との契約、請求日・納品日との関係を確認します。支払条件文から算出した日付は、原文の明記値として保存せず、適用したruleと算出者を記録します。条件が曖昧なら空欄やneeds_reviewを保ちます。

OCR候補と原本照合

Google Cloud Document AI Invoice Parserの公式processor listは、請求書からinvoice date、due date、supplier、amountなどのfieldを抽出する機能を示しています。ただし同じページの現在のsupported-language listにはJapaneseが掲載されていません。日本語請求書で利用する場合、対応言語を推測せず、利用するprocessor version・地域・入力言語を公式docsで確認し、実資料に対する適合を検証してください。fieldが列挙されていることは、日本語文書での精度や支払処理の安全性を保証しません。

Google Cloudのnormalization資料では、元のmention textとnormalized valueが別に得られるfieldが説明されています。原文表示と正規化値を両方保持し、日付のlocale、区切り、年の省略、和暦・西暦の違いを確認できるようにします。Normalizationは原文の意味を人が確認する工程を置き換えません。

日付を計算する場合

「月末締め翌月末払い」「検収後30日」などの条件は、起算日、営業日、休日、締め日、特約によって結果が変わる可能性があります。文章をAIに読ませて自動で支払日を確定させず、社内で承認された計算ruleに照らします。

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

抽出状況	保存	次の処理
期日が一つだけ明記	原文＋正規化値	原本と一致なら人の承認へ
候補が複数ある	全候補とページ位置	担当者へ確認
条件から算出	条件文＋算出rule	適用日・営業日を確認
OCR値が低信頼	OCR候補・画像位置	原本を拡大確認
請求書と取引が不一致	candidateを保留	取引先・番号・金額照合

人の確認へ回す条件

• scanが傾いている、文字が不鮮明、手書き、複数ページの表が崩れている。

• 期日候補が複数ある、または支払条件文だけで日付が明記されない。

• supplier・invoice number・amountのいずれかが取引記録と一致しない。

• due dateがinvoice dateより前、年をまたぐ日付、locale曖昧など不自然。

• processorが対象言語・region・file形式に対応しているか不明。

• 変更請求書、credit note、重複請求、差替え版が疑われる。

支払登録前に抽出値、原本、会計systemの3点を照合します。請求書の読み取りだけを根拠に支払を実行せず、承認者、支払先bank information、社内権限を別のcontrolで確認してください。変更された口座情報が請求書に記載されていても、自動で登録せず、既知の連絡経路で確認します。

段階的に導入する

最初は過去の完了済み請求書など、許可された検証用資料で、正解ラベルを人が作ったtest setと抽出結果を比べます。due dateだけでなくsupplier、番号、amountとの紐付け、ページ位置、誤検出を測ります。特定のfile形式や言語に対象を限定しても、難しいlayout、scan品質、手書きで結果が変わる可能性があります。errorが見つかったら、未対応条件を明示して人のreviewへ回します。

test setが許容できても、最初から自動支払へ接続せず、候補表示と人の承認を続けます。処理件数、要確認率、訂正率を見て対象範囲を再評価し、processor versionや入力形式を変えたら再testします。性能のthresholdを根拠なく一律に決めず、誤った期日を通したときの業務影響から承認基準を設定します。

AIものさしの判断

期日抽出の品質はOCRの値だけでなく、その日付が正しい請求書と結び付いているかで決まります。原文表記と正規化値を保持し、支払条件からの算出や日本語対応が未確認なら人へ回してください。抽出結果から支払可否を決めず、承認済みの会計・支払フローへ渡す段階までに留めます。

原文・正規化値・算出値を別フィールドにする

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

フィールド	例	意味
due_date_raw	請求書に記載された文字列	OCRの抽出結果そのもの
due_date_normalized	2026-10-31	原文の日付を機械処理用へ整えた値
due_date_calculated	未設定	支払条件から計算した日付。規則と対象期間が必要
due_date_source	invoice field / payment term	どの記述から値が生まれたか
review_status	needs_review	人の照合前は支払確定へ渡さない

Google Document AIのNormalizationは、該当するfieldで元のmention textと別に正規化値を返す場合があります。正規化値だけを残すと、OCRが何を読んだかと変換結果を比較できません。両方を保存し、日付formatの変換で月日が逆転していないか、年が欠落していないかを原文で確認します。

日本語請求書の対応を先に確かめる

Google Cloud Document AIのProcessor Listに掲載されたInvoice Parserの対応言語を確認し、使うprocessor/versionの対応範囲と対象regionを照合します。現在の公式一覧で日本語が確認できない場合、日本語請求書をそのまま正確に処理できると仮定しないでください。これはDocument AI全体が日本語を扱えないという主張ではなく、Invoice Parserの当該一覧と個別processorの条件を確認するという意味です。機能や対応言語は変わり得るため、導入時に最新の一覧を再確認し、実データに近いsampleで精度を測ります。

日付抽出のFailure Matrix

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

症状	起こり得る原因	処理
請求日を期日として抽出	複数日付を混同	field labelと前後の記述を原本確認
10/11の月日が不明	locale・書式の曖昧さ	正規化せず要確認
末日がずれる	支払条件の起算日・休日扱い	条件と会社ruleを担当者確認
同じ期日が別invoiceへ付く	file/recordの結合ミス	invoice number、supplier、amountを再照合
confidenceが高いが値が誤る	confidenceは業務承認ではない	原本との照合を継続

信頼度は人の確認順位を決める補助には使えますが、支払可否の判定ではありません。金額やsupplierの不一致、日付候補が複数ある場合には、confidenceが高くても止めます。読み取り不能をAIに補わせず、原本の再取得や担当者確認へ回してください。

小規模評価セットを作る

本番導入前に、請求書の種類別に正解labelを人が付けた検証セットを用意します。電子PDF、scan、傾き、低解像度、複数ページ、複数の期日表記を含め、supplierやinvoice numberとdue dateの紐づけも評価します。測定は「期日文字列の抽出」だけでなく、「正しい請求書recordへの紐づけ」「誤読をQAで止められた率」「要確認への振り分け」を分けます。少数sampleで高い一致率が出ても、別の帳票形式へそのまま一般化しないでください。

支払フローとの接続

抽出処理は、請求書受付、重複照合、期日の確認、承認、支払予定登録、実支払を別stateとしてつなぎます。AI処理が成功しても請求の真正性や支払承認が済んだことにはなりません。少なくともsupplier・invoice number・amount・due dateが同じdocumentから取れたかを検証し、承認者の記録があるものだけ次の支払工程へ渡します。訂正が入った場合に元の抽出値と修正後の値を追跡できる履歴も必要です。

導入判断

帳票が一定で日本語対応と精度を確認でき、間違いを人が止められる場合は、期日候補の抽出から始められます。入力言語や帳票形式が未確認、支払条件が文章だけ、複数候補がある場合は、抽出値を支払システムへ直結しません。まずOCRの出力と人の確認結果を並べて蓄積し、どの誤りが実際に起こるかを見た後で処理範囲を決めます。