請求書の承認履歴を残す仕組み｜AI利用前に決める担当と証跡

請求書処理へAI-OCRや生成AIを使うと、日付、取引先、金額、支払期限などの転記を減らせる可能性があります。しかし、読み取り結果が画面に入っただけでは、誰が原本と照合し、誰が支払を承認したのか分かりません。自動化より先に、原本と承認履歴を残す仕組みが必要です。

この記事では、税務判断や仕訳判断をAIへ任せず、請求書の受領から支払確定までを追跡できるようにする業務設計を扱います。

AIの役割と承認を分ける
正本を一つ決める
承認履歴に残す8項目
例外処理を先に設計する
小さく試す手順
導入前チェックリスト
履歴を改善へ使う
関連するAI業務設計

AIの役割と承認を分ける

AIは、文字の抽出、項目候補の提示、重複候補の検出などを補助できます。一方、取引の実在、契約との一致、支払可否、勘定科目、税務上の扱いは、権限を持つ担当者が原資料と社内規程に基づいて判断します。

工程	AI・システムの補助	人が残す判断
受領	ファイル登録、項目抽出	正本データと受領経路の確認
照合	発注番号や金額差の候補表示	発注・納品・契約との一致
差し戻し	不足項目の通知文案	差し戻す理由と依頼先
承認	承認待ちの通知	承認者、日時、対象版、判断
支払	支払データ候補の作成	最終金額、口座、実行権限

正本を一つ決める

メール添付、クラウド、紙をスキャンした画像など、同じ請求書が複数経路に存在すると、どれを確認したか分からなくなります。最初に、正本として扱うデータ、保存場所、ファイル名、重複時の扱いを決めます。

国税庁は、電子取引で受領した請求書等の取引情報について、データ保存が必要となる制度を案内しています。保存要件は事業者の状況や受領方法で確認が必要です。本記事の承認履歴は業務管理の設計であり、これだけで法令上の保存要件を満たすと断定するものではありません。実際の保存方法は国税庁の最新資料や税理士等へ確認してください。

承認履歴に残す8項目

請求書を識別する番号と正本ファイル
受領日時と受領経路
AIが抽出した値と、修正前の値
原本と照合した担当者・日時
発注・納品・契約との照合結果
差し戻し理由と修正版の受領記録
承認者、承認日時、承認対象の版
支払確定者と実行結果

履歴は後から上書きするのではなく、いつ、誰が、何を変更したかを追える形にします。AIの出力だけでなく、人が修正した値も残すと、誤読が起きやすい帳票や項目を改善できます。

例外処理を先に設計する

通常処理だけを自動化すると、例外が担当者の受信箱や口頭連絡へ戻り、履歴が途切れます。少なくとも次の例外を決めます。

同じ請求書番号・金額の重複候補
発注金額や納品内容との不一致
口座情報の変更
承認者の不在や権限超過
読み取れない項目や手書き修正
締日を過ぎた受領、緊急支払

例外ごとに「止める場所」「確認者」「必要資料」「再開条件」を決めます。AIが不一致を見つけても、自動で支払可否を判断させません。

小さく試す手順

一つの受領経路、一種類の請求書に対象を絞る
正本、入力項目、照合資料、承認者を一覧化する
AI抽出値と人の確定値を別項目で保存する
通常例と例外例で、履歴が最後までつながるか試す
誤読率だけでなく、差し戻し時間と確認負担を記録する
支払実行は既存の権限管理を維持し、段階的に範囲を広げる

導入前チェックリスト

電子データと紙のどちらを正本にするか決めた
AI抽出と人の確定を区別して保存できる
照合者と承認者の権限を分けた
修正前後、差し戻し、再承認の履歴が残る
口座変更や重複候補では自動処理を停止する
法令上の保存要件を最新の公式情報で確認した
障害時に原本から処理を再開できる

履歴を改善へ使う

承認履歴は問題が起きた後の証拠だけではありません。どの取引先・帳票・項目で修正が多いか、どの工程で差し戻しが止まるかを集計すると、入力形式や発注時の案内を改善できます。ただし、担当者の評価へ直結させる前に、帳票の読みづらさ、元データの不足、承認権限の不在など工程側の原因を確認します。

月次確認では、AIの読取件数だけでなく、原本との不一致件数、差し戻し理由、承認までの日数、例外から通常処理へ戻せた割合を見ます。誤読が多いのに処理速度だけが上がっている場合は範囲を広げません。データ保持期間と閲覧権限も見直し、必要以上に請求書や履歴をAIサービス側へ残さない運用にします。