PoC開発サービス
請求書が届くたびに発注書を探し、品目、数量、単価を見比べている。この確認を支援するPoCでは、書類から必要な項目を取り出し、対応する明細を並べ、差異を担当者が確認するところまで試します。最初は取引の種類と書類形式を絞り、支払処理へ自動で進めない範囲で検証します。
請求書と発注書の記載が一致していても、納品や検収が済んだとは判断できません。どの書類で何を確かめるかを決め、納品確認や支払承認は既存の担当と手順を維持します。AIの読取結果と、会社が支払いを認める判断を分けて設計します。
どの取引と明細を照合するか決める
初回は、発注番号があり、発注と請求の明細を対応付けやすい取引から選びます。一枚の請求書に複数の発注がまとめられる場合や、分割納品がある場合は、通常の一対一の照合とは分けて扱います。
| 照合する項目 | 比較前に決めること | 保留する例 |
|---|---|---|
| 発注番号 | どの番号を照合キーにするか | 番号がない、候補が複数ある |
| 品目 | 商品コードと名称の扱い | 同じ名称で規格が異なる |
| 数量 | 単位と対象期間をそろえる | 箱と個、部分納品の区別が不明 |
| 単価・金額 | 値引きや別行の費用を含む範囲 | 送料や調整額の対応が取れない |
| 版・状態 | 訂正版と旧版を識別する | 同じ番号で金額が異なる |
合計金額だけで一致と扱うと、単価と数量の誤りが相殺される場合があります。明細単位で比較するのか、合計だけを確認するのかを先に決め、比較できなかった項目は未確認として表示します。
書類の読取と数値の比較を分ける
MicrosoftのDocument Intelligenceの請求書モデルは、請求書や発注書などから項目と明細を抽出する機能として案内されています。読取機能があることは、自社の取引で正しい照合結果を出せる保証ではありません。書類形式や言語の対応と、必要な項目を読めるかを実物で確認します。
AIには名称の表記違いや明細の対応候補を扱わせ、抽出した数値の比較は、決めた計算方法で再現できるようにします。元の記載と正規化した値を両方残し、どこで変換したか追える設計にします。空欄をゼロとして埋めたり、小数点を推測して補ったりしません。
差異の許容範囲を設けるなら、対象項目と理由を担当部署が決めます。PoCでは差額を消して一致に見せる処理を避け、許容範囲に入る場合も元の差額を確認できるようにします。
検証に必要な資料と正解データ
通常の一致例だけでなく、数量違い、単価変更、訂正、重複受領などを含めます。実際の資料を外部へ渡してよいかを確認し、検証に不要な口座情報や担当者の個人情報は除きます。最初は架空の名称・数値に置き換えた資料で動作を確かめる方法もあります。
用意するもの
- 請求書と、対応する発注書または発注データ
- 必要に応じて納品・検収の確認結果
- 担当者が確定した明細の対応関係と差異の理由
- 照合キー、単位変換、別行費用の扱い
- 結果を出す一覧の項目と、保留時の確認先
調整に使った取引とは別の取引で最終評価を行います。資料が不足して正解を決められないものは、無理に一致・不一致へ分類せず、資料不足として止められるかを確認します。
仮例：100個発注し、60個分の請求が来た場合
以下は検証設計のための仮例で、導入実績ではありません。100個の発注に対して60個分の請求が来た場合、数量が違うという結果だけでは、誤請求か部分納品かを判断できません。納品状況と残りの扱いを確認する必要があります。
PoCでは発注数量、請求数量、差分を並べ、納品状況の確認待ちとして担当者へ回します。参照する納品情報がないなら、AIが部分納品だと推測して一致へ変更しない設計にします。
同じ請求書を再度受け取った場合も、ファイル名だけで新しい取引と判断しません。取引先と請求番号など、社内で決めた識別情報で既存の処理状況を確認します。訂正版か重複か判定できないものは、原本を残して確認に回します。
成功条件は差異の見落としと確認時間
抽出できた文字数や照合した件数だけでは、業務で使えるか判断できません。正解データと比べ、誤った明細同士を結び付けた件数、差異を見逃した件数、不要な保留を作った件数を分けて記録します。
業務責任者と検証前に合格条件を決め、次の点を確認します。目標値は取引量と見落としの影響から設定し、実測していない削減率は置きません。
- 元の書類と比較結果を、明細ごとに確認できる
- 番号や単位が不明な取引を、無理に確定しない
- 訂正版や再処理で、処理済みの結果を二重に作らない
- 読取修正と差異確認を含む総時間が、手作業より短い
- 保留理由と確認先が分かり、担当者が処理を再開できる
初期検証では一致と出たものも担当者が確認します。不一致だけを見た場合、誤って一致に分類した取引を評価できないためです。
開発費と運用範囲を見積もる
AiPHAのPoC開発は1業務を対象に20万円〜、10日でAIエージェントを納品する案内です。金額は対象業務と開発範囲に応じて見積もります。書類形式の数、明細の対応方法、確認画面、既存システムとの連携を相談時に確認します。
AIサービスの利用料などは別途必要な費用として事前に案内します。継続的な保守や追加開発も、範囲と費用を別に確認してください。月間の書類枚数、明細数、再処理回数に加え、確認担当者の時間を運用費に含めます。
最初は確認用の一覧を出すところまでに絞り、会計システムへの登録や支払処理は別の検証範囲にできます。書類形式が変わった際の連絡先、照合ルールの更新担当、原本と結果の保存先も決めます。
個別開発を急がない方がよい条件
発注と請求のデータが共通の番号でそろっているなら、既存システムの照合機能や表計算の処理で対応できるか比較します。取引量が少ない場合も、専用開発と毎月の確認負担を比べて判断できます。
発注番号が付かず、対応する発注を人も判断できない状態では、資料の管理方法を整えることが先です。社内の照合ルールが決まっていない場合は、まず確認担当者と保留条件を決めます。
月間の書類枚数、発注データの形式、よく発生する差異、現在の確認手順をお知らせください。請求書と発注書の照合について無料相談する