経費精算の確認をAIで補助するには｜領収書・社内規程・例外保留のPoC設計

経費申請の欄は埋まっていても、添付された領収書と金額が違う。規程の上限は分かるが、誰に適用する条件なのかを確認し直している。こうした作業では、証憑と申請内容を並べ、確認すべき差異をAIで示すPoCが候補になります。

最初は一つの経費区分に絞り、担当者へ確認候補を渡すまでを試します。支払承認や会計への確定登録は人が行います。税務上の判断や証憑保存の法的要件を、AIの出力だけで満たした扱いにはしません。

読み取りと社内規程の照合を分ける

領収書の文字を読めたことと、申請を認めてよいことは別々に検証します。前者は日付、店名、合計額などの抽出です。後者には、利用目的や対象者、事前承認の有無など、領収書に書かれていない情報も必要です。

Microsoftの領収書抽出モデルの公式資料では、店名、取引日、合計額、明細などの抽出項目が説明されています。ただし、項目を抽出する機能から、自社規程への適合判断までできるとは言えません。採用する方式の対応言語や文書形式を確認し、自社のサンプルで読み取りを確かめます。

画像と抽出値を行き来できない構成では、誤読の確認に時間がかかります。抽出結果をExcelへ並べるだけで足りるか、原画像の該当箇所も必要かを先に決めます。

対象の規程から、費目、対象者、金額の単位、適用条件を取り出し、担当者と判定表を作ります。誰が見ても計算できる上限や日付の比較は、通常の条件分岐で処理する方法もあります。AIは説明文や例外理由の候補整理に使い、すべてを曖昧な文章判断へ任せる構成を避けます。

これは説明用の仮例です。ある会社では、特定の会食費に一人当たりの上限と事前承認が定められているとします。合計額が読み取れても、参加人数や承認記録がなければ、その条件に合うかは判定できません。

この場合は人数や承認の根拠を示して確認を求めます。空欄を推測で埋めたり、上限内という理由だけで承認候補を確定したりしません。会社ごとの規程を例示したもので、税務や経理の共通基準を示すものではありません。

規程が複数版ある、例外承認が口頭だけで残っていない、部署によって同じ文言の扱いが違う場合は、先に参照先と確認責任者をそろえます。

保留は一種類にまとめず、次の確認先が分かるようにします。画像が不鮮明なら再撮影、申請額と合計額が違うなら申請者への確認、規程の適用が不明なら経理担当者への確認です。

同じ領収書の再提出も試験対象に含めます。ただし、店名と日付、金額が同じだけで重複と断定しません。原資料と申請番号を対応付け、担当者が同じ取引かを確認できる候補として表示します。

実データを使う前には、領収書に含まれる氏名などの扱い、外部サービスへの送信範囲、閲覧権限を決めます。PoC用コピーの削除方法と、業務上保存する原本の管理も分けて確認します。

検証資料には、通常の申請に加え、金額不一致、必要情報不足、規程の例外、読み取りにくい画像を用意します。担当者が原資料と規程を見て作った正解表を使い、調整用と評価用の資料を分けます。

確認する指標は、重要な差異を見落とした件数、不要な指摘の件数、保留理由の妥当性、修正まで含めた作業時間です。たとえば合計額の誤読と、店名の軽微な表記差を同じ重みで集計しないようにします。

合格水準は処理前に合意します。件数を減らせても、確認者が根拠を探す時間が増えるなら、出力項目や対象区分を見直します。PoCの結果は対象とした資料の範囲で説明し、全社の全費目へ精度を広げて主張しません。

既存サービスに証憑読み取りと規程設定、確認フローがあるなら、まず設定で不足を埋められるかを確認します。新規開発は、独自規程の扱い、既存台帳への出力、確認画面などの不足部分に絞ると見積りを比較しやすくなります。

AiPHAのPoC開発・検証は20万円からで、対象業務と開発範囲に応じた見積りです。AIサービス利用料などの別途費用は事前に案内します。LPの「10日で納品」という表記についても、資料準備や連携範囲を含む今回の条件は相談時に確認します。継続保守や追加開発は別途相談となります。

運用費には、文書処理料のほか、例外確認の時間、規程改訂時の判定表更新、連携エラーの対応を含めます。規程が未整理、確認者が不在、支払いまで無人で確定したい場合は、この範囲のPoCを急ぐ段階ではありません。

相談前には、一つの費目について、現在の規程、申請項目、月の件数、差し戻し理由を整理してください。実際の領収書を送る前に情報の扱いを確認し、必要なサンプルの用意を相談できます。