購買担当が発注書を探し、倉庫が入荷数量を確認し、経理が納品書と請求書を見比べる。この検収業務の自動化で本当に減らしたいのは、紙を読む時間だけではありません。発注書（PO）、受入実績、請求書を行単位で結び、許容差内は次工程へ、差異や証拠不足は担当者へ戻し、承認後にERPへ二重なく登録できる流れをつくることが目的です。本稿では、AI-OCR、照合ルール、例外承認、監査証跡を一体で設計する実務を解説します。
検収業務の自動化は「OCR導入」ではなく証拠と判断の設計
検収には少なくとも三つの意味が混在します。現物が届いたことを確認する受入、発注条件どおりかを確認する業務検収、支払ってよい債務かを確認する請求照合です。工場では、数量だけでなく品番、ロット、単位、品質判定、保管場所、部分納入、返品も関係します。役務では現物がないため、作業完了報告や部門責任者の承認が受入証拠になります。
このため、スキャナーとOCRを入れても、照合に使うキーや例外責任が決まっていなければ、紙の確認が画面の確認に変わるだけです。自動化の対象を次の閉じた流れとして定義します。
- 発注書、入荷実績、納品書、請求書、クレジットノートを受け取る。
- 文書種別と取引先を識別し、必要項目を抽出する。
- 発注番号、行番号、品番、数量、単位、単価、税、通貨などを正規化する。
- PO、受入、請求書を行単位で照合し、許容差を適用する。
- 一致しない案件を理由別の例外キューへ送る。
- 権限を持つ担当者が証拠を確認し、承認、差戻し、保留、修正を選ぶ。
- 承認結果をERPへ冪等に登録し、元文書と判断履歴を結ぶ。
- 登録後の照合、取消、返品、クレジットノートまで追跡する。
ここでAIは文書の読取り、候補の提示、低信頼値の検出に使えます。しかし、支払承認者の責任を代替しません。NIST AI RMFのCoreは、AIリスクをGovern、Map、Measure、Manageの継続活動として整理しています。これは任意のリスク管理枠組みですが、AI-OCRを一度評価して終わりにせず、変更、監視、対応を運用に入れる考え方として有用です。NIST AI RMF Core
三点照合とは何か：PO・受入・請求書を行レベルで結ぶ
三点照合は、一般に発注書、受入実績、仕入先請求書の三つを比べる統制です。Microsoft Dynamics 365の公開ドキュメントでも、請求書照合を請求書、発注書、製品受領情報の比較として説明し、照合ポリシーや許容差を設定できる構成を示しています。これは特定製品の機能説明であり、すべてのERPが同じ動きをするという意味ではありませんが、設計項目を整理する参考になります。Accounts payable invoice matching overview
ヘッダー一致だけでは不十分な理由
請求書の合計額がPOと同じでも、行の内訳が違うことがあります。品目Aの数量が不足し、品目Bが過剰でも合計が同じなら、合計照合だけでは見逃します。また同じ発注番号に複数回の分納や複数枚の請求書がぶら下がる場合、残数量を行単位で持たないと、二重請求や未請求残を見分けにくくなります。
最低限、次の要素を行レベルで扱います。
| 照合項目 | 比較する証拠 | 設計上の注意 |
|---|---|---|
| 発注参照 | PO番号、PO行番号 | OCR結果だけでなく取引先と未消化POから候補を絞る |
| 品目・役務 | 品番、説明、サービスコード | 仕入先品番と社内品番の対応表を管理する |
| 数量 | 発注、受入、請求数量 | 分納、過納、返品、検査保留を別状態で持つ |
| 単位 | EA、BOX、KGなど | 換算ルールと丸め規則を明示する |
| 単価・金額 | PO価格、請求価格 | 契約改定、段階価格、割引、端数を扱う |
| 税・送料 | 税区分、税額、運賃 | 商品代と付帯費用を分離し、適用判断は専門担当へ回す |
| 通貨・為替 | PO通貨、請求通貨、レート日 | 換算日とレートの正本をERP側で定義する |
| 受入証拠 | 受入伝票、検査結果、役務完了 | 誰がいつ何を確認したかを残す |
OpenPeppol BIS Billing 3.0は、電子請求書のビジネス用語と検証規則を定義する構造化仕様です。請求明細には注文行参照を表現する要素もあります。構造化データならOCRを省ける場合がありますが、参照番号が実際に送られること、取引先・品目マスターと一致すること、例外が処理されることは別問題です。OpenPeppol BIS Billing 3.0 / Order line reference
二点照合と非PO請求書も同じ箱に押し込まない
すべての支払が三点照合に適するわけではありません。たとえば家賃、通信費、専門家報酬、定額保守、旅費、公共料金は、POや物品受入がないことがあります。役務は、作業完了、マイルストーン、契約条件、責任者承認による二点または別の統制が必要です。
重要なのは「POがないから例外」として放置するのではなく、非POの正規ルートを定義することです。依頼部門、費用科目、契約、予算、期間、成果物、承認権限を確認し、物品の三点照合とは別のルールセットを通します。PO作成を回避するための非PO利用を検知するKPIも有効です。
納品書データ化と発注書OCR：AI-OCRの役割を限定する
AI-OCRは、レイアウトが異なる発注書、納品書、請求書から項目候補を抽出する入口として有効です。ただし精度は、画像品質、言語、字体、表構造、スタンプ、手書き、複数ページ、取引先ごとの表記に左右されます。一つの「読取精度」だけで本番可否を決めてはいけません。
フィールドごとに信頼値と重要度を分ける
請求書番号を1文字誤ると重複検知が外れ、PO行番号を誤ると別の受入へ結びつき、税額を誤ると会計処理に影響します。一方、備考欄の句読点差は支払判断に影響しないかもしれません。そこで、項目ごとに次を定義します。
- 必須項目か、任意項目か。
- 誤りの影響が致命、高、中、低のどれか。
- 自動確定できる条件は何か。
- マスターや計算で検証できるか。
- 低信頼値または不整合時に誰へ回すか。
- 修正前後の値と修正者をどれだけ保存するか。
AIの信頼値が高くても、未消化POが存在しない、数量が受入残を超える、同じ取引先・請求番号・金額が既に登録済み、といった業務ルールに反すれば人へ回します。逆にOCR信頼値が低くても、バーコードや構造化XML、取引先ポータルの値で補強できる場合があります。詳しい評価方法はAI-OCRの読取精度を検証する実務ガイドも参照してください。
OCR対象を減らすことも自動化
取引先が構造化データを送れるなら、XML、EDI、API、ポータル入力を優先し、PDFは証憑として保持する設計が考えられます。タイではRevenue Departmentがe-Tax Invoice & e-Receiptの公式情報を提供し、ETDAもFAQを公開しています。実際の適用、形式、電子署名、保存、送信、税務処理は最新の公式情報と専門家へ確認してください。この記事は税務助言ではありません。Revenue Department e-Tax Invoice & e-Receipt / ETDA FAQ
請求書処理自動化の標準フロー
1. 受領と原本管理
メール添付、ポータル、紙スキャン、EDI、e-Taxなど受領経路を記録します。同じ請求書がメールと紙で届いても、二重案件を作らないように受領IDとファイルハッシュを持ちます。原本保存期間、アクセス権、削除、バックアップは会社の法務・税務・情報管理方針に合わせます。
2. 文書分類と取引先同定
請求書、納品書、見積書、クレジットノートを分類し、税番号、銀行情報、住所、送信ドメインなど複数の手掛かりで取引先候補を出します。銀行口座変更のような高リスク項目は、文書上の変更だけでマスターを自動更新せず、既定の再確認手続きを通します。
3. 抽出・正規化・検証
日付形式、全角半角、通貨、桁区切り、単位、税表記、品番を正規化します。小計、税、合計の算術整合、必須項目、重複、取引先状態、PO残を機械検証します。OCRの出力と業務検証を分けると、どこで止まったか説明できます。
4. 行照合と許容差
候補POを特定し、行ごとに発注数量、受入済み数量、既請求数量、今回請求数量を比べます。価格、数量、金額、税、送料、為替の許容差をルールとして管理します。許容差は「AIの推奨」ではなく、会社が承認する購買・会計ポリシーです。取引先、品目カテゴリ、金額帯、拠点で異なる場合は優先順位も定義します。
5. 例外キューと承認
理由コードを付けて、購買、倉庫、品質、依頼部門、経理へ分配します。「不一致」だけでは担当者が調査をやり直すため、元文書、抽出値、ERP値、差異、推奨次アクションを同じ画面に表示します。承認者は証拠を確認し、承認理由や差戻し理由を残します。
6. ERPへの冪等登録
連携がタイムアウトすると、RPAやAPIが同じ請求書を再送する可能性があります。そこで取引先ID、請求番号、会社コード、会計年度などを組み合わせた重複キーと外部処理IDを持ち、同じ要求の再送で二重伝票を作らないようにします。登録済み、処理中、失敗、取消の状態を分け、再実行は同じIDで行います。
7. 登録後照合とクローズ
ERP伝票番号を案件へ返し、合計件数・金額・税・通貨を日次で突合します。受領済みだが未登録、登録済みだが案件側に結果がない、取消済みだがワークフローが開いている、といった宙ぶらりんを監視します。
MicrosoftはDynamics 365向けに自動ベンダー請求書照合とワークフロー送信の構成を公開しています。これは自動化パターンの一例であり、無人処理率や統制有効性を保証するものではありません。自社ERPでは、機能、権限、ログ、再実行、変更管理を個別に検証します。Automate vendor invoice matching
例外処理が検収業務の自動化の成否を決める
正常系のデモは簡単です。現場時間を使うのは、証拠が不足し、複数の解釈があり、担当部門がまたがる例外です。
| 例外 | 自動判定の材料 | 人が決めること |
|---|---|---|
| 部分納入・分納 | PO残、受入履歴、今回数量 | 未納を待つか、受入分だけ請求を認めるか |
| 分割請求 | 既請求額、契約マイルストーン | 支払条件を満たしたか |
| 数量差 | 計量値、検品、単位換算 | 過不足を受け入れるか、返品するか |
| 単価差 | PO改定、契約、価格有効日 | 改定が正当か、遡及を認めるか |
| 税差 | 税区分、登録情報、明細 | 正しい税務処理（専門担当が確認） |
| 送料・付帯費用 | Incoterms、PO条件、契約 | 仕入先負担か自社負担か |
| 通貨・為替 | PO通貨、請求通貨、基準レート | 換算基準と差額処理 |
| 非PO請求 | 契約、予算、部門承認 | 正規ルートか、事後発注回避か |
| 役務 | 完了報告、成果物、期間 | サービスが受領・受入済みか |
| 重複請求 | 取引先、番号、日付、金額、明細 | 真の重複か再発行か |
| 返品・クレジットノート | 返品記録、元請求、参照番号 | 相殺、返金、次回充当の扱い |
例外キューに必要な管理項目
案件ID、理由コード、重要度、金額・通貨、経過時間、担当者、次の期限、関連文書、差異、承認履歴、保留理由、再開条件を持ちます。単なる受信箱ではなく、SLAとエスカレーションを持つ作業キューにします。
「AIが自信を持っているから承認」と「会社の許容差内だから自動通過」を混同しないことが重要です。AI信頼値は抽出の不確実性、許容差は業務ポリシーです。両方を満たし、必要証拠が揃い、重複や制裁・取引停止などの別統制にも抵触しない場合にだけ次へ進めます。
OCRとRPA連携：API優先、画面操作は管理対象にする
ERPに正式APIや取込機能があれば、状態、エラーコード、冪等キーを扱いやすいため通常は優先します。RPAはAPIがない旧システムや一時的な橋渡しに有効ですが、画面項目や応答時間の変更で停止し得ます。
OCR RPA連携を採用する場合、次を受入条件に含めます。
- Botが処理する専用IDと最小権限。
- 本人用IDの共有を禁止する。
- 入力案件IDとERP伝票番号の対応ログ。
- 画面変更を検知する監視と停止条件。
- タイムアウト後に登録有無を照会してから再実行する手順。
- CAPTCHAや多要素認証を回避する設計を前提にしない。
- 失敗キュー、再実行権限、手動切替手順。
- 本番変更前の回帰テスト。
ERP側の標準機能だけで足りない場合は、生産管理システムのスクラッチ開発を判断する観点も、連携境界と保守責任を整理する参考になります。
監査証跡・職務分離・データ統制
職務分離
発注を作る人、受入を記録する人、請求書を登録する人、支払を承認する人を同一権限に集約しないのが基本です。小規模拠点で完全分離が難しい場合は、上位者レビュー、変更レポート、金額閾値、事後照合など補完統制を設計します。AIやRPAのサービスIDも一つの役割として権限表に載せます。
説明可能な証拠
各案件について、元ファイル、受領時刻、抽出モデル・バージョン、抽出値と信頼値、マスター参照、照合規則と版、差異、修正前後、担当者、承認理由、ERP要求と応答を追えるようにします。ログは誰でも書き換えられる共有表ではなく、権限と保存方針を持つ仕組みに置きます。
変更管理
AIモデル、プロンプト、OCRテンプレート、品目マッピング、許容差、税ルール、ERP画面の変更は、同じサンプルで回帰テストします。ベンダーがモデルを更新した場合の通知、再評価、ロールバック、障害時の手動運用も契約に含めます。
GS1 EPCIS 2.0は、サプライチェーンの可視化イベントをwhat、when、where、whyなどの観点で表現する標準です。入荷や移動のイベント証拠を連携する発想には役立ちますが、イベントがあることだけで検収合格や債務を証明するわけではありません。品質判定、所有権、契約、承認を別に扱います。GS1 EPCIS 2.0
30・60・90日PoCの進め方
PoCはOCRの見栄えを確認する実験ではなく、対象範囲で運用判断ができる証拠を作る期間です。
0〜30日：定義とベースライン
- 対象会社、拠点、取引先、文書、言語、ERPを限定する。
- 現行の受領から支払までを観察し、手戻りと待ち時間を測る。
- PO、受入、請求書、例外のデータ辞書を作る。
- 過去サンプルを正常系と例外系に分け、評価セットを固定する。
- 重要フィールド、許容差、承認権限、保存方針を決める。
- API、RPA、EDI、e-Taxの連携可能性を確認する。
- 成功、停止、拡張のDecision Gateを合意する。
31〜60日：限定運用と例外学習
少数の取引先または文書種でShadow Modeを行います。AIは候補を出しますが、現行担当者が並行確認し、誤抽出、誤照合、見逃し、誤った自動通過候補を記録します。部分納入、単位換算、送料、税、クレジットノートなど重要例外を意図的に含めます。
61〜90日：統制付き本番と引継ぎ
合意した範囲だけ本番連携し、例外キュー、承認、ERP冪等登録、日次突合、障害時切替を運用します。担当者がベンダーなしで一次対応できるか、変更後の回帰テストを実行できるかを確認します。90日目は自動終了日ではなく、継続、修正、停止、範囲拡大を決めるゲートです。
KPI：OCR正解率だけを見ない
KPIは分母と除外条件を固定し、言語、取引先、文書種、拠点、例外種別で分解します。平均だけでは少数の重大エラーが隠れます。
| KPI | 定義例 | 見る目的 |
|---|---|---|
| フィールド抽出品質 | 重要項目ごとの正解・欠落・誤り | 重大項目の弱点を特定する |
| 行結合成功率 | 正しいPO行・受入行へ結べた割合 | OCR後の業務品質を見る |
| 例外率 | 全対象に占める例外案件 | マスターやルールの改善余地を見る |
| 誤自動通過 | 本来止めるべき案件が通った件数 | 最重要の統制リスクを見る |
| 例外解決時間 | キュー投入から解決まで | 部門間の待ちを改善する |
| 再処理率 | 修正、再読取、再登録が必要な割合 | 隠れ工数を把握する |
| 重複防止 | 重複候補と誤検知の件数 | 支払リスクと業務負荷を両方見る |
| ERP照合差 | 案件側とERP側の件数・金額差 | 連携欠落と二重登録を検知する |
| 手動フォールバック | 障害時に手動へ切替えた件数と復旧時間 | 継続性を見る |
改善率や目標値は、現状測定、リスク許容度、サンプル数から決めます。ベンダーの一般値を自社の保証値に置き換えません。
RFPに書くべき要件
業務・データ範囲
会社・拠点、文書種、月次変動、言語、ページ数、受領経路、対象取引先、PO/非PO、物品/役務、部分納入、通貨、税、ERP、承認組織を明記します。サンプルを提供できない条件や匿名化方法も書きます。
機能・統制
抽出項目、行照合、許容差、例外理由、キュー、SLA、職務分離、承認、重複防止、冪等登録、取消、クレジットノート、ログ、検索、保存、監査出力を要求します。「AI-OCR対応」だけでは比較できません。
非機能・運用
可用性、性能、同時処理、セキュリティ、暗号化、データ所在地、サブプロセッサー、バックアップ、監視、障害通知、復旧、変更通知、モデル更新、保守時間、出口時のデータ返却・削除を確認します。
価格とTCO
初期設定、文書・ページ・項目の従量、AI利用、連携、RPAライセンス、ERP改修、環境、監視、保守、サポート、取引先追加、帳票変更、再学習、監査、データ保管、バックアップ、内部担当工数を分けます。料金体系の比較方法はAI-OCRの費用・料金を比較する実務ガイドも参考にしてください。具体額は要件と処理量で変わるため、本稿では示しません。
受入テスト：正常系より例外と再実行を厚くする
受入データは、きれいなPDFだけでなく、スキャン傾き、低解像度、スタンプ、複数ページ、日本語・タイ語・英語、表の続き、手書き修正、似た品番、単位違いを含めます。実際の取引分布を反映しつつ、発生頻度が低くても影響の大きい例外を追加します。
最低限、次を試験します。
- 同じ請求書を二つの経路から受領しても一件にまとまる。
- PO番号は正しいがPO行が誤っている場合に停止する。
- 部分納入、分割請求、数量超過、単価差を理由別に振り分ける。
- 非PO請求と役務を正規の別ルートへ送る。
- 送料、税、通貨、為替差を自動で無理に確定しない。
- 低信頼値、計算不整合、マスター不一致を担当者へ送る。
- 承認者自身が発注・受入を作った場合に権限統制が働く。
- ERP応答前にタイムアウトしても二重登録されない。
- ERP停止中にキューを保持し、復旧後に順序を管理して再開する。
- 返品とクレジットノートを元請求・受入へ追跡できる。
- モデル、ルール、ERP画面変更後に回帰テストが通る。
- 元文書、修正、承認、登録の監査証跡を出力できる。
受入判定は、平均精度だけでなく、重大エラーゼロ条件、例外解決、職務分離、再実行、照合差、手動切替を含めます。どれかが未達なら、対象範囲を狭める、追加統制を入れる、手動工程を残す、停止する、の判断をします。
導入前のチェックリスト
- [ ] 検収の意味を物品受入、品質判定、請求照合に分けた。
- [ ] PO、受入、請求書を行単位で結ぶキーがある。
- [ ] 非PO、役務、部分納入、分割請求の正規ルートがある。
- [ ] 税、送料、通貨、為替、クレジットノートの責任者が決まっている。
- [ ] AI信頼値と業務許容差を別に管理する。
- [ ] 低信頼値と不整合は人へ回し、AIは承認者を代替しない。
- [ ] 職務分離と補完統制を権限表にした。
- [ ] ERP登録は冪等キーと登録後突合を持つ。
- [ ] RPA停止時の復旧と手動切替がある。
- [ ] KPIに誤自動通過、例外時間、再処理、ERP差を含めた。
- [ ] 90日PoCの継続・修正・停止ゲートがある。
- [ ] TCOに内部運用と変更対応を含めた。
FAQ
検収業務の自動化はどこから始めるべきですか？
まず対象を一つの会社・拠点・文書群に限定し、受領からERP登録までを観察します。紙の枚数より、PO行と受入行を結べるか、どの例外が多いか、誰が承認するかを確認します。過去データでベースラインを作り、重大例外を含む評価セットを固定してからツールを比較します。
納品書データ化だけで三点照合できますか？
できません。納品書は重要な証拠ですが、実際の受入数量、検査保留、返品、役務完了を表さない場合があります。ERPや倉庫システムの受入実績、発注条件、請求明細と結ぶ必要があります。
発注書OCRの精度は何％あれば十分ですか？
一律の数字はありません。PO番号、行番号、品番、数量、単位、単価など重要度ごとに評価し、誤った行結合や誤自動通過を別に測ります。低信頼値や業務不整合を人へ回せることも受入条件です。
請求書処理自動化で承認者は不要になりますか？
なりません。定義済みの低リスク・許容差内案件を次工程へ自動送信する設計は可能ですが、承認権限と説明責任は会社側に残ります。例外、非PO、高額、マスター変更などは適切な担当者が証拠を確認します。
OCRとRPA連携はAPIより安いですか？
初期改修が小さく見える場合はありますが、画面変更、監視、停止、再実行、ライセンス、運用者工数を含めたTCOで比較する必要があります。APIが利用できる場合は、状態と冪等性を扱いやすいことが一般的です。
タイのe-Tax Invoiceへ対応すれば紙はすべて不要ですか？
制度の適用、取引先との合意、形式、署名、送信、保存、社内統制によります。Revenue DepartmentとETDAの最新情報を確認し、税務・法務の専門家へ相談してください。e-Taxへの対応と、PO・受入・請求の業務照合は別の設計課題です。
PoCはOCRデモだけでもよいですか？
本番判断には不足します。行照合、例外キュー、権限、ERP二重防止、登録後突合、障害時手順まで限定範囲で試します。30・60・90日のゲートで、継続、修正、停止、拡張を決めます。
まとめ：自動化するのは入力ではなく、証拠からERPまでの閉じたループ
検収業務の自動化は、発注書や納品書をデータ化するだけでは完成しません。PO、受入、請求書を行単位で照合し、許容差を会社のポリシーとして管理し、非PO、役務、分納、単価・数量・税・送料・通貨・為替・クレジットノートを理由別に人へ回す必要があります。AI-OCRは抽出候補と不確実性を提示し、承認者を代替しません。職務分離、監査証跡、冪等なERP登録、登録後照合、変更管理までを受入対象にすれば、速さと統制を同じ設計で追えます。
TOMAS TECHでは、対象文書やERP連携方式が未確定の段階でも、現行フローの可視化、三点照合ルール、例外キュー、AI-OCR評価セット、30・60・90日PoCの範囲整理をご一緒できます。タイ・ASEAN拠点での検収・請求処理を具体化したい場合は、お問い合わせください。
参考資料
- Thailand Revenue Department: e-Tax Invoice & e-Receipt
- ETDA: e-Tax Invoice & e-Receipt FAQ
- Microsoft Learn: Accounts payable invoice matching overview
- Microsoft Learn: Automate vendor invoice matching and workflow submission
- OpenPeppol: Peppol BIS Billing 3.0
- OpenPeppol: Invoice line order-line reference
- NIST: AI RMF Core
- GS1: EPCIS 2.0
*本稿は検収・請求処理のシステム設計を検討するための一般情報であり、法務・税務・会計上の助言、特定製品の性能保証、投資効果の保証ではありません。制度適用、保存、承認、会計処理は最新の公式情報と社内専門部署・外部専門家へ確認してください。*
