在庫差異対策｜EC在庫が合わない7つの原因と防止手順

ECの管理画面では在庫が10個あるのに、実際に数えると8個しかない。このような「システム在庫と実在庫が合わない状態」を在庫差異・在庫ズレと呼びます。

差異が出たときに数量だけ合わせても、入荷、注文、キャンセル、返品、破損、複数店舗連携などの原因が残っていれば、同じズレが再発します。

この記事では、EC在庫が合わなくなる7つの原因を整理し、 差異を発見する→原因を絞る→在庫を修正する→再発を防ぐ までの実務手順を解説します。

この記事の要点

在庫差異はシステム在庫と実在庫のズレ
数量を修正するだけで終わらせない
最初にSKU・場所・差異数量を特定する
入荷から現在まで在庫が動いた履歴をさかのぼる
入荷・注文・キャンセル・返品の反映タイミングを確認する
破損・廃棄・サンプル利用など販売以外の減少も記録する
複数店舗ではSKU対応と在庫同期を確認する
棚卸しでは差異理由まで記録する
差異が多いSKU・工程を優先して改善する
再発防止では担当・タイミング・記録方法を決める

ECの在庫差異とは？システム在庫と実在庫のズレ

在庫差異とは、ECカートや在庫管理システム上の数量と、倉庫や店舗で実際に存在する数量が一致していない状態です。

差異数量の基本

在庫差異＝実在庫 − システム在庫

たとえば管理画面では20個、実際には18個なら差異はマイナス2個です。

反対に管理画面では18個なのに実物が20個ある場合も在庫差異です。少ない場合だけを問題にするのではなく、増えている場合も原因を確認します。

在庫差異を放置すると起こること

状態	起こりやすい問題
システム在庫の方が多い	売り越し、注文キャンセル、出荷遅延
実在庫の方が多い	販売できる商品を販売停止してしまう
差異が頻発する	棚卸し・調査作業が増える
原価の高い商品で発生	在庫資産の把握へ影響する
複数店舗で発生	店舗間で二重販売・販売停止が起こる

「在庫差異ゼロ」だけを目的にしない

重要なのは、差異を見つけたときに原因を追跡でき、同じ原因を繰り返さないことです。数量を合わせる作業と原因改善を分けて考えます。

在庫差異が出たら最初に「どの商品が何個違うか」を確定する

差異を発見したら、いきなり管理画面の数量を変更するのではなく、対象を特定します。

SKU
商品名・バリエーション
保管場所
システム在庫
実在庫
差異数量
確認日時
確認担当者

もう一度数える

差異が見つかったときは、まず物理在庫を再確認します。

数え間違い、別棚への移動、返品商品の一時保管などによって、実際には差異がない場合もあります。

システム在庫を先に実在庫へ合わせない

履歴を確認する前に数値を上書きすると、どの工程でズレたのか追跡しにくくなります。差異を記録してから必要な修正を行います。

販売可能在庫と物理在庫も区別する

倉庫に存在している数量と、販売できる数量は同じとは限りません。

注文引当済み
検品待ち
返品確認中
破損品
サンプル
安全在庫として確保

などが含まれていないか確認します。

EC在庫が合わない7つの主な原因

在庫差異の主な原因と確認場所
原因	確認する場所
1．入荷ミス	仕入・納品・検品履歴
2．注文・出荷の減算ミス	注文・出荷・在庫履歴
3．キャンセル・返品	キャンセル・返品履歴
4．破損・廃棄・社内利用	在庫調整履歴
5．SKU・商品登録	商品マスタ
6．複数店舗・倉庫連携	連携・同期ログ
7．棚卸しミス	棚卸し記録・保管場所

原因1｜入荷数量・入荷計上が間違っている

最初に確認したいのが入荷です。納品書上の数量と実際に到着した数量が違う場合や、入荷処理を二重に行った場合は、その時点から在庫差異が残り続けます。

入荷時に確認すること

発注数量
納品書の数量
実際に受け取った数量
破損・不足数量
検品合格数量
システムへ登録した数量
登録したSKU
登録日時

発注数ではなく実際の入荷数を反映する

100個発注したから100個在庫へ追加するのではなく、実際に到着し、必要な検品を終えた販売可能数量を反映します。

分納にも注意する

100個発注して60個と40個に分かれて入荷する場合、最初の60個を100個として登録すると差異が生じます。

一部入荷・未入荷を区別できる運用にします。

原因2｜注文・出荷時の在庫減算タイミングが合っていない

ECでは、「いつ在庫を減らすか」がシステムによって異なります。

注文受付時
支払い確定時
出荷確定時

などがあります。

自社の在庫システムとECカートで減算タイミングが違うと、同じ注文を二重に減らしたり、反対に減算されなかったりする可能性があります。

確認する順番

対象SKUの注文を確認する

差異が発生した期間の注文数量を確認します。

在庫履歴を確認する

各注文に対応する在庫減算が記録されているか確認します。

連携システムも確認する

ECカート、OMS、WMSなど複数システムを使う場合、どこが在庫の基準値を持つか確認します。

「在庫の正本」を決める

複数システムがそれぞれ在庫数を更新すると原因追跡が難しくなります。どのシステムの数量を基準として各販売先へ配信するのか決めてください。

原因3｜キャンセル・返品時の在庫戻しが間違っている

注文時に在庫を減らせていても、その後のキャンセルや返品処理でズレることがあります。

キャンセル

注文キャンセル時は、システムが自動で在庫を戻すのか、担当者が手動で戻すのか確認します。

同じ注文について自動処理と手動処理を両方行えば、在庫が実際より増える可能性があります。

返品

返品では、商品が戻っただけで販売可能在庫へ戻さない方がよい場合があります。

商品本体に問題がない
付属品が揃っている
開封状態を確認した
破損・汚損がない
再販可能と判断した

返金完了と在庫戻しを混同しない

顧客への返金が完了していても、返品商品がまだ倉庫へ戻っていない場合があります。再販可能と確認できたタイミングで在庫を更新します。

原因4｜破損・廃棄・サンプル利用を記録していない

EC在庫は販売だけで減るわけではありません。

倉庫内破損
期限切れ
廃棄
撮影用サンプル
社内利用
展示用
仕入先への返品
紛失

などでも物理在庫は減ります。

担当者が商品を棚から取り出しただけでシステムを更新しなければ、管理画面には在庫が残り続けます。

在庫調整には「理由」を残す

単に「マイナス1」と変更するのではなく、破損・廃棄・棚卸し・サンプルなど理由を記録します。後で同じ原因が多発していないか集計できます。

原因5｜SKU・商品登録の紐付けが間違っている

在庫差異が特定のカラー・サイズだけで繰り返される場合は、SKU設定を確認します。

たとえば、

商品	正しいSKU例
白・M	TS-WH-M
白・L	TS-WH-L
黒・M	TS-BK-M

のように、在庫を別々に管理する単位を識別できる必要があります。

よくある登録ミス

2商品で同じSKUを使っている
モールと自社ECでSKUが異なる
カラー・サイズの紐付けが逆
旧商品と新商品を同じSKUで管理
セット商品の構成品が登録されていない

商品名で連携しない

商品名は変更される可能性があります。複数システムを連携する場合は、安定したSKUや商品コードで対応関係を管理します。

原因6｜複数店舗・倉庫間で在庫同期が遅れている

自社ECだけでなく、モール、実店舗、複数倉庫などで同じ在庫を販売すると、同期タイミングも差異原因になります。

たとえば自社ECで最後の1個が売れた後、モール側へ在庫0が反映されるまで時間がかかれば、その間にもう1件注文される可能性があります。

確認すること

在庫同期の頻度
同期失敗時の通知
API・CSV連携のエラー
SKU対応表
各店舗の注文取得頻度
キャンセル時の戻し先
倉庫移動中在庫の扱い

原因7｜棚卸し時に数え間違えている

システムに問題がなくても、棚卸しそのもののミスで差異が発生したように見える場合があります。

数え間違いが起こりやすい状態

同じSKUが複数の棚に置かれている
返品商品が別場所にある
検品待ち商品を含めている
箱数と個数を混同する
棚卸し中にも入出荷が動いている
似た商品を別SKUとして数える
担当者が数えた後に商品が移動する

差異が出たSKUだけ再カウントする

1回目の棚卸し結果だけで在庫を修正せず、差異が大きいSKUや重要SKUは再カウントしてから確定します。

全数棚卸しだけに頼らない

商品数が多い場合は、全商品を低頻度で確認するだけでなく、重要商品や差異が多い商品を定期的に部分棚卸しする方法もあります。

売上や金額への影響が大きい商品ほど確認頻度を高くします。

在庫差異の原因を調べる7つの手順

実在庫を再カウントする

別棚・返品・検品待ちなども確認し、実在庫を確定します。

差異数量を記録する

SKU、システム在庫、実在庫、差異、確認日時を残します。

最後に数量が一致していた時点を探す

前回棚卸しや入荷時など、基準となる時点を確認します。

入荷履歴を確認する

発注数量、受領数量、登録数量が一致しているか確認します。

注文・キャンセル・返品を確認する

在庫が増減した取引がすべて反映されているか照合します。

その他の在庫調整を確認する

破損、廃棄、サンプル、倉庫移動、手動修正を確認します。

原因を分類して再発防止策を決める

単発ミスか、同じ工程で繰り返される構造的な問題かを判断します。

最後の在庫数ではなく「変化」を追う

現在庫だけを見ても原因は分かりません。最後に在庫が合っていた時点から、入荷・販売・キャンセル・返品・調整の履歴を順番に追うと原因を絞りやすくなります。

在庫数を修正するときは「誰が・なぜ」を残す

原因を確認したら、必要に応じてシステム在庫を実在庫へ合わせます。

そのとき、最低限次を残します。

項目	記録内容
日付	修正した日時
SKU	対象の商品
修正前	システム在庫
実在庫	確認した数量
修正数量	増減数量
理由	棚卸し、破損、入力ミス等
担当者	修正した人
再発防止	必要な工程改善

Shopifyでは在庫数量の変更履歴として、誰が・いつ・どのように数量を変更したかを確認でき、棚卸し結果に合わせる「Count」などの調整理由も記録できます。

このような履歴を残せる場合は、単なる数値上書きではなく理由付きの在庫調整を使います。

原因不明を無理に埋めない

調査しても原因を特定できない場合は「原因不明」と記録します。推測で原因を選ぶと、後から原因別件数を分析したときに誤った改善へつながります。

在庫差異を再発させない7つの対策

対策1｜在庫が変わるタイミングを決める

入荷、注文、キャンセル、返品、廃棄など、どの時点でシステム在庫を変更するか決めます。

対策2｜在庫調整理由を必須にする

手動修正するときは、修正理由を残します。

原因分類の例は次です。

入荷差異
棚卸し
破損
廃棄
返品
サンプル利用
登録ミス
原因不明

対策3｜SKUを統一する

自社EC、モール、POS、倉庫システムで同じ商品を同じ管理単位へ対応付けます。

対策4｜返品商品を一時保留にする

返品された商品を即座に販売可能在庫へ戻さず、検品後に状態を確定します。

対策5｜差異が多いSKUを部分棚卸しする

全商品を同じ頻度で確認するのではなく、差異が発生しやすいSKUを優先します。

対策6｜連携エラーを確認できるようにする

自動連携は手作業を減らせますが、エラーへ気づけなければ大量の差異につながります。

同期失敗通知
最終同期時刻
エラーログ
未連携SKU
異常な在庫数

を確認できる状態にします。

対策7｜原因別件数を定期的に見る

在庫差異を記録したら、月次など自店で決めた期間で原因を集計します。

原因	件数	次の改善例
入荷ミス	集計	検品・入力方法を見直す
返品戻し	集計	返品工程を見直す
破損・廃棄	集計	調整ルールを統一する
連携エラー	集計	同期・通知設定を確認する
原因不明	集計	履歴取得方法を改善する

棚卸し回数を増やす前に原因を見る

入荷入力ミスが主原因なのに棚卸しだけ増やしても、差異は繰り返されます。最も多い原因の工程から改善してください。

棚卸しは在庫差異の影響が大きいSKUから優先する

商品数が増えると、全商品を高頻度で数えるのは負担になります。

次のようなSKUは確認優先度を上げます。

販売数が多い
在庫が少ない
高単価
差異が繰り返される
返品が多い
セット商品の構成品
複数販売チャネルで共有している
破損・紛失リスクが高い

「全商品を同じ頻度」でなくてよい

Squareでも、全商品を確認するフルカウントと、一部商品を定期的に確認するサイクルカウントが区別されています。自店でも重要度や差異リスクに応じて確認頻度を変える考え方が使えます。

在庫差異対策で確認するKPI

在庫差異対策では、「棚卸しが終わったか」だけではなく、差異そのものが減っているか確認します。

KPI	確認すること
差異SKU数	ズレが発生する商品が減ったか
差異数量	ズレの規模が縮小したか
差異金額	金額面の影響が減ったか
原因別件数	どの工程で多く発生しているか
原因不明率	履歴から原因を追跡できているか
売り越し件数	差異による注文トラブルが減ったか
手動修正件数	在庫調整作業が減ったか
調査時間	差異発生後の確認負担が減ったか

差異率だけで判断しない

低単価SKUの1個と高単価SKUの1個では事業への影響が異なります。数量だけでなく差異金額、売り越し、作業時間も確認してください。

EC在庫差異チェックリスト

対象SKUを特定した
保管場所を確認した
実在庫を再カウントした
販売可能在庫と物理在庫を区別した
差異数量を記録した
前回在庫が一致した時点を確認した
入荷数量を確認した
入荷登録数量を確認した
注文による減算を確認した
キャンセル時の戻しを確認した
返品商品の状態を確認した
破損・廃棄を確認した
サンプル・社内利用を確認した
SKUの紐付けを確認した
複数店舗の在庫同期を確認した
倉庫間移動を確認した
在庫調整履歴を確認した
差異原因を分類した
修正担当者を記録した
再発防止策を決めた
差異が多いSKUを次回棚卸し対象にした

EC在庫差異に関するFAQ

Q. ECの在庫数と実在庫が合わない場合、最初に何をしますか？

まず対象SKUの実在庫を再カウントします。その後、システム在庫との差を記録し、前回一致していた時点から入荷、注文、キャンセル、返品、在庫調整履歴を確認します。

Q. 在庫差異が出たらすぐ管理画面の数量を修正してよいですか？

販売への影響を防ぐため数量修正が必要な場合はありますが、修正前に差異数量と確認日時を記録してください。可能であれば履歴を確認し、調整理由も残します。

Q. 在庫差異の主な原因は何ですか？

入荷登録、注文時の減算、キャンセル・返品、破損・廃棄、SKU設定、複数チャネル連携、棚卸しなどが主な確認対象です。どの原因が多いかは店舗ごとに異なります。

Q. 棚卸しは何回行えばよいですか？

すべてのECに共通する回数はありません。高単価、販売数が多い、差異が繰り返されるなど影響の大きいSKUは頻度を上げ、低リスク商品とは分けて管理します。

Q. 自動在庫連携を使えば在庫差異はなくなりますか？

自動化によって手入力ミスを減らせますが、SKU紐付け、同期エラー、返品・破損処理など別の原因は残ります。自動化後もエラー通知や棚卸しは必要です。

Q. 返品商品はすぐ在庫へ戻してよいですか？

商品が実際に戻り、再販可能と確認できてから販売可能在庫へ戻す方が安全です。返金処理が完了したことと、商品が再販可能になったことは分けて管理します。

Q. 原因が分からない在庫差異はどう記録しますか？

推測で原因を決めず、「原因不明」と記録します。原因不明が多い場合は、在庫履歴、担当者、調整理由など、原因を追跡するための記録方法そのものを改善します。

まとめ｜EC在庫差異は数量を合わせるだけでなく原因まで記録する

システム在庫と実在庫が合わない場合は、数量を修正するだけではなく、どの工程でズレたのか確認することが重要です。

在庫が合わない7つの主な原因

入荷数量・計上ミス
注文・出荷時の減算ミス
キャンセル・返品の戻しミス
破損・廃棄・社内利用の未記録
SKU・商品登録の間違い
複数店舗・倉庫の同期ズレ
棚卸し・数え間違い

差異を発見したら、実在庫を再確認し、最後に在庫が一致していた時点から入荷・販売・キャンセル・返品・調整履歴をさかのぼります。

そして修正時には「誰が・いつ・なぜ変更したか」を残してください。原因別に件数を集計すれば、棚卸しを増やすべきなのか、入荷工程を改善すべきなのか、在庫同期を見直すべきなのか判断しやすくなります。

参考にした公式情報

在庫の状態、調整理由、変更履歴、棚卸し機能は利用するECカート・POS・在庫管理システムによって異なります。実際の運用時は利用サービスの最新仕様を確認してください。

まず差異が出たSKUを1商品だけ追跡する

システム在庫と実在庫の差を記録し、最後に一致していた時点から入荷・注文・キャンセル・返品・在庫調整を順番に確認してください。原因が分かったら、数量修正だけでなく同じ工程の再発防止まで行います。

在庫差異を調べる7手順を見る