受発注在庫管理システムとは？受発注と在庫を連携する仕組みと発注点の計算、選び方

受発注在庫管理システムは、受注・発注・入荷という3つの伝票を1つの在庫データで結び、受注が入れば在庫を引き当て、在庫が減れば発注を提案し、入荷すれば待っている受注へ在庫を回す仕組みです。受注管理と発注システムと在庫管理システムを別々に使っていても業務は回りますが、つなぎ目の転記や同期の遅れで在庫数がずれます。この記事では、つなぎ目で動く数量の定義、発注点を正しく判定する計算、連携方式ごとに在庫が反映されるタイミングの違い、取引先とのデータ接続、導入形態の選び方を順に説明します。

まとめ：受発注在庫管理システムで押さえる3つの判断

受発注在庫管理システムの価値は、受注・発注・入荷のつなぎ目で在庫の数が食い違わないことです。機能の一覧より先に、次の3点を確かめてください。

• 発注の判定に使う在庫：棚にある数ではなく「手持在庫－引当済＋発注残－未引当の受注残」（在庫ポジション）で発注点と比べているか。発注残を数えない設定のまま提案を毎日確定すると、入荷を待つ間に同じ品目を重ねて発注します。
• 在庫が反映されるタイミング：受注・入荷の登録と同時に在庫が動く一体型か、API・CSVで後から同期する連携型か。連携型は、販売側で在庫を減らす・在庫切れで販売を止めるといった設定がないと、同期の間隔のあいだに在庫のない注文を受けるおそれがあります。
• 導入形態：引当や発注のルールが標準的ならクラウドの一体型か既存システムのAPI連携で足ります。基幹システムとの双方向の在庫同期や、独自の単位・ロットでの引当が要り、それを候補製品の標準機能・設定・連携機能で実現できないときに受託開発を検討します。

受発注在庫管理システムの役割と単体システムとの違い

受発注在庫管理システムは製品カテゴリの名前というより、受注管理・発注（購買）管理・在庫管理を同じ在庫データの上で動かしている状態を指す言葉です。単体システムとの違いは、在庫数を誰が書き換えるかにあります。

単体を3つ並べた運用でも、APIで随時つないでいれば在庫はほぼ同じように動きます。問題になるのは、つなぎ目が人の転記（受注表の数を在庫表へ、在庫表の不足を発注表へ）や夜間のCSV取り込みに限られる場合です。在庫数を書き換える経路が複数あるため、どこかで1回漏れると以降の数がずれ続けます。受発注在庫管理システムでは書き換えの経路が伝票の登録1本になり、在庫数は伝票から計算される結果になります。受発注業務そのものの範囲は受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準、在庫を記録する側の仕組みは在庫管理システムとは？入出庫管理と引当の仕組み・機能・種類・費用と選び方で扱っています。

受注から入荷までのつなぎ目で動く在庫の数量

受発注と在庫の連携は、伝票が1枚登録されるたびに、どの数量が増減するかで説明できます。まず数量の名前をそろえます。この記事でいう「未引当の受注残」は、未出荷の受注全体ではなく、在庫不足で引き当てられていない分だけです（引当済の分は引当済に含めるため、両方を引くと二重に差し引くことになります）。表は検品待ち・破損・期限切れなど販売に使えない在庫を手持在庫に含めない単純化したモデルで、実運用ではそれらも有効在庫から除きます。検品・入庫・引当をどの時点で計上するかは製品の仕様で確かめてください。

受注・発注・入荷の伝票ごとに増減する数量

伝票ごとの動きは次のとおりです（引当は棚にある現物に対して行う前提）。受注を確定すると、有効在庫の範囲で引当済が増え、足りない分は未引当の受注残になります。発注を確定すると発注残が増えます。入荷を検品して登録すると、手持在庫が増え、発注残が同じ数だけ減ります。出荷すると手持在庫と引当済が同時に減り、有効在庫は変わりません。

数がずれる原因の多くは、この増減のどれかが別の画面や別のシステムに分かれていることです。入荷を在庫管理システムに登録しても発注システム側の発注残を消し込まなければ、在庫ポジションは実際より多く見えます。

入荷した在庫を受注残へ先に回す引当の順序

在庫不足で受注残が出ている品目に入荷があったとき、その在庫を待っている受注へ先に引き当てるかどうかは、製品ごとに挙動が違います。入荷登録と同時に受注残へ自動で引き当てる製品もあれば、担当者が引当処理を手で実行するまで有効在庫として残す製品もあります。後者で引当処理より先に新しい受注が入ると、後から来た注文が在庫を取ります。たとえば未引当の受注残30個の品目に40個が入荷し、引当処理の前に新しい受注20個が入ると、新しい受注に20個が先に引き当たり、待っていた30個には残りの20個しか回らず、10個が受注残のまま次の入荷を待つことになります。引当の対象も製品で違い、Microsoft Dynamics 365 Supply Chain Managementの解説では、受注明細の作成時に自動で引き当てるか手動で引き当てるかを選べ、棚にある在庫だけでなく発注済みで未入荷の在庫にも引き当てられるとしています。入荷予定に引き当てる製品では、在庫ポジションの式を製品の数え方に合わせて読み替えます。

受注残を古い順に引き当てるのか、取引先の優先度や納期で並べ替えるのかは、商習慣で決まります。業界の取引慣行で特定の得意先を優先する必要があるなら、引当順序を設定で変えられるかを選定時に確認してください。受注残そのものの扱いはバックオーダー（B/O）とは？意味と受注残との違い・車の部品で長引く理由で説明しています。

発注点を在庫ポジションで判定する計算と二重発注の防ぎ方

発注点方式は、在庫があらかじめ決めた量まで減ったら一定量を発注する方式です（発注方式の比較は在庫管理とは？JIS定義でみる目的・発注方式・業務フローと指標の決め方）。受発注在庫管理システムに発注点を任せるとき、計算式そのものより、発注点と比べる在庫の数を何にしているかで結果が変わります。

発注点と安全在庫の計算例

発注点は「1日の平均出荷量×調達期間（リードタイム）＋安全在庫」で求めるのが一般的です。安全在庫は、出荷のばらつきに備える上乗せ分で、「安全係数×1日の出荷量の標準偏差×√調達期間」で見積もります。この式は、調達期間が毎回同じで、日々の出荷が互いに独立に正規分布でばらつく、という前提で成り立ちます。調達期間そのものが遅れて振れる品目では、その振れも安全在庫に足す必要があります。安全係数は欠品をどこまで許すかで決まり、約1.65は「発注してから入荷するまでの1回の補充サイクルで在庫切れになる確率を5%に抑える」水準にあたります（欠品する数量の割合を5%にする、という意味ではありません）。

1日平均20個出荷し、日々の出荷の標準偏差が6個、発注から入荷まで5日かかる品目で計算します。

• 安全在庫＝1.65×6×√5＝22.1 → 切り上げて23個
• 発注点＝20×5＋23＝123個

平均出荷量と標準偏差は、定期的に計算し直す前提の数字です。欠品で出荷できなかった日の出荷量は実際の需要より少なく出るので、そのまま使うと平均を小さく見積もり、標準偏差と安全在庫も実際の需要のばらつきとずれた値になります。欠品があった期間は、出荷ではなく受注の数で補ってから計算します。季節で出荷が大きく動く品目では、通年の平均で決めた発注点は繁忙期に欠品し、閑散期に余ります。

有効在庫だけで判定すると二重発注になる理由

上の品目で、手持在庫150個・引当済40個のときに判定すると、有効在庫は110個で発注点123個を下回るため、200個の発注を提案します。ここで発注を確定したとします。

翌日、出荷が進んで手持在庫130個・引当済20個になっても、有効在庫は110個のままです。発注点と有効在庫だけを比べる設定では、翌日も「発注点割れ」と判定され、入荷を待っている200個とは別に再び200個を提案します。入荷までの5日間、担当者が毎日提案を確定すれば、必要量の数倍を発注することになります。

在庫ポジションで判定すれば、この問題は起きません。翌日の在庫ポジションは、未引当の受注残がなければ有効在庫110個＋発注残200個＝310個で、発注点123個を上回るので提案は出ません。製品のデモでは、発注を確定した翌日に同じ品目が再提案されないかを、実際に1品目で試してください。

分納とキャンセルで在庫ポジションがずれる場面

発注200個のうち120個だけが先に届く分納では、残りの80個を発注残として残す必要があります。入荷1回で発注伝票を完了扱いにする製品では、残り80個が発注残から消え、在庫ポジションが80個少なく計算されて、余分な発注提案が出ます。

受注のキャンセルでも同じことが起きます。キャンセル時に引当を解除しない運用だと、有効在庫が減ったまま戻らず、在庫ポジションが少なく見えて、発注点割れの提案が出続けます。分納とキャンセルは、受発注と在庫をつなぐときに最初に確かめたい異常系です。

連携方式ごとの在庫が反映されるタイミングと起きる事故

受発注と在庫をつなぐ方式は、1つの製品で全部持つ一体型、別々のシステムをAPIで随時つなぐ方式、CSVやEDIのファイルを決まった間隔で取り込む方式の3つに分かれます。違いは、在庫が反映されるまでの遅れと、その遅れで起きる事故です。

CSV・EDIの取り込み間隔と売り越しの量

定期取り込みでは、販売側に在庫切れで受注を止める仕組みがないと、在庫が尽きてから次の取り込みまでの間も、在庫があるものとして注文を受けます。売り越す量の目安は「1時間あたりに受ける数量×在庫が尽きてから次の取り込みまでの時間」です。1日10時間の営業で240個売れる品目なら、注文が均等に入ると仮定して1時間あたり24個です。取り込みの直後に在庫が尽きた場合、1時間ごとの取り込みなら約24個、1日1回の夜間取り込みなら営業が終わるまでの残り時間ぶん（朝に尽きれば約240個）を在庫なしで受ける計算になります。注文が特定の時間に集中する品目では、これより多くなります。

売れ行きの速い品目や在庫が少ない品目は、取り込み間隔を詰めるか、安全枠を差し引いた在庫数を販売側に出す設計にします。モールや自社ECの在庫をまとめる構成はEC在庫管理システムとは？多店舗の在庫連携・受注同期の機能と費用・選び方を解説で扱っています。

API連携の再送で在庫を二重に動かさない仕組み

API連携の反映の速さは、呼び出しの間隔と、伝票の登録ごとに即時送るか一定間隔でまとめて送るかで決まります。どちらでも、通信が途切れたときの扱いを決めておかないと数がずれます。送信側が応答を受け取れずに同じ入荷データを再送し、受信側がそれを2件目として処理すると、在庫が2回加算されます。これを防ぐには、論理的に同じ1件の処理に重複判定用のキー（冪等キー）を1つ付け、再送するときも同じキーを使い、受信側は同じキーの2回目に1回目の結果を返して処理を繰り返さない仕組みが要ります。決済APIのStripeの仕様も、接続エラー時に同じキーで再送すれば二重に作成・更新されないという設計です。伝票番号だけをキーにすると、同じ伝票の数量訂正や分納の2回目の入荷まで「重複」として捨ててしまうため、再送と更新を区別できる仕様かを連携仕様で確認してください。

逆に、送信に失敗したデータを再送しない実装では在庫の動きが抜け落ちるので、送信の失敗を一覧で確認し再送できる管理画面があるかも見ておきます。

取引先とつなぐ受発注データの入口と法令の確認点

社内で受発注と在庫をつないでも、取引先からの注文がFAXや電話のままなら、注文が届いてから担当者が受注を登録するまで在庫は動きません。取引先とのデータの入口で、在庫の数がどれだけ新しいかが決まります。

FAX・Web受発注・EDIで変わる在庫の反映

FAXの注文が多い取引先が残るなら、その分だけ在庫の反映が遅れる前提で、販売側に出す在庫数に余裕を持たせます。取引先にWeb受発注へ移ってもらう進め方は受発注システムを取引先に展開する方法｜ID設計と移行率の上げ方で扱っています。

ISDN回線を使う従来型のEDIには期限があります。NTT西日本の案内では、INSネットは「切替後のINSネット上のデータ通信（補完策）」を含めて2028年12月31日に提供を終了します。EDIを更新する時期に合わせて在庫連携の方式も見直すと、取引先との仕様確認と接続テストを1つの計画にまとめられます。

取適法の発注内容の明示と電子帳簿保存法の保存要件

2026年1月1日に施行された中小受託取引適正化法（取適法・旧下請法）の第4条第1項は、製造委託等をした委託事業者に、給付の内容、代金の額、支払期日、支払方法などを直ちに「書面又は電磁的方法」で明示するよう求めています。旧下請法では電磁的方法で交付するのに相手の承諾が必要でしたが、取適法の条文に承諾の要件はありません。一方で第4条第2項により、電磁的方法で明示した後に受託側から書面を求められたら、原則として遅滞なく交付しなければなりません（受託側の保護に支障がない場合として公正取引委員会規則が定める場合を除く）。対象となる取引で受発注システムの注文データを明示に使うなら、これらの事項が注文データに載っているかを確かめてください。

受発注データは電子帳簿保存法の電子取引にもあたります。国税庁のリーフレットは、注文書・見積書・請求書などに相当するデータをメール・EDI・クラウド等で授受した場合に電子での保存を義務付けています。保存の要件は2つです。真実性は、タイムスタンプ付きのデータを受け取るか受領後速やかに付与する、訂正・削除の履歴が残る（または訂正・削除できない）システムで授受・保存する、改ざん防止の事務処理規程を策定して運用・備え付ける、のいずれかの措置で確保します。可視性は、ディスプレイやプリンタ等を備え付けたうえで「日付・金額・取引先」で検索できることが求められ、さらに範囲指定・組み合わせ検索ができるか、税務調査の際にデータのダウンロードの求めに応じられることのどちらかが必要です（基準期間の売上高が5,000万円以下の事業者などは、ダウンロードに応じられれば検索要件は不要）。製品を比べる前に、自社が真実性をどの措置で満たすか、検索要件の免除にあたるかを決めておき、それに必要な機能（訂正・削除の履歴、範囲指定の検索、データのダウンロードなど）を比較の項目にします。

一体型・API連携・ERP・受託開発の選び方

導入形態は、受発注と在庫を1つの製品で持つか、既存のシステムをつなぐかで4つに分かれます。費用の相場は受発注システム開発の費用相場は？スクラッチ・クラウドの内訳と外注依頼先の選び方と販売管理システムの費用相場：クラウド・パッケージ・受託の初期費用と月額、5年総額の試算【2026年】で試算しているので、ここでは向き不向きの条件だけを示します。

ソフトウェアの導入費には、旧IT導入補助金の「デジタル化・AI導入補助金2026」が使える場合があります。通常枠の公募要領では、補助率は原則1/2以内（最低賃金近傍の事業者などは2/3以内の特例あり）、補助額は5万円〜150万円未満（業務プロセス1つ以上）と150万円〜450万円以下（4つ以上）の2段階で、プロセスの1つに「供給・在庫・物流」があります。対象は事務局に登録済みのITツールに限られ、交付決定前に契約・発注した分は補助されないため、製品を決める前に登録の有無を確認してください。

標準製品で足りる条件

次の3つがそろうなら、受託開発は過剰です。引当は先着順か納期順で足り、発注は発注点か定期発注の標準的な方式で回る。販売チャネルが1つか、楽天市場・Amazon・Yahoo!ショッピングなど製品が標準で接続できる先に限られる。取引先とのやり取りがWeb受発注か、流通BMSのような業界標準のEDIで済む。この条件で独自開発をすると、製品の月額で済む機能に開発費を払うことになります。

受託開発を選ぶ条件と、避けたい失敗

反対に、ケース・ボール・バラの入数換算で引き当てる、ロットや賞味期限を指定して引き当てる、生産管理や既存の基幹システムと在庫を双方向でリアルタイムに同期する、といった要件は、まず候補製品の標準機能と設定で表現できるかを確かめます。入数換算やロット・期限の引当は既製品にもある機能なので、自社の換算規則や引当の優先順位が設定項目で表せない、基幹システムとの双方向同期に製品の連携機能が対応しない、と分かった時点で受託開発を検討します。こうした在庫連動の作り込みは、在庫管理システム開発として相談を受けています。

避けたいのは、標準製品に独自要件を詰め込めずに、はみ出した部分を担当者のExcelと手作業で埋める形です。発注提案を毎回手で直す、受注残の引当を毎朝手で回す、という作業が残るなら、システムを入れても在庫のずれの原因は残っています。製品の比較軸は受発注システムの比較｜4タイプの選定軸と2028年の期限から逆算する判断でも整理しています。

導入前に試すつなぎ目の異常系テスト

製品のデモや無料期間では、正常な受注・発注・入荷・出荷を一巡させたうえで、つなぎ目の異常系を試します。自社の品目を数件登録して、次のケースを確かめてください。

このうち同時受注の取り合いは、データベースの更新の書き方で決まる問題です。仕組みと確認の仕方は在庫管理システムの記事で実行例つきで説明しています。全品目・全チャネルを初日からつなぐより、主力の品目と主要な販売チャネルで連携を動かし、上の結果を確かめてから広げるほうが、設定の誤りが全体に広がりません。ベンダーの導入事例を比べるときの読み方は受発注管理システムの導入事例の読み方｜効果指標の前提条件と自社での再現判定にまとめています。

よくある質問

受発注システムと在庫管理システムは別々に導入してもよいですか？

別々でも運用できます。その場合は、入荷の登録で発注残が消し込まれるか、受注のキャンセルで引当が戻るかなど、システムをまたぐ数量の受け渡しが自動で行われるかを確認してください。

受注高と受注残高の違いは何ですか？

受注高は、一定の期間に新しく受けた注文の金額（または数量）の合計です。受注残高は、受注したもののまだ出荷・売上計上していない注文の残りで、ある時点の残高として表します。在庫の観点では、受注残高のうち在庫が引き当たっていない分が、入荷を待つ受注残にあたります。

ERPの受発注・在庫管理と何が違いますか？

ERPは販売・購買・在庫に会計や生産管理まで加えた全社のデータを1つにまとめる製品で、受発注在庫管理はその一部です。在庫の動きをそのまま仕訳や原価計算につなげたいならERP、受発注と在庫のずれだけを早く直したいなら受発注在庫管理システムか既存システムの連携が向きます。

発注点を割ったら自動で発注まで任せてよいですか？

判定に在庫ポジション（有効在庫＋発注残－未引当の受注残）を使い、分納とキャンセルで数が正しく動くことを確かめるまでは、自動で発注せず提案にとどめるのが安全です。確かめた後も、出荷が季節で大きく動く品目は、平均出荷量と安全在庫を定期的に計算し直さないと過不足が出ます。

受発注システムをSaaSで始めるとき、在庫連携で何を確かめればよいですか？

在庫が伝票の登録と同時に動くか、API・CSVの同期を待つかを最初に確かめ、同期型なら間隔と再送・重複の扱いを連携仕様で確認します。そのうえで上の異常系テストの7項目を無料期間に試してください。

関連記事

• 受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準
• 在庫管理システムとは？入出庫管理と引当の仕組み・機能・種類・費用と選び方
• 発注システムとは？機能・メリットと購買・仕入業務を効率化する選び方
• EC在庫管理システムとは？多店舗の在庫連携・受注同期の機能と費用・選び方を解説
• 受発注システムの比較｜4タイプの選定軸と2028年の期限から逆算する判断