販売管理システムと在庫連携で欠品・二重引当が起きる理由と中小企業の選び方

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

B2B EC-COLUMN

受注は取れているのに在庫が足りない・二重に引き当たるのはなぜか

受注データは間違いなく入っているのに、いざ出荷しようとすると在庫が足りない。
販売管理システムの画面では残っていたはずの数が、倉庫側やECの管理画面では別の数になっている。
こうした欠品や二重引当の多くは、担当者の入力ミスというより、二つの仕組みの間で在庫数がやり取りされるタイミングのずれと、チャネルごとに在庫をどう見せるかの設定が決まっていないことから生まれます。
連携の方式によって在庫が反映される速さは変わり、拠点や販売チャネルが増えれば、どこの在庫から引き当てるかというルールも必要になります。
自社の受注がどう動いているかに照らして、どこまでの即時性が要るのかを見極めるところが、連携方式を選ぶ出発点になります。

連携方式によるタイムラグが不整合を生む仕組み

引当とは、受注に対して出荷する分の在庫を確保しておく処理のことです。
販売管理システムと在庫管理システムが別々の仕組みである以上、片方で起きた在庫の増減は、もう片方に伝わって初めて数字が揃います。
つまり在庫数は常に一致しているのではなく、伝わるまでの間だけ食い違う時間があるということです。

この伝わり方には大きな違いがあります。
リアルタイム連携はデータが発生した瞬間に即座に処理するのに対し、バッチ連携はスケジュールに基づいてまとめて処理します²。
まとめて処理する方式では、次の処理が走るまでの間、販売側は更新前の在庫数を参照し続けることになります。

たとえば朝の処理で在庫数を受け渡し、日中に倉庫が出荷を進めたとします。
その出荷分は次の処理まで販売側に反映されないため、午後に受注を確定した担当者は、すでに出ていった在庫を残っているものとして引き当ててしまいます。
同じ1個を二つの受注に確保してしまう二重引当も、多くはこの「古い数字を見て確保した」状態から生まれます。
在庫情報がリアルタイムに同期されていない状態では、売り越しが発生するリスクが指摘されています²。

ここで大事なのは、担当者がどれだけ丁寧に確認しても、画面に出ている数字自体が古ければ結果は変わらないという点です。
不整合の原因を人の注意力ではなく、データが届くまでの時間の側に置いて考えると、打つ手が見えてきます。

チャネルごとの在庫の見せ方が不足すると起きること

原因はタイミングだけではありません。
複数のモールや自社ECで売っている場合、売り越しを防ぐには、1つの在庫を全チャネルで共有する在庫の一元同期、注文確定時に「注文済み未発送」分を販売可能在庫から除外する引当、実在庫数をチャネルごとに按分する在庫の見せ方のコントロールが必要とされています³。
このうち引当と見せ方の設定が抜けていると、反映が速くても売り越しは起こり得ます。

分かりやすいのは、実在庫10個をすべてのチャネルに10個と表示している状態です。
どのチャネルから見ても10個売れるように見えるため、同じ時間帯に注文が重なった瞬間、システムは実在庫を超える受注を受け付けてしまいます。
注文済みでまだ発送していない分を販売可能数から差し引いていなければ、同じ在庫が何度でも売れる計算になります。

つまり読者が直面している欠品や二重引当は、在庫が届くまでの時間の問題と、在庫をどう見せるかという設定の問題に分けて考えられます。
前者は連携方式の選択で縮められ、後者は引当と按分の設計で塞ぎます。
どちらか一方だけを直しても、もう一方の穴が残ることになります。

ただし、実際にどのくらいの更新間隔になるのか、按分が必要かどうかは、導入するツールと設定によって変わります。
ここから先は、自社がどちらの原因に当たっているのかを、受注の入り方と現在の設定に照らして見ていくことになります。

連携方式(バッチ・リアルタイムAPI・ミドルウェア)で引当のタイミングと精度はどう変わるか

「反映のタイミング」が引当の正確さを決める

在庫管理システムと基幹システムをつなぐ方式には、API連携、CSV/XML連携、ミドルウェア連携という選択肢があります¹。
方式によって変わるのは機能の多さではなく、在庫の変動が相手側に届くまでの時間です。
その時間が、そのまま引当を間違える余地の大きさになります。

もっとも、すべての処理を即時にすればよいというものでもありません。
実務では、在庫の即時反映や受注の即時処理のように即時性が必須な処理はリアルタイム連携、大量データの集計や定型処理はバッチ連携と使い分けるのが合理的とされています²。
受注時の在庫確保は前者に近く、日次や月次でまとめる集計は後者で足ります。

そう考えると、判断すべきなのは「自社の業務のどの部分に即時性が要るのか」です。
受注を受けた瞬間に在庫を押さえないと販売が止まる業務なのか、それとも当日中に整合が取れていれば出荷に支障がない業務なのか。
ここが決まらないまま方式だけを比べても、過剰にも不足にもなります。

「リアルタイム」表示でも売り越しの余地は残る

注意したいのは、同期が「リアルタイム」と表示されていても完全ではないという点です。
セール開始直後など複数の注文が重なる場面では、売り越しの余地が残るとされています³。
公開仕様を見ると、在庫更新が5分間隔や5〜10分間隔とされる例、受注を通常3分おきに取得する例が示されています³。

数分の間隔であっても、その数分に同一商品へ複数の注文が集中すれば、引当は競合します。
逆に言えば、注文がまばらに入る事業であれば、数分のずれが実害になる場面はほとんどありません。
方式の優劣ではなく、自社の受注がどれだけ重なるかで必要な精度が決まるということです。

そこで見ておきたいのが、1日の受注件数、注文が集中する時間帯、同じ商品に短時間で複数の注文が入る頻度です。
販促やセールを打つ日があるなら、その日の受注の入り方が実質的な要件になります。
「何分のずれまでなら業務が回るか」を自社の数字で言えるようになると、方式の比較が具体的な判断に変わります。

複数拠点・複数販売チャネルがある場合、引当の仕組みはどう設計を変える必要があるか

在庫の一元同期と受注時の自動引当

販売先が増えると、在庫の持ち方そのものを設計し直す必要が出てきます。
複数モールの売り越しを防ぐうえで必要とされるのは、1つの在庫を全チャネルで共有する一元同期と、注文確定時に注文済み未発送分を販売可能在庫から除外する引当です³。
チャネルごとに別々の在庫表を持ったままだと、どこかで人が転記して数を合わせることになり、その転記の間に必ず差が生まれます。

一元同期にすると、この転記作業そのものが減ります。
担当者が各モールの管理画面を順に開いて在庫数を打ち直す必要がなくなり、確認するのは同期が正常に完了しているかどうかに絞られます。
それでも、同期の失敗やエラーの検知は人の運用として残ります。

チャネルごとの在庫の見せ方をどう決めるか

按分とは、実在庫数をチャネルごとに割り当てて表示することを指します³。
実在庫10個のうち、モールAに6個、自社ECに4個までしか見せない、といった決め方です。
売り越しの余地を、表示する数の側で先に削っておく考え方だと捉えると分かりやすくなります。

どう配分するかは、各チャネルの売れ方と、在庫が反映されるまでの間隔の両方から考えることになります。
反映までの時間が長い方式を使っているほど、その間に重なる注文を吸収する余地が要ります。
逆に売れ筋が偏っているチャネルに少なくしか割り当てないと、在庫はあるのに売る機会を逃します。

按分が必要かどうか、どの比率にするかは、扱う商品と使うツールの設定によって変わります。
一律の正解を決めるより、売り越しが起きた商品と時間帯を見て、その商品だけ配分を見直すほうが現実的です。

拠点間で引き当てる優先順位の考え方

倉庫が複数になると、「在庫があるか」だけでなく「どの拠点の在庫を引き当てるか」という判断が増えます。
全社の合計では足りているのに、引き当てた拠点にだけ在庫がなく出荷できない、という形の欠品はここから起きます。
受注のたびに担当者が拠点を選んでいると、判断が人によってばらつき、結果として在庫の偏りが固定されていきます。

複数拠点での引当については、採用する戦略は荷主や商品特性によって異なるため、ルールとして設定できる柔軟性が重要とされています⁵。
つまり、どれか一つの考え方を全商品に当てはめるのではなく、商品ごとに切り替えられる形で持っておくという設計です。

なお、この整理は第三者物流(3PL)の事業者が複数の荷主の在庫を扱う文脈を含みます⁵。
自社の倉庫だけを複数持っている場合は、荷主ごとの事情にあたる部分を除いて、自社に当てはまる考え方を選んで使うことになります。

出典：株式会社クリエイティブバンク「ネットショップの在庫管理｜複数モールの売り越しを防ぐ一元管理の方法」（2026年、複数モール展開のネットショップが対象）

中小企業が連携を導入・見直す際、どの条件(費用・互換性・導入体制)を確認すべきか

費用面で使える補助金の対象条件

連携の見直しには費用がかかりますが、公的な支援制度の対象になる場合があります。
デジタル化・AI導入補助金2026の通常枠では、販売管理システムなどの業務プロセスソフトウェアの購入費やクラウド利用料(最大2年分)に加え、機能拡張やデータ連携ツール、導入コンサルティング・導入研修などの役務費用も補助対象とされています⁶。
連携ツールの追加や、設定を任せる際の支援費用まで含めて検討できる枠組みです。

金額の条件は、補助率が1/2以内、条件により2/3以内、補助額はITツール1プロセス以上の類型で5万円以上150万円未満、4プロセス以上の類型で150万円以上450万円以下とされています⁶。
ここで見落としやすいのが、申請するソフトウェアは共通プロセスまたは業種特化型の業務プロセスを1種類以上保有する必要があり、汎用ツール単体では申請できないという点です⁶。
在庫連携の仕組みだけを単独で申請しようとすると、この要件に照らして構成を組み直すことになります。

これらは2026年度時点の公募の内容です。
対象経費や補助率、補助額は年度の公募要領によって変わるため、実際に申請する時点の最新の情報を確認したうえで計画を立てる必要があります。

既存システムとの連携可否の確認ポイント

費用のめどが立っても、手元のシステムと実際につながるかどうかは別の話です。
製品の「対応」という表示だけを見るのではなく、受注連携・在庫連携・商品連携のそれぞれについて可否を分けて確認する必要があるとされています³。
ひとまとめに対応と書かれていても、中身が同じとは限らないためです。

たとえば、受注データの取り込みには対応していても、在庫数の書き戻しは手動という組み合わせがあり得ます。
この場合、受注入力の手間は減っても、在庫を合わせる作業と、そこで生じるずれは残ったままです。
いま困っているのが引当のずれであれば、確認すべきは受注の取り込み可否よりも、在庫が双方向に更新されるかどうかになります。

あわせて、在庫がどの間隔で更新される仕様なのかも確認の対象です。
方式の名前だけでは、自社の受注の集中に耐えられるかどうかは判断できません。

移行時の並行稼働などの実施体制

連携方式を変えるということは、日々の受注と在庫の流れを切り替えるということです。
販売管理システムの移行では、新旧のシステムを同時に稼働させ、月次締めを2回跨いで、1回目で差異を洗い出し、2回目で結果が一致することを確認する進め方が示されています⁴。
この並行稼働の期間は6〜8週間を設けることが多いとされます⁴。

並行稼働の間は、日次の受注・出荷データを新旧の両方に入力し、売上集計と売掛金残高が一致しているかを毎日チェックする運用が求められます⁴。
言い換えると、切り替えの期間中は入力が二重になり、その分の人手が要るということです。
受注担当が一人で回している体制であれば、この期間に何を止めるか、誰が確認を担うかを先に決めておかないと、移行そのものが滞ります。

この期間はシステムの規模や移行するデータ量によって前後する目安です。
金額の見積もりと同じくらい、この二重入力の期間をどう回すかが、導入を決める段階での判断材料になります。

複数の拠点を持っている場合は、どの拠点から引き当てるかというルールの立て方が次の論点になります。

連携方式の違いまでは整理できても、自社の受注がどれだけ重なっているのか、どこまでの即時性が必要なのかは、実際の受注と出荷のデータを見ないと決めにくいところです。

直近の受注件数と出荷のタイミング、チャネルごとの在庫の見せ方を一緒に確認すれば、更新の間隔を縮める必要があるのか、引当と按分の設定を直せば足りるのかの見分けがつきます。無料相談で要件を整理する

複数拠点で在庫を引き当てる際の考え方

配送先との距離、拠点間の在庫の偏り、費用のどれに重きを置くかという着目点の違いで並べています。

• 近接拠点優先：配送先に最も近い拠点から引き当てる

• 在庫偏在是正：拠点間の在庫バランスを平準化するように引き当てる

• コスト最小化：保管料と配送料の合計が最も低くなる拠点を選ぶ

同じ事業者でも、季節や販促で特定の拠点に在庫が偏ったときは在庫偏在是正へ、配送料の比重が大きい商品はコスト最小化へ、といった形で商品特性に応じて使い分けることになります。

連携方式ごとの中身と、どんな事業者に向くか

連携方式	在庫が反映されるタイミング	向くとされる事業者
バッチ(CSV/XML)連携	1日1〜数回の処理で受け渡し、間隔の間は古いまま	更新頻度が低い事業者、連携の初期段階
リアルタイムAPI連携	在庫が変動した瞬間に両システムが同期	SKU数が多く複数チャネルでリアルタイム管理したい事業者
ミドルウェア連携	つなぎ方の設計により変わるハイブリッド型	連携先が複数あり、将来さらに増える可能性がある事業者

バッチ(CSV/XML)連携は更新の合間に古い在庫が残る

1日1〜数回の受け渡しで現場に何が起きるか

CSV/XML連携では1日1〜数回のバッチ処理になるため、更新間隔の間は在庫データが古い状態になります¹。
朝と夕方の2回で受け渡している事業者であれば、日中に倉庫で出荷された分は夕方まで販売側に伝わりません。
その間に入った受注を確定すると、すでに出ていった在庫を引き当てることになります。

この方式で起きるずれは、受注担当が慎重かどうかとは無関係に発生します。
逆に言えば、いつ在庫が反映されるのかを担当者が把握していれば、ずれが起きる時間帯も読めます。
どの時間帯に受けた注文が危ないのかが分かるだけでも、出荷前の確認の的が絞れます。

更新頻度が低い事業者や、連携を始める段階で選ぶ場合

CSV/XML連携は、更新頻度が低い事業者や連携の初期段階に向くとされています¹。
受注が1日に数件で、同じ商品に短時間で注文が重なることがまずないなら、間隔の間に引当が競合する場面自体が少なくなります。
仕組みとしても理解しやすく、まず在庫を二重管理する状態から抜け出したい段階では現実的な選択肢です。

この方式を続けるなら、受け渡しの回数を増やす、あるいは出荷指示を処理の前後にまとめるといった運用で、ずれが生じる時間帯を短くする工夫が考えられます。
ただし、これは競合の起きる確率を下げる運用であって、売り越しが起きなくなるという意味ではありません。
販促で受注が集中する日をつくるようになったら、間隔そのものを見直す段階に入ります。

リアルタイムAPI連携は在庫変動の瞬間に同期する

同期のタイミングと、それでも残る競合

API連携では、在庫が変動した瞬間に両システムのデータが同期します¹。
倉庫で出荷処理をした時点で販売側の在庫数も動くため、古い数字を見て受注を確定するという場面がほぼなくなります。
先に触れたとおり、それでも注文が重なる瞬間には売り越しの余地が残るため³、引当と在庫の見せ方の設定は別に要ります。

現場の作業としては、在庫数を合わせるための転記と、その転記が済んでいるかの確認がなくなります。
残るのは、同期が止まっていないか、エラーになった連携がないかを見る作業です。
確認の対象が数字の突き合わせから、連携そのものの稼働状況へ移ると考えると分かりやすくなります。

SKU数が多い・複数チャネルを持つ場合

この方式は、SKU数が多く複数チャネルで在庫をリアルタイムに管理したい事業者に向くとされています¹。
扱う商品点数が増えるほど、手作業や定時の受け渡しで在庫を合わせる負荷は急に重くなります。
チャネルが複数あれば、そのたびに同じ作業が掛け算で増えていきます。

一方で、受注が少なく商品点数も限られている事業者が、即時同期そのものを目的に切り替えても、業務の変化は小さくなります。
判断の起点は方式の新しさではなく、いまのずれが実際に欠品や出荷遅れにつながっているかどうかです。

ミドルウェア連携は複数システムを疎結合でつなぐ

間に一段はさんでつなぐという考え方

ミドルウェア連携は、複数のシステムを疎結合でつなぐハイブリッド型とされています¹。
販売管理システムと在庫管理システムを直接つなぐのではなく、間に受け渡しを担う層を置いて、それぞれがその層とやり取りする構成です。
システム同士を一対一で直接結んでいく形と比べて、つなぎ先が増えたときの組み替え方が変わってきます。

即時に反映したい処理と、まとめて処理すればよいものを分けて扱える点も、この構成が使われる理由につながります²。
受注時の在庫確保は速く、日次の集計は定時に、といった使い分けを一つの仕組みの中で整理できるためです。

連携先が将来さらに増える見込みがある場合

この方式は、連携するシステムが複数あり、将来さらに増える可能性がある事業者に向くとされています¹。
販売チャネルの追加や、倉庫システム、会計システムとの接続が視野に入っているなら、つなぎ方を先に整えておく価値があります。
逆に、いま接続する相手が販売管理システムと在庫管理システムの二つだけで、当面増える予定もないのであれば、構成が重くなる分だけ判断は慎重になります。

どの方式を選ぶにせよ、決め手になるのは自社の受注がどれだけ重なるか、つなぐ相手がいくつあるか、そして今後増えるかどうかです。
この三つが見えていれば、製品ごとの機能一覧を比べる前に、必要な方式の範囲はかなり絞り込めます。

要点の整理

軸	基準
不整合の原因の切り分け	在庫が届くまでの時間の問題か、引当・按分の設定の問題かを分けて見る
必要な即時性	1日の受注件数と注文が重なる時間帯から、何分のずれまで業務が回るかを決める
連携方式の選択	更新頻度が低いならCSV/XML、SKU数が多く複数チャネルならAPI、連携先が増える見込みならミドルウェア1
複数チャネルの設計	在庫の一元同期・受注時の自動引当・チャネルごとの在庫の見せ方の按分3
複数拠点の設計	どの拠点から引き当てるかを商品特性に応じて切り替えられるルールにする5
費用	2026年度の通常枠は補助率1/2以内(条件により2/3以内)、補助額は5万円以上150万円未満または150万円以上450万円以下6
連携可否の確認	「対応」表示ではなく受注・在庫・商品連携それぞれの可否を分けて確認3
移行体制	並行稼働6〜8週間、月次締め2回で差異の洗い出しと一致確認4

いま使っている販売管理システムと在庫管理システムの組み合わせで、受注・在庫・商品のどこまでが実際につながるのかは、製品資料の表示だけでは判断しきれません。 現在のシステム構成と業務の流れを整理しながら相談すれば、どの連携方式が現実的か、並行稼働にどれだけの期間と人手が要るのかを具体的に見積もれます。

よくある質問

バッチ連携からリアルタイムAPI連携に切り替える際、業務を止めずに移行できますか。

販売管理システムの移行では、新旧のシステムを同時に稼働させ、月次締めを2回跨いで1回目で差異を洗い出し、2回目で結果が一致することを確認する進め方が示されており、並行稼働の期間は6〜8週間を設けることが多いとされます⁴。
この間は日次の受注・出荷データを新旧の両方へ入力し、売上集計と売掛金残高の一致を毎日チェックする運用が求められます⁴。
業務を止めずに進められる代わりに、その期間は入力と確認が二重になるため、誰がその作業を担うかを先に決めておく必要があります。
期間はシステムの規模やデータ量によって前後する目安です。

在庫の見せ方の按分とは、具体的にどう設定するのですか。

実在庫数をチャネルごとに割り当てて表示することを指します³。
実在庫が10個あるとき、全チャネルに10個と見せるのではなく、モールごとに割り当てた数までしか販売可能として表示しない、という設定です。
あわせて、注文確定時に注文済み未発送分を販売可能在庫から除外する引当も必要とされています³。
配分の比率に決まった正解はなく、各チャネルの売れ方と、在庫が反映されるまでの間隔を見ながら、売り越しが起きた商品から見直していくのが現実的です。

デジタル化・AI導入補助金は、在庫連携ツールの追加費用にも使えますか。

2026年度の通常枠では、ソフトウェア購入費やクラウド利用料(最大2年分)に加えて、機能拡張やデータ連携ツール、導入コンサルティング・導入研修などの役務費用も補助対象とされています⁶。
ただし、申請するソフトウェアは共通プロセスまたは業種特化型の業務プロセスを1種類以上保有している必要があり、汎用ツール単体での申請はできないとされています⁶。
連携ツールだけを切り出して申請する形にはならない場合があるため、どの構成で申請するかを含めて確認してください。
補助率や補助額を含め、内容は年度の公募要領によって変わります。

1拠点・1チャネルだけの場合でも、連携方式を見直す必要はありますか。

必ずしも必要とは限りません。
CSV/XML連携は更新頻度が低い事業者や連携の初期段階に向くとされており¹、受注が少なく、同じ商品に短時間で注文が重なることがないのであれば、定時の受け渡しで業務が回ります。
見直しを考える目安になるのは、出荷時に在庫が足りないことが実際に起きているか、販促などで受注が集中する日をつくるようになったかどうかです。
チャネルや拠点を増やす計画があるなら、増やす前に方式を検討したほうが、後からの組み替えは少なく済みます。

1. 1　出典：株式会社ripla「ECサイトの在庫管理と基幹システム連携｜3方式の選び方と設計の実務ポイント」（2026年）
2. 2　出典：アステリア株式会社「リアルタイム連携とは｜仕組みとバッチ連携との違いを解説」（2026年）
3. 3　出典：株式会社クリエイティブバンク「ネットショップの在庫管理｜複数モールの売り越しを防ぐ一元管理の方法（デジタル化の窓口）」（2026年）
4. 4　出典：株式会社ripla「販売管理システムのデータ移行を成功させる5ステップ」（2026年）
5. 5　出典：株式会社ripla「3PL・複数倉庫のWMS開発、5つの必須要件【拠点間管理ガイド】」（2026年）
6. 6　出典：独立行政法人中小企業基盤整備機構（デジタル化・AI導入補助金2026事務局）「デジタル化・AI導入補助金2026 通常枠」（2026年）