Meridian Apparelは、複数地域にまたがる海外工場から調達を行う中規模の消費財ブランドです。2人から3人の調達アナリストが、流入するすべてのサプライヤー請求書を、会社の未処理POデータベースおよびベンダーマスターリストと照合してから、データを財務および在庫システムへ流し込みます。マスター用ワークブックの誤りは、CFOレビュー対象のレポーティングパッケージに直接波及します。
改ページの分断、結合セル、埋もれたPO番号が、マスターシートを静かに壊していた
毎月のサイクルで、チームは最大50行の明細を含む数十件の請求書を処理していました。請求書は、スキャンPDF、ネイティブのデジタルファイル、結合セルレイアウトのExcelワークブックとして届きます。集約作業はほぼ完全に手作業でした。各請求書を開き、目視で解析し、各行を手入力するのです。
そこには3つの失敗要因が重なっていました。改ページによる分断は、数量がnullの孤立したSKUを生み出しました。見た目は完全でも、構造的には壊れているレコードです。サプライヤーのExcelテンプレートにある結合セルは空白行を発生させ、アナリストはそれを一貫性なく補完していました。さらに、サプライヤーが「Re: Your order 45992-A」のように自由記述のヘッダーにPO参照を埋め込むと、PO不一致フラグが立ち、個別の修正サイクルが発生しました。数値照合は、分断された行のOCRエラーのおよそ90%を検出していましたが、それもデータ入力が完了した後のことでした。季節的な立ち上げで3〜5社の新工場をオンボーディングし、支払条件をnet-45からnet-30へ短縮する財務施策が入ると、この暗黙のスケーリングモデルは崩れました。請求書バッチは、今や1営業日以内に検証を通過しなければならなかったのです。
Energent.aiがエンドツーエンドの集約パイプラインになった
チームは、拡張版のExcelマクロスイートと、単体のOCRポイントソリューションを評価しました。どちらも取り込みと検証を切り離された工程として扱っており、抽出値をベンダーマスターや未処理POデータベースと照合することはできませんでした。Energent.aiは、1回のエージェントセッションで完全なパイプラインを処理しました。
- 各ドキュメントをルーティングし、テキストレイヤーの有無で判定 — ネイティブPDFは直接処理、スキャンPDFはビジョン抽出 — することで、座標ずれを排除
- 改ページをまたぐ明細を抽出し、ページ境界ではなく表ヘッダーを基準にアンカー
- 結合セルの列を前方補完 — 工場名、スタイルコード、PO番号 — してサプライヤーの意図に合わせる
- 埋もれたPO番号を復元し、全文テキストブロックに対するregexで抽出、復元値に
source: text_recoveryフラグを付与 - 追加前に2段階検証を実行 — Phase 1で日付と数値フィールドを正規化し、Phase 2でベンダーマスター照合、未処理POの検証、行レベルおよび請求書レベルの数値チェックを実施
- 失敗コードごとに例外をステージング —
vendor_unmatched,math_fail,po_not_found,confidence_below_85pct— し、検証済みデータには触れず専用タブに格納
カスタムOCRパイプラインは不要。別個の検証スクリプトも不要。保守が面倒な脆弱なマクロスイートも不要でした。
検証はマスターシートへの追加より前に移動した
- 85%で信頼性ゲートを設定。 閾値を下回るレコードはマスターシートに到達せず、失敗理由付きでステージングタブに入ります。
- 数値チェックは後ではなく前に。 行レベルおよび請求書レベルの照合が自動パイプラインの一部として実行され、ワークブックを汚染する前に約90%の分断行エラーを検出します。
- フォーマット非依存のルーティング。 スキャンPDF、ネイティブPDF、Excelワークブックは同じセッションで処理され、ドキュメント種別が抽出経路を決め、アナリストの判断には依存しません。
- 注釈付きの例外キュー。 フラグが付いた各レコードには具体的な失敗コードが付与され、場当たり的な修正ではなく、優先順位付きのレビューリストに置き換わります。
1バッチあたり2〜3人日だった作業が、例外レビューのみに削減された
- それぞれ30〜50行の明細を含む10件の請求書バッチは、以前は2〜3人日を要していました。現在は、Phase 2の照合を通過したすべてのレコードをアナリスト介入なしでストレートスルー処理できます
- 前方補完の正規化とregexによるPO復元により、すべてのサプライヤーテンプレート形式にまたがる2種類のサイレントな抽出エラーが解消されました
- ラベル付きのステージングタブは、各例外に具体的な失敗コードを付与し、曖昧な修正プロセスを、明確で実行可能なキューへと置き換えました
"変わったのは、検証をデータ入力の後に起こるものとして扱うのをやめたことです。例外は理由付きでステージングタブに置かれるため、手を付ける前に何を、なぜ修正すべきかが正確に分かります。" — Priya Sharma, Procurement Operations Lead at Meridian Apparel