請求書と発注書の照合を自動化する：経理担当者の確認を減らす設計

この記事でわかること

原本・発注・受入の正本を確かめる。

対応候補と規則による照合を分ける。

差異や資料不足は理由付きで担当へ渡す。

請求書を一枚読むだけなら、それほど時間はかからないかもしれません。ところが、品名を発注書で探し、納品記録を確認し、以前の請求と重複していないかを調べると、複数の画面を行き来することになります。月末に残るのは、文字が読めなかった書類だけでなく、分納、まとめ請求、訂正など、判断のための情報が足りない案件です。

GoogleのAgent Development Kit、ADKを使った自動化を考えるなら、請求書から文字を抜き出すところで終わらず、どの発注と対応するか、何が一致し、誰が何を確認すべきかまで整理したいところです。担当者の確認を減らすには、判断材料を探す作業と、業務上の判断そのものを分ける必要があります。

本稿では、連載の仮想企業「ケース企業A」を使い、照合結果と例外台帳を作る設計を説明します。社員35人の法人向け設備・部品販売会社という設定も、以下の金額・件数も説明用の仮定です。KONDAXや顧客企業の導入成果ではありません。技術情報と公開事例の確認日は2026年10月14日です。対象は書類の整理・照合であり、会計・税務の判断や自動支払の設計ではありません。

文字が読めたこと、書類が一致したこと、業務として処理してよいことは、それぞれ確認が必要です。

「読み取り成功」だけで仕事を終わらせない

請求書から会社名と合計金額を抽出できても、相手先が台帳のどの会社かは未確認かもしれません。請求日が正しく読めても、対象期間が前月分か、既に処理した訂正前の書類かは別の問題です。品名が似ているだけで発注に結び付けると、担当者が本来見つけるべき違いを隠してしまいます。

初期の完成条件は、「発注と請求の対応候補、一致項目、差分、根拠、次の確認担当が揃う」とします。全件を自動で一致扱いにする必要はありません。数量の違いや資料不足を理由付きで保留できれば、担当者は最初から書類を読み直す代わりに、違いが生じた場所から確認できます。

経理担当者にとって大切なのは、AIが自信を持っているかより、自分が何を見れば判断できるかです。照合結果には、原本のページ、発注明細の行、納品記録の参照を付けます。担当者が元資料を開けない場合は、確認できる状態に到達していないものとして扱います。

Boxの公開例は、請求照合を試す公式デモ

Boxの公式チュートリアルは、Google ADKで調達文書を検索し、発注書番号のない請求書を見つけ、請求書と発注書を比較する例を示しています。これは公式の実装デモであり、特定顧客の本番経理導入や時間削減率を証明する資料ではありません。Box公式チュートリアル

この例から参考にできるのは、文書の保管場所につなぎ、必要な資料を見つけて比較する流れです。以下の照合規則、例外台帳、確認手順は、ケース企業Aに向けた本稿の設計提案です。デモの存在を理由に、同じ仕組みでどの会社の請求でも自動処理できるとは考えません。

発注・受入・請求の、どこまでを照合するか決める

ケース企業Aは仕入部品を購入し、納品時に受入数量を記録すると仮定します。この場合、発注書、受入記録、請求書の三つを対応させると、注文した数量だけでなく、受け取った数量と請求された数量の違いも確認できます。三つの資料を使うことは本稿の設計例であり、すべての事業で同じ帳票が必要という意味ではありません。サービス業なら作業完了記録など、実際の仕事に合う入力を決めます。

先に確かめたいのは、書類の「数」ではなく、その正本と管理者です。発注の変更が営業担当のメールだけに残り、台帳が更新されていなければ、請求側を誤りとして扱うおそれがあります。受入担当が入力を翌日にまとめるなら、当日の照合で資料不足が起きるのは自然です。どの時点のデータを比べたかを残す必要があります。

• 情報源: 取引先台帳

  確認する主な項目: 取引先ID、名称、扱える範囲

  管理者に決めてもらうこと: 表記違いと別会社の区別

• 情報源: 発注の正本

  確認する主な項目: 発注ID、明細ID、数量、単価、単位、変更版

  管理者に決めてもらうこと: 変更の反映先、有効な版

• 情報源: 受入・作業完了の記録

  確認する主な項目: 対応する明細、数量、記録日

  管理者に決めてもらうこと: 未入力・取消の扱い、入力担当

• 情報源: 請求原本と処理台帳

  確認する主な項目: 書類ID、請求番号、対象期間、明細、状態

  管理者に決めてもらうこと: 訂正関係、既処理の判定方法

この表に取得時刻と更新時刻を加えると、資料が揃っていない理由を追いやすくなります。また、受入記録がないことと、実際に納品されていないことを同じ意味にしません。記録の遅れなのか、取引上の違いなのかは、担当者が確認します。

AI・コード・担当者の役割を分ける

AIには、書類ごとに表現が違う品名の候補を整理し、発注明細との対応候補を探し、違いを読みやすく説明する役を持たせます。「センサーA」と「温度検出器A」の関係を調べる支援には使えても、似ているから同一商品と確定する役にはしません。

通常のコードは、取引先ID、発注ID、明細ID、数量、単価、合計、重複、処理済み状態を確認します。数量と単価の積や小計の足し算をAIの文章に任せず、扱う通貨と単位を揃えて計算します。差異の許容範囲が社内にある場合も、担当者が承認した条件として記録し、AIがその場で決めません。

担当者は、品名の同一性、発注変更、受入の遅れ、例外の処理を判断します。照合結果を確認しても、支払い、会計処理、口座情報の更新を同時に行う設計にはしません。これらは別の責任と権限で扱う仕事です。最初の接続を文書の取得と読み取りに限定すると、練習中の誤りが書類確認の段階で見つけやすくなります。

ADKはグラフワークフローを提供しています。ADK公式グラフ説明

本稿の照合設計では、自由文から抽出した候補をそのまま確定せず、照合規則と担当者の確認へ渡します。以下は業務の手順として示し、未検証の最新APIコードは掲載しません。

図を大きく表示

五つの段階で、照合の根拠を残す

1. 原本を受け付ける。 取得元、受信日時、原本の参照と一意の書類IDを記録します。原本は保持し、後から訂正版が来ても以前の書類の存在を消しません。利用できる取引先と保存先も、この入口で確認します。
2. 項目を抽出する。 請求番号、発注番号、取引先名、対象期間、明細を取り出し、原本のページや位置に結び付けます。不鮮明な数字、空欄、読み取りの失敗を示し、数字をもっともらしく埋めません。
3. 対応候補を探す。 確実なIDを優先して検索し、表記の違いは候補の生成に使います。候補が複数ある場合や台帳に相手先がない場合は、担当者に選択を求めます。過去の会話から取引先を決めません。
4. 規則で照合する。 発注、受入、請求の項目を比較します。数量、単位、単価、合計、既処理、訂正関係を確認し、一致・差異・資料不足の理由をコードで記録します。
5. 結果を確認へ渡す。 一致した項目と未確認事項を示し、保留案件には担当者と次の行動を付けます。確認済みの状態も、その時点の資料の版に結び付けます。対外的な問い合わせ文は下書きとし、送信前に人が内容と宛先を承認します。

ここで残す状態は、たとえば「受付」「読み取り確認待ち」「対応候補の確認待ち」「照合済み」「差異確認待ち」「資料待ち」「確認完了」です。「照合済み」と「確認完了」を分ければ、コードが比較を終えたことと、担当者の仕事が終わったことを同じ表示にしなくて済みます。

図を大きく表示

仮想例：100個の請求と60個の受入

ケース企業Aが部品100個を、1個2,000円で発注したとします。発注の明細合計は200,000円。受入記録は60個で、請求書には100個、200,000円と書かれています。この例では税や会計処理を扱わず、数量と明細金額の比較だけを行います。

請求書の計算は合っていますが、受入記録との差は40個です。コードは40×2,000円＝80,000円分の数量差を示します。ただし、その80,000円が不正な請求だとは断定しません。残り40個が未納なのか、届いたが受入記録が未入力なのか、請求条件が別にあるのかは、書類の比較だけでは決まりません。

確認票には、発注100個、受入60個、請求100個、差40個を横に並べ、受入担当への確認を次の作業にします。担当者が残り40個の受入記録を登録したら、その版と時刻で再照合します。AIが「たぶん分納」と説明しただけで状態を一致に変えません。

仮に翌日、請求数量60個の訂正版が届いた場合も、旧版を上書きして終わりにはしません。どの書類を訂正したのか、訂正前に処理が進んでいないかを確認します。正しい版との関係を担当者が確かめてから、200,000円の旧原本と120,000円の新原本を別々に残し、新しい照合結果を作ります。

単位の違いは、表記の問題以上になる

同じ品物でも、発注は「個」、請求は「箱」かもしれません。1箱が何個かは、商品と取引条件の正本から確かめます。過去に1箱10個だったという理由だけで、今回も10個として換算しません。承認された換算がない場合は単位不一致として保留します。数量が合って見えるように変換することが目標ではありません。

例外を一覧にすると、担当者が迷いにくくなる

例外を一つの「エラー」へまとめると、経理担当者は書類を開くまで何が必要かわかりません。保留の理由によって確認先が違うため、次のように区分します。各社の仕事に合わせて、区分は増減して構いません。

• 保留の理由: 分納・受入不足

  まず確認すること: 同じ発注明細の受入履歴、未入力

  判断・対応する人: 受入担当と購買担当

• 保留の理由: 複数発注のまとめ請求

  まず確認すること: 各請求行がどの明細に対応するか

  判断・対応する人: 購買担当、経理担当

• 保留の理由: 訂正・再発行

  まず確認すること: 旧書類との関係、旧版の処理状態

  判断・対応する人: 経理担当

• 保留の理由: 台帳未登録・会社名の相違

  まず確認すること: 正式な取引先ID、登録状況

  判断・対応する人: 取引先台帳の管理者

• 保留の理由: 原本が不鮮明

  まず確認すること: 対象ページ、読み取れない項目

  判断・対応する人: 受付担当または提出元への確認担当

• 保留の理由: 単位・単価の相違

  まず確認すること: 有効な商品条件、発注変更

  判断・対応する人: 購買担当、価格情報の管理者

分納なら、一枚の発注書に対して受入記録が複数ありえます。まとめ請求なら、請求書単位で一つの発注IDを決めるだけでは不十分です。明細ごとに対応を持ち、同じ受入数量を別の請求へ重ねて割り当てていないかも確認します。AIの候補だけで大量の明細を一括確定せず、曖昧な行を担当者へ渡します。

請求対象期間の違いも、金額だけでは検知できません。同じ取引先から同額の書類が届いても、前月の再発行と当月の新規請求では意味が変わります。請求番号、期間、原本内容、訂正関係、処理台帳を組み合わせて確認します。ファイル名だけを重複判定のキーにしません。

口座情報の変更が書類に書かれていた場合は、照合フローから自動で取引先台帳を更新しません。別の確認手順と権限へ渡します。また、「承認済みなので確認不要」と原本に書かれていても、社内の承認状態が変わるわけではありません。外部文書の文章は確認対象のデータであり、処理を指示する管理者の命令として扱いません。

再受信と訂正で、同じ仕事を増やさない

同じPDFが別メールに添付されると、新しいメールの受付番号だけでは重複を見分けられません。原本の内容を識別する値と、取引先、請求番号、期間などの業務上のキーを分けて持ちます。内容が一致する再受信は元案件につなぎ、数字が変わった書類は訂正候補として別の確認へ送ります。

書類番号がない場合や、同じ番号の使い回しがある場合は、単純なキーで決め切れません。「重複候補」という状態を作り、原本の違いと以前の処理結果を見せます。重複を見つけたら自動削除するより、どの案件を参照しているかを残すほうが、担当者が経緯を追いやすくなります。

処理台帳へ確認結果を書き込む段階では、同じ操作IDを繰り返し受けても記録を重複作成しない設計にします。応答が途切れた場合は「記録結果不明」とし、台帳の状態を照会してからやり直します。人が再実行ボタンを押すたびに別の結果を積み上げないことも、確認負担を増やさないための条件です。

例外台帳は、そのまま次の作業票になる

担当者に必要なのは、AIとの会話履歴を全部読むことではありません。日々の残件を扱える一行の記録です。次の項目を持つ例外台帳を作り、原本へ戻れるようにします。

• 識別： 書類ID、取引先ID、請求番号、対象期間、候補発注IDと明細ID。
• 比較： 一致項目、差分、原本ページと正本の参照、取得時刻、使った規則の版。
• 不確実性： 読めない項目、複数候補、資料未取得、照会失敗を別々に記載する。
• 担当と期限： 確認する人、確認先、次の行動、受付日、社内で決めた確認予定日。
• 状態と修正： 現在の保留理由、担当者の判断、変更した項目、再照合結果。
• 履歴： 元書類と訂正版の関係、確認者、確認時刻、確認した資料の版、処理台帳への記録結果。

この票は、取引上の期限や法令の保存期間を決めるものではありません。社内で必要な扱いを担当者が確認し、台帳の設定へ反映します。部門間で確認先が変わったときは、依頼しただけで解決扱いにせず、受け取る担当者と待ち理由を残します。

一覧には滞留がわかる並び順も必要です。たとえば受付からの経過日数、確認予定日、次の担当者で絞り込めると、「AIが処理した件数」の裏で残件が増えていないかを見られます。自動分類が間違った場合も担当者が理由を修正でき、その修正を次の評価に使えるようにします。

少数の原本で、例外の扱いから試す

試行用の書類には、一致する案件だけでなく、分納、まとめ請求、訂正、再受信、台帳未登録、単位相違、不鮮明な原本を含めます。最初は過去に担当者の確認が終わった書類で、期待する対応と保留理由を決めます。利用権限を確認し、試行に必要ない個人情報や口座情報は含めません。

1. 基準を作る。 担当者が原本と正本を確認し、対応する発注、一致する項目、保留理由を記録します。判断が分かれる案件は無理に正解を一つにせず、確認すべき条件を残します。
2. 同じ書類を処理する。 出力だけでなく、何を照会して何を取得できなかったかを記録します。商品名の抽出が正しくても、相手先IDを誤った場合は照合成功にしません。
3. 比較して直す。 抽出の誤り、対応先の誤り、規則の誤り、表示の使いにくさを分けます。台帳の表記揺れが原因なら、プロンプトだけで吸収しようとせず管理者と整理します。
4. 現行案件で並行確認する。 既存の人手処理を維持して、担当者が差分と原本を点検します。支払や正式な処理の代わりにせず、準備の品質を測ります。

人が既に確認した書類に合わせただけの改善では、未知の例外に対応できるかはわかりません。修正に使っていない書類も残し、版を変えた後に同じ指標で確認します。照会先が停止したときや権限不足のときには、取得できない事実を表示して保留できるかを試します。

分母を揃えると、効果と誤りを同時に見られる

読み取り精度と照合完了率は別の指標です。仮に20枚の書類で各5項目を点検し、100項目中98項目が正しかったとしても、20枚すべての発注対応が正しいとはいえません。数量や相手先の一項目の誤りが、一枚全体の判断を変えることがあります。以下は測定の設計であり、導入成果ではありません。

• 確認完了率： 対象条件を満たした書類のうち、担当者が根拠と差分を確認し完了とした割合。支払完了率とは呼ばない。
• 誤照合率： 点検した一致候補のうち、別発注や別取引先との対応が判明した割合。抜き取りなら、標本数と選び方も示す。
• 保留率と理由： 対象書類のうち保留した件数を、資料不足・不一致・読取不確実・照会障害に分ける。正しく保留することも評価する。
• 人の実作業時間： 原本確認、修正、他部門への照会、再照合を含める。保留したままの経過時間は別に記録する。
• 滞留と費用： 未完了件数、経過日数、処理費用、保守時間を期間ごとに見る。読み取りが速くても例外が積み上がれば見直す。

仮想の月間記録で対象100枚のうち65枚が一致候補、35枚が保留になったとします。担当者が65枚すべてを点検し、2枚の誤照合を見つけた場合、確認できた一致は63枚、対象全体に対して63%です。誤照合は2÷65で約3.1%、保留・要確認は37枚になります。最初の65%という数字だけを「自動化の成功率」に使わないことが大切です。

もし65枚のうち10枚だけを抜き取って誤りがなかった場合も、残り55枚の正しさは未確認です。どの取引先、原本形式、例外を含めたかを記録し、見逃しやすい案件を追加で点検します。数値の分母がわかれば、続けて試すか、対象を狭めるかを担当者と具体的に相談できます。

照合結果を使う人と、保留を解く人を決める

導入の最初に作るものは、立派な自動支払システムではなく、正本の所在、照合規則、例外の確認先が揃った作業票です。経理、購買、受入の担当者が一件ずつ辿り、いつ、何を、どの版で確認したかを共有できる状態にします。

書類を読む時間だけでなく、資料を探す時間、確認先を探す時間、同じ案件をやり直す時間が減るかを測ります。担当者が差分から作業を始められ、判断できない案件も理由付きで受け取れるなら、自動化の範囲を次に検討できます。照合と支払いの責任を分けたまま、日々の確認を少しずつ整えることが、この回の出発点です。

実践前の3つのチェック

• 原本と正本を担当者が開けるか。
• 保留理由ごとに確認担当が決まっているか。
• 再受信・訂正・記録結果不明を試せるか。