Web受発注システムの在庫機能｜連携の仕組みと選び方

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

B2B EC-COLUMN

Web受発注システムの在庫機能とは

Web受発注システムの在庫機能とは、受注画面上で在庫状況を提示し、受注データと在庫データを結び付けて引当・出荷につなげる仕組みです。取引先は電話や電子メールで問い合わせることなく、発注の画面上で在庫の状況を確かめられます。ただし在庫数の反映には連携の方式に応じた時差が生じますので、画面の数値と倉庫の現物が常に一致する前提では設計できません。在庫の見せ方と引当の決まりを先に定めることが、導入後の齟齬を抑える出発点になります。

在庫機能が担う範囲は、在庫数の表示だけにとどまりません。取引先ごとに見せる数量を変える公開範囲の制御、受注と同時に数量を確保する<a href="/column/inventory-allocation/">在庫引当</a>、入荷予定日の提示、在庫が減ったときの通知までを含みます。在庫を管理する主体は<a href="/column/kikan-system-renkei/">基幹システムや倉庫システム</a>に置き、受発注の画面はその数値を受け取って見せる側に立ちます。どこまでを受発注側で持ち、どこからを基幹側に残すかの線引きが、要件定義の最初の論点になります。

在庫の数量には少なくとも3つの区分があり、混同すると受注可否の判断を誤ります。区分ごとの意味は次のとおりです。

<ul><li>実在庫は倉庫にある現物の数量で、棚卸の差異や入出庫の計上遅れを含みます。</li><li>引当可能在庫は、実在庫から受注済みの引当分を差し引いた数量で、取引先に見せる数量の基本になります。</li><li>入荷予定在庫は仕入先からの入荷が確定している数量で、欠品が起きた場面の納期回答に使えます。</li></ul>

電話やファクスによる在庫確認との違いは、回答までの経路の長さに表れます。電話での確認は、受注担当者が基幹システムを開いて数量を読み、口頭で伝え、取引先が発注書に書き写す流れをたどります。この経路では、伝達の途中で数量が変わっても取引先には伝わりません。受発注の画面に在庫を出す方式であれば、発注の直前に読んだ数値がそのまま受注データへ引き継がれますので、転記の誤りが入り込む余地は狭まります。

画面上の在庫が現物と完全に一致する状態は、実務では想定しにくいものです。では、時差はどこまで許容できるのでしょうか。夜間に1日1回だけ在庫を送る方式であれば、反映までに最大で24時間の時差が生じます。15分間隔で送る方式でも、送信の直後に出荷が発生すれば数量はずれます。時差をゼロにする発想ではなく、時差があっても受注が破綻しない見せ方と引当の決まりを用意する発想が求められます。

企業間取引の電子化は、年次の公的調査で追跡されています。経済産業省の『電子商取引に関する市場調査』は、令和6年度調査を2025年に公表しました。同調査によれば、企業間の電子商取引化率は4割を超えています¹。総務省の『通信利用動向調査』（令和6年、2025年公表）でも、クラウドサービスを利用する企業の割合は7割を超えました²。受発注の画面を社外の取引先に開くこと自体は、特別な取り組みではなくなりました。在庫機能の検討は、その延長線上にある実務の設計作業と位置づけられます。

受発注業務で在庫情報が問われる理由

取引先が在庫を問い合わせるのは、納期の見通しが立たないまま発注を確定できないからです。企業間の取引では、1回の発注が生産計画や店頭の陳列に直結しますので、在庫の有無が発注量そのものを左右します。在庫情報を受発注の画面に出す取り組みは、問い合わせ対応の削減だけを狙うものではありません。取引先の発注判断を早め、欠品と過剰在庫の双方を抑えることに主眼があります。

受注センターに1日30件の在庫確認が入る企業では、1件5分でも月に50時間近い対応時間が生まれます。中小企業庁の『中小企業白書』（2025年版）は、人手不足への対応を大きく取り上げました。同書では、業務の省力化とデジタル技術の活用が課題に挙がっています³。受注の窓口を人手だけで開け続ける運用は、要員の確保という面から見直しの対象になります。在庫の確認を画面に任せる取り組みは、その見直しの一部に当たります。

在庫確認の問い合わせは、1件あたりの時間が短くても件数が積み上がります。電話は相手の都合に関わらず着信し、受注の入力作業を中断させます。中断のたびに入力の途中経過を思い出す時間が生まれ、誤入力の芽にもなります。受注センターの繁忙は締め時間の直前に集中しますので、問い合わせの波と受注の波が重なる時間帯ができます。

欠品と過剰在庫は、どちらも取引関係に跡を残します。欠品が起きると、取引先は代替の仕入先を探し、次回以降の発注配分を見直します。緊急の補充出荷は小口かつ急送になりやすく、物流費の押し上げにつながります。公益社団法人日本ロジスティクスシステム協会の『物流コスト調査報告書』（2024年度版）によれば、売上高に占める物流コストの比率は5%台で推移しています⁴。緊急対応の積み重ねは、利益率にそのまま響いてきます。

在庫の見せ方を誤ったときの損失は、受注の取り消しだけにとどまりません。引当のない在庫数をそのまま公開すると、同じ数量に対して複数の取引先の受注が同時に成立します。出荷の段階で欠品が判明すれば、出荷指示の取り消し、納期の再調整、代替品の提案が連鎖します。1件の欠品が営業・受注・倉庫・配送の4つの持ち場に作業を発生させる点は、電話での確認との大きな違いです。

取引先の側から見ると、在庫が見える窓口の有無は発注先の選定条件になります。発注のたびに電話をかける手間と、画面で確かめてそのまま発注できる手軽さでは、担当者の負担が異なります。商品コードや発注単位が取引先ごとに違う場合、画面での確認は読み替えの誤りも減らします。窓口の使いやすさは、価格や納期と並ぶ取引の条件として扱われます。

在庫情報の提示は、営業活動の一部としても働きます。欠品の代わりに規格の近い商品を画面上で示せば、失注の一部は代替の受注に変わります。入荷予定日を添えれば、取引先は待つか他所から買うかを自分で決められます。判断の材料を先に渡す姿勢が、問い合わせの往復そのものを減らします。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。

在庫にかかわる主な機能と役割

在庫にかかわる機能は、受注前・受注時・受注後で担う役割が入れ替わります。受注前は在庫数の表示と公開範囲の制御、受注時は在庫引当と締め時間の扱い、受注後は入荷予定日の提示と在庫アラートが中心になります。どの局面の機能から着手するかで、必要な連携の頻度も費用の掛かり方も変わります。自社の受注の流れに沿って、機能を局面ごとに割り付ける進め方が扱いやすいでしょう。

在庫数の表示では、数量をそのまま出すか、記号に置き換えるかを選びます。実数の公開は取引先の発注精度を高めますが、生産量や販売量を推測される材料にもなります。「◎・○・△・×」のような4段階の記号表示にすれば、在庫の水準だけを伝えられます。公開範囲の制御では、取引先の区分ごとに表示の方法を切り替える設定が働きます。

在庫引当は、受注の確定と同時に数量を確保する処理です。引当の時点が遅いほど、同じ在庫に複数の受注が重なる余地が広がります。締め時間の扱いも合わせて決める必要があり、例えば正午を締め時間とすれば、それ以降の受注は翌営業日の出荷に回ります。仮の引当のまま滞留した受注は在庫を押さえたまま出荷されない状態を生みますので、解放までの時間を先に決めておきます。

入荷予定日の提示は、欠品の場面で効いてきます。在庫が0の商品に入荷予定日を添えれば、取引先は納期を見たうえで発注を続けられます。代替提案では、規格や荷姿の近い商品を同じ画面に並べます。仕入先からの入荷が確定していない商品に予定日を出すと信頼を損ねますので、確定した数量だけを入荷予定在庫として扱います。

在庫アラートと発注点の管理は、社内に向けた機能です。商品ごとに発注点（発注を掛ける在庫数の下限）を設定し、引当可能在庫が発注点を下回った時点で通知します。発注点は、調達に要する日数と1日あたりの平均出荷数量から求めます。通知の宛先を仕入の担当者に限れば、取引先の画面には影響しません。

機能をすべて同時に備える必要はあるのでしょうか。在庫数の表示と引当の2つが動けば、問い合わせ対応の削減という目的の大部分は果たせます。入荷予定日の提示や代替提案は、対象の商品を絞って後から足せます。段階を分けて足す進め方は、連携の負荷を抑える面でも利点があるといえます。

基幹システムや倉庫システムとの在庫連携の仕組み

在庫連携の方式は、ファイル連携・API連携・EDI連携の3つに大別できます。反映の速さ、開発の手間、既存システムへの影響がそれぞれ異なり、どれか1つが常に優れているわけではありません。基幹システムを刷新しなくても、在庫データを取り出す口を1つ用意すれば連携は始められます。方式の選択より先に、在庫データの粒度と商品コードの整備を済ませる順序をおすすめします。

在庫データが受注の画面に届くまでの経路は、5つの段に分かれます。倉庫での入出庫の計上から始まり、在庫データの抽出、受発注側での在庫数の反映、受注時の引当、出荷指示へと進みます。段のどこかで滞れば、その先の数値はすべて古いまま残ります。連携の設計では、各段の実行時刻と、失敗したときの扱いを同時に決めておきます。

各方式の中身は、実行の仕方も改修の重さも異なります。

<ul><li>ファイル連携は、在庫データをファイルに書き出して受け渡す方式です。既存システムへの改修が小さく、夜間の1日1回など決まった時刻での実行に向きます。</li><li>API連携（システム同士が必要な時点で直接データをやり取りする接続方式）は、必要な時点で在庫を問い合わせる方式で、反映の時差を短くできます。</li><li><a href="/column/edi-renkei/">EDI連携</a>（企業間で発注・出荷データを定型フォーマットで交換する仕組み）は、発注や出荷のデータ交換の枠組みに在庫の情報を載せる方式です。</li></ul>

標準化された取引データの仕様として、流通ビジネスメッセージ標準（流通BMS）があります。一般財団法人流通システム開発センターが管理する同標準では、発注から請求までの業務を共通のメッセージで扱えるように定められています⁵。一方、取引先ごとの画面から手作業で転記する運用も残っており、画面の数が増えるほど発注側の負担が積み上がる点は、中小企業共通EDIの普及活動でも多画面問題として指摘されています⁶。自社の画面を1つ増やす取り組みは、取引先から見れば覚える画面が1つ増えることでもあります。標準の仕様に沿ったデータ交換と、画面での在庫確認を併存させる設計が現実的な落としどころになります。

商品コードの統一は、連携の前提に当たります。一般財団法人流通システム開発センターが管理するJANコードには、13桁の標準タイプと8桁の短縮タイプがあります⁷。いずれも国際標準の商品識別コードとして、商品の識別に用いられます。社内の品番、取引先の品番、標準コードの3つが並存する場合は、対応表をどちら側で持つかを決めます。対応表を受発注側に持たせると基幹側の改修は避けられますが、保守の担い手が受発注側に移ります。

連携の頻度は、商品の回転の速さから決めます。1日1回の連携で足りる商品と、15分ごとの更新が要る商品が同じシステムに混在することは珍しくありません。全商品を同じ頻度で更新する設計は、負荷と費用の両面で無駄が出ます。回転の速い上位の商品だけ頻度を上げる二段構えにすれば、費用を抑えたまま時差を縮められます。

在庫機能を選ぶ際の検討ポイント

在庫機能の選定では、製品の機能一覧を比べる前に、自社の在庫の決まりを言語化することが先決です。在庫を数える単位、拠点の持ち方、取引先ごとの公開の可否は、いずれも自社の商習慣から決まります。決まりが定まらないまま製品を選ぶと、導入後に運用の側を製品へ合わせる作業が発生します。選定の観点は、適合性・設定の自由度・拠点の扱い・保守のしやすさの4つに整理できます。

自社の在庫管理方式との適合は、最初に確かめたい観点です。単一の倉庫で商品単位に在庫を持つ運用と、ロットや期限の単位で在庫を分ける運用では、必要な機能が変わります。食品や医薬品のように期限の管理が要る商品では、引当の対象を期限別に分ける必要があります。製品が期限単位の引当に対応していない場合、運用での回避には手作業が残ります。

取引先ごとの在庫公開ルールを設定できるかどうかも、確認の対象です。すべての取引先に同じ在庫数を見せる設計しか選べない製品では、契約に基づく優先の出荷を画面に反映できません。取引先の区分ごとに、実数・記号・非表示の3通りを切り替えられるかを見ます。設定の変更に開発が要るのか、画面から操作できるのかで、運用開始後の手間が変わります。

拠点や倉庫が複数ある場合は、在庫の合算の方法を決めます。全拠点の合計を見せる方式は数量が大きく見えますが、遠方の拠点の在庫は納期が伸びます。出荷元を先に決めてから、その拠点の在庫だけを見せる方式であれば、納期の齟齬を抑えられます。取引先の所在地から出荷元を自動で決める機能の有無は、拠点が3か所以上ある企業ほど効いてきます。

運用開始後の保守と改修のしやすさは、見落とされやすい観点です。在庫の公開ルールは、取引先の増減や商品の入れ替えのたびに手が入ります。改修のたびに開発の依頼と見積りが要る仕組みでは変更の頻度が落ち、運用の実態と設定が離れていきます。設定の変更を自社で行える範囲がどこまでかを、契約の前に確かめておきます。

在庫連携を自社だけで組む場合、3つの担い手が要ります。基幹システムのデータの持ち方を読める担当者、在庫の業務ルールを決められる担当者、取引先との運用調整を担う担当者です。1人が兼ねると、業務の決めごとが技術の都合で決まり、後から運用が回らなくなります。外部の支援を使うかどうかの判断は、難易度そのものよりも、この3者を社内で同時に確保できるかで決まります。

観点の確かめ方には順序があります。自社の在庫の決まりを固め、公開ルールを決め、拠点の扱いを定めてから、製品の設定範囲と保守の体制を見ます。順序を逆にして製品から入ると、決めていない事柄を製品の初期設定が代わりに決めてしまいます。決めた事柄を一覧にしておけば、複数の製品を同じ物差しで比べられます。

在庫機能を活かす導入の進め方

導入は、現行業務の棚卸しから始めて、対象取引先の限定、公開範囲の拡大、効果の測定の順に進めます。最初から全取引先・全商品を対象にすると、在庫の差異と運用の例外が同時に噴き出します。取引量の多い数社に絞って始めれば、想定外の事象を小さな範囲で吸収できます。効果の測定は、導入の前に指標を決めておかないと、後から比べる材料が残りません。

現行業務の棚卸しでは、在庫確認の依頼を経路別に数えます。電話・電子メール・ファクスの3つの経路について、届いた件数と対応に要した時間を記録します。繁忙期と閑散期をまたぐ期間で記録すれば、波の大きさまで見えてきます。記録がないまま導入すると、削減できたかどうかを語る材料が残りません。

対象取引先の限定では、取引量の多い順に数社を選びます。件数の多い相手ほど、改善の効果が数値として見えやすいからです。並行して、公開する商品も回転の速い上位の商品に絞ります。範囲を絞る判断は、在庫の差異が出たときに手作業で吸収できる量に収めるための備えでもあります。

公開範囲の拡大は、運用が落ち着いてから進めます。拡大の前に、在庫の差異が何件起きたか、原因が計上の遅れか設定の誤りかを分けて数えます。取引先への案内では、画面上の在庫数がどの時点の数値かを明記します。反映の時差を先に伝えておけば、数量の食い違いが起きたときの説明が短く済みます。

取引先への案内と定着の支援は、機能の提供と同じだけ手間が掛かります。画面の使い方を書いた1枚の手引きを用意し、発注の締め時間と在庫の更新時刻を併記します。導入の初期は、電話での受付も残したまま並行して運用します。電話の受付を細める時期は、画面経由の発注比率が想定の水準に届いた時点で判断します。

効果の測定では、指標を3つ程度に絞ります。候補として挙げられるのは、次の指標です。

<ul><li>在庫確認の問い合わせ件数を、経路別に数えます。</li><li>受注から出荷指示までの所要時間を測ります。</li><li>欠品による出荷取消の件数を記録します。</li></ul>

導入の前後で数え方をそろえないと、比較の意味が薄れてしまいます。数値の取得元と担当を決めておけば、測定そのものが負担になりません。

寄せられる問いは、在庫数の見せ方に集まります。次いで基幹システムの刷新の要否、在庫データがずれたときの扱いが続きます。先に答えを述べますと、在庫数はそのまま見せる必要はなく、基幹システムの刷新も前提ではありません。ずれは起きる前提に立ち、検知と訂正の手順を先に決めておく形が実務に合います。いずれも製品の機能より、自社で決める運用の設計が結果を左右します。

在庫数をそのまま取引先に見せるべきかという問いには、商品と取引先の組み合わせで答えが変わります。実数の公開は発注の精度を高める一方、販売量を推測される材料にもなります。記号による水準の表示や、上限を設けた表示に切り替える方法もあります。取引先の区分ごとに見せ方を変えられる設定があれば、契約の内容に沿った公開ができます。

上限を設けた表示は、実数と記号の中間に位置します。例えば在庫が100個あっても、画面には「50個以上」とだけ示す方法です。取引先は発注できる数量を判断でき、こちらは総量を明かさずに済みます。数量の刻みを決める際は、取引先の標準的な発注ロットを下回らない値にそろえます。

基幹システムを刷新しないと連携できないかという問いには、刷新は前提ではないと答えられます。必要なのは、在庫データを決まった形式で取り出す口を1つ用意することです。ファイルの書き出しであれば、既存システムへの改修は小さく収まります。ただし取り出せるデータの粒度が粗い場合、粒度をそろえる処理をどちらの側で持つかの判断が要ります。

刷新の計画がある場合でも、在庫の公開を先に始める選択はあり得ます。受発注の画面と基幹システムの間に連携の層を挟んでおけば、基幹側が入れ替わっても画面側の改修は限られます。層を挟む設計は初期の手間が増えますが、刷新の時期が読めない場合の備えになります。判断の分かれ目は、刷新の時期が決まっているかどうかです。

在庫データがずれた場合の扱いは、検知・訂正・連絡の3段に分けて決めます。各段で決めておく内容は次のとおりです。

<ul><li>検知は、受発注側の在庫数と基幹側の在庫数を突き合わせる処理を定時に走らせる方法が基本です。</li><li>訂正は基幹側を正として上書きし、受発注側だけを直す運用は避けます。</li><li>連絡は、すでに成立した受注の数量に影響が出る場合に限り、取引先へ個別に行います。</li></ul>

入出庫の計上遅れ、連携の失敗、設定の誤りが、ずれを生む主な原因です。原因の内訳を記録しておくと、手を入れる順序が決まります。計上の遅れが多いなら倉庫の運用、連携の失敗が多いなら監視の仕組みが対象になります。ずれを0にする目標より、ずれを翌営業日までに解消する目標のほうが運用に馴染みます。

ここまでの論点を、あらためて振り返っておきましょう。在庫の見せ方は、実数・記号・上限表示のどれを取引先の区分ごとに割り当てるかで決まります。引当ルールは、数量を確保する時点と仮引当を解放するまでの時間を先に定めておくと運用が安定します。連携頻度は、回転の速い上位商品だけ間隔を詰める二段構えにすれば、費用を抑えたまま時差を縮められます。

<div class="eeat-box"><p>FSOLは、基幹システムと受発注システムをつなぐ在庫連携について、業務要件の整理から設計・構築・運用開始後の見直しまでを支援しています。流通・製造の受発注業務で積み重ねた実績をもとに、在庫の公開ルールづくりと連携方式の選定を伴走して進めます。</p><p>基幹データの持ち方を読める担当者、在庫の業務ルールを決められる担当者、取引先との運用調整を担う担当者を社内だけで同時に確保しにくい場合は、外部の支援を組み合わせる選択が現実的です。<a href="/service/">FSOLの受発注システム導入支援</a>では、不足する役割を補いながら、無理のない範囲から在庫機能の公開を始められます。</p></div>

<p>出典一覧</p><ul><li>¹ 経済産業省『電子商取引に関する市場調査』（令和6年度調査、2025年公表）</li><li>² 総務省『通信利用動向調査』（令和6年、2025年公表）</li><li>³ 中小企業庁『中小企業白書』（2025年版）</li><li>⁴ 公益社団法人日本ロジスティクスシステム協会『物流コスト調査報告書』（2024年度版）</li><li>⁵ 一般財団法人流通システム開発センター『流通ビジネスメッセージ標準（流通BMS）』</li><li>⁶ 特定非営利活動法人ITコーディネータ協会『中小企業共通EDI標準』</li><li>⁷ 一般財団法人流通システム開発センター『JANコード（GS1事業者コード）の桁数と種類』</li></ul>

Web受発注システムの在庫機能に関するよくある質問

受発注の画面が稼働したあとから、在庫機能だけを追加できますか。

後から追加する進め方はとれます。追加の際は、在庫データを取り出す口の有無と、社内の品番と取引先の品番をつなぐ対応表がそろっているかを先に確かめます。ただし受注データの持ち方によっては、引当の記録を保持する項目を足す作業が発生します。既存のデータをそのまま使えるかどうかで、作業量は大きく変わります。

取引先が画面の在庫を見て発注したのに欠品した場合、どう整理しますか。

画面の在庫数は発注時点の目安であり、数量の確定は受注の成立時点で行うという扱いを、事前に取引先と取り決めておきます。取り決めの文面や責任の範囲は契約ごとに異なりますので、法務の確認を経て定めます。画面に在庫の更新時刻を表示しておくと、行き違いが起きたときの確認が短く済みます。

在庫連携にかかる費用はどのくらい見込めばよいですか。

連携の方式、対象データの量、既存システムの改修範囲によって変わりますので、一律の相場は示せません。費用が動く要因は、在庫データを取り出す口の有無、商品コードの対応表の整備状況、連携の頻度の3点です。見積りを比べる際は、初期の開発費だけでなく、公開ルールを変更するたびに発生する作業費まで含めて確かめます。

複数の倉庫の在庫を1つの数量にまとめて見せてもよいですか。

合算した数量を見せる場合は、出荷元と納期の考え方を合わせて決めます。遠方の拠点を含めた合計を示すと、数量は満たせても納期が伸び、取引先の予定と食い違います。出荷元を先に確定させ、その拠点の在庫だけを見せる方式であれば齟齬を抑えられます。拠点が3か所以上ある場合は、出荷元を自動で決める仕組みの有無が運用の負担を左右します。

取引先が画面を使ってくれない場合はどうすればよいですか。

電話や電子メールでの受付を残したまま、画面での発注に利点を持たせる進め方をとります。在庫の確認と入荷予定日の提示を画面だけの機能にすれば、確認の手間を理由に画面へ移る取引先が出てきます。移行の状況は、取引先ごとの画面経由の発注比率で追います。比率が伸びない相手には手引きを渡し、初回の入力に伴走します。

1. 1　出典：経済産業省「令和6年度電子商取引に関する市場調査（結果公表）」（2025）　経路
2. 2　出典：総務省「令和7年通信利用動向調査の結果」（2026）　経路
3. 3　出典：独立行政法人情報処理推進機構（IPA）「DX動向2026」（2026）　経路
4. 4　出典：一般財団法人流通システム開発センター（GS1 Japan）／流通BMS協議会「流通BMS標準仕様」（2018）　経路
5. 5　出典：一般財団法人流通システム開発センター（GS1 Japan）／流通BMS協議会「流通BMSにおけるWeb-EDI」（2026）　経路
6. 6　出典：一般財団法人流通システム開発センター（GS1 Japan）「GTIN（JANコード）」（2026）　経路
7. 7　出典：公益社団法人日本ロジスティクスシステム協会「2025年度物流コスト調査報告書（概要版）」（2026）　経路
8. 8　出典：中小企業庁「2026年版中小企業白書・小規模企業白書（閣議決定の公表）」（2026）　経路