卸売業の受発注システム｜FAX・電話注文をWeb化する費用相場と進め方【2026年最新】

なぜ卸売業はFAX・電話受注から抜け出せないのか

「もうFAXの時代じゃない」と言われて10年以上。それでも卸売業の受注現場からFAXが消えないのには、はっきりした理由があります。感情論でも怠慢でもなく、構造的にFAXが強い場面が実在するからです。

まず、注文する側の都合があります。卸売業の得意先は、小売店・飲食店・工務店・工場など、事務スタッフが少ない事業者が中心です。営業時間中はレジや現場に人が出ていて、パソコンの前に座る時間がありません。手元の在庫を見ながら発注書にペンで書き込み、閉店後にまとめて送信する——この動作は、慣れた人にとって驚くほど速いのです。

次に、卸す側の都合があります。FAXは得意先ごとにフォーマットがバラバラでも、担当者の頭の中で解釈できます。「A店の『ミカン10』はいつもケース単位」「B店の『いつもの』は先月と同じ品番」——この暗黙知が、システム化を難しくする最大の壁です。

2026年に向けて状況が変わってきた3つの要因

とはいえ、ここ数年で潮目は変わりつつあります。

• 人が採れない：受注入力のパート採用が難しくなり、1人あたりの処理量を上げざるを得なくなった
• 電子帳簿保存法・インボイス制度への対応：紙の伝票と請求書の突合コストが上がり、データで持つ動機が強まった（2026年時点の一般的な状況です。自社の要件は税理士・所管省庁にご確認ください）
• 得意先側のスマホ慣れ：パソコンは触らないがスマホは使う、という層が増え、スマホ発注のハードルが下がった

特に3つ目は大きな変化です。「Web発注＝パソコンで面倒な入力」というイメージが「スマホで前回注文をコピーして数字だけ直す」に変わり、導入後の利用率が上がってきています。

受発注システムとは｜卸売業における定義と守備範囲

ここで押さえておきたいのは、「受発注システム」という言葉が指す範囲が会社によってまったく違うことです。ベンダーの提案書を比べるときは、必ず次の5階層のどこまでを含むのかを確認してください。

安価なBtoB ECパッケージの多くは①と②の一部までをカバーします。③〜⑤は基幹システム側の仕事、という前提で設計されているためです。自社の基幹システムがそこを担えるなら問題ありませんが、担えない場合は「受注はWeb化したのに、その後の工程は今まで通り手作業」という状態になります。

見積を取るときは「受注一覧をCSVで出せますか」ではなく、「当社の基幹システムAに、受注明細を自動で登録できますか。方式はAPIですか、CSV連携ですか、それとも人がインポートするのですか」と聞いてください。ここで答えが濁るベンダーは、③以降を想定していません。

FAX・電話受注が生んでいる5つの隠れコスト

「今のやり方で回っている」——これは事実です。問題は、回すために払っているコストが会計上どこにも表れないことです。代表的な5つを、金額に換算できる形で整理します。

1. 転記時間そのもの

FAX1枚を基幹システムに入力するのに要する時間は、明細数にもよりますが一般的に3〜8分程度です。1日30枚なら、単純計算で1.5〜4時間。年間240営業日で360〜960時間になります。時給1,300円換算で年間47万〜125万円が、価値を生まない転記作業に消えている計算です。

2. 入力ミスのリカバリコスト

転記ミスの発生率は、手書きFAXの解読を含めると一般的に0.3〜1%程度と言われます。1日30枚×明細10行なら1日300行、月6,000行。0.5%なら月30件の誤りが発生します。1件あたり、誤配送→返品→再出荷→謝罪で平均5,000〜15,000円のロスとすると、月15万〜45万円規模です。

3. 電話対応の中断コスト

「今、在庫ある？」「昨日の注文どうなった？」という問い合わせ電話は、受注担当の集中を切ります。1本3分でも、復帰を含めれば実質10分近い損失です。1日15本なら2.5時間。繁忙期の残業の主因になっていることが多い部分です。

4. 属人化による経営リスク

得意先別価格をベテラン事務員のExcelと記憶で運用している会社は、いまだに珍しくありません。この状態は、その人が辞めた瞬間に「正しい価格が誰にもわからない」という致命的な事態を招きます。これは業務効率の問題ではなく、事業継続の問題です。

5. 機会損失

FAX締めが「15時まで」の会社では、16時に発注したい得意先の注文は翌日扱いです。Web受注で締めを19時に延ばしただけで注文機会が増えたケースは多く見られます。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

卸売業の受発注システムに必須の機能【チェックリスト】

ここが本記事の中核です。一般的なEC機能では足りない、卸売業に固有の要件を洗い出します。ベンダー選定時のチェックリストとしてそのまま使えます。

価格・単位まわり（最も差が出る領域）

• 得意先別単価：同じ商品でもA社は120円、B社は135円。マスタで個別に持てるか
• 掛け率設定：定価×0.7、ただし特定カテゴリのみ0.65といった階層的な掛け率
• 数量スライド価格：10ケース以上で単価が下がる、という段階価格
• 期間限定価格：特売期間だけ価格を切り替え、期間終了で自動的に通常価格へ戻る
• ケース／バラ換算：1ケース＝24本。バラ発注可否と端数処理を得意先ごとに設定できるか
• 最低ロット・発注単位：この商品はケース単位のみ、この得意先は5,000円以上から
• 価格の非表示設定：得意先には自社向け価格のみ見せ、他社価格は絶対に見せない

受注・在庫まわり

• 前回注文コピー・定番リスト：これが無いとWeb発注は続きません。最重要機能です
• 在庫引当：受注確定時に在庫を確保。予約在庫と実在庫の区別
• 欠品時の挙動：注文を受けない／受けて後日出荷（バックオーダー）／代替品を提案
• 分納対応：一部を先に出荷し、残りを次回に回す
• 配送ルート別の締め時間：Aルートは15時締め、Bルートは17時締め
• 納品希望日の指定：カレンダーで休業日・配送不可日をブロック

締め・請求・管理まわり

• 得意先別の締め日：月末締め、20日締め、15日締めの混在に対応
• 与信・売掛残高チェック：与信限度額を超えた注文をアラート
• 請求書の発行形式：得意先ごとに合計請求／店舗別請求を切り替え
• 受注承認フロー：一定金額以上、または新規得意先の初回注文は営業承認を挟む
• 基幹システム連携：受注データを基幹へ自動連携（後述）

受発注システムの費用相場｜初期・月額・追加開発

2026年時点の一般的な費用レンジを、方式別に整理します。金額は規模・要件で大きく変動するため、目安としてご覧ください。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

費用を押し上げる要因トップ5

逆に、費用を下げられるポイント

• Phase1で受注受付だけに絞る：在庫引当・請求は既存運用のまま残し、まず転記をゼロにする。初期費用が半分以下になることも珍しくありません
• 得意先を絞って始める：全得意先対応を前提にすると個別要件が積み上がります。上位20社から始める設計にする
• 連携をCSVで割り切る：リアルタイムAPI連携にこだわらず、1日3回のファイル連携で十分な業務は多いです
• 管理画面を作り込まない：発注側（得意先）の画面に予算を集中し、社内管理画面は最小限にする

費用対効果の考え方については 業務システム化の費用対効果(ROI) と システム開発の相場 も併せてご覧ください。

BtoB ECパッケージ vs カスタム開発｜比較と判断基準

ここは正直にお伝えします。既製のBtoB ECパッケージで十分な卸売会社は、実際にかなり多いです。むやみに作るべきではありません。

既製パッケージで十分なケース（正直に書きます）

• 得意先ごとの価格差が「掛け率1つ」で表現できる
• 商品点数が数百〜2,000点程度で、単位はケースかバラのどちらかに統一されている
• 在庫引当は不要で、「在庫あり／なし」の目安表示で運用が回る
• 締め日が全社共通、または2パターン程度
• 基幹システム側にCSV取込機能があり、1日1回の取込で足りる

この条件に当てはまるなら、月額数万円のサービスで十分な効果が出ます。開発会社に相談するより先に、まず既製サービスの無料トライアルを試すことをおすすめします。

カスタム開発を検討すべきケース

• 価格が「得意先 × カテゴリ × 数量帯 × 期間」の多重条件で決まる
• 受注時点の在庫引当が必須（限定品・生鮮・受注生産部材など）
• 基幹システムが独自仕様で、標準連携のあるパッケージが存在しない
• 締め日・請求形式が得意先ごとにバラバラで、月10パターン以上ある
• 大手得意先の指定EDIフォーマットへの対応が売上維持の条件になっている
• 既にパッケージを入れたが、Excel回避運用が発生して現場が使っていない

この判断の詳細は スクラッチ vs パッケージ vs SaaS でさらに深く整理しています。

得意先別価格・掛け率をどう設計するか

価格決定の優先順位を「1本の階段」にする

複数のルールが競合したとき、どれが勝つのか。ここを曖昧にしたままシステムを作ると、必ず「思った価格と違う」というクレームが出ます。次のように上から順に判定し、最初にヒットしたものを採用する設計が扱いやすいです。

1. 個別特価（得意先 × 商品 × 期間の直接指定）— 最優先
2. 数量スライド価格（得意先 × 商品 × 数量帯）
3. キャンペーン価格（全社共通の期間限定）
4. 得意先 × カテゴリ別掛け率
5. 得意先の基本掛け率
6. 標準価格（どれにも該当しない場合）

この階段を紙1枚に書き、営業部長と経理と受注担当の3者で「この順番で合っていますか」と確認してください。この確認だけで、後工程の手戻りが劇的に減ります。要件定義の進め方は 業務システム要件定義の進め方 も参考になります。

Excelの価格表からの移行は「棚卸し」から

ベテラン事務員のExcelには、たいてい次のようなものが混在しています。

• すでに取引のない得意先の行が残っている
• 同じ商品が旧品番と新品番の両方で載っている
• 「※Cさんに要確認」のようなコメントが価格の代わりに入っている
• 数式が壊れていて、手入力で上書きされたセルがある

これをそのままシステムに取り込むと、汚れたデータが永続化します。移行前に、直近12か月に実際に出荷実績のある「得意先 × 商品」の組み合わせだけを抽出し、その分だけ価格を確定させるのが現実的です。実績のない組み合わせは標準価格にしておき、注文が来たときに個別対応すれば十分です。

価格改定のオペレーションまで設計する

見落とされがちなのが導入後の価格改定です。仕入価格が上がったとき、300社分をどう一括更新するのか。ここを考えずに作ると「価格更新はExcelで作ってインポート」という運用に戻ります。

• カテゴリ単位・仕入先単位での一括改定機能
• 改定予約（適用開始日を指定して事前登録）
• 改定前後の差分プレビューと、影響を受ける得意先の一覧出力
• 改定通知の自動送付（得意先へのお知らせ）

在庫引当・欠品対応の設計が成否を分ける

受発注システムのトラブルで最も多いのが、この在庫まわりです。設計パターンを整理します。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

「リアルタイム引当が必要」は本当か

ヒアリングをすると、多くの会社が「リアルタイムでやりたい」とおっしゃいます。しかし実際に受注データを分析すると、同一商品に同日中に複数の注文が競合するケースは全受注の数%以下ということが少なくありません。この場合、バッチ引当＋競合時の例外運用のほうが、コストも運用負荷も低くなります。

判断材料として、まず過去3か月の受注データから「同一SKUが同日に2件以上受注された割合」を出してみてください。この1つの数字で、80万円以上の投資判断が変わります。

欠品時の挙動は必ず事前に決める

欠品が発生したとき、システムがどう振る舞うか。ここを決めずに開発を始めると、テスト段階で紛糾します。

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

実務では、商品カテゴリごとに挙動を変えられるのが理想です。定番品はバックオーダー、季節品は在庫数まで、といった使い分けができると現場が納得します。

締め請求と基幹システム連携の現実的な作り方

受注をWeb化しても、その先の締め・請求が手作業のままなら、月末の負荷は変わりません。ここを最初から視野に入れておくかどうかで、投資対効果が大きく変わります。

締め請求で確認すべき論点

• 締め日の種類：月末／20日／15日／10日など、実際に何パターンあるか棚卸しする
• 請求単位：本部一括請求か、店舗別請求か。得意先ごとに違うことが多い
• 返品・値引きの扱い：締め後に発生した返品をどの月に計上するか
• 請求書の送付方法：郵送／PDFメール／得意先の請求書受領システムへのアップロード
• 売掛消込：入金データと請求の突合を自動化するか、経理が手動で行うか

基幹システム連携の4方式

※ 上記は一般的なモデルケースであり、成果を保証するものではありません。

連携でよくある落とし穴

• 商品コードの不一致：Web側と基幹側でコード体系が違い、変換テーブルが必要になる
• 取込エラー時の運用：1件エラーで全件止まるのか、エラー分だけ止まるのか。後者を設計しないと運用が破綻します
• 重複取込：ネットワーク障害でリトライした際に、二重に受注が登録されないための冪等性設計
• マスタの同期方向：商品マスタと得意先マスタは基幹が正、を明確にする（両方で編集できると必ず壊れます）

保守運用の考え方は システム保守とは でも整理しています。

導入の進め方6ステップと得意先への移行設計

システムを作ることより難しいのが、得意先にWeb発注へ移ってもらうことです。ここに失敗すると、Webも運用しつつFAXも受け続ける二重運用になり、業務量はむしろ増えます。

導入の6ステップ

得意先にWeb発注へ移ってもらう5つの実務策

1. 営業担当が最初の1回を一緒に入力する：メール案内だけでは動きません。訪問時にスマホで一緒に発注してもらうのが最も効きます
2. 初回ログイン時に定番リストを登録済みにしておく：過去の出荷実績から自動生成しておけば、初回から「前回コピー」が使えます
3. Web発注のメリットを得意先目線で伝える：締め時間の延長、注文履歴の閲覧、納品予定の確認、請求書のダウンロード。自社の効率化ではなく相手の利便で語る
4. FAXを即日で止めない：「3か月後からWeb推奨、1年後にFAXは特定条件のみ」といった長めの併走期間を設ける
5. 入力が難しい得意先は残す判断も持つ：全社100%を目指すとコストが跳ね上がります。上位80%の受注件数がWeb化できれば十分な成果です

現場でツールが使われない理由については ITツールが現場で使われない理由 が参考になります。社内も社外も、原因は驚くほど共通しています。

よくある失敗パターンと回避策

失敗1：Webフォームを作っただけで終わる

最も多い失敗です。注文は入るが、価格は人が直す、在庫は人が確認する、基幹への入力は人がやる。これでは転記作業が減りません。回避策：投資判断の指標を「Web受注比率」ではなく「受注1件あたりの人手介在時間」に置く。この数字が下がらない案件は、そもそも設計が間違っています。

失敗2：全得意先・全商品を一度に対象にする

個別要件が積み上がり、要件定義が終わらないまま1年が過ぎます。回避策：受注件数の上位20社で全体の何%を占めるか計算してください。多くの卸売業でパレートの法則が効いており、上位20%の得意先で70〜80%の受注件数を占めることが一般的です。そこだけ対応すれば効果の大半が取れます。

失敗3：マスタを整備せずに開発を始める

商品コードが揺れたまま開発を進めると、テスト段階で「同じ商品が2つ出てくる」という問題が噴出し、大幅な手戻りになります。回避策：STEP3のマスタ整備を、開発とは別の工程として明確に予算・期間を確保する。ここを圧縮した案件は、ほぼ例外なく後で倍の時間を失います。

失敗4：ベテラン事務員をプロジェクトから外す

「忙しいから」と現場の最重要人物を外すと、暗黙知が仕様に反映されず、稼働後に「これでは使えない」となります。回避策：週2時間でよいので、必ずプロジェクトに参加してもらう時間を業務として確保する。属人化の解消手順は 属人化を解消する3つの手順 も併せてご覧ください。

失敗5：パッケージの標準機能に業務を合わせられると思い込む

「業務をシステムに合わせましょう」は正論ですが、卸売業の価格条件は得意先との商談で決まった約束事であり、自社都合で変えられません。ここを軽く見ると、稼働後にExcelでの例外運用が復活します。回避策：変えられる業務（社内の承認手順、帳票レイアウト）と、変えられない業務（得意先との取引条件）を最初に仕分けする。

失敗6：保守と改善の予算を取らない

受発注システムは稼働後に必ず改善要望が出ます。回避策：初期費用の10〜20%程度を年間の保守・改善予算として見込んでおく。この枠があるだけで、小さな不満が放置されて使われなくなる事態を防げます。