販売管理システムと在庫の連携｜二重入力を減らす設計

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

B2B EC-COLUMN

販売管理と在庫を一本化する連携の定義

販売管理システムと在庫の連携とは、受注・出荷・請求を扱う販売管理システムと、在庫の数量を持つ仕組みとの間で、在庫データを自動でやりとりする設計です。2023年の事業者間取引のEC化率は40.0%に達しており¹、受注の入口が増えた分だけ、目視確認と転記が現場に残ります。

午前9時、受注のファクスとメールが届きます。担当者は販売管理システムの画面を開き、別の窓で在庫の一覧を呼び出し、数量を目で突き合わせます。倉庫へ電話をかけ、「まだ残っていますか」と確かめます。確かめた数量を受注画面へ手で写し、出荷指示の紙を印刷する。ここまでで1件です。同じ突き合わせが、その日の受注の件数だけ繰り返されます。

この突き合わせを機械へ渡すのが、販売管理と在庫の連携です。やりとりする在庫データは、品目コード・実在庫数・引当在庫数・入荷予定数の4項目が中心になります。実在庫数だけを渡す設計にすると、受注済みで未出荷の分が二重に売れます。引当在庫数まで含めて渡せば、受注の時点で残数が正しく見えますね。

機械へ渡さないかぎり、在庫を目で突き合わせ、電話で確かめる時間は、どの請求書にも載らないまま、毎日の人件費として現に支払われています。

二重入力と欠品を生む分断の構造

転記と締め遅れが生む在庫のずれ

在庫のずれは、数量が動く時刻の違いから生まれます。販売管理システムでは、受注データの受付をした時点で受注残が立ちます。在庫の側は、出荷の実績が入るまで数量が動きません。この間に別の注文が入れば、在庫の目視確認をした担当者は、すでに売れた分を残数として読みます。

この時刻の差を埋めているのは人の手です。転記と電話確認を挟み、確かめた数量を受注画面へ写します。出荷指示を出すのは、そのあとになります。1件あたり数分の作業でも、受注の件数だけ積み上がる。件数が伸びた日ほど確認が後回しになり、ずれの幅が広がります。

欠品と過剰在庫は、同じ原因から同時に起きます。売れた分が在庫に反映されていなければ、受けられない注文を受けてしまいます。出荷済みの分が在庫から引かれていなければ、まだ残っていると見える品目へ追加の発注をかけます。どちらも、数量の正本が決まっていないことから生じるのです。

クラウド利用80.6%でも残る分断

仕組みを新しくしても、在庫の数量が揃うとは限りません。2024年にクラウドサービスを利用している企業の割合は80.6%です²。これに対し、2023年の事業者間取引のEC化率は40.0%です¹。2つの数値は対象も調査も異なりますので、単純に比べられるものではありません。読み取れるのは、仕組みを導入することと、仕組みどうしをつなぐこととが別の作業だという点です。

つなぐ作業を後回しにした現場では、品目が増えるほど目で見る確認は成り立たなくなります。株式会社ポディウムは、取扱商品点数20,000点を新しいBtoB ECサイトへ移した事例を公開しています⁵。この規模の品目を担当者が画面で見比べる形は、受注の波が来た日に破綻します。仕組みの数が増え、品目の数も増えれば、人の確認は追いつきません。

いまの形を続けた先に待つのは基幹システムそのものの刷新で、2025年度にIT予算が増える理由としてこれを挙げた企業は44.5%にのぼります³。

在庫連携の方式と選ぶときの判断軸

基幹の刷新を待たずに始めるなら、着手の順序は3段で足ります。在庫データの棚卸し、在庫マスタの正本、連携方式の選定です。順番を入れ替えると、方式を先に決めたあとで正本が定まらず、作り直しになります。段を増やさないのは、着手の負担を下げるためです。

在庫データの棚卸しでは、品目コード・実在庫数・引当在庫数・入荷予定数の4項目が、どの仕組みに在るかを1件ずつ書き出します。単位の持ち方も併せて見ます。販売側がバラで数え、倉庫側がケースで数えていれば、渡した数量は合いません。ここで見落とした違いは、あとの工程では表に出てこないのです。

在庫マスタの正本は、数量を正とする仕組みを1つに決める作業です。出荷の指示を出す側に置くと、実物の動きと数量の動きが揃います。正本を2つ持てば、どちらの数量を信じるかが日々の判断になり、いったん減らした人の確認が戻ってきます。

連携方式の選定では、CSV連携とAPI連携を選び分けます。CSV連携は、表計算で扱える文字だけのファイルをやりとりする方式です。既存の出力機能をそのまま使えますので、基幹に手を入れずに始められます。反映は出力の時刻ごとになります。

API連携は、仕組みどうしが直接データを受け渡す接続の口を使う方式です。受注のたびに在庫へ反映できる一方、基幹側に接続の口を用意する改修が要ります。締めのある取引ならCSV連携、随時の受注が続く取引ならAPI連携。これが選び分けの目安になりますが、方式を選んだだけでは数量は揃わず、在庫の基準を決める作業が残ります。

連携で決める在庫の基準と締め処理

基準は3つ決めれば動きます。在庫マスタの正本、反映頻度と締め時刻、初期在庫の移行です。どれも仕組みの話に見えて、中身は現場の運用の取り決めです。決めないままつなぐと、数量が合わないたびに人が調べる仕事だけが残ります。

在庫マスタの正本は、出荷の指示を出す側へ置くのが扱いやすい形です。数量の持ち方は、バラとケースのどちらで数えるか、品目コードをどちらの体系へ合わせるかまで含めて揃えます。更新の権利も1つに絞り、正本以外の仕組みから数量を書き換えない取り決めにします。二方向から書き換えれば、あとから書いた側の数量だけが残ります。

反映頻度と締め時刻は、取引先に締めがあるかどうかで決まります。引当のタイミングを受注の時点へ置けば、残数はその場で正しく見えます。締め後の突き合わせは、出荷実績と在庫の差を毎日見る運用にしてください。差が出た理由をたどれるのは、その日のうちだけです。

初期在庫の移行では、棚卸しの基準時点を先に決めます。移行の作業中も受注は止まりませんので、基準時点より後の動きは別に記録し、あとから足します。本番前の検証は、実際の受注データで数量の動きを追う形にします。画面が開くかどうかではなく、数量が合うかどうかを見るのです。

ここまでで標準的な取引の在庫連携は形になりますので、以降は基幹を触れない・在庫を自社で持たない・EDI対応を求められるといった条件がある方に向けた、更に詳しい内容です。

ここまでの手順を自社の条件で確かめたい場合は、無料相談で要件を整理するのが近道です。

45.5%が首位のIT予算増の理由

順位は公表された調査に依りますが³、予算の付き先が決まっても、在庫連携の進め方は自社の条件で分かれます。

自社の事情がこの4つの理由に収まらない方は、次の表で自社に近い型を探してください。

改修可否で分かれる在庫連携の型

型	当てはまる条件
基幹改修が難しい情報システム部門	基幹システムの改修に予算と承認が下りず、既存の出力機能だけが使える
在庫数を自社で持たない販売部門	在庫が外部の倉庫に在り、数量の正本を自社の仕組みで持っていない
EDI対応を求められる卸の受注担当	取引先から流通BMSでの受発注を求められ、期限が自社の外にある

出力の時刻が反映頻度の上限になる情報システム部門の型

基幹改修が難しい型では、第1ブロックで示した「正本を決めて方式を選ぶ」順序が途中で止まります。基幹側に接続の口を足す改修が、予算と承認の外にあるためです。方式を比べる前に、選べる方式が1つに絞られています。

選べる方式が絞られた先では、判断の軸が入れ替わります。標準の型では「締めのある取引か、随時の受注か」で方式を選びました。この型では「改修の承認が要らない範囲はどこまでか」が軸になります。既存の出力で取り出せるファイルの種類と、その出力が終わる時刻。この2つが、そのまま在庫の反映頻度の上限です。

最初にすることは、出力できるファイルの一覧と出力の時刻を書き出すことです。そのうえで、在庫を反映する時刻を決めます。夜間の出力が午前3時に終わるなら、朝の受注は前日の数量を見ていることになりますので、受注可能数の見せ方を控えめにする運用で埋めます。

外部へ委ねずに済ませる道もあります。1日1回の締めで足りる取引だけを扱っているなら、既存のCSV出力と表計算での突き合わせを日課にするだけで、在庫のずれの大半は把握できます。外部へ委ねる判断は、受注の件数と品目の数が増え、日課が終わらなくなってからで構いません。

この型は改修を伴わない分だけ着手しやすい一方、出力の時刻と反映頻度の対応を1件ずつ確かめる手間がかかり、確かめ漏れが出荷停止につながりますので、抜けを潰す段だけ外の目を入れるとリスクを小さくできます。

確認する項目	見るところ	決めること
出力できるファイル	基幹の帳票とデータ出力の一覧	在庫の数量が含まれる出力が在るか
出力の時刻	夜間の処理が終わる時刻	在庫を反映できる最も早い時刻
品目コードの体系	基幹側と倉庫側の桁数と採番	突き合わせの鍵をどちらへ合わせるか
引当在庫の持ち場	受注済みで未出荷の数量の在り処	受注可能数をどちらで計算するか

委託先が出せる頻度が設計を決める販売部門の型

在庫数を自社で持たない型では、在庫マスタの正本を自社に置けません。数量を数えているのは委託先の倉庫であり、自社の仕組みに在るのは受け取った報告の写しだからです。出荷の指示を出す側へ正本を置く、という標準の考え方がそのまま当てはまりません。

軸は「自社で何を決められるか」ではなく、「委託先が出せる形式と頻度は何か」に移ります。契約の範囲で提供される在庫データの形式と、その提供の時刻が、設計できる上限です。上限を超えた反映頻度を前提に画面を作れば、残数の表示だけが実態から離れていきます。

残数の表示を実態に合わせる行動は2つです。委託先へ提供形式と提供の時刻を確認し、契約書の範囲に書かれているかを見ます。そのうえで、受注可能数の見せ方を頻度に合わせます。報告が1日1回なら、締め後の受注は翌日まで在庫に載りませんので、その分を差し引いた数量を受注可能数として見せる形が現実的です。

この型は自社側の改修が小さく済む一方、委託先との取り決めを契約の言葉にまで落とす必要があり、口頭の合意のままでは提供が止まった日に受注が止まりますので、条件を文書にする段で外の目を入れるとリスクを小さくできます。

委託先が出せる形式	販売側の受け方	残る手作業
1日1回のファイル提供	締めのあとに在庫を一括で更新	締め後の受注は当日の在庫に載らない
随時の接続による照会	受注の時点で残数を問い合わせ	照会が止まった日の代わりの運用
電話とメールでの報告	担当者が数量を手で入力	入力の遅れがそのまま在庫のずれになる

取引先の標準と期限が順序を決める卸の受注担当の型

取引先から標準を求められる型では、着手の順序を自社で組めません。EDI（企業どうしが受発注データを直接やりとりする仕組み）への対応を求めているのは取引先であり、期限も取引先の側にあるためです。在庫の正本を決める作業より、受発注の電文へ応じる作業が先に来ます。

取引先が求める電文の標準は流通BMS（流通業界の受発注データをやりとりする共通の規格）で、対応した卸・メーカーは2025年時点で21,600社以上です⁴。直近半年で増えたのは700社以上で、求めは広がり続けています⁴。取引先から名指しで規格を指定される場面が、この型の起点になります。

軸は「取引先が求める標準と、その期限」です。自社の都合で方式を選ぶ標準の型とは、決め方の向きが逆になります。まず対象の取引先が求める電文の範囲を確認し、次にその範囲へ在庫の引当をどう連動させるかを、期限から逆算して決めます。

期間の見立ては公開されている事例から拾えます。フリュー株式会社は、BtoB ECサイトの構築期間を2か月とした事例を公開しています⁶。取引の形も対象の範囲も異なりますので、そのまま自社に当てはめられる数値ではありません。期限のある案件では、公表された事例の範囲を手がかりに、社内の合意を先に取っておく形が現実的です。

この型は期限が外にある分だけ後戻りが利かず、電文の範囲と在庫の引当を同時に決める判断が続きますので、対象の取引先が複数に及ぶ段では外の目を入れると、期限切れのリスクを小さくできます。

確認する事柄	取引先に聞くこと	自社で決めること
求められる標準	流通BMSのどの電文を使うか	対応する電文の範囲
期限	運用を始めたい時期	在庫連携との前後の順序
取引先の数	同じ標準を求める先が他にもあるか	取引先ごとに作るか共通で作るか

この型に当てはまる場合は、判断の抜けによる手戻りを防ぐために、無料相談で自社の条件を持ち込むのが確実です。

要点の整理

判断軸	標準の取引での基準	条件のある型での基準
在庫マスタの正本	出荷の指示を出す側に置く	外部倉庫の場合は委託先の報告を正本として扱う
連携方式	締めの有無でCSV連携とAPI連携を選ぶ	改修の承認が下りる範囲の中から選ぶ
反映頻度	受注の時点で引き当てる設計を基本にする	委託先が出せる提供の頻度が上限になる
着手の順序	棚卸し・正本・方式の3段で進める	取引先が求める標準と期限が順序を決める
外部へ委ねる判断	日課の突き合わせで把握できるうちは自社で足りる	抜けの確認と契約の文言を固める段で外の目を入れる

よくある質問

基幹システムを入れ替えずに在庫のずれを止められますか

止められる場合があります。基幹の出力機能で在庫の数量を取り出せるなら、CSV連携から着手できますので、入れ替えは前提になりません。ただし反映は出力の時刻ごとになりますので、締めのあとに入った受注は翌日まで在庫へ載りません。受注の波が1日の中で大きい取引では、受注可能数の見せ方を控えめにする運用と組み合わせてください。

CSV連携とAPI連携のどちらから始めるのがよいですか

取引に締めがあるかどうかで決まります。1日1回の締めで運用が回る取引ならCSV連携で足ります。随時の受注が続き、残数をその場で見せる必要がある取引ではAPI連携が要ります。判断がつかない場合は、直近1か月の受注が何時台に集中しているかを数えてください。締めの時刻の後ろに受注が集まっているなら、CSV連携では追いつきません。

在庫マスタの正本は販売管理と倉庫のどちらに置きますか

出荷の指示を出す側に置く形が扱いやすくなります。実物の動きと数量の動きが同じ場所で揃うためです。外部の倉庫へ委託していて数量を自社で数えていない場合は、委託先の報告を正本として扱い、自社側は写しとして持ちます。いずれの場合も、正本以外の仕組みから数量を書き換えない取り決めを併せて決めてください。

在庫連携の費用はどのくらいかかりますか

公表された相場の一次情報が確認できませんので、金額の目安は示せません。費用が動く要素は挙げられます。渡す在庫データの項目数、CSV連携かAPI連携か、基幹側に改修が要るか、取引先ごとに個別の対応が要るかの4点です。見積もりを取る際は、この4点を先に固めてから依頼すると、条件の違いによる金額の開きを抑えられます。

EDI対応と在庫連携はどちらを先に進めますか

取引先から期限を示されている場合はEDI対応が先になります。期限が自社の外にあり、後ろへ動かせないためです。流通BMSに対応した卸・メーカーは2025年時点で21,600社以上に達しています⁴。ただし電文の設計を決めるときに、在庫の引当をどこで行うかを同時に決めておくと、あとから在庫連携を足す際の作り直しを避けられます。

反映頻度はどのくらいに設定すればよいですか

取引先の締めと、1日の受注の入り方から決めます。締めが1日1回で、受注も締め前に集まる取引なら、1日1回の反映で運用は回ります。締めの後ろに受注が続く取引では、受注の時点で在庫を引き当てる設計が要ります。頻度を上げるほど倉庫側と自社側の負荷も上がりますので、まず現在の受注の時刻分布を数えてから決めてください。

1. 1　出典：総務省「令和7年版 情報通信白書（顧客との接点や事業者間取引）」（2025年）　経路
2. 2　出典：総務省「令和7年版 情報通信白書（クラウドサービス）」（2025年）　経路
3. 3　出典：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査2025 プレスリリース第1弾」（2025年）　経路
4. 4　出典：GS1 Japan（一般財団法人流通システム開発センター）「流通BMS（流通EDI標準）導入企業数の調査」（2025年）　経路
5. 5　出典：株式会社フットボールソリューション「EC-Rider B2B 導入事例（株式会社ポディウム様）」（2025年）　経路
6. 6　出典：株式会社フットボールソリューション「EC-Rider B2B 導入事例（フリュー株式会社様）」（2016年）　経路