在庫引当(ひきあて)は、手持ちの在庫などから、特定の受注や生産に使う分を確保する処理です。棚に品物が残っていても、別の受注に約束済みなら自由には使えません。現物の数と、予約済みの数を分けて見ることが出発点です。
確認するのは、受注を受けたときの予約更新と、倉庫から出したときの数量更新です。この2つを混ぜると、同じ品物を二つの注文に約束したり、出荷済みの予約を残したりします。数字だけでなく、いつ誰が更新するかを決めます。
以下では、引当から出庫までを単純な例で追い、社内の台帳やシステムで確認する項目を整理します。根拠はIPAの技術資料と中小機構の導入手引です。会計上の在庫評価や、製品ごとの操作方法を決めるものではありません。
棚の数量と、次の受注に使える数量は違う
在庫引当では、現物を動かす前に、その在庫を使う相手や用途を決めます。予約の記録です。単に在庫が100個あると伝えるだけでは、そのうち何個が別の受注に確保されているかが分かりません。
説明用に、倉庫にある製品100個のうち、受注Aに60個を確保する場面を考えます。まだ出庫していないので、棚の数量は100個です。一方、ほかの受注に使える分は40個になります。受注Bから50個の注文が来ても、この条件では全数を約束できません。
ここで見るべきなのは、引当済みという合計だけではなく、その内訳です。受注番号を残します。品番、確保した数量、出庫予定日を受注に結び付ければ、変更連絡を受けたときにどの予約を見直すか追えます。
将来の入荷分まで含めて約束できるかも、別の条件です。到着予定と手持ちを混同しないでください。まず営業と生産管理が、納期回答で見る数字に何が含まれるかを確認します。
二重引当は、確認した残数が古くなると起きる
複数の受注が同じ残数を参照するなら、確認と予約の更新の間にずれがないか調べます。残数を見るだけでは足りません。予約を反映する前に別の担当者が同じ数字を見ると、使える量を過大に捉えるおそれがあります。
IPA(情報処理推進機構)の『はじめてのSTAMP/STPA〈実践編〉』は、システムの危険を分析する技術資料です。2017年3月版のネット通販の例に、引当と在庫更新の関係が示されています。現在の製品に共通する操作手順ではなく、失敗の仕組みを考える材料です。
同資料の表3.4-1では、最新の在庫更新前に、次の引当可能という応答を返す場合を扱っています。在庫が足りなくても出荷指示につながるというシナリオです。対策として、在庫の参照と更新を分割されない処理にする考え方が示されています。
現場で置き換えるなら、「同じ在庫に別々の担当が同時に予約を入れたらどうなるか」を確認します。試験用のデータで試してください。先ほどの例なら、Aの60個を予約した後、Bの担当画面に40個が反映されるかを見る手順です。
台帳を共有することと、二重引当を防ぐことは同じではありません。共有ファイルでも、更新の間に別の人が古い数を読む可能性があります。システム担当には、同時処理、更新失敗、再入力のときの扱いを確認します。
出庫したら、現物とその受注の予約を対応させる
出庫時は、倉庫の数量変化と、出荷した受注の予約残を対応させて確認します。二重に差し引かないことです。A向け60個を出した後もAの予約60個を残すと、手持ち40個からさらに60個を差し引くような誤った見方になります。
←→ 横にスクロールできます
| 段階 | 現物の数量 | Aの予約/ほかに使える分 |
|---|---|---|
| 予約前 | 100個 | 0個/100個 |
| Aへ60個を予約 | 100個 | 60個/40個 |
| Aへ60個を出庫・処理完了 | 40個 | 0個/40個 |

表の最後は、出庫と必要な処理が完了した状態です。実際の画面でどの操作が予約を消化するかは、製品ごとに確認します。出庫と売上計上の時点が異なる運用もあるため、画面の名前だけで表へ当てはめないでください。
中小企業基盤整備機構の「IT戦略ナビwith・在庫管理システム」は、入出庫の正確な管理と手順の標準化を挙げています。バーコードを使い、倉庫から入出庫データを更新する例もあります。2026年9月8日に確認した公的な導入手引です。
この手引を自社の確認に使うなら、読み取った後にどの数量が変わるかまで見ます。読取だけで完了とはしません。倉庫担当とシステム担当が、受注番号、品番、数量、処理結果を一緒に照合します。
変更・取消・分納は、予約の残りを受注ごとに追う
受注が変わったときは、現物を動かしたかどうかと、予約を変更したかどうかを分けて記録します。取消連絡だけで閉じないことです。営業が受けた変更を、倉庫や生産管理が処理したかも確認します。
たとえばAの60個が、出庫前に40個へ減った場合を考えます。この例では、20個分の予約を戻す対象として確認できます。ただし、すでに梱包した分や出庫した分があれば、同じ操作をそのまま適用できるとは限りません。
分納は、受注した数量を複数回に分けて納めることです。Aの60個のうち20個だけを先に出すなら、残り40個をどう管理するかを決めます。受注を完了扱いにして残りの予約を消すと、後の出荷分を別の注文へ回すおそれがあります。
- 変更前後の数量と、対象の受注番号を残す
- 未着手・梱包済み・出庫済みなど、自社で必要な状態を確認する
- 変更する予約と、残す予約を分ける
- 処理後の数量と、営業への回答内容を照合する
この順序は、例外処理を確認するための提案です。すべての製品に共通する解除操作ではありません。日常で多い変更を一つ選び、営業・倉庫・システム担当で実際の処理をたどります。
導入前に、通常処理と例外処理を一つずつ試す
在庫引当を見直すときは、通常の受注から出庫までと、数量変更などの例外を同じ品番で試します。確認点を絞るためです。画面の機能一覧だけでなく、自社の受注が最後まで追えるかを見ます。
受注Aを入れ、引当後の数量を別の担当画面から確認し、出庫した後の予約残も見ます。これが通常の流れです。次に、数量を減らす、分けて出す、入力をやり直すといった実際にある場面を加えます。
入力に失敗したときも確認対象です。同じ操作をやり直した結果、予約が二つできないかを見てください。自動処理と手修正が混ざる箇所では、どちらの記録を正とするかをシステム担当と決めます。
棚と帳簿の数量そのものが合っていない場合は、引当だけを直しても前提が揃いません。差の原因は別に調べます。棚卸差異の原因を切り分ける手順で、現物・時点・記録を確認してください。
また、いくつ持つべきかという在庫量の判断と、持っているものを誰に割り当てるかは別です。必要量は適正在庫を下限と上限で考える手順につなげます。引当の見直しでは、まず一つの受注の予約と出庫を最後まで追うことに集中します。
よくある質問
引当すると、棚の在庫も減りますか
予約しただけなら、現物はまだ動いていません。例では100個のままです。ただし、画面が示す「在庫」の定義は製品や設定で違います。現物、予約済み、利用可能な数量のどれを表示しているか確認してください。
Excelの共有台帳で管理できますか
必要な記録は作れますが、共有だけで二重引当を防げるとはいえません。誰がいつ更新するかが要点です。複数人が同時に使う場合や、ほかのシステムから受注が入る場合は、更新の仕組みを確認します。
どの受注から優先して引き当てますか
納期順などの優先順位は、自社の約束と運用に合わせて決めます。一律の順番は示せません。すでに引き当てた分を別受注へ回す場合の確認者も含め、営業と生産管理で基準を共有します。
まとめ
- 現物と予約済みの数量を分け、受注番号で内訳を追う
- 残数の確認から予約更新までに、別受注が割り込んだ場合を確認する
- 出庫後は現物の減少と、その受注の予約残を照合する
- 変更・取消・分納の処理は、自社の運用と製品仕様で確認する
最初の確認は、直近の受注一件で十分です。受注した数、確保した数、出した数を並べてみてください。周辺の在庫管理を見直すときは、在庫・物流のテーマページから必要な手順を選べます。
この記事の確認方法
株式会社恒電社 編集部
法令・告示・公的統計・白書など、国や行政が公表している原典にあたり、出典・前提条件・数字の扱いを編集部で確認しています。