「得意先別の実質粗利をちゃんと見たい、でもリベートやセンターフィーを引いた後の数字を出そうとすると毎月Excel調整で消耗する」。そんな相談を月に何件かいただきます。
卸売・商社のデータは、得意先側のEDI/EOSと仕入先側のERP、自社WMSの在庫がそれぞれ別テーブルに閉じており、共通の商品マスタとリベート契約で横串を通す仕組みが業界的に定着していません。だから月次の実質粗利算定が手作業に寄り、赤字取引の是正判断が翌々月まで先送りになりやすい構造があります。
そこで本記事では、卸売・商社の営業本部と情シスが本部データ基盤の要否と進め方を判断できるよう、実現アプローチと費用相場を整理しました。データ基盤全体の費用の内訳はすでにデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説で扱っているので、こちらは卸売特有のデータ構造とスモールスタート設計に軸足を置いています。
卸売・商社でデータの統合が特に大変なのは、他業種と比べても「上流（仕入先）」「下流（得意先）」「自社在庫」の3層が別々の言語で動いており、共通の商品コードや取引条件マスタでつなぎ切れていないことに原因があります。まず、この構造から見ていきます。
図のように、卸売・商社のデータは大きく3つの層に分かれています。
下流（得意先向け） は販売の現場です。大手小売チェーンは流通BMSやJCA手順のEDIで受注をもらい、地域スーパーはWebEOS、飲食チェーンは独自フォーマットのExcel、個人商店はFAX、というのが2026年時点でも一般的な現実です。得意先ごとに商品コード（自社SKU・JAN・GTIN・得意先の独自コード）の紐づけルールが違い、単価も契約リベートも異なります。
上流（仕入先向け） は調達の現場です。メーカーとの取引はEDIやERP連携、輸入商材はインボイス＋通関書類、スポット仕入はメール発注、というように仕入経路もフォーマットも分散します。仕入単価・リベート契約・支払条件が仕入先ごとに違い、期末の仕入割戻や戻し金がさらに実質原価を動かします。
自社在庫と物流 は中間層です。自社倉庫のWMS、3PL倉庫の在庫データ、預り在庫、通過型物流（TC）、店舗直送（DC）、コンテナ単位のインバウンドと、在庫が置かれる場所も所有権もバラバラです。ロケーション別・ロット別・賞味期限別に持たないと管理できない商材（食品・医薬・化粧品）もあります。
この3層のデータを、営業本部が「得意先A向けに商品Bを提案するとき、実質粗利はいくらで、在庫と入荷予定はどうなっていて、過去3か月の販売推移とA社の類似店舗の実績はどうか」と1画面で見たい、というのが本来のあるべき姿です。しかし販売管理・WMS・仕入EDI・リベート管理台帳が別々のシステムに閉じているため、この一発の問いに答えるのに何時間もかかるのが実態です。
さらに厄介なのが、次の3点です。
商品マスタの一意性がないのが卸売の最大の悩みです。自社の商品コード、JANコード、GTIN、得意先ごとの独自コード、仕入先の型番。これらが1対Nで絡み合い、廃番・改廃・パッケージ変更のたびに紐づけメンテが発生します。マスタが揃わないと売上集計も在庫回転も正しく出ません。
リベート・センターフィー・戻し金が実質粗利を見えなくするのも卸売特有の構造です。表面上の販売単価から、得意先ごとのボリュームリベート、大手小売のセンターフィー、期末の仕入割戻、返品による戻し、物流費の配賦、を差し引かないと実質粗利は出ません。これらは販売管理システムの本体テーブルではなく、契約書や別ファイル、Excelで管理されていることが多く、月次締めの手作業で調整しているのが実情です。
返品と与信のリスク管理が別階層に閉じているのが3点目です。返品率・不良品発生率・売掛回転日数・与信残高は、営業判断の重要な材料ですが、販売管理システムと売掛管理システムが別だったり、与信管理をExcelで別建てしていたりすると、営業本部が瞬時に把握できません。結果として与信超過や不良取引先への露出が後追いになります。
こうした構造があるため、扱い得意先と仕入先とSKUが増えるほど、卸売・商社のデータは「販売管理BIで表面売上は見えるが、実質粗利と在庫回転と与信を横断した経営判断ができない」という壁にぶつかります。データ基盤の全体像そのものを押さえたい方は、データ基盤とは？企業が導入すべき3つの理由と構成要素を解説を先に読んでいただくと、この記事の話がより具体的に感じ取れます。
「うちは販売管理システムのBIオプションで足りている」「Excelでリベート調整して月次を出せている」と言う卸売の営業本部は多いのですが、じわじわとひずみが出ているケースがほとんどです。次の3つで、統合検討の時期を判断できます。
これが最もはっきりした判断基準です。販売管理システムの月次締め後、リベート・センターフィー・戻し金・物流費配賦をExcelで調整して「実質粗利」を出すのに、営業本部で3営業日以上を要しているなら、データ基盤化を検討するフェーズに入っています。中堅の食品卸・日用品卸では、この作業に月40〜60時間を使っているケースが珍しくありません。
問題は工数の大きさだけではありません。「月次締めが遅れる → 経営会議で使う数字が10営業日目にしか出ない → 赤字取引の是正判断が翌々月まで先送りされる」というループが定着してしまうことが本当の損失です。実質粗利がリアルタイムに出れば、赤字取引や採算悪化SKUの是正が月単位から週単位に早まります。
卸売業では商品点数が数万〜数十万SKUに達し、季節性・トレンド・パッケージ改廃・廃番リスクを抱えながら在庫を持ちます。「動かなくなったSKU」の発見が月次棚卸のタイミングまで遅れると、値引き販売でも捌けない在庫が積み上がり、期末に評価損として跳ね返ります。
回転日数の悪化・入荷予定と受注推移の乖離・実質粗利がマイナスになった商品、こうしたシグナルを日次で拾えるかどうかが、棚卸資産の健全度を左右します。中堅卸で棚卸資産が売上高の10〜15%を占めているなら、この不動在庫の管理が経営に与えるインパクトは非常に大きくなります。
大手小売の本部バイヤーへの棚割提案、飲食チェーンへの新商品提案、地域スーパーへのカテゴリ提案。これらの提案営業では、「A得意先のカテゴリ別売上推移」「類似規模の他得意先での売れ筋」「季節性を考慮した推奨SKUと発注ロット」といった分析が必須です。
これを営業担当が販売管理システムのCSV出力からExcelで個別に組み立てていると、1提案あたり3〜5時間の準備工数が発生し、しかも担当ごとに集計軸がバラバラで再現性がありません。営業本部として提案の質を揃えるには、共通のデータ基盤とダッシュボードから引ける状態が必要です。
3つのうち2つ以上に当てはまれば、卸売・商社のデータ基盤化を検討するフェーズに入っています。逆に、得意先数が20社以下・扱いSKUが1万以下で販売管理BIのテンプレートで足りているうちは、Excelとテンプレート整備でしばらく戦えます。業種横断のExcel限界サインについては、Excel集計が限界になったら｜スプレッドシートからデータ基盤への移行にもまとめています。
「統合」といっても、実現手段はいくつかあります。卸売・商社でよく検討されるのは、次の3つです。それぞれ費用感と柔軟性がまったく違います。
大蔵大臣・商奉行・スーパーカクテル・SMILE・PCA商魂などの販売管理システムに付属するBIオプションや、卸売向けに特化した集計SaaSを使う方法です。単一の販売管理システムで完結しているなら、追加設定で得意先別売上・商品別売上のダッシュボードを出せます。
弱点は、リベート・センターフィー・戻し金・物流費配賦を組み込めない（あるいは組み込むと極端に複雑化する）ため、実質粗利の可視化に届かないことです。WMSや仕入EDIとの統合、AIによる需要予測や与信スコアリングも、テンプレートの範囲を超えるとほぼ手が出ません。営業本部の日次運用の入り口としては使えますが、経営判断のダッシュボードにするには物足りないケースが多いのが実情です。
販売管理システムからの日次CSVや、リベート管理Excel、WMSのエクスポートをGoogle DriveやスプレッドシートやAccessに集約し、Looker StudioやTableauで可視化する方法です。BIツール単体の月額は数千円〜と安く、既存のExcel運用に近い形で始められます。
弱点は、得意先数と仕入先数とSKU数が増えると、スプレッドシートの行数上限や更新スピードにぶつかることです。特に日次で数万〜数十万件の受注明細をさばく規模になると、Google Sheets/Excelは実質的に運用不能になります。またリベート契約が数十件を超え、契約条件（達成率別・カテゴリ別・期間別）が複雑になると、Excelでの計算ロジック管理が属人化して事故のリスクが上がります。BI選定はPower BI・Tableau・Looker比較｜5軸の違いと選び方【2026年版】にまとめています。
複数の販売管理・WMS・仕入EDI・リベート契約マスタ・与信管理を、本部のクラウドDWH（BigQuery・Snowflake・AWS Redshift）に自動集約し、dbtで統合モデルに変換し、BIで可視化する方法です。もっとも柔軟で、実質粗利・在庫回転・与信・提案営業の材料を1つの基盤から取り出せます。
費用は3アプローチで最も高く見えますが、売上100億円を超える中堅卸では、不動在庫削減による棚卸資産の10〜15%圧縮（年数千万円のインパクト）と実質粗利可視化による赤字取引是正で、1〜2年での回収が現実的です。データ基盤構築の見積もりの内訳はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説でくわしく整理しています。
3つのアプローチの選び方は、リベート・センターフィー込みの実質粗利を経営指標として使いたいか、そして将来の需要予測や自動発注まで見据えるかで決まります。表面売上の管理で当面足りるならアプローチ1、実質粗利を見たいならアプローチ2以上、複数販売管理・WMS・与信・提案営業まで統合するならアプローチ3、というのが判断の骨格です。
「初期500万〜1,500万円」と聞くと大きく感じますが、卸売業が抱えている不動在庫と赤字取引の見えないコストと比べると、判断は変わります。
棚卸資産の10〜15%削減が、卸売業のデータ基盤化で最も大きな効果です。売上100億円の中堅卸で、棚卸資産が売上高の12%（12億円）を占めているとします。データ基盤で日次の回転率・滞留日数・実質粗利マイナスSKUを可視化し、値引き・返品・仕入抑制のアクションが早まると、棚卸資産を10〜15%削減できるケースが実務では多くあります。
金額に直すと棚卸資産1.2億〜1.8億円の圧縮です。これは決算書上の資産圧縮でありキャッシュフローの改善であり、しかも評価損リスクの低減でもあります。年間の効果として1,000万円以上のインパクトが継続的に出ます。
実質粗利可視化による赤字取引の是正も継続的に効きます。中堅卸のポートフォリオを実質粗利で見ると、上位20%の得意先が粗利の80%を稼ぎ、下位10%は継続赤字、という80:10:10のような分布になっているのが典型です。データ基盤で赤字取引を可視化し、値上げ交渉・条件見直し・撤退判断が早まれば、営業利益率が0.5〜1.5ポイント改善するインパクトがあります。
営業本部の集計工数削減も定量効果として計算できます。実質粗利算定に月40〜60時間、提案営業の材料集計に営業10人×月10時間、合計で月140〜160時間を人件費換算すると、月40万〜60万円、年間480万〜720万円のコストが集計作業に消えています。
提案営業の質改善は定量化しづらいものの、大手小売の棚割提案や飲食チェーンへのカテゴリ提案で、データに基づく提案ができる営業と勘に頼る営業では、成約率・棚シェア獲得率に明確な差が出ます。中堅卸の営業本部長からは「データが揃った瞬間、若手営業でもベテラン並みの提案書が出せるようになった」という声を聞くことが多くあります。
これらを合計すると、売上100億円規模の中堅卸でExcel＋販売管理BI止まりで発生している見えないコスト・機会損失は年5,000万〜1億円規模になります。500万〜1,500万円の初期投資は、この見えないコストに対して1〜2年で回収できるレンジです。
内製と外注のどちらで進めるかは、データ基盤は内製と外注どっち？判断基準とハイブリッドの進め方で判断軸を整理しています。卸売の場合、データエンジニアの採用が難しいことに加え、EDI/EOSの業界慣行やリベート契約の複雑さに詳しい人材が市場にほとんどいないため、業務ドメインを持つ外部パートナーと組んで立ち上げる企業がほとんどです。
小売や外食など他の業種のデータ基盤と比べて、卸売・商社で特に設計を丁寧にすべきポイントが3つあります。ここを甘く見ると、基盤を作った後に「思ったより使えない」となりがちなので、事前に押さえておいてください。
自社SKU・JAN・GTIN・得意先ごとの独自コード・仕入先の型番、これらの多対多マッピングをどこで持ち、いつ更新するかの設計が、卸売データ基盤の成否を分けます。
推奨される設計は、商品マスタを1つの中央テーブル（dbtのdim_product）で持ち、コードマッピングを別の関連テーブルで管理する形です。廃番・パッケージ改廃・新商品追加のたびに、マッピングテーブルを更新するオペレーションを月次で決めておきます。得意先ごとの独自コード管理は営業事務が持つケースが多く、そのオペレーションを基盤側に取り込む設計を最初にやり切ることが重要です。
得意先ごとのボリュームリベート、大手小売のセンターフィー、期間限定の販促協賛、期末の仕入割戻、これらは契約書の紙ベースで管理されていることが多く、Excelで期末に手計算しているのが実情です。
データ基盤側では、リベート契約を「契約マスタ（dim_rebate_contract）」と「達成判定ロジック（fact_rebate_calculation）」の2層でコード化します。契約条件の変更履歴を保持し、いつからいつまでの取引にどの条件が適用されるかを日付軸で管理します。これができると、月次締めのExcel調整がゼロになり、実質粗利が日次で出せるようになります。
与信残高・与信超過アラート・返品率・不良品発生率は、営業判断の重要な材料ですが、販売管理システムと別の与信管理システムやExcelに閉じているケースが多くあります。データ基盤でこれらを統合すると、「A得意先は売上は伸びているが返品率が悪化・与信残高が枠の90%」といったシグナルが日次で見えるようになります。
営業本部と経理・与信管理部門の両方が、同じ数字を見て判断できる状態を作ることが、卸売業のガバナンスにとって非常に大きな意味を持ちます。データマネジメントとしての取り組み方はなぜ今データマネジメントが必要なのか？DX成功の本質を解説も参考にしてください。
卸売・商社のデータ基盤化は、いきなり全得意先・全仕入先・全システムを対象にすると要件が膨らんで頓挫します。最初の運用開始までを3〜6か月に区切ったスモールスタートで進めるのが、実務では失敗しにくい進め方です。
ここで欲張らないことが最大のコツです。最初は「営業本部が日次で見る実質粗利ダッシュボード」を1つ作り切る、と決め打ちします。全社の需要予測や自動発注は次フェーズに回します。
この段階でデータの品質チェック（欠損・重複・異常値）まで組み込んでおくと、後戻りが少なくなります。データパイプラインの考え方はデータパイプラインとは？ETLとの違いと仕組みを図解で解説で整理しています。
このタイミングで、実際の月次締めを新旧併走で回します。Excelと基盤の数字が一致することを確認してから、Excel運用を段階的に卒業します。
ここまでで最初の運用が回り始めます。その後、BigQuery ML / Snowflake Cortex での需要予測、EDI受注の自動化、生成AIによる商品提案書ドラフト、と段階的にスコープを広げていくのが、無理のない進め方です。需要予測フェーズに進む際の必要データ・基盤構成・費用感はAI需要予測を始めるためのデータ基盤と進め方で、全体スケジュールの目安はデータ基盤構築の期間はどのくらい？規模別・工程別スケジュールの目安でも工程別に解説しています。
卸売・商社のデータ基盤について、要点を整理します。
卸売・商社のデータ基盤化で本当に効いてくるのは、月次締めが早くなることよりも、営業本部・経理・与信管理・物流が同じ実質粗利と在庫回転を同時に見て、赤字取引と不動在庫の兆候に翌月ではなくその日のうちに手を打てる状態を作れることではないでしょうか。日単位で機会損失と評価損を減らせれば、営業利益率とキャッシュフローの改善はすぐに現れます。
まずは自社が実質粗利算定にどれくらいの時間を使っていて、棚卸資産と赤字取引がどれくらいの規模になっているかを棚卸ししてみるところから、検討を始めてみてください。
株式会社Evastでは、卸売・商社のデータ基盤構築と実質粗利の可視化を、業種特有の論点（商品マスタ統合・リベート契約のコード化・与信/返品リスクデータの統合）を踏まえてご支援しています。BigQuery／Snowflake／AWS上での本部データ基盤構築、dbtによる実質粗利モデル、EDI/EOSの統合、需要予測・自動発注までを、業種ドメインの理解とセットでご提案します。
現状の集計工数の棚卸しや、販売管理BIで足りるのか本部データ基盤が必要なのかの判断からでも構いません。3〜6か月のスモールスタートのロードマップまで一緒に描きます。
データ基盤SUUMO・HOME'S・REINS・自社CRMに物件と顧客データが分散して、反響から成約までの実質歩留まりが見えない。不動産業に固有のデータ分断を、費用相場と3つの実現アプローチで整理しました。反響ロス3〜5割改善の投資回収シナリオと、3〜6か月で本番運用に乗せるスモールスタートを、賃貸・売買・管理の3業態向けに具体化しています。
データ基盤freee会計・マネーフォワード クラウド会計のデータをBigQueryに載せる方法を、trocco・Fivetran・Airbyte・Cloud Run内製・特化型SaaSの5パターンで費用比較。月額0円〜月30万円まで、freeeプラン別のAPI制限差、非同期ジョブや締め後修正の実装落とし穴、Shopifyや広告費との突合ユースケースを稟議に使える形で整理した2026年版です。
データ基盤Shopifyの注文・顧客・在庫データをBigQueryで分析する方法を、Fivetran・trocco・Airbyte・Cloud Run内製・Stitch/Hevoの5パターンで費用比較。月0円〜月20万円まで、月商1,000万〜10億円規模のD2Cケースを想定した費用相場と、GraphQL calculated cost・Bulk Operations API・多店舗・多通貨・返品遅延・メタフィールドの実装落とし穴を整理した2026年版です。
