製造業 入荷差異管理システム 導入｜PO・ASN・現物をつなぐ設計

製造業で入荷差異管理システムの導入を考えるとき、最初に決めるべきことはバーコード端末の機種ではありません。「発注書（PO）では何個を約束し、事前出荷通知（ASN）では何個が届く予定で、荷受け場で実際に何個を確認したか」を、同じ品番・単位・納入単位で比較できるかです。過納、不足、品番違いを見つけても、現物を一時保管したまま承認が止まり、ERPの在庫や請求書には別の数量が流れる工場は少なくありません。本稿では、差異の記録から許容差、承認、在庫確定、請求照合までを一つの業務として設計する方法を説明します。

入荷数量差異を管理する目的を先に定義する

差異管理の目的は「受入数を発注数に合わせること」ではありません。目的は、現物と約束の違いを消さずに残し、誰がどの根拠でどう処理したかを追跡できるようにすることです。発注100個、ASN100個、現物98個なら不足2個です。現物を100個と入力して発注残をゼロにすれば画面は整いますが、倉庫の実在庫は2個過大になります。次工程の払出、棚卸、請求書の照合で再び問題が現れます。

反対に、PO100個、ASN100個、現物103個なら過納3個です。3個を勝手に良品在庫へ計上すれば、発注していない物の支払義務や保管責任が曖昧になります。差異の発見と在庫への受入承認は別イベントです。品番違いも数量だけを足し引きしてはいけません。POのA品100個に対しA品90個とB品10個が届いたなら、A品不足10個とB品の未発注品10個を別行で記録します。代替品として受け入れる場合も、購買と品質の承認が必要です。

Microsoft Dynamics 365の製品受入の説明でも、倉庫での登録（Registered）、必要に応じた品質処理、購買発注に対する正式な受入（Received）が区別されています。数量差異に合わせて受入数量を変更でき、受入識別子は納品書などとの照合の根拠になります。これは特定製品の処理ですが、「現場で見た数量」と「正式に受け入れた数量」を区別する設計上の参考になります。Microsoftの製品受入説明

三つの数量を混同しない

最低限、PO発注数量、ASN出荷予定数量、現物確認数量を分けます。ここに正式受入数量、品質合格数量、請求数量を追加すると、後工程まで一本の線で追えます。ASNはサプライヤーの予告であり、入荷の証拠ではありません。運送伝票のケース数も、箱内の実数と同義ではありません。現物確認では荷姿、単位、開梱要否、サンプル検査の扱いを明記します。「100箱」と「100個」を同じ数として扱わないためです。

入荷差異は、通常 現物確認数量 − 比較対象数量 として計算できます。ただし比較対象をPOにするのかASNにするのかを帳票ごとに明示してください。PO100個、ASN90個、現物90個なら現物対ASNの差異はゼロでも、POに対しては10個不足です。出荷予告どおり届いたという事実と、発注残が残るという事実は両立します。ダッシュボードではこの二つを別列で表示すると、見落としを減らせます。

PO・ASN・現物を突合するデータ設計

主キーは「発注番号だけ」では足りません。同じPOに複数明細、分納、複数便があるからです。推奨する照合単位はPO番号、行番号、発注品番、納入先、便またはASN番号、荷姿識別子、受入イベントIDの組です。ロットやシリアルの指定がある材料なら、その識別子を別フィールドに保持します。受入イベントIDは一度の荷下ろし・計数を一意に示し、同じASNを再読込しても二重に在庫を増やさない冪等キーになります。

GS1の物流ラベルを使う現場では、SSCCなどの物流単位識別子をケースやパレットの入口に利用できます。ただし物流単位のIDだけで中身の品番・数量が正しいと保証されるわけではありません。ASNとの紐付けと現物計数の結果を別々に保持します。ラベルが読めないときの手入力、ラベル貼替、混載パレット、部分開梱も例外処理に入れてください。バーコード読取を導入しても、その先の差異記録がなければ、誤りの速い転記になってしまいます。

明細に必要なフィールド

設計時には次の項目を一枚の画面に詰め込むより、どの時点で誰が記録するかを決めます。

発注品番とサプライヤー品番が違う場合は、変換テーブルに有効開始日と終了日を持たせます。過去に使った対照表で現行品を誤認しないためです。発注単位と在庫単位の換算も履歴を残します。例として発注1箱=12個なのに、納品書が1箱、現物が10個なら、単なる「1対10」の差異ではありません。どの換算率を使い、誰が変更を承認したかまで記録します。

比較の順序を固定する

推奨順序は、①PO行の有効性確認、②ASNとの予定比較、③現物の識別、④数量再計数、⑤差異分類、⑥承認・是正、⑦正式受入です。最初の比較で品番違いがあれば、数量許容率の判定に進ませません。別品番を数量だけで相殺してしまうからです。単位が違えば換算ルールを確認し、換算不能なら保留にします。二回目の計数は初回の記録を上書きせず、再計数者、時刻、理由を残します。多い・少ないのどちらでも同じ順序にすることで、担当者ごとの判断差を減らせます。

過不足納品の受入処理を状態として設計する

「受入」と呼ぶ操作が現場でいくつもあることが、システム導入時の混乱の元です。トラックから荷物を降ろした、ラベルを読んだ、数量を数えた、品質検査に回した、発注に対して検収した、良品棚へ入れた、ERPへ在庫計上した。これらは同時刻に起きるとは限りません。状態は少なくとも、到着、計数中、差異保留、品質保留、承認済み、正式受入、返品・取消に分けます。現場画面には現在状態と次の責任者を表示し、単なる色分けだけに頼らないようにします。

不足の場合は「受け取った分だけ正式受入」と「残数を発注残として維持」する処理が基本候補です。ただし、残分を後日納入するのか、発注数量を減らすのか、請求クレジットを求めるのかは契約と業務規則に依存します。勝手に発注残を消さないことが重要です。過納の場合は、数量許容内でも自動受入にするか、人の承認を必須にするかを品目・サプライヤーごとに決めます。保管場所と所有権が未確定なら、使用可能在庫に混ぜず、隔離または預かり状態にします。

MicrosoftのLanded costの文書は、入荷時の過不足に対して金額許容差とPO行の率許容差を見て、移動伝票や追加POなどの処理に分岐する例を示します。ただしこの機能は輸送中在庫の特定処理であり、そこで例示される10%を工場一般の許容基準にしてはいけません。許容差は自社の契約、品目リスク、会計方針、WMS/ERPの機能に合わせて決める設定値です。Microsoftの過不足処理

品番違いを「許容差内」で通さない

発注品番A100個に対し、A95個とB5個が届いたとします。合計100個なので数量差ゼロとする設計は危険です。Aの不足5個とBの未発注品5個を別イベントにし、代替承認か返品かを判断します。代替品として認める場合も、購買契約、図面版、工程適合、品質要求、単価、請求書の品目表記を確認します。現場の一時的な救済措置がマスタ変更と混同されないよう、承認の対象を「今回の受入イベント」に限定するか、恒久代替として登録するかも明記します。

破損・外観不良は数量差異とは別の品質事象です。箱数がPOと一致していても、良品在庫にできないことがあります。受入検査そのものを本稿の主題にはしませんが、差異管理システムは品質保留IDへ連携できる必要があります。計数上は到着した数量と、使用可能な良品数量を分けます。「届いた」と「使える」は違う値です。発注残の消し込みがどの値に基づくかも、商品・契約ごとに合意しておきます。

許容差・承認権限・在庫確定点を明文化する

許容差は「何%まで許すか」だけでは設計できません。分母は発注行数量か、今回便の予定数量か。絶対数量と割合を併用するか。高額部品と汎用副資材を同じ扱いにするか。過納と不足を対称にするか。仕入先が変更を予告したか。これらで判断が変わります。少量発注では1個の差が割合で大きくなるため、率だけでは運用しにくいこともあります。許容条件を満たした場合でも、記録を消さず「許容内差異」として残します。

Oracleの品目購買属性には、過剰受入に対する警告または拒否の制御と許容率が記載されています。同じページには受入経路として直接、検査経由、標準があり、代替品の受入可否も別属性です。製品の設定例にある5%はOracleの説明例であり、どの工場にも推奨される数値ではありません。設計上の示唆は、数量許容と検査経路と代替品可否を別のルールとして持つことです。Oracleの品目購買属性

承認権限は差異の種類と影響で分けます。倉庫は現物の計数と隔離を確定し、購買はPO改訂、追加発注、サプライヤー交渉を判断します。品質は代替品や破損品の使用可否を判断し、経理は請求差額の保留・解消を判断します。権限を一人に集中させると待ち時間が伸びますが、誰でも発注数量や在庫数量を書き換えられる状態も避けるべきです。しきい値内の自動判定と、しきい値外の明示承認を分け、代行承認と期限超過のエスカレーションも設計します。

在庫はいつ確定するか

実務では、荷受け場でラベルを読んだ瞬間にERPの利用可能在庫を増やす方式と、数量・品質の承認後に増やす方式が混在します。どちらを採るかは既存WMS/ERPに依存しますが、少なくとも「物理的に到着した数」「正式に受け入れた数」「引当可能な良品数」を別に扱える必要があります。差異保留品を良品棚へ移してから帳簿だけ止める運用は、現場のピッキングで誤使用を起こしやすくなります。隔離ロケーションや在庫ステータスを端末表示までつなげます。

在庫確定点を業務図に一本の縦線として示してください。承認前は到着・仮置きの記録だけ、承認後にERPの正式受入伝票を起票し、品質合格後に利用可能在庫へ移す、といった設計です。既存ERPが受入時に必ず財務在庫を増やすなら、保留在庫や隔離倉庫を使う方式を検討します。どの方式でも、同じイベントをWMSとERPの両方から再送した際に二重計上しないキーが必要です。取消は履歴を消去せず、逆仕訳・取消伝票を参照させます。

WMS・ERPとの連携は「失敗時」を先に設計する

インターフェースの正常系だけを描くと、現場は翌日から手入力へ戻ります。WMSの受入イベントがERPに届かなかった場合、誰が気づき、どの画面から再送するのか。ERPは受け取ったが応答が返らなかった場合、二重送信をどう防ぐのか。夜間にマスタの品番や単位が変わったら、保留中の入荷にどの版を適用するのか。これらをFAT前に決めます。

連携メッセージには、受入イベントID、PO行、ASN、現物品番、数量、単位、差異理由、承認ID、時刻、元システムの状態、処理版を含めます。ERPの応答には受入伝票IDと確定数量を返させます。応答が来るまで端末には「ERP未反映」と表示し、現場が正式受入済みと誤解しないようにします。CSV連携でもAPI連携でも、監査ログの要件は同じです。バッチの場合は日次境界を越える入荷が発生するので、時刻と会計日付を別フィールドにします。

発注残管理は、POに対して何個がまだ未納かを追う隣接業務です。本稿は、実際に届いた便で生じた差異をどう判定し、どの数量を正式受入にするかに焦点を当てています。発注残の全体設計は発注残管理の記事を参照してください。請求書との突合をAIで補助する話題は入荷・請求照合の記事で扱っています。差異イベントの正本が整って初めて、請求照合の自動化が安定します。

発注数量・受入数量・請求数量の3-way matching

3-way matchingでは通常、PO、正式受入記録、請求書を照合します。入荷時の数量差異と、請求書が届いた後の請求数量差異は別イベントです。PO100個、正式受入98個、請求100個なら、入荷不足2個の記録に加え、請求が受入数を2個上回る問題があります。サプライヤーが不足分を後送するなら請求を一時保留するのか、98個分だけ先に支払うのか、契約に沿って判断します。会計処理を自動化する前に、この判断ルールを定めます。

Oracleの請求許容差の説明では、請求書が発注や受入の数量・金額からどれだけ違ってよいかを設定し、超えた場合は請求書に保留が付くとされています。受入数量を基準にする許容差と発注数量を基準にする許容差は別です。設定値が空の場合の意味も製品固有なので、画面表示だけを見てゼロ許容と決めつけてはいけません。Oracleの請求許容差

過納では、受入承認済み数量がPOを超えていても、請求書の支払を無条件に許すべきではありません。追加POや契約変更が必要なら、受入イベントからその文書を参照できるようにします。返品なら返品出荷とクレジットノートまで追います。請求書の品目、数量、単価、税区分のどれが違うかを分け、数量差異の承認を単価差異の承認に流用しないようにします。経理担当が現物を見に倉庫へ行かなくても判断できる証跡が、導入効果を左右します。

導入前の現状調査：何を数えるか

システム選定前に、直近の入荷案件から差異の実例を抽出します。差異件数だけでなく、発見までの時間、保留から決着までの時間、請求書の保留件数、再計数率、手入力の修正件数を記録します。差異がゼロに見える工場でも、現場が納品書の数字をそのまま入力している可能性があります。現物計数と帳票転記が同じ工程になっていないかを観察してください。

サンプルは通常便だけでなく、分納、混載、週末到着、夜間到着、委託倉庫、返品、無償支給、代替品などを含めます。PO改訂前後で納入されたケースも重要です。差異の多い仕入先だけを対象にすると、まれだが影響の大きい品番違いや高額部品の過納を見落とします。現状調査では担当者の責任を問うより、判断に必要な情報がどこにあり、何回転記されるかを可視化します。

RFPに書くべき要件

RFPには「過不足に対応」とだけ書かず、入力と期待出力を例で示します。たとえばPO行A100個、ASN A100個、現物A98個なら、差異行に不足2個、正式受入候補98個、発注残候補2個を表示すること。PO行A100個、現物A100個+B3個なら、Aは一致、Bは未発注品として隔離すること。PO行A100個、現物A103個で許容条件外なら、承認前にERPの利用可能在庫へ3個が流れないこと。このように数値と状態を固定すれば、ベンダー間の比較ができます。

さらに、品番マッピング、単位換算、ASNなし入荷、ラベル読取不能、再計数、写真添付、オフライン復旧、承認代行、監査ログ、部分受入、取消、請求照合のイベント参照を入れます。タイ工場なら現場のタイ語画面と日本語・英語の管理帳票のどちらが必要か、時刻・日付・通貨の扱いも指定します。ただし言語数を増やすだけでは運用は整いません。「不足」「受入済み」「仮置き」などの用語を業務上の状態と一対一に定義しておくことが先です。

導入見積・責任分界・本番移行の確認点

見積では「端末数」より例外処理と連携の範囲を揃える

入荷差異管理システムの導入費用を比較するとき、ライセンス数やスキャナー台数だけを横並びにしても判断できません。ある提案はASNの取込までを含み、別の提案はCSV手動取込を前提にすることがあります。ある提案はWMS内の仮置き記録までで、ERPの正式受入伝票は手入力のままかもしれません。見積条件には、対象拠点、月間入荷行数、対象サプライヤー、ASNの形式、ラベルの種類、既存ERPの接続方式、承認者数、保留品のロケーション、請求書連携の範囲を書きます。比較表の列を同じにしないと、安く見える見積が運用開始後に追加開発へ変わります。

初期構築だけでなく、マスタ整備、教育、ラベル変更、サプライヤーへの周知、稼働後の例外分析も作業に含めます。特に品番対照と単位換算が不安定な工場では、システム設定よりデータ修正に時間を使う可能性があります。費用対効果を試算するなら、月間差異件数に一件あたりの調査・承認時間を掛け、請求保留や再計数に使う時間も分けて測ります。金額の根拠がないまま「自動化で何%削減」と置くより、現状サンプルから範囲を示す方が社内稟議で検証できます。誤受入による停止・返品・棚卸修正は発生頻度と影響が大きく変わるため、平均値一つにまとめず、重大事例を別に示します。

責任分界を一枚の表に落とす

現場で滞留しがちなのは、差異の検知そのものより「誰が決着をつけるか」です。例えば不足2個では、荷受け担当が再計数し、購買がサプライヤーへ後送予定を確認し、倉庫が実数での正式受入を起票し、経理が後日届く請求書をその受入と照合します。過納3個では、倉庫が隔離し、購買が追加購入または返品を判断し、必要なら品質が使用可否を確認します。品番違いでは、品質が技術的な代替可否を判断しても、価格や契約の変更は購買の決定です。権限の境界を曖昧にしたまま「承認ボタン」だけ設けても、承認待ち一覧が増えるだけです。

権限表には、差異種別、金額影響、品目リスク、発注変更要否、品質判定要否、承認者、代行者、期限、期限超過時の通知先を並べます。承認者が変更を却下した場合の出口も必要です。再計数へ戻すのか、返品するのか、発注を取り消すのかを状態遷移として定義します。承認操作の証跡には変更前後の数量、理由、添付資料、操作者、時刻を残します。現物の計数値そのものを承認者が修正する方式は避け、計数訂正と処理判断を別操作にします。これにより「実際はいくつ届いたか」と「いくつを会社が受け入れたか」を後から再現できます。

本番移行時に未完了の入荷をどう扱うか

導入日には、発注済みだが未着のPO、ASNだけ到着した便、倉庫で計数済みだがERP未登録の便、品質保留中の品、請求書だけ先に届いた案件が存在します。これらを一括して「当日残」として移すと、後から由来が追えません。移行前日に状態別の件数と数量を確定し、各レコードに旧システムIDと移行時点の責任者を付けます。旧システムで正式受入済みの数量を新システムから再送しないことが最重要です。未着のPOと受入済みのPOを同じ変換ルールにしないでください。

本番切替では、短期間だけ紙と新システムを併用する場合もあります。その間はどちらが正本かを決め、一件の入荷に一つの受入イベントIDを割り当てます。並行入力を無期限に続けると、二重計上や差異の見逃しを招きます。稼働初週は毎日、現物確認件数、差異保留件数、ERP受入伝票件数、請求照合待ち件数を突き合わせ、欠落や重複を当日中に確認します。監査可能な移行記録を残してから旧入力を止めることが、安全な段階導入です。

FAT・SATで確認する具体的なシナリオ

FATはベンダー環境での機能確認、SATは自社の端末、ラベル、ネットワーク、WMS/ERP連携、実担当者を含めた現地確認として計画します。画面が動くかだけでなく、差異を放置したときに何が止まり、誰に通知されるかを見ます。デモ用のきれいなマスタだけでは、実装の弱点が見えません。実際のPO行と荷姿を匿名化して持ち込み、現場の作業順に試験します。

SATでは受入端末の読取距離、手袋着用時の操作、混載パレットの動線、通信断からの再接続、夜勤の承認者不在も確認します。失敗したケースは「現場で回避」ではなく、ルール変更、システム修正、教育、マスタ修正のどれで解決するか記録します。正式稼働の判定条件は、全ての差異をゼロにすることではありません。差異が正しく見つかり、保留中に誤った在庫・支払が進まず、承認後に一貫した数量へ収束することです。

KPIと段階導入の進め方

最初は一拠点・一品目群・数社のサプライヤーで、差異が多いか、記録と照合の負荷が高い流れを選びます。パイロットでは「差異検知率」だけを成果にしません。これまで見逃していた差異を記録し始めると、初月の差異件数はむしろ増えることがあります。保留解消までの時間、PO/ASN/現物を追える割合、ERP二重計上件数、請求保留の処理時間を併記します。改善は基準期間と対象範囲を揃えて判断します。

導入順は、①数量の正本を定める、②差異を消さず記録する、③承認と在庫確定点を固める、④WMS/ERPへ連携する、⑤請求照合へつなぐ、が現実的です。サプライヤーにASNの入力を求める前に、POの品番・単位・分納予定が安定しているかを確認します。社内マスタに揺れがあるまま外部入力だけを増やすと、差異の原因が現物かデータか判別しにくくなります。サプライヤーとの共同改善では、差異の責任追及より、ラベル、梱包、ASN送信時点、数量単位の標準化を優先します。

よくある導入失敗と対処

第一は、端末の計数結果をそのまま正式受入にする設計です。過納と品番違いの保留場所がなく、現場が帳尻を合わせ始めます。第二は、許容差を全品目共通の率で決める設計です。価値、単位、契約が違う品目を同じ処理に押し込みます。第三は、ERP側の受入伝票とWMS側のイベントの対応表がない設計です。障害時に再送の安全性を確認できません。第四は、請求書の差異を入荷差異の一部として扱う設計です。時点と責任者が違うため、解決漏れが起きます。

対処は、状態遷移表、権限表、例外ケース、イベントIDをRFP段階で一緒に確認することです。パッケージ標準機能があるかどうかだけでなく、自社の「保留」「承認」「取消」に適合するかを試験します。カスタマイズ費用を抑えるために業務を標準へ寄せる場合でも、現物と正式受入の区別、承認の証跡、在庫の二重計上防止は外せません。そこが曖昧なら、後からレポートを追加しても数字の信頼は回復しません。

まとめ：差異を消さず、決着までつなぐ

製造業の入荷差異管理システムは、PO、ASN、現物の数量を比べる画面だけでは完成しません。過納・不足・品番違いを別々に記録し、品目ごとの許容差と承認権限を適用し、正式受入と利用可能在庫の確定点を明示する必要があります。その後、WMS/ERPの受入伝票と請求照合へ同じイベントIDでつなげます。まず一つの入荷便について、発見から決着までの全記録が追えるかを確認してください。

自社のPO、ASN、現場計数、ERP受入、請求書の間で数量が食い違う箇所を整理したい段階でも、TOMAS TECHへご相談いただけます。既存システムと現場運用を見ながら、差異の記録単位、承認、FAT/SATの試験ケースを一緒に具体化します。

FAQ

入荷数量差異は発注数量とASNのどちらを基準に管理しますか？

両方を別々に比較します。ASN対現物は出荷予告の精度、PO対現物は発注に対する納入状況を示します。ASNどおりでもPOに対して不足することがあります。比較対象、単位、対象便を画面と帳票に明記してください。

過不足納品の受入処理は何%まで自動承認できますか？

共通の正解値はありません。品目の価値とリスク、契約、発注単位、サプライヤー、経理方針で決めます。MicrosoftやOracleの文書にある率は各製品の設定説明・例であり、業界一律の基準ではありません。許容内でも差異の記録は残します。

発注数量と受入数量が違う場合、請求書はどう照合しますか？

PO、正式受入、請求書を別文書として3-way matchingします。入荷差異と請求差異は別イベントとして管理し、相互参照で結びます。請求書を保留するか、部分支払するか、クレジットを求めるかは契約と社内規則に従います。

品番違いでも数量が一致すれば受け入れられますか？

数量一致だけでは判断できません。発注品番の不足と未発注品の到着を別行に記録し、代替可否、品質、価格、請求表記を購買・品質で確認します。承認前は使用可能在庫に混ぜない設計が必要です。

FATとSATで最優先の確認点は何ですか？

不足、過納、品番違い、再計数、品質保留、ERP応答消失、二重送信、請求差異を通します。画面の表示だけでなく、保留中に在庫や支払が進まないこと、承認後に正しい数量へ収束することを確認します。

参考情報

• Microsoft: Product receipt against purchase orders
• Microsoft: Process over/under transactions
• Oracle: Item Purchasing Attributes
• Oracle: Invoice Tolerances
• SAP: Workflow for goods receipt-based invoice verification
• GS1: Logistic Label Guideline