請求書照合をAIで効率化するには？読取・突合・差異確認の業務設計

AI-OCRの導入だけでは照合業務は終わらない

請求書の処理には、受領、内容の読み取り、取引先確認、発注・検収との照合、差異への問い合わせ、承認、会計システムへの登録などがあります。どの工程に時間がかかるかを見ずに読み取りだけを導入すると、差異確認の負担が残ることがあります。

MicrosoftのDocument Intelligenceは、請求書の項目や明細を抽出して構造化データとして返す機能を説明しています。ただし、抽出できることは取引内容や請求の妥当性を保証することではありません。読取と業務上の確認を分ける必要があります。

本記事は業務システムの設計案です。税務判断、会計処理や保存要件への適合を保証するものではありません。正式な処理・保存方法は自社の経理・法務・専門家が確認したルールを適用してください。

照合の前に、比較できる単位へ揃える

請求書の「1箱」と発注データの「10個」は、文字や数量をそのまま比べても一致しません。商品コード、数量単位、対象期間、分納、費用項目の定義を整理します。AIで表記の候補を探しても、換算条件は確認済みのマスタやルールを使う構成を考えます。

合計が一致しても、明細の組み合わせが誤っている場合があります。自動で一致と扱う条件を総額だけにせず、対象の発注・明細・期間が特定できているかまで確認します。

確認画面は原本・根拠・差異を同時に示す

担当者が原本を探してシステムを行き来する状態では、読み取りを自動化しても確認時間が減りません。原本の該当箇所、読み取った値、照合した発注・検収、差異の理由を並べて確認できる画面を設計します。修正した項目と担当者を記録し、どこで誤りが起きたか追えるようにします。

モデルが出す確信度の数値だけで承認を決めないことも重要です。高い確信度でも誤った取引先や対象期間を選んでいる可能性があります。実際の帳票で、項目別の誤読と業務上の誤照合を別々に測定します。

振込先の変更や想定外の取引先は、通常の金額照合とは異なる確認が必要です。文書の記載だけでマスタや支払先を書き換える仕組みにはせず、社内の確認経路へ渡します。

登録前後の状態を記録する

照合が終わったら、承認済みのデータだけを会計システムへ渡します。「送信待ち」「登録済み」「結果不明」「差戻し」を区別し、外部システムの登録番号と元の請求書を結び付けます。通信失敗の表示が出ても、相手側では登録が終わっている場合があるためです。

AWSの資料は、再試行で処理を重複させない冪等性の考え方を説明しています。請求データの登録でも、同じ依頼を繰り返しても二重登録しない識別方法を、連携先と合わせて検討します。

最初は登録用データの下書き出力に限定し、現在の承認と照合する進め方もあります。既存の証跡を残したまま比較し、対象帳票の範囲を徐々に広げます。

検証シナリオ：分納と訂正請求が重なったら

架空の例として、一つの発注が二回に分けて納品され、最初の納品分だけ請求された場面を考えます。発注総額との不一致を、ただちに誤請求と扱わず、どの検収分に対応する請求かを特定できるか試します。

次に訂正版が届く条件を加えます。元の請求が未処理なら差替え候補、承認済みなら再確認、登録済みなら経理の訂正手順へ渡すなど、現在の状態で扱いが変わります。番号が同じだから重複として捨てるだけでは、訂正を見落とす可能性があります。

照合画面には、元の請求、訂正版、変更箇所、すでに実行した処理をまとめて示します。AIが修正内容を説明しても、会計データを勝手に削除・訂正せず、社内で定めた権限と手順に従います。

このような条件を含めた匿名化サンプルを開発会社と共有すると、単純な読取デモとの違いを確認できます。試験結果は帳票別に残し、難しい帳票だけを評価から除外しないようにします。

月末の例外まで含めて評価する

検証用の帳票は、読取りやすいPDFだけに偏らせず、スキャン、複数ページ、明細が多いもの、訂正・再発行、分納を含めます。対象外の帳票は対象外と明記し、担当者が見分けられるようにします。

評価指標は、項目の一致率、誤照合、確認にかかった時間、登録の手戻り、締め時点の未処理件数です。自動処理ができた件数だけでなく、人に戻した案件の処理時間を含めて比べます。

相談時には、匿名化した帳票、照合元データの項目一覧、承認経路、例外一覧を用意してください。既存システムを残す接続方法はAIと既存システムの連携、費用の見方は見積もり比較が参考になります。