請求書をAIで読み取るには？経理の確認項目と導入の進め方

取引先から受け取った紙やPDFの請求書を、ここでは「原本」と呼びます。原本を表へ写す仕事と、注文した内容が届いたかを確かめる仕事は別です。転記が速くなっても、何の取引か分からないままでは正式な処理へ進めません。

AIは、請求書に書かれた番号や金額を取り出し、決めた表の欄へ並べる入力案づくりを補助できます。発注・納品・過去の支払いと合うか、会計へ正式登録してよいか、支払いを承認するかは、人と社内の手続きに残します。入力案ができたことを、経理全体の自動化が終わったことにはしません。

社内で利用を認めた環境と資料で試します。読み取るサービスへ資料を渡してよいか、誰が原本を見られるかも先に決めます。この記事の架空例を、本物の取引情報を外部へ送ってよいという許可には使わないでください。

Microsoftの請求書処理モデルの公式資料には、請求番号や期日、金額、前回未払などを取り出す項目と、読み取りへの確かさを表す信頼度が載っています。これは製品の機能説明で、請求の正当性や支払承認の証明ではありません。自社の帳票に使えるかは、契約・対応条件と試行で確かめます。

最初の材料は、請求書一件、今の転記先、照合に探す発注・納品・支払記録です。経理以外の現場が確認するなら、誰へ渡し、何が戻れば処理を続けられるかも決めます。入力案だけを外注し、資料探しが経理に残る場合は、その仕事も比較に含めます。

この章の根拠：Microsoft：請求書処理モデルNIST：生成AIリスク管理プロファイル

架空の請求書には、請求番号「I-01」と、今回分44,000円、前回未払11,000円、請求総額55,000円が書かれています。支払期日は記載されていません。この5項目を写す例で、番号は今回の原本を識別するための見本です。

44,000円と11,000円を足すと55,000円です。しかし55,000円を「今回分」の欄へ写すと、原本の意味が変わります。請求書に書かれた総額と、照合後に支払ってよいと決める金額も別です。前回分がすでに支払済みなら、その記録を確かめる必要があります。

期日がない場合は「未記載」と書き、過去の請求書や一般的な締日からAIに補わせません。読めない文字は読み取り不明として残します。米国国立標準技術研究所（NIST）の資料も、生成AIが誤った内容をもっともらしく出すリスクを扱っています。自信のある文章や高い信頼度を、確認済みの印にはしません。

表で計算する場合も、原本の「55,000円」という表記と数値55000を対応させます。通貨、税込・税抜、マイナスや単位は原本に沿って残し、意味の分からない欄をAIに決めさせません。税区分や正式な会計処理は、必要な担当者が確認します。

複数ページの請求書は、総額のあるページと明細の続きがそろっているかを見ます。一枚目だけを読ませ、二枚目の値引きを落とすと違う案になります。必要なページがない場合は、値を推測せず原本不足として戻します。

表は横に動かして、右端の確認内容まで読めます。

この章の根拠：Microsoft：請求書処理モデルNIST：生成AIリスク管理プロファイル

今回分44,000円は、何を注文し、何が届いたことへの請求かを、対応する発注書と納品記録で確かめます。前回未払11,000円は、過去の支払記録と照合します。足し算が合うことは、両方の取引を確認したことではありません。

確認途中の見本は「今回分44,000円は納品記録と照合待ち。前回未払11,000円は支払済み一覧を確認中。期日は取引条件を確認中」です。確かめたことと残ったことを分ければ、次の担当も何を開けばよいか分かります。この文章は架空の作業例で、確認が終わった実績ではありません。

同じ取引先・請求番号・総額の記録が二つあっても、一つは訂正前の版かもしれません。どちらかをすぐに削らず、受領日、元の請求書と修正版、訂正の経緯を調べます。逆に番号が違っても、同じ納品への二重請求の可能性は残ります。

口座や金額が変わったときも、読み取り結果をそのまま採用せず、会社で決めた方法で確認します。重複候補を自動で出す場合は、何を同じとみなし、誰が確定するかを試行で決めます。取引や支払いの判断を、入力案の印だけで代わりにしません。

この章の根拠：Microsoft：請求書処理モデルNIST：生成AIリスク管理プロファイル

入力案で期日が未記載なら、そのまま確認担当へ戻します。人が取引条件を調べて期日を追記した場合は、AIが原本から読んだ値と、人が根拠を見て加えた値を区別します。何を誰が直したか、戻れる資料を残します。

「確認済み」の意味も分けます。原本の金額を確認した印、発注・納品を確認した印、支払いを承認した印は同じではありません。社内で正式処理する担当者が、必要な根拠へ戻れることが大切です。通知を送っただけで、担当者の確認が済んだことにはしません。

一部が読めない場合は、読めた欄と読めない欄を分けて残せます。ただし会社の処理に必要な項目が欠けているなら、正式登録や支払いへ進めません。確認中に別の担当が同じ請求書を登録しないよう、入力案・確認待ち・正式処理の状態も共有します。

訂正は、値だけを入れ替える方法と、元案を残して訂正版を作る方法を比べます。履歴や保存の要件は自社の運用に合わせ、少なくとも元の記載と、後から確認した内容が混ざらないようにします。責任者の権限と承認手続きは、今の社内ルールを使います。

この章の根拠：NIST：生成AIリスク管理プロファイル

既存の会計ソフトに読み取り機能があるなら、請求書一件で、5項目を出せるか、原本を開けるか、未記載を残せるかを確かめます。今の機能で確認作業が進むなら、まず設定や帳票の整理で足りるかを見ます。追加のAIを先に買うことが出発点ではありません。

少量で項目が少なければ、手入力と表の整備が候補です。OCRは紙や画像の文字を読み取る仕組みで、必要な欄を取り出す機能と組み合わせる場合もあります。生成AIは文章を表へ整理する候補ですが、原本にない値を補わない条件と人の照合が必要です。名前だけでどの帳票にも使えるとは判断しません。

依頼先には、取引情報を伏せた請求書と欲しい表を渡します。「請求番号、今回分、前回未払、請求総額、期日の5項目をこの欄へ。期日は未記載のまま。元のページと読んだ場所へ戻れるようにする」が入力案の完成条件の例です。複数ページ、訂正、読みにくい原本も含めて、できることと戻す条件を比べます。

入力案を受け取ることと、会計ソフトへ正式登録することは分けて頼みます。接続が必要なら、出力形式、渡す項目、権限、取り込みエラーと重複時の戻し方を確認します。ソフト名が同じだけで接続できるとは限りません。仕組みの変更後に誰が直すかも、保守の条件です。

費用は、初期設定、利用契約、処理枚数、接続、例外対応、保守で変わります。枚数には複数ページや再処理をどう数えるかも聞きます。原本探し、入力案の訂正、照合、会計へ渡すまでの全員の時間を同じ範囲で測り、一件だけ速かった結果で導入を決めません。

電子で受け取った取引データの保存は、国税庁の案内と自社の取得方法・運用を確認します。入力表だけを残して原本を捨てたり、このメモだけで保存要件を満たすと判断したりしません。必要な判断は経理の責任者や専門担当へ確認します。

表は横に動かして、右端の確認内容まで読めます。

この章の根拠：Microsoft：請求書処理モデルNIST：生成AIリスク管理プロファイル国税庁：電子取引関係

この架空例では、今回分44,000円、前回未払11,000円、原本の請求総額55,000円を分け、期日は未記載にしました。原本の5項目を写せても、取引や支払いの確認が終わったわけではありません。元の欄と根拠へ戻れることが、経理の次の仕事につながります。

まず今の会計ソフトで試し、足りなければ入力案づくり、確認待ちの管理、会計への接続のどこを頼むか決めます。担当へ渡すのは、利用してよい原本、欲しい表、確認する資料と人、必要な欄が欠けたときの戻し方です。費用は同じ完成範囲で聞いてください。

下の7欄メモは、その相談を始めるための任意の補助です。全部を埋めなくても、分かることと不明なことを分けて相談できます。記入・保存を、会計への正式登録や支払いの承認と混同せず、処理へ進む前に確認担当へ戻しましょう。

この章の根拠：Microsoft：請求書処理モデルNIST：生成AIリスク管理プロファイル国税庁：電子取引関係