販売管理システムと在庫・引当の連携方法｜二重引当と欠品を防ぐタイミングと方式の選び方

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

B2B EC-COLUMN

受注は取れたのに出荷できない――在庫がずれる典型パターン

受注データの上では在庫があったはずなのに、出荷指示を出す段になって現物が足りない。
自社ECとモールで最後の一点が同時に売れてしまい、片方のお客様を待たせることになる。
こうしたずれは、在庫の数え間違いというより、「どの時点で」「どの範囲で」在庫を引き当てるかという設計が自社の実情に合っていないことから起きます。
設計として動かせるのは、引当のタイミング（受注時か出荷時か）と、システム間の連携方式（リアルタイムかバッチか）の組み合わせです。
加えて、複数チャネルがあるなら引き当てる場所を一箇所に定めること、商品マスタの正をどのシステムに置くかを決めること、キャンセル・返品で在庫をどう戻すかを決めておくこと。
ここまで含めて揃ったとき、二重引当と欠品は運用の気合いではなく設計で抑えられる範囲に入ります。

同じ在庫を、別々の場所で引き当てている

在庫が合わないと聞くと、まず棚卸の精度や入出庫の記帳漏れが疑われます。
ところが、受注は正しく取れていて倉庫の現物も帳簿どおりある、という状態でも出荷できない事態は起こります。
このとき食い違っているのは在庫の数そのものではなく、「あと何個売ってよいか」という販売可能数を、どのシステムが持っているかという点です。

自社ECのカートが持つ在庫数、モールに登録した在庫数、販売管理システムの在庫数、倉庫側の実在庫。
これらがそれぞれ独立に減る構造になっていると、どこか一つで売れた瞬間に、残りの数字はすべて古くなります。
たとえば最後の一点が自社ECで売れたとして、その情報がモール側へ伝わるまでの間、モールの画面には在庫が残っています。
そこに注文が入れば、一つの在庫に対して二つの受注が成立します。
やっかいなのは、どちらの受注も画面上は正常に「在庫を引き当てた」ように見えることです。
ずれは受注の時点では見えず、出荷の直前になって初めて表面化します。

この構造に対しては、各チャネルが自分で在庫を減らすのをやめる方向で手が打たれてきました。
OMS（注文管理システム。
複数チャネルの受注と在庫をまとめて扱う仕組み）は、APIやCSVによる連携で各販売チャネルと在庫データを同期し、自社ECで商品が売れた場合にモールECの在庫数を更新することで在庫情報のずれを避ける役割を持ちます⁶。
さらに踏み込んで、OMSを唯一の在庫引当ポイントにすることが、複数チャネルの売り越しを防ぐ根本的な解決策とされています⁷。
引き当てる権限を一箇所に集め、他のチャネルには「売ってよい数」を配るだけにする、という考え方です。

「いつ」と「どの範囲で」の二つの軸に分けて考える

ただし、引き当てる場所を一箇所に集めても、それだけで話は終わりません。
その一箇所が「いつ」在庫を確保するのか――注文を受け付けた瞬間なのか、出荷指示を出す段階なのか――で、仮押さえの長さも、取り合いが起きる余地も変わります。
そしてもう一つ、集約した在庫情報が各チャネルや倉庫へ「どのくらいの速さで」返るのか。
この二つ、つまり引当タイミングと連携方式が、在庫のずれを生む余地の大きさを決めています。

以降ではこの二軸に沿って、それぞれ何が変わるのかを分解していきます。
なお、ここで扱う取り合いの問題は、自社EC・モール・実店舗など二つ以上の販売経路が同じ在庫から出荷している事業者で起きやすいものです。
販売経路が一つだけの場合はチャネル間の取り合い自体は生じませんが、受注から出荷までの間に在庫がどう扱われるかという論点は同じように残ります。

引当タイミングの違い:受注時引当と出荷時引当

受注時引当の仕組みとメリット・デメリット

受注時引当は、注文が確定した時点でその注文に必要な数量を在庫から確保し、販売可能数からすぐに差し引く方式です。
注文を受けた順に在庫が押さえられていくため、売り越しを最も確実に防げる方式とされています⁷。
お客様に「確保できました」と伝えられる状態を早い段階で作れるので、欠品連絡や納期調整のやりとりは減ります。

一方で、キャンセルが多い商材では在庫の仮押さえが蓄積するというデメリットがあります⁷。
決済が完了していない注文、与信の確認待ち、受注直後の取り消し。
これらがすべて販売可能数を削っている状態になると、棚には現物があるのに売れない在庫が生まれます。
売り越しを防いだつもりが、別の形の機会損失に置き換わっているわけです。

そのため受注時引当を選ぶなら、押さえた在庫をいつ・どうやって解放するかを同時に決めておく必要があります。
キャンセル操作をすれば自動的に戻るのか、担当者が別の画面で解除しないと戻らないのか。
この解除の作法は製品によって違い、後の節で扱うように例外もあります。

出荷時引当の仕組みとメリット・デメリット

出荷時引当は、出荷指示を出す段階になって初めて在庫を確保する方式です。
仮押さえの期間が短く済むため在庫の回転率は上がりますが、引当から出荷までの間に別の注文が入るリスクがあります⁷。
正確には、受注してから出荷指示に至るまでの間、その注文のための在庫は誰にも押さえられていません。
その空白の時間に別の注文が入れば、先に受けたはずの注文が出荷段階で足りなくなります。

この空白は、受注から出荷までのリードタイムが長いほど広がります。
取り寄せや検品、まとめ出荷の都合で出荷指示が翌日以降になる運用では、その分だけ取り合いの余地が残るということです。
逆に、受注後すぐ出荷指示が走る運用であれば空白は短く、仮押さえが積み上がらない利点の方が効いてきます。

この記事としての整理を言えば、キャンセルが多く出荷までが短い事業なら出荷時引当寄り、受注から出荷まで日数があり確実に届けることを優先するなら受注時引当寄り、という見方になります。
どちらが優れているかは条件次第で、自社のキャンセル率と出荷リードタイムを並べて初めて判断できます。

引当処理は基幹システムとWMSのどちらで行うか

同じ受注時引当でも、その処理を実行するのが販売管理（基幹）側なのか、倉庫側のWMS（倉庫管理システム）なのかで、引当が表現できる中身が変わります。
API連携による在庫同期が可能であれば、在庫管理システム側で引当処理を実行するのが望ましいとされ、その理由として、基幹システムにはロット別・ロケーション別在庫の設計が無い場合が多いことが挙げられています³。

この違いは実務では小さくありません。
引当が「商品Aを三個」という粒度までしか持てないと、どのロットの、どの棚にある三個なのかは現場の判断に委ねられます。
賞味期限順に出したい、同一ロットでまとめて出したい、といった条件は引当と切り離され、ピッキングの段階でしか担保されなくなります。
ロットやロケーションまで含めて引き当てられれば、出荷指示の時点で在庫の状態と引当の状態が一致します。

ただしこれは、受注管理とWMSが別システムで構成され、ロットやロケーション単位の在庫を管理している事業者を前提にした判断です。
受発注から出庫まで一つのシステムで完結している場合は、そもそもどちらで引き当てるかという分岐が生じません。
自社がどちらの構成なのかを先に確かめると、この節の判断が当てはまるかどうかがはっきりします。

連携方式の違い:リアルタイム連携とバッチ連携のタイムラグ

リアルタイム連携(API連携)の仕組み

引当のタイミングを決めても、その結果が他のシステムへ届くまでに時間がかかれば、届くまでの間は古い在庫数で売られ続けます。
ここで効いてくるのが連携方式です。
リアルタイム連携はデータが発生した瞬間に即座に処理する方式で、バッチ連携はスケジュールに基づいてまとめて処理する方式だと整理されています¹。
とくにイベント駆動の方式では、データの変更を検知した瞬間に後続の処理が走るため、人手やスケジュールを待たずに反映が完了します¹。

在庫に当てはめれば、引当が成立した瞬間に各チャネルの販売可能数が書き換わるということです。
API連携は在庫変動の瞬間に両システムのデータが同期され、SKU数が多く複数チャネルでリアルタイムに在庫を管理したい場合に向くとされています²。
SKUとは、色やサイズまで区別した最小の商品管理単位のことで、この数が増えるほど手作業や定期取り込みでの追随は難しくなります。

代償として挙げられているのが実装工数の大きさです²。
項目の対応付けを決める作業に加えて、連携が一時的に途切れたときにどこから追いつくのか、どの操作までを即時に送るのかといった取り決めも必要になります。
導入前に確認しておくと、稼働後に想定外の手戻りが出にくくなります。

バッチ連携(CSV連携)の仕組みとタイムラグ

CSV連携は、既存システムから出力したファイルを定期的に取り込む方式で、追加開発が不要である一方、タイムラグが避けられず売り越しのリスクが生じるとされています²。
ここでいうタイムラグは、単に「反映が少し遅い」という話ではありません。
前回の取り込み以降に売れた分は、次の取り込みが走るまで他のチャネルからは見えない、ということです。

平常時であれば、その間に同じ商品が別チャネルで売れる確率は高くないかもしれません。
問題が出るのは、セールや露出で短時間に注文が集中する場面です。
取り合いが起きる余地は同期の間隔に比例して広がるので、注文の集中する時間帯だけ危険度が跳ね上がります。
取り込みの間隔を詰める、あるいはチャネルごとに確保する在庫を決めて取り合いそのものを起こさせない、といった手当てとセットで考えることになります。

もう一つの選択肢として、ミドルウェアを介して複数システムを間接的に連携させる方式もあります。
片方のシステムをリプレイスしても連携への影響を抑えられる反面、ライセンス費用が発生するとされています²。
販売管理システムやECカートを将来的に入れ替える可能性があるなら、直接つなぐ前に検討に入れておく価値のある方式です。

複数チャネル(EC・実店舗・卸)の在庫配分をどう設計するか

全チャネル共通在庫のメリット・デメリット

引き当てる場所を一箇所に定めたあとに残るのが、その一箇所が各チャネルへ「何個まで売ってよい」と見せるかという配分の問題です。
全チャネルが同じ在庫を共有する方式は在庫効率が高い一方、売り越しリスクが残るとされています⁷。
手元の在庫をどのチャネルからでも売れるため、どこかに眠らせたまま別のチャネルで欠品する、という無駄が起きにくいのが利点です。

リスクが残る理由は、同期が速くても注文の間隔がそれより短くなり得るからです。
OMSがAPIやCSVで各チャネルと在庫を同期し、自社ECで売れた商品のモールECの在庫数を更新する仕組みであっても⁶、更新が各チャネルに行き渡るまでの間に注文が入る余地までがゼロになるとは言い切れません。
共通在庫は、その余地を許容したうえで在庫効率を取る選択だと考えると、判断しやすくなります。

チャネル別在庫確保のメリット・デメリット

もう一方は、チャネルごとに最低限確保する在庫を決めてしまう方式です。
確実性は高い反面、在庫が過剰になりやすいとされています⁷。
あるチャネルに割り当てた在庫は、そのチャネルで売れなければ残り続けます。
別のチャネルが売り切れていても、割り当てた分は動かせません。

選び方は、欠品の許容度と過剰在庫の許容度のどちらを優先するかに帰着します。
販促や露出で特定チャネルの注文が跳ねると分かっている期間はそのチャネルに確保を厚くし、通常期は共通在庫に戻す、といった使い分けも設計次第で成り立ちます。
どちらか一方に固定しなければならないものではありません。

実店舗を含める場合には、もう一つ前提の確認が要ります。
店頭での販売はその場で現物が減るため、レジ側の販売情報がどの経路で、どのくらいの頻度で引当ポイントへ返るのかが共通在庫の前提になります。
店頭の販売実績が定期的にしか戻らないなら、店舗在庫を共通在庫に含めた瞬間にタイムラグの問題が持ち込まれることになります。
ここは前節の連携方式の話と地続きです。

連携が機能する前提:商品マスタ・SKUの整合性

どのシステムの商品マスタを「正」とするか

ここまでは在庫数をどう動かすかの話でしたが、その前提として、同じ商品が同じ商品として突き合わせられている必要があります。
複数のシステムで同じ商品を別のコード体系で管理していると、データ連携時に同じものを別のものとして扱ってしまう問題が発生します⁵。

この問題は、在庫のずれとしてはやや分かりにくい形で出ます。
連携先では別のSKUとして登録されるため、在庫が二重に存在するように見えたり、更新が片方のコードにしか当たらず、もう一方は最初に登録した数のまま止まったりします。
同期の仕組みは正常に動いているのに数が合わない、という状態になるため、原因を連携方式の側に探しに行ってしまいがちです。

対処として示されているのは、どのシステムのデータを正とするか、つまりマスタオーナーシップを明確に決めることです⁵。
商品マスタは販売管理または在庫管理が正を持つケースが多く、正が決まれば他のシステムは参照コピーとして一方向で同期する設計にするとされています⁵。
どちら側でも自由に編集できる状態にしておくと、最後に更新した側の内容が残る形になり、あとから「どちらが正しかったのか」を判定する手立てがなくなります。
編集できる場所を一つに絞ることが、突き合わせの前提を守る一番の近道です。

連携の粒度と更新頻度を先に決める

もう一つ、連携の粒度（SKU単位かロット単位か）と更新頻度を初期段階で合意しておくことが、手戻りを防ぐ最大のポイントとされています⁵。
粒度を後から変えるのが難しいのは、それが引当の表現力そのものを決めてしまうからです。

たとえばロット単位で引き当てたいのに、システム間でSKU単位でしか在庫をやりとりしていなければ、倉庫側で引当処理を行う構成にしても、引当の結果をもう一方へ正確に返せません。
粒度の合意は、前の節で触れたロット別・ロケーション別の在庫管理を選べるかどうかと直結しています。
更新頻度についても同じで、どの頻度で同期するかが決まって初めて、共通在庫で運用できるのか、チャネル別に確保しておくべきなのかを判断できます。

あわせて、新商品の追加や廃番、SKUの改定をどちら側で行うのかも同じ取り決めの中に入れておくと、運用が始まってから迷わずに済みます。
マスタの整合性は、一度整えれば終わりではなく、商品が増減するたびに問われ続けるためです。

返品・キャンセル時に引当をどう解除するか

通常受注のキャンセル時の在庫戻し

受注時引当を選んだ場合、キャンセルの扱いはそのまま販売可能数に返ってきます。
戻し方を決めていないと、前の節で触れた仮押さえの蓄積が、そのまま売れない在庫として残り続けます。

具体例として、あるECプラットフォームでは、受注のキャンセル時に「在庫を反映させる」にチェックして更新すると在庫が戻り、チェックしなければ在庫は戻らない仕様になっています⁴。
つまり自動的に戻るわけではなく、操作する人の選択に委ねられているということです。

この作り自体には理由があります。
返品でまだ現物が戻ってきていない段階や、戻ってきた商品が破損して再販できない場合には、在庫を戻さない方が実態に合います。
裏を返せば、どの場面でチェックを入れ、どの場面で入れないのかを運用ルールとして決めておかないと、担当者ごとに判断が分かれ、数字が合わなくなるということでもあります。
ここは仕組みで自動化しきれない部分なので、ルールを文書にしておく価値があります。

なお、ここで挙げた設定はこのプラットフォーム固有の仕様であり、他社の販売管理システムやECシステムでは設定項目も既定の動作も異なります。
自社のシステムに同種の設定があるかどうかを仕様書で確かめるための、一例として読んでください。

予約受注・予定在庫の例外処理

さらに注意が要るのは、通常の受注とは扱いが分かれるケースです。
同じプラットフォームでは、予約受注のキャンセルでは在庫は予約在庫数へ戻り、その商品が通常販売に切り替わっていても通常在庫には戻らないとされています⁴。
また、予定在庫から購入された場合には、在庫を戻す処理自体が行われません⁴。

運用の目で見ると、これは「戻ったように見えて、売れる在庫としては戻っていない」状態が生じうるということです。
予約期間が終わって通常販売に移ったあとにキャンセルが入れば、その数量は予約の枠に戻り、通常の販売可能数は増えません。
入荷前の予定在庫から売れた注文がキャンセルされたときも、数字は動きません。
いずれも仕様として決まった動きなので、知らずに運用すると、原因の分からない欠品として現れます。

自社のシステムを確認するときは、次の点を仕様書や設定画面で見ておくと判断がつきます。
キャンセル時に在庫が自動で戻るのか操作が必要なのか、戻る場合はどの在庫の枠へ戻るのか、予約・取り寄せ・入荷予定分は別扱いになっていないか、そして戻した結果が連携先のチャネルにも伝わるのか。
最後の一点は、引当を一箇所に集める設計を採っている場合にとくに効いてきます。
戻りが連携先まで届かなければ、解除したはずの在庫がチャネル側では欠品のままになるからです。

自社の状況別チェックリスト:受注件数・更新頻度から選ぶ

受注件数・更新頻度から連携方式を絞る

ここまでの論点を、自社の条件に当てはめる段に進みます。
連携方式については、SKU数が多く更新頻度が高い場合はAPI連携、SKU数が中程度で更新頻度が低い場合はCSV連携で足りるケースがあるとされています²。

この「更新頻度」を数えるときは、受注件数だけを見ないことです。
入荷、出荷、返品、棚卸の修正、いずれも在庫の変動です。
一日のうちに在庫が動く回数と、その変動が他のチャネルの販売判断に影響するかどうかを合わせて見ます。
変動が多くても、それが他チャネルの販売可能数に影響しない構成なら、即時性の必要度は下がります。

キャンセル率を重ねて引当タイミングを決める

引当タイミングの選択は、キャンセル率とのトレードオフです⁷。
キャンセルが多い商材で受注時に引き当てれば仮押さえが積み上がり、少ない商材で出荷時まで待てば、待った時間だけ取り合いの余地を抱えることになります。

この二つの目安を重ね合わせると、SKU数と更新頻度が高くキャンセルも多い事業者はリアルタイム連携と出荷時寄りの引当が噛み合いやすく、更新頻度が低くキャンセルも少ない事業者はバッチ連携でも成立しやすい、という見方ができます。
これは各社が示す一般的な目安を組み合わせた本記事の整理であり、自社の実測データによる検証ではありません。
最終的には、自社の受注件数・在庫の変動回数・キャンセル率を並べて確かめる必要があります。

導入・見直しの前に確認する項目

設計を決める、あるいは既存の設計を見直すときに、先に答えを出しておきたい項目を整理します。
いずれも後から変えると連携の作り直しにつながるため、導入前の打ち合わせで合意しておく類のものです。

この一覧のうち、引当ポイントと引当タイミングは業務ルールの決め事で、連携方式とマスタの粒度はシステムの仕様に縛られます。
先に業務側の希望を固めてから仕様を確かめると、実現できない前提で設計を進めてしまう事故を避けられます。
逆に、既存システムの連携手段が限られている場合は、そこから逆算して業務ルールを寄せることになります。

最後に一点。
引当の設計を変えると、影響は在庫だけでなく、出荷・請求・返品の処理にも及びます。
本記事で扱った各社の説明は仕組みと選び方の目安であり、自社で採用できる範囲は使用中の製品の仕様と契約条件によって変わります。
方式の見当をつけたあとは、自社のシステムの仕様書で同じ論点がどう実装されているかを確かめたうえで決めてください。

引当のタイミングと連携方式の組み合わせは、受注件数やキャンセル率、いま使っているシステムが備える連携手段によって答えが変わり、一般的な目安だけでは自社の設計まで決めきれないためです。

現在のチャネル構成と在庫の更新経路を書き出したうえで、引き当てる場所をどこに置き、どの粒度で同期すれば手作業の在庫調整が減らせるのかを一緒に整理できます。無料相談で要件を整理する

要点の整理

軸	基準
引当ポイント	複数チャネルがあるなら引き当てる場所を一箇所に定め、各チャネルには売ってよい数を配る
引当タイミング	キャンセル率と出荷リードタイムで選ぶ。受注時は売り越しに強く仮押さえが溜まり、出荷時は回転が上がり取り合いが残る
引当の実行場所	ロット・ロケーション管理が必要で在庫同期ができるなら在庫管理システム側が望ましいとされる
連携方式	SKU数と在庫の更新頻度で絞る。バッチは同期間隔ぶんのタイムラグを許容できるかで判断する
商品マスタ	正を一つに決めて一方向同期にし、粒度と更新頻度を導入前に合意する
キャンセル・返品	在庫が戻る条件と戻り先の在庫枠、予約・予定在庫の例外を自社の仕様書で確認する

販売管理システムやECカートが備える連携手段と、キャンセル・返品時の在庫戻しの既定動作は製品ごとに異なり、仕様書を読むだけでは実際の運用にどう響くかを読み取りにくいためです。 手元の仕様と現在の運用ルールを前提に、どこまで自動で在庫が戻り、どの確認作業が人手に残るのかを具体的に洗い出せます。

よくある質問

販売管理システムとWMSを連携させず、販売管理システム単独で引当処理を行うことはできますか

受発注から出庫まで一つのシステムで完結している構成であれば、販売管理システム側で引き当てる運用は成立します。
判断が分かれるのは、ロット別・ロケーション別の在庫を扱う場合です。
API連携による在庫同期が可能であれば在庫管理システム側で引当処理を実行するのが望ましいとされ、その理由として基幹システムにはロット別・ロケーション別在庫の設計が無い場合が多いことが挙げられています³。
自社の販売管理システムがロットやロケーションまで表現できるかどうかを先に確かめると、単独で足りるかどうかが見えてきます。

商品マスタの情報はどのシステムで更新すればよいですか

どのシステムのデータを正とするか（マスタオーナーシップ）を決め、更新はその一箇所だけで行うのが基本的な考え方です。
商品マスタは販売管理または在庫管理が正を持つケースが多く、正が決まれば他のシステムは参照コピーとして一方向で同期する設計にするとされています⁵。
どちら側でも編集できる状態にしておくと、更新が競合したときにどちらが正しいか判定できなくなります。
あわせて、連携の粒度と更新頻度も初期段階で合意しておくことが手戻りを防ぐポイントとされています⁵。

API連携を導入する場合、必ず追加開発が必要になりますか

どの程度の開発が要るかは、つなぐシステム同士の仕様によって変わるため、一律には言えません。
一般的な傾向として、API連携は在庫変動の瞬間に両システムのデータが同期される反面、実装工数が大きいとされ、CSV連携は既存システムからファイルを定期的に取り込む方式のため追加開発は不要とされています²。
また、ミドルウェアを介して間接的に連携させる方式では、ライセンス費用が発生します²。
まずは使用中の製品が標準でどこまでの連携手段を備えているかを仕様書で確かめ、足りない部分だけを開発の対象として見積もるのが現実的な進め方です。

予約商品やまだ入荷していない商品のキャンセルも、通常商品と同じルールで在庫が戻りますか

同じとは限りません。
あるECプラットフォームでは、予約受注のキャンセルで在庫は予約在庫数へ戻り、その商品が通常販売に切り替わっていても通常在庫には戻らないとされています⁴。
さらに、予定在庫から購入された場合は在庫を戻す処理自体が行われません⁴。
これは同社プラットフォーム固有の仕様で、他社の販売管理システムやECシステムでは扱いが異なります。
自社の環境では、キャンセル時にどの在庫の枠へ戻るのか、予約や入荷予定分が別扱いになっていないかを、仕様書で確認しておくことをおすすめします。

1. 1　出典：アステリア株式会社「リアルタイム連携とは｜仕組みとバッチ連携との違いを解説（ASTERIA Warpブログ）」（2026年）
2. 2　出典：株式会社ripla「ECサイトの在庫管理と基幹システム連携｜3方式の選び方と設計の実務ポイント」（2026年）
3. 3　出典：株式会社オンザリンクス（INTER-STOCK提供元）「在庫引当処理を行うのは基幹システムとWMSどっち？在庫引当処理の要諦を解説」（2026年）
4. 4　出典：株式会社フューチャーショップ「受注の処理－キャンセル・返品編（futureshopオンラインマニュアル）」（2026年）
5. 5　出典：株式会社ripla「販売管理のERP連携設計｜押さえたい5つの指針」（2026年）
6. 6　出典：SUPER STUDIO INC.「OMS（注文管理システム）とは？機能・メリット・選び方をわかりやすく解説（ecforce blog）」（2026年）
7. 7　出典：株式会社ripla「オムニチャネル対応WMSで店舗在庫を一元化する方法【小売・OMS連携設計】」（2026年）