返送された納品書から印字された出荷データと手書きの受領確認を抽出する方法

なぜ署名入り納品書は「2つの文書」なのか

サプライヤーの倉庫を出る納品書には、品目コード、出荷数量、注文番号、運送会社、出荷日という一つのデータセットが記載されています。これはサプライヤーが出荷したものの記録です。この書類は貨物とともに移動し、受け入れドックに到着すると、受取側の手書き注釈という第二のデータ層が追加されます。

これらの注釈はノイズではありません。受入チームによる運用上の判断であり、法的な重みを持ちます。統一商事法典（UCC第2条）の下では、例外事項を記載した署名入り納品書は、出荷が完全に受け入れられなかったことを示す文書証拠となります。注釈がなければ証拠はありません。受取人が、段ボール2箱が潰れていたことや、50ユニットのラインアイテムのうち15ユニットが不足していたことを記さずに署名した場合、サプライヤーは商品が完全な状態で受け入れられたと主張することができます。

課題は手順ではなく構造にあります。印刷データは設計上、機械で読み取れます。一方、手書きの受入確認情報（署名、破損コード、数量訂正、運転手IDメモ）は読み取れません。それらは紙の上にあり、人間の目には見えても、WMSやERPには見えません。受入チームがその日の業務を終えるとき、これらの注釈は物理的なコピーに残ります。デジタル記録にはサプライヤーのバージョンがあります。真実は紙の上にあるのです。

これが2層問題です。1枚の納品書、2つのデータシステム、そしてデジタル化されるのは片方だけ。

印刷層だけを読むと何が失われるのか

サプライヤーが出荷したものと、受取人が手書きで記録したものとの間のギャップは理論上の話ではありません。以下は、チームが印刷フィールドのみを抽出するときに消えてしまう4種類の受入注釈です。

この層を失うコストは雪だるま式に膨らみます。たった一つの破損メモを見逃すだけで、売れない商品に200ドル支払うことになりかねません。中規模倉庫の標準的な量である1日50枚の納品書では、記録されていない受入例外による月間エクスポージャーは5桁に達する可能性があります。そして、それはあなたが知っているインシデントに過ぎません。

AIが両方のレイヤーを同時に読み取る仕組み

従来のOCRは、納品書を「フィールドの位置特定問題」として扱います。PO番号は座標X、出荷日は座標Yというように。しかし、サプライヤーがレイアウトを変更したり、印字された文字の上に手書きで書き込まれたりすると、その方法はすぐに破綻します。

Vision-Language Model（VLM）は、この問題に異なるアプローチで取り組みます。固定された座標でテキストを探す代わりに、文書全体を視覚的なシーンとして読み取ります。数量欄に印字された「12」と、その横に走り書きされた手書きの「10 ✓」が、同じデータポイントに関する異なる2つの主張であることを理解し、両方を別々の列に抽出できます。

これがカスタム列抽出の仕組みです。「PO番号」「SKU」「出荷数」「受領数」「破損メモ」「受領者」など、必要な列を定義するだけで、AIは各値をページ上のどこからでも、その「位置」ではなく「意味」を理解して見つけ出します。印字されたフィールドはサプライヤーのテンプレートから、手書きのフィールドは受領者の注釈から取得され、1つのスプレッドシートの同じ行に配置されます。

ステップバイステップ：印字と手書きのフィールドを一度に抽出

署名済みの納品書の束を、出荷されたものと受領されたものの両方が含まれる1つのスプレッドシートに変換するワークフローは次のとおりです。

出力スプレッドシートの見た目

マージされた出力は、明細行ごとに1行で、両方のデータレイヤーにまたがる列が含まれます。構造は以下の通りです。

ステータス列は推論列で自動生成できます。ステータス (選択肢: OK/不一致)のような列を定義すると、AIが破損備考と数量不一致を読み取り、正しい値を判定します。抽出と分類を1回のパスで実行するため、標準的なケースでは別途レビューステップは不要です。

下流システムとの連携では、このテーブルは3者照合ワークフローに直接投入されます。買掛金チームは、請求書を承認する前に、サプライヤーが出荷したと主張する数量ではなく、実際に受領したもののデジタル記録を入手できます。POはサプライヤーの主張と一致します。配送伝票の抽出結果は実際に到着したものと一致します。これらが一致しない場合、証拠書類とともに入金が保留されます。

よくある質問

署名済み配送伝票で試す