2026.10.27 ERP

卸売業のシステム開発会社の選び方｜商習慣の理解度と見積の内訳で見極める手順

卸売業の基幹システムを任せる開発会社は、見積金額や会社の規模より先に、得意先ごとの掛率、月末締めの請求、FAXと小売EDIが混ざる受注をどこまで仕様に落とせるかで差がつきます。同じ「販売管理を作れます」という会社でも、卸の商習慣を知らなければ要件定義の段階で質問が尽き、稼働後に単価や請求の例外処理が手作業のまま残る状態です。この記事では、卸売業のシステム開発で開発会社の力量が出る業務領域、依頼先4タイプの違い、商談で投げる質問、見積が膨らむ箇所と契約の分け方を整理し、受託開発会社に頼むべき卸と、開発会社を探す前に止めるべき卸の条件まで言い切ります。商社の基幹システムを検討している場合にも同じ手順で読めます。

まとめ：卸売業のシステム開発会社は商習慣を仕様に翻訳できるかで選ぶ

卸売業のシステム開発会社選びで見るべきは、開発言語や実績社数ではありません。得意先別の掛率とリベート、締め請求とインボイスの端数処理、受注入口の混在という三つの業務を、初回の打ち合わせから具体的な質問に変えて返してくる会社かどうかです。ここで質問が出ない会社は、要件定義を発注側に丸投げしてきます。

進め方は、まず自社の価格・請求・受注の例外を書き出し、次に依頼先のタイプを絞り、商談で同じ質問を各社に投げ、見積はデータ移行とEDI接続試験の行で比べる順番です。要件定義だけを先に別契約にすると、開発会社の理解度を本契約の前に確かめられます。価格・受注・外部連携のうち二つ以上が標準品で回らない卸は受託開発へ、一つ以下なら開発会社を探す前に標準パッケージで回るかを試すのが妥当です。

卸売業のシステム開発で開発会社の力量差が出る価格・請求・受注入口の業務領域

卸売業の基幹システムは、受注・出荷・売上・請求・入金という流れ自体は他業種と同じです。差が出るのは、その流れの途中に入る例外の多さです。業界ごとに要件の出どころが違う点は金融・公共・流通系のシステム開発とは？業界特化の要件と外注先の選び方で概観しているので、ここでは卸に絞って、開発会社の理解度が表に出る三つの領域を見ます。

得意先別の掛率やリベートなど価格の決まり方を単価マスタに落とす設計力

卸の売価は、定価に得意先ごとの掛率を掛け、数量やロットで段階を付け、期間限定の特売単価で上書きし、期末に販売奨励金（リベート）で戻す、という何層もの決まり方をしています。これを「得意先×商品の単価表」1枚で持とうとする開発会社は危険信号です。

掛率の階層、適用期間、優先順位を別々のマスタに分け、どの単価が採用されたかを伝票に残す設計にしないと、得意先から「先月と単価が違う」と問い合わせを受けたときに追えません。リベートを売上値引で処理するのか、別途の支払として処理するのかでも、請求と会計の連携が変わります。開発会社に価格表の実物を見せたとき、優先順位と適用期間について聞き返してくるかどうかが最初の見極めになります。

締め請求とインボイスの端数処理を請求書単位で組めるかという請求周りの知識

卸の請求は、納品ごとの都度請求より、得意先ごとの締め日でまとめる締め請求が中心です。20日締め・月末締めが混在し、締め後の返品や値引は赤伝で翌月に回す、といった運用が一般的に見られます。

インボイス制度の下では、消費税額の端数処理のやり方がシステム設計に直接響きます。国税庁のタックスアンサー No.6371 端数計算は、適格請求書の消費税額等の端数処理を「一の適格請求書につき、税率ごとに1回」と定め、個々の商品ごとに端数処理して合計する方法は認められないとしています（令和8年4月1日現在法令等）。明細行ごとに税額を丸めていた古い販売管理をそのまま移すと、請求書の税額と規定がずれます。

開発会社には「納品書と請求書のどちらで税額を確定させる設計か」「8%と10%の商品が同じ締めに入ったときの計算順」を聞いてください。即答できる会社は、卸の請求を作った経験があると見てよいでしょう。

FAX・電話・小売EDIが混ざる受注入口を一つの受注データにそろえた経験

卸の受注は、得意先によってFAX、電話、メール、Web発注、小売チェーンのEDIと入口がばらばらです。受注データを一つの形式にそろえる取り込み部分が、開発規模を大きく左右します。入口別の設計や流通BMSへの移行は卸売業の受発注システムとは？FAX・電話・EDI混在の受注を一本化する選び方で詳しく扱いました。

開発会社選びの観点では、EDIの接続先ごとに「どの手順で、何時に、どのフォーマットで受けるか」を一覧にした経験があるかを確かめます。NTT東日本のISDN(INSネット)とは？2028年12月終了の影響と企業が取るべき対応によると、INSネットのディジタル通信モードは2024年1月から段階的に終了し、暫定の補完策も2028年12月31日に提供を終える予定で、EDIシステムが影響を受ける可能性があると明記されています（2026年2月時点の情報）。INSネット経由のEDIが残る卸では、この期限を前提に工程を引ける会社かどうかも見ておく必要があります。

卸売業の開発依頼先4タイプの違いと自社の規模や業務に合う選び分け

「卸売業システム開発会社」で探すと、製品を売る会社と作る会社が同じ一覧に並びます。依頼先は大きく4タイプに分かれ、得意な案件の形が違います。

卸向けパッケージベンダー・導入代理店・受託開発会社・SIerの比較

4タイプの違いを、卸の基幹システムを任せる前提で並べると次のとおりです。

依頼先	主な提供形態	向く卸	注意点
卸向けパッケージベンダー	自社製品の導入と設定	業務が業界標準に近い中小卸	標準外の業務は追加開発費が別建て
パッケージ導入代理店	複数製品の提案と導入	製品を比べてから決めたい卸	扱う製品の範囲でしか提案が出ない
受託開発会社	要件定義からの個別開発	価格や受注に独自の決まりが多い卸	卸の経験の有無で品質差が大きい
SIer	大規模案件の一括請負	多拠点・グループ会社を持つ大手卸	中小規模では見積が過大になりやすい

中小から中堅の卸が迷うのは、パッケージベンダーと受託開発会社の間です。パッケージ側は標準機能の範囲なら導入が速く、受託開発側は独自の単価体系や受注入口をそのまま形にできます。どちらが上ということはなく、自社業務のどこが標準から外れているかで決まります。

パッケージ追加開発かスクラッチ開発かを分ける業務の独自性の測り方

独自性は「うちは特殊だ」という感覚ではなく、例外処理の件数で測ります。価格の決まり方、締めと請求、受注入口、在庫の持ち方の4つについて、標準パッケージのデモを見ながら「この画面では処理できない取引」を書き出してください。

書き出した例外が、件数ベースで取引全体の1割に満たず、手作業で吸収できる量ならパッケージで十分です。逆に、主要得意先の取引そのものが例外に当たる場合は、追加開発の費用が膨らみ、スクラッチの受託開発と変わらない金額になることがあります。機能面の比べ方は卸売業の販売管理システムとは？受発注・掛売・多倉庫在庫に対応する選び方で整理しています。

初回打ち合わせで卸売業の業務知識を見極める質問と回答の聞き分け方

開発会社の提案書はどこも似た構成になります。差が出るのは、こちらの質問に対する返し方です。同じ質問を各社に投げ、回答を並べて比べると判断がぶれません。

商談で投げる8つの質問と、卸の業務を知る開発会社が返す回答の特徴

初回か2回目の打ち合わせで、次の質問をそのまま投げてください。

得意先別の掛率、数量段階、特売単価が重なったとき、採用単価の優先順位をどう持たせますか。
リベートは売上値引と別途支払のどちらで処理する前提の設計ですか。
締め日の異なる得意先が混在するとき、締め処理と請求書の発行はどう分けますか。
適格請求書の消費税額は、納品書と請求書のどちらで確定させますか。
締め後の返品・値引は、当月修正と翌月の赤伝のどちらで扱いますか。
メーカーから得意先への直送は、仕入と売上をどの伝票で結び付けますか。
EDIの接続先ごとの手順・フォーマット・受信時刻の一覧は、誰がいつ作りますか。
現行システムの単価マスタと売掛残高は、どの時点の値をどう移しますか。

卸を知る会社は、答える前に「得意先は何社で、そのうち個別単価を持つのは何社ですか」のように、数を聞き返してきます。一般論で「柔軟に対応できます」と返す会社は、要件定義の段階で同じ質問を発注側に投げ返してくると考えてください。全問に即答できなくても構いませんが、質問の意図を取り違える会社は外します。

導入実績は社名でなく取引形態・得意先数・EDI接続先数で確かめる

「卸売業の実績多数」という表記だけでは、受注画面を1本作っただけなのか、基幹全体を作ったのかが分かりません。実績は、取引形態（在庫販売・直送・受託在庫）、得意先数、EDI接続先数、担当した工程の4点で聞くと中身が見えます。

守秘義務で社名を出せない会社は多いので、社名は求めなくて構いません。「得意先300社・EDI接続8社・要件定義から保守まで担当」のように規模と範囲を言えるかを見ます。担当範囲が開発工程だけで、要件定義を元請が行っていた実績は、卸の業務知識の証明にはなりません。

卸売業システムの見積書で金額が膨らむ箇所と相見積もりの具体的な比べ方

相見積もりを総額で比べると、作業範囲の抜けている会社が安く見えます。卸の案件では、金額がぶれる行がほぼ決まっているので、その行だけを横に並べて比較してください。依頼手順や契約全般の流れは業務システム開発の外注先はどう選ぶ？依頼手順と発注前準備・失敗回避を解説にまとめています。

単価マスタと売掛残高のデータ移行工数が見積で過小になりやすい理由

卸の現行システムには、得意先×商品の単価が数万件単位で溜まっていることがあります。期限切れの特売単価や取引の止まった得意先の単価が混ざり、そのまま移すと新システムの優先順位ルールと衝突します。

見積で「データ移行一式」としか書かれていない場合は、移行前の単価の棚卸しを誰が行うのか、売掛残高を締め日のどの時点で切り替えるのか、移行リハーサルを何回行うのかを確認してください。この3点が書かれていない見積は、稼働直前に追加費用が発生する可能性が高いものです。

EDI取引先ごとの接続試験と帳票の本数で見積額がぶれる構造と確認法

EDIは接続先の小売チェーンや取引先ごとに、手順、メッセージの版、受信時刻、テスト日程が異なります。開発会社の作業は接続先の数にほぼ比例して増えますが、見積では「EDI連携」の1行にまとめられがちです。

帳票も同様で、得意先指定の納品書や請求書の様式が10種類を超える卸は珍しくありません。見積を比べるときは、EDI接続先数と帳票の本数を発注側から明示し、各社に1件あたりの工数を書かせると、範囲の抜けがすぐに分かります。

要件定義だけを先に別契約にする多段階発注と準委任・請負の切り分け方

卸の業務知識を見極める確実な方法は、要件定義だけを先に発注することです。IPAの情報システム・モデル取引・契約書（第二版）は2020年12月22日に公開され、見直しポイントとして「プロジェクトマネジメント義務及び協力義務」と「システム開発における複数契約の関係」を挙げています（ダウンロードファイルは2025年4月8日更新）。工程ごとに契約を分ける考え方は、このモデル契約で整理されています。

要件定義は成果物の中身が発注側の判断で変わるため準委任、仕様が固まった設計・開発は請負、と分けるのが一般的な組み方です。要件定義の成果物を見てから開発の本契約を結べば、卸の理解が浅い会社とは本契約の前に別れられます。要件定義を別契約にしたがらない会社は、その理由を聞いておくと判断材料になります。

受託開発会社に頼むべき卸と開発会社探しをやめて標準品で回すべき卸の条件

ここまでの見極めは、受託開発会社に頼むと決めた後の話です。そもそも受託開発が要るかどうかを、条件で切り分けます。

受託開発会社へ依頼すべき卸の条件は価格・受注・連携のうち二つ以上

次の3条件のうち二つ以上に当てはまる卸は、パッケージの追加開発より受託開発会社への依頼が向いています。一つ目は、掛率・数量段階・特売・リベートが重なる単価体系で、主要得意先の取引が標準機能の例外に当たること。二つ目は、FAX・Web・複数のEDIが混在し、受注入口ごとに取り込みの作り込みが要ること。三つ目は、倉庫管理、会計、ECなど既存の外部システムとの連携が5本以上あり、連携仕様を自社で決めたいことです。

この場合、基幹全体を同じ設計思想で作れる受託開発会社に要件定義から任せるほうが、パッケージに追加開発を重ねるより保守の手間が読みやすくなります。一創の流通システム開発では、卸・小売の受発注や販売管理を要件定義から受託しています。

開発会社を探す前に止めるべき場面と2028年末のINS期限から逆算する順序

3条件のうち当てはまるのが一つ以下なら、開発会社探しはいったん止めてください。標準パッケージで業務が回る可能性が高く、受託開発は過剰投資になります。

業務の決まりが社内で固まっていない場合も同じです。担当者ごとに単価の付け方や締めの扱いが違う状態で開発会社を呼んでも、要件定義が社内調整の場になり、準委任の費用だけが積み上がります。先に価格と請求のルールを文書にし、例外を数えてから声をかける順番が妥当です。

INSネット経由のEDIが残る卸だけは例外で、補完策の提供終了予定の2028年12月31日から逆算すると、基幹刷新とEDI移行を同時に進める時間が足りなくなることがあります。その場合は基幹の作り直しを待たず、EDIの受け口だけを先に切り替え、基幹は後から段階的に作り直す順序を開発会社と相談するのが現実的です。

卸売業のシステム開発会社選びと見積・契約に関するよくある質問

卸売業や商社の基幹システムを外部の開発会社に任せるときに、発注側から多く聞かれる質問をまとめました。

卸売業のシステム開発会社は卸の導入実績がない会社でも任せられますか？

任せられる場合はありますが、条件付きです。卸の実績がない会社でも、流通や小売の受発注、EDI連携を経験していれば、価格や請求の決まり方を短期間で理解できます。判断の目安は、本記事の8つの質問に対して聞き返しが出るかどうかです。聞き返しがなく一般論で答える会社には、要件定義だけを先に発注し、その成果物を見てから本契約を決めると失敗の幅を抑えられます。

卸売業の販売管理システムを受託開発するときの費用は何で決まりますか？

費用を大きく左右するのは画面の数より、例外処理の数です。具体的には、単価体系の層の数、締め日の種類、EDI接続先の数、得意先指定の帳票の本数、外部システムとの連携本数、移行するマスタと残高の量で決まります。相見積もりを取るときは、これらの数を発注側から示し、各社に同じ前提で見積もらせると比較できる金額になります。

開発会社への相見積もりは何社に出し、どの順番で比べればよいですか？

依頼先のタイプを先に1〜2種類に絞り、その中で3社程度に出すのが現実的です。比べる順番は、最初に商談での質問への回答、次に見積のデータ移行とEDI接続試験の行、最後に総額です。総額から比べると、作業範囲の抜けた見積が安く見えて選ばれやすくなります。要件定義を別契約にできるかどうかも、この段階で各社に確認しておきます。

商社と卸売業ではシステム開発会社に求める要件がどう違いますか？

国内の卸売業は掛率や締め請求、小売EDIへの対応が中心になるのに対し、商社は輸出入に伴う多通貨、為替予約、三国間貿易、与信管理の比重が大きくなります。そのため商社の場合は、貿易実務と外貨建ての会計処理を理解している開発会社かどうかも、追加で確かめるべき事項です。商社の販売管理の要件は、関連記事の商社向けの解説で詳しく整理しています。

INSネットを使うEDIが残っている場合、開発会社にはいつ相談すべきですか？

早いほど選択肢が残ります。NTT東日本の案内では、INSネットの補完策は2028年12月31日に提供を終える予定です。EDIの切り替えには、接続先ごとの日程調整と接続試験が要り、接続先が多いほど期間が延びます。基幹システムの刷新を予定しているなら、EDIの受け口だけを先行して切り替えるか、刷新と同時に行うかを、要件定義の初期に開発会社と決めておくと手戻りが減ります。