受注管理システムで欠品が起きる原因は？引当の仕組みと方式の見直し方を解説

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

B2B EC-COLUMN

「受注は取れたのに欠品」が起きる仕組みと引当の定義

受注データは問題なく取り込めているのに、倉庫から「この商品は在庫がありません」と連絡が返ってくる。
お詫びと代替品の案内に追われて、なぜそうなったのかを確かめる時間が取れない、という状況ではないでしょうか。
受注成立後の欠品は、担当者の確認漏れよりも、在庫数がシステム間を伝わるまでのわずかな時間差と、どの時点で在庫を確保するかという引当の設計から生まれます。
引当は注文に対して手持ちの在庫や入荷予定分を確保する処理で、いつ実行するか（即時・タイムリー・バッチ）と、システム同士をどう繋ぐか（API・ファイル・ミドルウェア）の組み合わせによって、欠品の起きやすさが変わります。
自社では在庫がどの時点で確定しているのかを見極めるところが、対策の出発点です。

「引当」とは何を確定させる処理か

まず、注文を受け付けた時点では在庫はまだ押さえられていない、という前提を確認しておきます。
在庫引当とは、いま保有している在庫や今後入荷予定の在庫のうち、特定の注文に対応する分を「確保」する処理を指します²。
確保するというのは在庫を出庫して減らすことではなく、その注文のために取り置き、ほかの注文には割り当てないようにすることです。

この違いが、欠品が起きたときの感覚のズレにつながります。
受注管理システムの画面で注文が受注済になっていても、それは顧客との取引が成立したという意味であって、倉庫の棚にある一点がその注文のために確保されたという意味とは限りません。
受注の成立と在庫の確保は、システムの中では別々の処理として動いています。

また、引当の対象は手元にある実在庫だけとは限らず、今後入荷予定の在庫も含まれます²。
入荷予定分まで引当の対象にできるかどうかは使っているシステムの仕様によりますが、予約販売や取り寄せ販売を扱うときは、この点が受注可能数の考え方を左右します。

未引当・中途引当・引当済で見る受注ステータスの流れ

在庫が実際に確保されるまでの道のりは、受注ステータスの遷移として表されます。
受注管理システムの一般的なステータス設計では、未引当から中途引当、引当済、出荷指示済、出荷済へと進み、引当済は倉庫への出荷指示を通じて実際に在庫が確保された状態を指します⁵。
言い換えれば、引当済に到達するまでの区間は、在庫がまだ確定していない状態です。

欠品が表面化するのは、たいていこの区間です。
受注は取り込めているのに引当済へ進めない注文があり、その理由が在庫不足だったという順序で発覚します。
何らかの理由で在庫を引き当てられなかった注文は中途引当というステータスにまとめられ、在庫調整や顧客との協議が必要な注文として扱われます⁵。

ステータスの名前や粒度は製品によって異なりますし、生産管理の分野では同じ処理を別の言葉で呼ぶこともあります。
ただ、注文に対して在庫を確保するという処理の中身は共通しているので、自社のシステムではどの状態が「在庫が押さえられた」に当たるのかを一度確かめておくと、欠品の原因を切り分けやすくなります。

出典：Commerble「受注後のステータスフロー」／受注管理システムの一般的なステータス設計

なぜ受注成立後に欠品が起きるのか、主な原因

需要側・発注側・データ側の3つの原因ルート

欠品の原因は、引当の設定だけを見ていても全体像がつかめません。
EC・物流の実務では、欠品は需要側、発注側、データ側という3つのルートで起きると整理されています⁶。
需要側はセールやメディア露出による需要の急増、発注側は発注判断の遅れや仕入先の納期遅延、データ側は実在庫と帳簿在庫のズレや複数モール間の在庫連携タイムラグです⁶。

この3つは、受注担当者が手を打てる範囲が違います。
需要の急増そのものは受注側では止められませんし、仕入先の納期遅延も受注管理システムの設定では解決できません。
一方でデータ側のズレは、引当のタイミングと在庫連携の設計を変えることで縮められる部分です。

発注側については、補充の判断基準を数式に落としておく方法があります。
発注点は「1日あたり平均出荷数×調達リードタイム（日数）＋安全在庫」で算出し、安全在庫は需要のばらつきとリードタイムの変動を吸収するバッファとして置く考え方です⁶。
いま欠品対応に追われている商品が、そもそも補充の設計で足りていないのか、それとも在庫はあるのに引き当てられていないのかを分けて見ると、直すべき場所が変わります。

在庫連携をしていても数分単位のタイムラグは残る

在庫連携ツールを入れているのに欠品が減らない、という感覚はここに関係します。
あるサービスでは、モール・カートへの在庫情報の更新は、システム側で在庫変動があったタイミングから約10分程度の間隔で行われると案内されています¹。
この間隔は特定の製品の仕様で、すべての在庫連携ツールが同じ間隔というわけではありませんが、外部のチャネルへ在庫を伝えている以上は何らかの反映時間が存在する、という点は共通します。

反映までの時間が欠品にどう効くのかを、残り1点の商品で考えてみます。
Aのモールで1点売れて在庫が0になっても、Bのモールの商品ページに0が反映されるまでには間隔があります。
その間にBのモールで注文が入れば、受注は2件成立し、引き当てられるのは1件だけという状態になります。
反映の間隔がそのまま、売り越しが起こりうる窓の長さになるという理屈です。

さらに、連携が正しく動いていても、仕入れ遅延や返品処理、キャンセル対応といった予期しないイベントが起きるとデータにはズレが生じます⁴。
返品された商品をいつ販売可能な在庫として戻すか、キャンセルされた注文の引当をいつ解放するかは、システムの自動処理だけでは決まらず、運用の取り決めに依存する部分が残ります。

ここまでを踏まえると、欠品対策は「在庫の数字を速く正しく伝えること」と「在庫をいつ確保するか」の二つに分けて考えられます。
後者が、引当のタイミングという話です。

出典：株式会社KEYCREW（STOCKCREW）「欠品とは？EC・物流で欠品が起きる原因と影響・防止策」／EC発送代行事業者の実務知見に基づく整理

引当のタイミング方式（即時・タイムリー・バッチ）と欠品リスクの違い

即時引当・タイムリー引当・バッチ引当の違い

引当をいつ実行するかには、受注確定時点で即座に確保する即時引当、出荷や生産の直前に確保するタイムリー引当、MRPと連動して定期処理するバッチ引当という3つのタイミングがあります²。
MRPは資材所要量計画のことで、この分類はもともと生産計画・供給計画システムの文脈で説明されているものです。
ECの受注管理でも、在庫をいつ押さえるかという考え方はそのまま当てはまりますが、自社のシステムでどのタイミングを選べるかは製品の仕様に左右されます。

3つの違いを一言でいえば、受注が成立した瞬間から在庫が確保されるまでの距離です。
即時引当はその距離がほぼゼロ、バッチ引当は次の処理タイミングまで空きます。
タイムリー引当はその中間で、出荷作業に取りかかる直前まで在庫を確定させません。

方式ごとの欠品リスクの傾向

距離が短いほど安全、と言い切れないところが判断の難しい点です。
即時引当では、受注と在庫確保の間に他の注文が割り込む余地が小さくなります。
ただし確保するというのは、その注文が取り消されるまでほかの注文に在庫を回さないということでもあります²。
入金待ちの注文や後でキャンセルされる注文も在庫を押さえ続けるため、販売できる在庫が見かけ上減り、別の顧客からの注文を取りこぼす場面が出てきます。

タイムリー引当は逆の性質を持ちます。
出荷の直前、実態に近い在庫の状態で確保するので、押さえたのに出荷できないという食い違いは起きにくくなります。
その一方で、在庫が足りないと分かるのが出荷直前になるため、顧客へ連絡できるタイミングが遅くなります。
納期を伝えたあとで欠品が判明する形になりやすく、この遅れは顧客対応の負担にそのまま跳ね返ります。

バッチ引当は、処理の間隔がそのまま在庫確定の遅れになります。
1日1回の処理なら、その日に入った注文はすべて次の処理まで未引当のままです。
まとめて処理するぶんシステムへの負荷は抑えられますが、受注から引当までの間に在庫が動く余地は3つの中で最も大きくなります。

もう一つ押さえておきたいのは、社内で引当が速いことと、販売チャネルの表示在庫が速く直ることは別だという点です。
受注管理システムの中で受注と同時に引き当てられていても、モールやカートの在庫数が更新されるまでに反映の間隔があれば¹、その間は在庫のない商品が売れてしまう状態が続きます。
引当のタイミングを見直すときは、社内で在庫を押さえる速さと、外部チャネルへ在庫を伝える速さを分けて確認すると、原因の切り分けがずれません。

複数チャネル・拠点で在庫を扱う場合の連携設計と方式の選び方

在庫更新ルール・在庫レベル・監視という3つの運用設計

複数のチャネルや拠点で在庫を扱うと、どのシステムの数字が正なのかが曖昧になりがちです。
ECサイトの制作・運用を手がける事業者からは、確実な在庫管理には、いつ・誰が在庫を更新するかを決める在庫更新ルール設計、在庫水準を段階で管理する在庫レベル別対応設計、ズレの発見から修正までを組み立てる監視と復旧プロセス設計の3つが必要だという提案が示されています⁴。
これは同社が実務から整理した枠組みで、業界で決まった標準手順ではありませんが、運用のどこに穴が空きやすいかを見る区切りとしては扱いやすいものです。

在庫更新ルールで問題になるのは、システムが自動で処理してくれない場面です。
実店舗との併売で店頭の在庫が動いたとき、拠点間で在庫を移動したとき、返品された商品を再び販売可能に戻すとき。
こうした場面で誰がいつ数字を直すのかが決まっていないと、連携の速度をいくら上げても、元になる数字が合いません。

在庫レベル別対応は、残数に応じて扱いを変える考え方です。
潤沢にある商品と残りわずかの商品を同じルールで販売していると、タイムラグの影響をまともに受けるのは常に残りわずかの商品側になります。
販売を止める残数の線をどこに引くか、その線を超えた商品を誰が見るかを決めておくと、欠品が起きうる場面を絞り込めます。

監視と復旧は、ズレが起きる前提で用意しておく仕組みです。
棚卸や日次の突き合わせで差異を見つけたあと、誰がどの順番で直すのかまで決めていないと、発見はできても在庫が合わない状態が続きます。

接続方式の違いが、選べる引当タイミングを決める

運用のルールを整えたうえで残るのが、システム同士をどう繋ぐかという技術的な選択です。
在庫連携には、APIで直接つなぐAPI連携、CSVやXMLを定期的に取り込むファイル連携、iPaaSやETLを介すミドルウェア連携の3方式があります³。
iPaaSはシステム間の連携をクラウド上で仲介する仕組み、ETLはデータを抜き出し、変換し、別のシステムへ格納する処理の総称です。

ここで重要なのは、接続方式が、選べる引当のタイミングを先に決めてしまうことです。
1日1回ファイルを取り込む構成のまま、受注と同時に最新の在庫を押さえる即時引当を成立させることはできません。
引当のタイミングだけを見直したのに欠品の出方が変わらないという場合、土台になっている接続方式が要件に追いついていない可能性があります。

方式の向き不向きは、SKU数、在庫の更新頻度、この先どれだけシステムが増えるかという観点で分かれます³。
自社の条件をこの3点で言葉にしておくと、方式ごとの特徴と突き合わせやすくなります。

出典：福岡ECサイト株式会社「商品数が多いネットショップで在庫連携システムを導入しても欠品が発生する理由と確実な在庫管理を実現する3つの設計とは」／同社が提案する運用設計フレーム（業界標準ではない）

欠品が発生した場合の受注側のシステム対応・顧客対応

中途引当になった注文の在庫調整と顧客連絡

引当の設計を見直しても、欠品がゼロになるわけではありません。
仕入れの遅れや返品処理のように、システムの外で起きる出来事はデータのズレとして残ります⁴。
だからこそ、欠品が判明した注文をどう扱うかをあらかじめ決めておくと、対応の質が安定します。

システム上の扱いとしては、引き当てられなかった注文を中途引当として分けて管理する方法があります⁵。
中途引当は在庫調整や顧客との協議が必要な注文をまとめた状態なので、まだ処理していない未引当の注文と混ざらずに済みます⁵。
未引当のまま放置すると、対応が必要な注文が新しく入ってくる注文の中に埋もれ、顧客への連絡が遅れる原因になります。

顧客への連絡は、在庫調整の見込みが立った時点で行うと話が一度で済みます。
入荷予定があるならいつ出荷できるのか、ないなら代替品か取り消しか、伝えられる選択肢を揃えてから連絡する形です。
この運用でキャンセルが減ると約束できるわけではありませんが、「確認して折り返します」という往復が減り、どの注文が顧客の返答待ちなのかを画面上で追える状態になります。

欠品時のステータス管理の考え方

ステータスを分ける目的は、注文が止まっている理由を後から見分けられるようにすることです。
同じ「出荷できていない注文」でも、まだ引当処理が走っていないのか、引当を試みて在庫が足りなかったのか、顧客の返答を待っているのかで、次に取る行動は違います。
この区別がステータスに入っていないと、一件ずつ経緯を確認し直すことになります。

見直しの効果を確かめるには、欠品の量を同じ定義で測り続ける必要があります。
欠品率は、欠品で出荷できなかった受注件数を総受注件数で割って100を掛ける方法と、欠品が発生したSKU数を総SKU数で割る方法があります⁶。
件数ベースは売上への影響を、SKUベースは品揃えの欠け具合を映すので、どちらで測るかを決めてから引当のタイミングや接続方式を変えると、前後の比較ができます。

欠品対応の記録は、原因の切り分けにも使えます。
同じ商品で繰り返し中途引当が発生しているなら補充の設計を、複数チャネルで同時に売れた直後に集中しているなら在庫の反映間隔を疑う、という具合に、次に見る場所を絞れます。

在庫をいつ押さえるかを決めたら、次は、それを支える接続方式をどう選ぶかです。

出典：Commerble「受注後のステータスフロー」で示された中途引当の扱いを基に、対応の順序として整理

欠品が起きている原因が、外部チャネルへの反映の間隔なのか、引当のタイミングなのか、在庫を更新する運用ルールなのかは、自社の受注の流れと使っているシステムの設定を突き合わせないと切り分けられないためです。

受注から出荷までのどの時点で在庫が確定しているか、どのチャネルの反映間隔が売り越しの窓になっているかを一緒に洗い出し、手を入れる順番を確かめられます。無料相談で要件を整理する

引当タイミング3方式（即時・タイムリー・バッチ）の特徴整理

受注が確定してから在庫を確保するまでにどれだけ間が空くかという、引当の実行タイミングで分けています。

• 即時引当：受注確定の時点で在庫を確保する。受注と確保の間が最も短いが、後で取り消される注文も在庫を押さえ続ける

• タイムリー引当：出荷・生産の直前に確保する。実態に近い在庫で確保できる反面、不足の判明が出荷直前になる

• バッチ引当：MRPと連動して定期処理する。処理の間隔ぶん在庫確定が遅れるが、まとめて処理するためシステムの負荷は抑えられる

この分類は生産計画・供給計画システムの文脈で説明されたものです。自社の受注管理システムで実際にどのタイミングを設定できるかは、製品の仕様を確認したうえで当てはめてください。

在庫連携方式別に見る、引当をどう繋ぐか

連携方式	向いている事業者の条件	引当の即時性	導入・運用の負担
API連携	SKU数が多く、複数チャネルで1日に何度も在庫が動く	受注確定と同時に引き当てられ、最も高い	実装・保守の工数が大きい
ファイル連携（CSV/XML）	更新頻度が低いBtoB向けEC、試験導入の段階	取り込みの間隔ぶんタイムラグが残る	既存システムに標準搭載され、導入しやすい
ミドルウェア連携（iPaaS/ETL）	将来的に連携するシステムが増える可能性がある	ハブ上でどう連携を組むかによって決まる	運用・ライセンス費用が発生する

API連携――受注と同時に在庫を押さえたい場合

受注確定と同時に在庫を確保できる

API連携は、受注管理システムと在庫を持つシステムを直接つなぎ、受注が確定したその時点で在庫を引き当てられる構成です³。
3方式の中では即時性が最も高く、即時引当を実現したい場合の前提になります。
そのかわり、実装と保守にかかる工数は大きくなります³。

工数が大きいというのは、つなぐときの開発だけの話ではありません。
接続先のシステムが仕様を変えたとき、通信が失敗したときの再送やエラーの扱いを決めておく必要があり、運用が始まってからも手当てが続きます。
間違えるとそのまま顧客対応に跳ね返る在庫データを扱うぶん、失敗したときにどう戻すかまで設計しておかないと、かえって不整合の原因になります。

向いている条件と、それでも残るタイムラグ

向いているのは、SKU数が多く、複数チャネルで1日に何度も在庫が動く事業者だとされています³。
目安としてSKU数1,000以上、更新頻度が1日に複数回という水準が挙げられていますが³、これは受託開発の実務経験に基づく見解で、業界で決まった閾値ではありません。
自社がこの水準に近いなら、更新の多さが工数に見合うかを考える材料になります。

注意したいのは、API連携にしても外部チャネルの表示在庫まで即座に直るとは限らないことです。
社内のシステム間で在庫を押さえる速さと、モールやカートへ在庫数を伝える速さは別の経路で、後者には反映の間隔があります¹。
API連携を選ぶ判断は、社内側の引当を確実にするための選択だと捉えておくと、期待とのズレが起きません。

ファイル連携――定期的な取り込みで足りる場合

導入のハードルは低く、間隔ぶんのズレが残る

ファイル連携は、CSVやXMLを定期的に取り込んで在庫を合わせる方式です³。
多くの既存システムに標準で備わっているため導入のハードルが低く、新しい開発を伴わずに始められます³。
ただし取り込みの間隔ぶんタイムラグが残り、売り越しのリスクが残ります³。

取り込みの間隔は、そのまま欠品が起こりうる窓の長さになります。
1日1回の取り込みなら、前回の取り込み以降に他のチャネルで売れた分は反映されていない在庫で販売していることになります。
引当のタイミングで言えばバッチ引当と組み合わせやすく、受注をまとめて処理する運用とは無理なく噛み合う構成です。

更新頻度が低い事業なら現実的な選択肢になる

向いているのは、更新頻度が低いBtoB向けのECや、まず小さく始めて確かめるPoCの段階だとされています³。
PoCは本格導入の前に行う試験的な検証のことです。
受注が特定の時間帯に集中し、日中ずっと在庫が動き続けるわけではない事業なら、タイムラグによる実害は小さく収まります。

逆に、同じ商品を複数チャネルで同時に売っていて在庫が一日中動く事業では、取り込みの合間に注文が重なる場面が増えます。
この構成を当面続けるなら、残数が少ない商品だけ早めに販売を止めるといった在庫レベル別の運用⁴と組み合わせて、窓の影響を受ける商品自体を減らす方向で補うことになります。

ミドルウェア連携――つなぎ先が増えていく場合

データハブを介して疎結合にする

ミドルウェア連携は、iPaaSやETLといった仲介の仕組みを間に置き、各システムをデータハブ経由でつなぐ方式です³。
システム同士が直接依存しない疎結合の構成になるため、どれか一つを入れ替えたときの影響を抑えられます³。
そのかわり、仲介する仕組みそのものに運用・ライセンスの費用が発生します³。

この費用は仲介基盤を維持するためのもので、払えば欠品が減るという性質のものではありません。
在庫がどの間隔でどちらの方向に流れるかは、ハブの上でどう連携を組むかで決まります。
つまりこの方式は、引当の速さそのものを買うというより、つなぎ替えのしやすさを確保する選択です。

将来つなぎ先が増える見込みがあるとき

向いているのは、将来的に連携するシステムが増える可能性がある企業だとされています³。
実店舗のPOS、新しい販売チャネル、倉庫の管理システムと、つなぐ先が増えるたびに個別の接続を作っていると、組み合わせの数だけ保守する対象が増えていきます。
ハブを一つ置く構成なら、増えるのはハブとの接続だけで済みます。

判断の分かれ目は、いま繋いでいる本数よりも、この先つなぎ先が増える見込みがあるかどうかです。
増える見込みがないなら仲介の費用は負担だけになりますし、増える見込みがあるなら、後から個別の接続をほどく手間を先回りで避けられます。
3方式のどれが優れているという順位はなく、SKU数・更新頻度・拡張の見込みという条件で向き先が変わる、という整理になります³。

要点の整理

軸	基準
引当とは何か	注文に対して実在庫や入荷予定在庫を確保する処理。受注の成立とは別の処理として動く
在庫が確定する位置	引当済（倉庫への出荷指示を通じて確保された状態）に至るまで在庫は確定していない
欠品の原因	需要側・発注側・データ側の3ルート。受注側の設計で縮められるのは主にデータ側
引当のタイミング	即時は確保が早い／タイムリーは実態に近い／バッチは間隔ぶん遅れる。早いほど安全とは限らない
接続方式の選択	SKU数・在庫の更新頻度・将来の拡張見込みで向き先が変わる。優劣の順位ではない
欠品発生時の扱い	中途引当として分けて管理し、在庫調整の見込みが立った時点で顧客へ連絡する

接続方式の選択には実装の工数と運用の費用、そして今後つなぎ先が増えるかどうかの見通しが絡み、自社の条件を言葉にしないと方式の比較が進まないためです。 SKU数・在庫の更新頻度・今後の拡張見込みを整理したうえで、即時引当まで必要なのか、運用ルールと在庫レベルの見直しで足りるのかを確認できます。

よくある質問

欠品が多い商品だけ、引当のタイミングを変えることはできますか

商品ごとに引当の条件を設定できるかどうかは、使っているシステムの仕様によります。
どの製品でもできるとは言えないため、まず自社のシステムで設定可能かを確認することになります。
設定できない場合でも、残数が少ない商品ほど販売を止める線を高めに置く在庫レベル別の運用⁴で補える場面があります。
その前に、その商品の欠品が補充不足によるものか、反映の間隔の中で売り越したものかを分けて確認しておくと、手を入れる場所を間違えずに済みます。

入荷前受注（予約販売）の場合、引当はどう扱えばよいですか

引当の対象には、いま保有している在庫だけでなく、今後入荷予定の在庫も含まれます²。
入荷予定分を引当の対象にできる設定であれば、予約された注文を入荷予定に紐づけて確保し、入荷後に実在庫へ置き換える流れになります。
ただし入荷が遅れれば顧客から見れば欠品と同じ結果になるため、仕入先の納期遅延は発注側の原因ルートとして別に見ておく必要があります⁶。
自社のシステムが入荷予定在庫を引当対象にできるかは、仕様の確認が前提です。

在庫連携ツールを導入すれば、欠品はゼロにできますか

ゼロにはなりません。
連携していても在庫情報の反映には間隔があり、あるサービスでは在庫変動から約10分程度の間隔で更新されると案内されています¹。
加えて、仕入れ遅延や返品処理、キャンセル対応など予期しないイベントが起きればデータにズレが生じます⁴。
ツールは売り越しが起こりうる窓を狭める手段であって、窓をなくす手段ではありません。
窓が残る前提で、欠品が判明したときの扱いを決めておくほうが現実的です。

中途引当になった注文は、必ずキャンセルするしかないのでしょうか

中途引当は、在庫調整や顧客との協議が必要な注文をまとめた状態であって、取り消しが確定した状態ではありません⁵。
入荷予定がある、他の拠点に在庫がある、分けて出荷することを受け入れてもらえるといった条件が揃えば、引当済へ進める道が残ります。
判断が分かれるのは顧客が待てるかどうかなので、いつ出荷できるかの見込みを先に固めてから連絡すると、取り消し以外の選択肢も提示できます。

引当の見直しで欠品が減ったかどうかは、どう確かめればよいですか

欠品率を同じ定義で測り続けるのが基本です。
欠品で出荷できなかった受注件数を総受注件数で割る方法と、欠品が発生したSKU数を総SKU数で割る方法があり⁶、前者は売上への影響、後者は品揃えの欠け具合を映します。
見直しの前後で定義を混ぜると比較にならないため、どちらで測るかを先に決めておきます。
あわせて中途引当が発生した件数と、それがどの場面で集中しているかを記録しておくと、残っている原因がデータ側なのか補充側なのかを見分けられます。

1. 1　出典：株式会社ネクストエンジン（Next Engine Developer Network）「在庫連携に関する質問回答」（2026年）
2. 2　出典：株式会社日立ソリューションズ東日本「『在庫引当』コラム（scSQUARE ISP 製品コラム）」（2026年）
3. 3　出典：株式会社ripla「ECサイトの在庫管理と基幹システム連携｜3方式の選び方と設計の実務ポイント」（2026年）
4. 4　出典：福岡ECサイト株式会社「商品数が多いネットショップで在庫連携システムを導入しても欠品が発生する理由と確実な在庫管理を実現する3つの設計とは」（2026年）
5. 5　出典：Commerble「受注後のステータスフロー（Commerble Docs）」（2026年）
6. 6　出典：株式会社KEYCREW（STOCKCREW）「欠品とは？EC・物流で欠品が起きる原因と影響・防止策｜欠品率の計算式・安全在庫・発注点の実務」（2026年）