注文管理システムと在庫管理システムの違い｜引当・欠品・分納の境界の決め方

◆監修・編集責任者　小園 将隆　2026年11月10日

B2B EC-COLUMN

注文は受けたが引当を誰がやるのか分からないとき、最初に決めること

得意先から注文が入ったのに、その分の在庫を誰が押さえ、足りないときに分納にするか入荷待ちにするかを誰が決めるのかがはっきりしない。
注文管理システムと在庫管理システムの違いで迷うのは、まさにこの場面です。
この迷いは、引当の実行、在庫数の保持、欠品時の判断の三つの担当を分けて決めると解けます。
注文管理は注文という取引の状態を追い、在庫管理はモノの数量と所在を追います。
ベンダーの用語解説では、引当は受注側が行い、在庫側が数を保持して出荷時に更新すると説明されています¹。
ただし「有効在庫」の数え方は資料によって異なります。

迷いの原因は3つの担当が決まっていないこと

注文管理システムと在庫管理システムの違いを調べ始めると、機能一覧の比較に目が向きがちです。
ただ、現場で手が止まる理由は、どちらの製品が優れているかではありません。
注文が入った瞬間から出荷までの間に、誰がその在庫を押さえ、誰が数を持ち、足りないときに誰が決めるのかが決まっていないことにあります。

たとえば、得意先のA社からある部品の注文が届いた場面を仮に考えます。
受注担当者は在庫の画面で残数を見て、足りていると判断し、注文を登録します。
このとき、その数量がA社の分として確保されたのか、まだ誰でも使える数のままなのかは、画面を見ただけでは分かりません。
出荷の段になって倉庫担当者が棚を見たら数が合わない、という事態は、システムの名前の問題ではなく、確保の手続きが誰の仕事か決まっていないことから起こります。

決めるべき担当は次の三つです。

• 引当の実行：注文に対して在庫を押さえる処理を、どの画面の操作で、誰が行うか
• 在庫数の保持：実際の在庫数や押さえ済みの数について、どのシステムの値を正として扱うか
• 欠品時の判断：押さえられなかった注文を、入荷待ちにするか、分けて送るか、得意先と納期を調整するかを誰が決めるか

この三つは互いに結び付いています。
引当を注文側で行うなら、在庫側はその結果を受け取って使える数を減らす必要があり、欠品の判断も、引当に失敗した注文を最初に知る注文側に寄せやすくなります。
逆に、出荷の直前まで何も押さえない運用なら、受注の時点では在庫が約束されていないことを、受注担当者も得意先も理解している必要があります。

在庫ありと思って受注してしまうと何が起きるか

引当を管理していないと、別の営業担当者が在庫はまだあると思って同じ品の注文を受け、実際には足りなくなるおそれがあると説明されています¹。
A社の注文を受けた担当者とは別の担当者が、同じ部品について得意先のB社から注文を受ける場面を思い浮かべると分かりやすいでしょう。
二人とも同じ在庫の画面を見て、同じ残数を前提に回答してしまいます。

受注担当が一人で、注文の窓口も一つのうちは、押さえ済みの数を手元の表や記憶で補えます。
担当者が増えたり、電話・FAX・メール・受発注サイトなど複数の窓口から注文が入ったりすると、ある担当者が受けた注文の分を、別の担当者が見ている在庫数から差し引けなくなります。
こうして生じた不足は、出荷の段階で初めて表に出ます。

不足が分かった時点で、A社とB社のどちらの注文を先に出すのか、残りをいつ届けるのか、得意先へ誰が連絡するのかを決めなければなりません。
つまり、引当の担当が決まっていないことは、そのまま欠品時の判断の担当が決まっていないことにつながります。
三つの担当を一緒に決める必要があるのは、このつながりがあるためです。

▼ 図の内容を文字で読む

1. 引当の担当が決まっていない
2. 押さえ済みの数が見えない
3. 同じ品を重ねて受注する
4. 欠品時の判断が必要になる

注文管理と在庫管理は、何を管理する点で違うのか

注文管理が追う情報

注文管理が追うのは、一件の注文という取引がいまどの段階にあるかです。
得意先から注文を受け付けた、内容を確認した、数量や納期が変更された、出荷を指示した、といった状態の移り変わりが中心になります。
A社の注文で言えば、「受け付け済みで、在庫の引当が済み、出荷指示待ち」という状態を一件ごとに持つのが注文管理の役割です。

請求との関係も、注文の状態の延長として考えると整理しやすくなります。
出荷が済んだ注文を請求の対象にする流れは、注文の状態を追っている側がつなぎやすいためです。
ただし、請求に必要な情報をどこまで注文管理に持たせ、どこから販売管理や会計の側に任せるかは製品ごとに範囲が異なりうるため、自社の請求の流れと製品の機能を照らし合わせて決める部分になります。

在庫管理が追う情報

在庫管理が追うのは、モノがいくつ、どこにあるかです。
入庫や出庫のたびに数が変わり、倉庫や棚の単位で所在が記録されます。
注文が一件増えても、モノそのものは出荷されるまで動きません。
この「注文は動いたがモノは動いていない」時間をどう扱うかが、二つのシステムの境目になります。

NetSuiteの用語解説では、受注管理システムが在庫の残数を検索して受注時に引当処理を行い、在庫管理システムは物理在庫と、引当を反映した有効在庫のデータを持ち、出荷時に在庫数量を更新するという分担が示されています¹。
押さえる操作は注文側、押さえた結果も含めた数を持つのは在庫側という分け方です。
これは同社の用語解説に示された役割分担であり、すべての製品がこの形で作られているわけではありません。
それでも、前の節で挙げた引当の実行と在庫数の保持を、別々の担当として切り分けられることはこの説明から読み取れます。

販売管理・基幹との重なり

販売管理システムや基幹システムの中に、受注と在庫の両方の機能を持つ一体型の製品もあります。
この場合、二つのシステムの境界という問題は見えにくくなりますが、なくなるわけではありません。
同じ製品の中でも、受注の画面で引当をするのか、出荷の画面で引当をするのか、欠品した注文をどの一覧で管理するのかは、設定や運用で変わります。

一体型を選ぶとしても、三つの担当をどの画面と誰の操作に置くかを決める作業は残ります。
システムが一つか二つかではなく、注文の状態とモノの数がどこで結び付くかを見ておくと、後で構成を比べるときの物差しがぶれません。

引当と有効在庫の数え方で、境界の作業が決まる

受注引当と出荷引当の違い

引当という言葉は一つでも、押さえる中身には段階があります。
一創の技術解説では、受注引当は注文が確定した時点で品目と数量だけを押さえる処理、出荷引当は出荷指示の直前に倉庫・棚番・ロットまで決める処理と整理されており、出荷引当はWMS（倉庫管理システム）側で行われることが多いとされています²。

この違いを境界の決め方に当てはめると、受注引当は注文側に、出荷引当は倉庫・在庫側に置きやすいと考えられます。
受注引当で必要なのは「この品目をこの数だけA社に約束した」という情報で、注文の状態と一緒に扱うのが自然です。
一方、どの棚のどのロットから出すかは、モノの所在を知っている側でなければ決められません。
二つの段階を同じシステムに置くか分けて置くかで、受注担当者と倉庫担当者がそれぞれどの画面で何を確認するかが変わります。

ここで注意したいのは、二つの資料が同じことを言っているわけではない点です。
NetSuiteの解説は受注時の引当を受注側が行うという分担を示し¹、一創の解説は引当を二段階に分ける考え方を示しています²。
発行元も目的も異なる説明を並べて読むと、引当を実行する側と数を持つ側は分けて考えられ、引当の段階によって置き場所も変わりうる、という整理ができます。
ただし、これはどの製品にも当てはまる標準仕様ではなく、用語の説明を比べたうえでの見立てです。

実在庫・引当可能数・有効在庫の違い

引当の置き場所を決めるには、画面に出てくる数が何を意味するかをそろえておく必要があります。
まず実在庫は、倉庫に実際にある数です。
注文を受けて引当をしても、モノはまだ倉庫にあるので実在庫は減りません。
減るのは出荷したときです。

NetSuiteの解説では、有効在庫数を、実在庫数から引当済みの数量を引いた、受注に使える残りの数として説明しています¹。
受注の時点で有効在庫が減り、出荷の時点で実在庫が追いつくように減る、という動きです。

一創の解説では、実在庫から引当済みを引いた数を引当可能数と呼び、即納できるかどうかの判断に使うとしています²。
そのうえで、引当可能数に入荷予定を加えた数を有効在庫と呼び、発注の判断に使うと整理しています²。

定義が資料によって異なる点の扱い

同じ「有効在庫」という言葉が、一方では入荷予定を含まない数を、他方では入荷予定を含む数を指しています。
この食い違いは、境界を決めるうえで小さな話ではありません。

たとえば、受注担当者がA社から即納の可否を聞かれ、注文管理の画面に表示された「有効在庫」を見て回答したとします。
その製品の有効在庫が入荷予定を含む計算であれば、まだ倉庫にないモノまで数に入っており、即納と答えた分が実際には入荷待ちになることがあります。
反対に、在庫管理の側では入荷予定を含めない意味でこの言葉を使っていれば、受注担当者と倉庫担当者が同じ言葉で別の数を見ながら話す状態になります。

そのため、製品を比べる段階で、画面の表記と計算式をそろえて確かめることが欠かせません。
見るべきなのは、引当済みの数をどこで差し引いているか、入荷予定を含めているか、受注の画面と在庫の画面で同じ計算を使っているかの三点です。
社内でも、即納判断に使う数と発注判断に使う数を別の名前で呼び分けておくと、製品が変わっても会話がぶれにくくなります。

▼ 図の内容を文字で読む

• 実在庫から引当済みを引いた数
  • 一方の解説では有効在庫と呼び、受注に使う
  • 他方の解説では引当可能数と呼び、即納の判断に使う
• 引当可能数に入荷予定を加えた数
  • 他方の解説では有効在庫と呼び、発注の判断に使う
  • 一方の有効在庫には入荷予定を含まない
• 実在庫そのもの
  • 引当をしても減らず、出荷したときに減る

欠品・分納・取置き・返品で、データの正をどちらに持たせるか

欠品と受注残

引当をしようとしたときに数が足りなければ、その注文は欠品になります。
一創の解説では、引当できない注文は受注残（バックオーダー）として入荷待ちになると整理されています²。

受注残をどちらに持たせるかを考えると、注文側に残すのが自然だと考えられます。
受注残は「まだ果たせていない約束」であり、得意先への納期回答や変更の連絡は注文単位で行うからです。
在庫側は入荷の予定と実績を持ちますが、入荷した分をどの注文に回すかは、注文の納期や条件を知らないと決められません。

入荷した分の配分順について、同じ解説はBtoBでは納期の早い順を第一とし、次に受注日時の早い順とするのが標準的だとしています²。
これは一つの技術解説の整理であり、すべての企業に共通する規則ではありません。
自社で得意先ごとに約束している条件があるなら、その条件を配分の順序にどう入れるかを決めておく必要があります。

分納の可否の持たせ方

受注残が入荷を待つ間に、注文数の一部だけが入荷することがあります。
ここで問題になるのが、入った分だけ先に送ってよいかどうかです。
一創の解説は、分納の可否を注文ごとに持たせる考え方を示し、入った分から送ってよい注文と、全量がそろってから出す注文が混在すると説明しています²。

仮に、A社は入った分から送ってほしい、B社は全量がそろってから一度に受け取りたい、という場面を考えます。
分納の可否を得意先の属性として固定してしまうと、同じA社でも急ぎでない注文はまとめて送りたい、といった場合に対応できません。
注文ごとの属性として注文側に持たせておけば、入荷時の配分で「この注文は一部でも出す」「この注文は全量まで待つ」を判断できます。

このとき在庫側から見ると、B社向けに入荷した分は、全量がそろうまで出荷されないまま押さえられた状態になります。
押さえたまま待っている数を在庫側でどう見せるか、たとえば引当済みに含めるのか、別の区分で見せるのかは、製品の仕様と社内の運用で決める部分です。

取置きと大口取引先の枠

得意先によっては、注文が確定する前から一定の数を押さえておいてほしいと頼まれることがあります。
一創の解説では、顧客のランクを配分の並び順に混ぜるのではなく、大口取引先向けに数量を先に確保する枠として別に持つ案が示されています²。
並び順とは別に枠を持てば、納期と受注日時による順序はそのまま保ち、枠の分だけを得意先との約束として別に説明できる、と読めます。

一方で、取置きを製品の中でどう扱うかは、仕様として確かめる必要がある項目です。
押さえた数を引当済みに含めるのか、別の区分で持つのか、期限が来たら戻すのか、注文側と在庫側のどちらで登録するのかによって、受注担当者が見る数が変わります。
境界を決めるときは、取置きを「注文になる前の約束」とみなして注文側で管理するのか、「動かせない在庫」とみなして在庫側で管理するのかを、まず社内で言葉にしておくと、製品の説明と照らし合わせやすくなります。

キャンセル・返品時の引当解除

注文がキャンセルされたら、押さえていた数は他の注文に使えるよう戻す必要があります。
受注引当を注文側で行っている構成なら、キャンセルの操作も注文側で起き、その結果を在庫側の引当済みの数に反映させる流れになります。
戻すのが遅れると、在庫はあるのに引当可能数が少なく見え、別の注文を受けられない時間が生まれます。

返品はキャンセルと違い、一度出荷されたモノが戻ってくる動きです。
出荷の時点で実在庫は減っているため、戻ってきた品をいつ実在庫と引当可能数へ戻すかを決める必要があります。
検品の前に戻すのか、検品が済んでから戻すのか、売り物にならない品をどう区分するのかは、自社の運用と製品の仕様で決める部分です。
注文側では返品の受付と得意先との精算の流れを、在庫側ではモノの戻りと数の更新を持つ、という分け方が一つの考え方になりますが、どこまで自動で連動するかは製品ごとに確かめる必要があります。

ここまでの場面を、注文側と在庫側のどちらを正とするかの提案としてまとめると、次のようになります。

場面	注文側を正とする情報（提案）	在庫側を正とする情報（提案）	社内で決めること
欠品	受注残、得意先への納期回答	入荷予定と入荷実績	入荷分の配分順
分納	注文ごとの分納可否	全量待ちで押さえている数	押さえたまま待つ数の区分
取置き・確保枠	どの得意先のための枠か	枠として押さえた数	注文前の約束か在庫の区分か
キャンセル	キャンセルの受付と注文の状態	引当済みの数の戻し	解除を反映する時点
返品	返品の受付と得意先との精算の流れ	戻った品の数と区分	検品の前後どちらで戻すか

▼ 図の内容を文字で読む

1. 引当できない
   • 受注残として入荷待ちにする
2. 入荷がある
   • 入荷した分を受注残へ配分する
3. 受注残へ配分する
   • 納期の早い順を第一にする
   • 次に受注日時の早い順にする
4. 分納可否を確かめる
   • 分納可の注文は入った分から送る
   • 分納不可の注文は全量がそろうまで押さえて待つ

在庫管理のみ・注文管理を追加・一体型は、どんな条件で分かれるか

比較の軸

どの構成を選ぶかは、前の節で見た境界の作業が自社でどれだけ込み入っているかで変わります。
比べる軸は、注文件数、引当の複雑さ、既存システムとの連携の可否、運用変更とマスタ整備の負担の四つです。
前の二つは今の運用を見れば分かることで、後の二つは導入した後の運用を想像して初めて見えてくることです。
費用や導入期間も判断には入りますが、製品と契約の条件ごとに異なるため軸には入れず、見積もりの段階で比べる前提にしています。

比較の軸	見る時点	在庫管理のみ	注文管理を追加し連携	一体型
注文件数	現状運用	担当者が押さえ済みの数を手元で把握できる範囲に収まる	窓口や担当者が多く、注文ごとの状態を一覧で追う必要がある	受注・在庫に加え、販売や請求まで同じ流れで扱いたい件数がある
引当の複雑さ（分納・取引先別の確保枠）	現状運用	分納や確保枠がほとんどなく、出荷時の確認で足りる	分納可否や受注残の配分を注文単位で管理する必要がある	注文単位の管理に加え、在庫の区分と注文の状態を一つの画面で合わせたい
既存システムとの連携可否	導入後運用	既存の在庫管理をそのまま使い、注文は別の手段で受ける	既存の在庫管理や基幹と、引当結果や在庫数をやり取りできる	既存の在庫管理や基幹を置き換えることを受け入れられる
運用変更とマスタ整備の負担	導入後運用	変更は小さいが、引当の手順を人の運用で補い続ける	商品・得意先のマスタを両方でそろえ、同期のずれに備える	移行時に受注・在庫・販売の運用とマスタを一度に見直す

表のうち判断が分かれやすいのは、引当の複雑さと既存システムとの連携可否の組み合わせです。
引当が込み入っていても、既存の在庫管理と数をやり取りできなければ、注文管理を足しても転記が増えるだけになりかねません。
以下では、三つの構成それぞれが合う条件と、選んだ後に残る作業を見ていきます。

在庫管理のみで足りる場合

在庫管理のみで足りるのは、受注の窓口と担当者が限られ、押さえ済みの数を在庫管理の側に手で登録すれば追いつく場合です。
この構成では、注文の状態は受注の帳票や表計算で追い、在庫管理には引当や出荷の結果だけを入れることになります。
分納や取引先別の確保枠がほとんどなく、欠品したときも担当者同士の声かけで判断できるなら、別のシステムを足すよりも、引当を誰がいつ登録するかの手順を決めるほうが先です。

見直しの合図になるのは、別の担当者が在庫ありと思って受注する場面が出始めたときです¹。
担当者や窓口が増え、押さえ済みの数を在庫管理へ入れるまでの間に別の注文が入るようになると、人の手順で境界を守り続けることが難しくなります。

注文管理を追加する場合

注文管理を追加して在庫管理と連携させるのは、注文ごとの状態や条件を追う必要が出てきたが、在庫管理そのものは今のものを使い続けたい場合です。
受注引当を注文管理に置き、在庫数の保持と出荷時の更新は既存の在庫管理に任せるという分担は、NetSuiteの解説が示す役割分担と同じ方向です¹。
出荷引当を倉庫側で行う二段階の使い方とも組み合わせられます²。

この構成の要は、既存の在庫管理が引当の結果を受け取り、在庫の数を返せるかどうかです。
やり取りできない場合、注文管理で押さえた数を在庫管理へ手で転記することになり、境界の作業を二つの画面に分けただけで終わってしまいます。
連携できる場合も、二つのシステムに同じ商品と得意先を登録し、品番や単位の対応をそろえておく手間がかかります。
さらに、二つのシステムの数が一時的に食い違うことを前提にした運用も必要になります。

一体型で持つ場合

一体型は、受注・在庫・販売を一つの製品で持つ構成です。
既存の在庫管理や基幹を置き換える判断ができるなら、二つのシステムの間で数を同期する問題はなくなります。
受注の画面で引当した結果がそのまま在庫の数に反映される作りであれば、転記や同期のずれを心配する場面は減ります。

その代わり、移行のときに受注・在庫・販売の運用とマスタを一度に見直すことになります。
また、先に触れたとおり、一体型でも引当をどの画面で行い、欠品した注文をどの一覧で扱うかは決める必要があります。
製品の中で境界が見えにくい分、導入前に「どの画面の操作で何の数が変わるか」を確かめる重みはむしろ増すと考えておくとよいでしょう。

連携するなら、何をいつ同期し、ずれたらどう扱うか

数の基準を決める

注文管理と在庫管理を分けて連携させると、二つのシステムにそれぞれ在庫の数が存在することになります。
ずれを扱う前に、まずどちらの数を基準にし、何の数をやり取りするのかを決めておく必要があります。

やり取りする数として考えられるのは、実在庫か、引当済みを差し引いた後の数かです。
実在庫を送る場合、注文管理の側で自分が押さえた分を差し引いて表示することになり、引当の記録が注文側にそろっていないと正しく計算できません。
引当後の数を送る場合、注文管理の側はそのまま受注に使えますが、その数が入荷予定を含むかどうかは資料によっても定義が分かれていたため、定義をそろえておかないと即納の回答を誤ります。

どちらにするにせよ、基準となる数は在庫側が持ち、注文側は引当の結果を在庫側へ返すという方向を決めておくと、ずれが出たときにどちらを直すかで迷わずに済みます。
NetSuiteの解説で在庫管理側が有効在庫を保持するとされていたのも¹、この向きを決める手掛かりになります。

同期の時間差と売り越し

連携の方式によっては、在庫の数を一定の間隔で取得して反映する形になります。
シッピーノの在庫同期の仕様では、倉庫から在庫を取得する処理と、ストアへ反映する処理がそれぞれ一定の間隔で行われており、時間差を完全になくすことはできないと説明されています³。
同じ仕様説明では、減算した分が戻ったタイミングで売り越しにつながるおそれがあることにも触れています³。

これはFBAなどの倉庫とネットショップのストアをつなぐサービスの仕様であり、企業間の受発注システム同士の連携にそのまま当てはまる間隔や方式ではありません。
それでも、二つのシステムが別々に数を持ち、間隔を置いて合わせる構成なら、合わせるまでの間に古い数を見て受注する時間が生まれる、という仕組みは同じように考えておく価値があります。

A社の例に戻ると、在庫が残りわずかの部品について、在庫側ではすでにB社の分が差し引かれているのに、注文管理の画面ではまだ数が残って見え、その間にさらに別の得意先の注文が入る、という形で表れます。
在庫に余裕がある商品なら時間差は吸収されますが、残りが少ない商品ほど、このずれが欠品として表に出やすいと考えられます。

閾値と手動確認の運用

同じ仕様説明では、売り越しを抑える手立てとして、商品ごとに在庫の閾値を設定すること、連携先のストアが一つの場合に同期を止めること、対象の商品だけ同期を切ることが挙げられています³。
あわせて、注文の重複や大量の購入は、閾値を設定しても防げない場合があるとしています³。

企業間の受注に置き換えると、閾値は「この数を下回ったら、注文側では自動で受けず、在庫を確かめてから回答する」という線として使えます。
残りが少ない商品だけを確認の対象にすれば、すべての注文で在庫を照会する手間をかけずに、ずれが欠品につながりやすい場面に人の確認を集められます。
ただし、閾値は時間差によるずれを小さくする仕組みであり、一度に大きな数量の注文が入る場面や、同じ注文が重複して登録された場面までは防げません。
大口の注文や、複数の窓口から同じ注文が届きうる得意先については、受注の段階で別に確認する手順を持っておくと、閾値だけに頼らずに済みます。

ずれが見つかったときの直し方も決めておきます。
基準の数を在庫側に置いているなら、注文側の表示を在庫側に合わせたうえで、合わない原因が引当の戻し忘れなのか、出荷の反映漏れなのかを追う順序になります。
原因の種類が分かれば、キャンセル時の引当解除や出荷時の更新など、決めた担当のどこに手当てが要るかが見えてきます。

▼ 図の内容を文字で読む

1. 在庫側の数を取得する
2. 注文側へ反映する
   • 次の反映までは古い数を見て受注する時間がある
3. 注文側で受注し引当する
4. 引当結果と出荷を在庫側へ返す

境界を決めたあと、導入前に確認すること

確認項目の一覧

ここまでに決めてきた境界を、製品を比べるときや導入を決める前に確かめる問いに置き換えると、次のようになります。

• 有効在庫の定義：画面の「有効在庫」は入荷予定を含むか。
  即納判断に使う数と発注判断に使う数は区別されているか
• 引当の実行主体：受注引当はどの画面の操作で行われ、出荷引当は注文側と倉庫・在庫側のどちらで行うか
• 欠品時の受注残：引当できなかった注文はどこに残り、入荷した分をどの順序で配分できるか
• 分納可否の持ち方：分納の可否を注文ごとに持てるか。
  全量待ちで押さえている数はどう見えるか
• 同期の方式と間隔：二つのシステムがやり取りするのは実在庫か引当後の数か。
  どの間隔で反映されるか
• キャンセル時の引当解除：キャンセルや返品で引当や在庫がいつ戻り、どちらのシステムに反映されるか

このうち、有効在庫の定義と引当の実行主体は、製品の説明書きの言葉だけでは判断しにくい項目です。
デモや試用の場面では、A社のような仮の注文を一件入れ、受注の画面と在庫の画面の数がそれぞれいつ、どう変わるかを順に見せてもらうと、言葉の違いに左右されずに確かめられます。
取置き、返品、請求との連携範囲も、自社の運用を伝えたうえで、どちらのシステムで登録し、どちらに反映されるかを個別に確かめておきたい項目です。

並行稼働と移行の確認

新しい構成へ移るときは、古い運用と新しい運用をしばらく並べて動かし、数が一致するかを確かめる進め方があります。
その期間の長さは、注文の件数や商品数、得意先との約束の複雑さによって変わるため、一律の目安は置けません。
代わりに、並行稼働の間に何を突き合わせるかを先に決めておくことが大切です。

突き合わせる対象は、引当済みの数、受注残の件数と内容、分納で待っている注文、取置きや確保枠として押さえている数です。
実在庫だけを比べて一致していても、引当済みの数がずれていれば、新しい構成で受注を始めた途端に、受けられないはずの注文を受けてしまうことがあります。

移行の時点で残っている受注残や、分納の途中にある注文をどう移すかも決めておく必要があります。
途中まで出荷した注文を新しいシステムで一件として登録し直すのか、残りの分だけを新しい注文として起こすのかで、得意先への納期回答や後の請求の扱いが変わります。
分納可否を注文ごとに持てるようにするなら、商品や得意先のマスタだけでなく、注文の入力項目と既定値の決め方まで整えておくと、稼働後に入力する人ごとの判断がばらつきにくくなります。

境界の考え方が分かっても、自社の受注窓口や得意先ごとの約束を当てはめると、どの数をどちらのシステムで持つかの判断が分かれる場面が出てきます。

自社の注文の流れを一件ずつたどりながら、引当・受注残・分納可否をどちらに置くかの整理を相談できます。無料相談で要件を整理する

要点の整理

軸	基準
境界の決め方	引当の実行・在庫数の保持・欠品時の判断の担当を分けて決める
引当の置き場所	受注引当は注文側、出荷引当は倉庫・在庫側に置きやすい
数の定義	「有効在庫」が入荷予定を含むかを製品と社内でそろえる
欠品・分納	受注残と分納可否は注文ごとに注文側で持つ
構成の選択	注文件数・引当の複雑さ・連携の可否・運用とマスタの負担で比べる
連携のずれ	基準の数を在庫側に置き、残りが少ない商品は閾値で人の確認に回す

製品の説明だけでは、有効在庫の計算や引当解除の時点まで読み取れないことがあります。 導入前に確かめる項目を自社の運用に合わせて整理し、製品比較や並行稼働で何を突き合わせるかを確認できます。

よくある質問

有効在庫と引当可能数は同じ意味ですか。

資料によって異なります。
NetSuiteの用語解説では、実在庫から引当済みを引いた数を有効在庫と呼んでいます¹。
一創の技術解説では、その数を引当可能数と呼び、そこに入荷予定を加えた数を有効在庫としています²。
製品の画面で同じ言葉が使われていても、入荷予定を含むかどうかで即納の回答が変わるため、計算式を確かめてから使うのが安全です。

受注引当と出荷引当は、どちらのシステムで行うべきですか。

決まった正解はありませんが、受注引当は品目と数量だけを押さえる処理なので注文側に、出荷引当は倉庫・棚番・ロットまで決める処理なので倉庫・在庫側に置きやすいと考えられます。
一創の解説では、出荷引当はWMS側で行われることが多いとされています²。
自社の構成でどちらの画面で行うかは、製品の仕様と倉庫の運用に合わせて決めます。

分納してよい注文と全量そろってから出す注文が混在するとき、どう管理しますか。

分納の可否を、得意先単位ではなく注文ごとの属性として注文側に持たせる方法があります²。
そうしておけば、入荷時の配分で、一部でも出す注文と全量まで待つ注文を分けて扱えます。
全量待ちの注文のために押さえている数を在庫側でどう見せるかは、別に決めておく必要があります。

注文管理と在庫管理を連携すると、在庫数がずれるのはなぜですか。

二つのシステムがそれぞれ数を持ち、一定の間隔で合わせる構成では、反映までの間に古い数を見て受注する時間が生まれるためです。
在庫同期の仕様として、時間差は完全にはなくせないと説明している例もあります³。
このほか、有効在庫の定義の違いや、キャンセル時の引当解除の反映漏れもずれの原因になります。
基準となる数をどちらが持つかを決め、残りが少ない商品には閾値を設けて人の確認に回すと、ずれが欠品につながる場面を減らせます。

キャンセルや返品のとき、引当はどのタイミングで戻しますか。

キャンセルでは、押さえていた数を他の注文に使えるよう戻す必要があり、反映が遅れると在庫があるのに受注できない時間が生まれます。
返品はすでに実在庫が減った後の動きなので、検品の前に戻すか、検品が済んでから戻すかを社内で決めることになります。
どちらも、どのシステムでいつ自動的に戻るかは製品によって確かめる必要があります。

1. 1　出典：オラクル（NetSuite）「在庫の引き当て（用語解説）」（2026年閲覧）
2. 2　出典：株式会社一創「在庫引当とは：受注引当と出荷引当の違い、有効在庫の計算と引当解除・欠品時の配分をSQLで実装」（2026年閲覧）
3. 3　出典：シッピーノ「在庫同期の基本仕様」（2026年閲覧）