流通BMS移行の費用と補助｜小規模な受注側が取引先に返答する前に確認すること

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

B2B EC-COLUMN

取引先から流通BMSを求められたら、返答の前に確かめる3点

取引先の小売から「流通BMSで受発注をお願いしたい」と言われたものの、いくらかかるのか、補助金を当てにしてよいのかが分からず、返事を保留している。
そんな場面では、金額を調べる前に、何を・どの方式で・いつまでに対応するのかを取引先に確かめることが先です。
範囲が決まれば、発注から支払までの6業務に沿って自社の作業と費用項目を分け、Web-EDI・ASP/SaaS・自社改修を同じ軸で比べられます。
補助は見積りが出てから制度の対象者と対象経費に当てはめます。
補助なしでも進められる形を用意しておけば、返答の道筋が立ちます。

何を（対応する業務とメッセージの範囲）

流通BMSは、小売と卸・メーカーの間の受発注などのやり取りを、業界で決めた共通の形式（標準メッセージ）で行うための仕様です。
基本形は発注・出荷・受領・返品・請求・支払の6業務を対象とし、8種の標準メッセージが定められています²。
2025年の推計では、流通BMSを導入した卸・メーカーは21,600社以上で、半年間で700社以上増えたとされています¹。

ただ、標準が6業務を定めていることと、自社がそのすべてに対応しなければならないことは別の話です。
取引先が発注データだけを送ってくるのか、出荷や請求のデータも返してほしいのかによって、自社の作業は大きく変わります。
同じ「流通BMSで」という依頼でも、受け取るだけの範囲と、返す範囲まで含む場合とでは、見積りの前提がまったく違ってきます。

仕様の版も、最初に聞いておくと後の手戻りが減ります。
基本形はVer2.2.2が公開されています¹。
取引先がどの版を前提にしているかは、後でベンダーの製品が対応しているかを照合するときの基準になります。

どの方式で（Web-EDI・EDIサービスなど）

流通BMSでは、通信回線が公衆回線からインターネットへ変わり、Web-EDIにも対応しています²。
つまり、取引先がどの方式を想定しているかで、自社が用意するものが変わります。
取引先が用意した画面から受注データを見る形を考えているのか、自社側でEDIサービスを契約して接続することを求めているのかで、検討すべき選択肢が絞られます。

方式の指定がない場合でも、取引先が使っている通信手順は聞いておく価値があります。
後で比べるASP/SaaSなどのサービスは、対応している通信手順が製品ごとに決まっており、取引先の手順と合っていることが選ぶ前提になるからです。

いつまでに（期限とテストの時期）

期限は二つに分けて聞くと、計画が立てやすくなります。
一つは本番で切り替える時期、もう一つは接続テストを始める時期です。
テストは取引先との日程調整が必要になるため、本番の期限だけを聞いて逆算すると、ベンダーとの契約や設定がテストの開始に間に合わないことがあります。

対応が必須なのか、期限がいつなのかは、取引先ごとの要請で決まります。
流通BMSが業界の標準だからといって、どの小売も同じ期限を設けているとは言えません。
複数の小売と取引している場合は、要請してきた相手ごとに範囲・方式・期限を分けて記録しておくと、後で方式を一つにまとめられるかを判断しやすくなります。

FAX・旧EDIを使っている場合の確認

いまFAXや電話で受注しているなら、変わるのは注文の受け取り方そのものです。
FAXで届いた注文を見て、自社の台帳や販売管理に打ち込んでいる場合、注文がデータで届くようになると、その転記をどこまで減らせるかが方式選びの論点になります。
移行後もしばらくFAXでの受注を併用できるかは取引先次第なので、切り替え期間の扱いも一緒に聞いておきます。

電話回線を使う旧来のEDIでやり取りしている場合は、回線側の事情も確かめます。
2018年の報道では、NTTの固定電話網のIP網移行に伴い、ISDNのディジタル通信モードが2024年に終了するとされ、ISDNを使うことの多かったEDIはインターネットを使う方式への移行が必要と指摘されていました⁷。
同じ報道では、対策が間に合わない企業向けに期間限定の補完策を提供する方針も示されていました⁷。
現在の提供状況はこの報道からは分からないため、自社の回線がどの状態にあるかは、契約している回線事業者に確かめることになります。

受注側で発生する作業と費用項目を、6業務ごとに分ける

受注データの受信と取込

取引先から範囲を聞けたら、次は自社の側でどんな作業が生まれるかを並べます。
金額は提供元ごとに違うため、ここでの目的は相場を知ることではありません。
見積りを依頼するときに「この作業の費用を出してほしい」と項目で示せるようにすることです。
項目がそろっていれば、複数のベンダーの見積りを同じ並びで比べられます。

6業務のうち、受注側が受け取る中心は発注です。
発注データを受信する作業と、そのデータを自社の販売管理や基幹システム（受注・在庫・請求などを管理する社内の中心的な仕組み）へ取り込む作業は、分けて考えます。
受信だけなら、届いたデータを画面で見て処理する形もあり得ます。
取込まで含めると、データの項目を自社の商品コードや取引先コードに合わせる設定が加わり、そのぶん初期の作業が増えます。

受領・返品・支払は、商品を受け取った取引先側の処理に関わる情報です。
自社では、請求との突き合わせや入金の確認に使う場面が考えられます。
受け取ったデータをどこで照合するのか、いまの照合を紙のままにするのかを決めておくと、見積りの項目に入れるかどうかを判断できます。

出荷・請求データの作成と送信

受注側が返すのは、主に出荷と請求のデータです。
出荷のデータは、どの注文に対して何をどれだけ出したかを取引先へ伝えるもので、受け取った発注データと対応付けて作ることになります。
請求のデータも同じく、どの取引に対する請求なのかを取引先が照合できる形で作ります。

ここで費用の掛かり方が分かれるのは、データを手で作るのか、自社のシステムから出力するのかです。
画面に手で入力する形なら、システムの改修は少なく済みますが、出荷のたびに数量や商品を打ち込む作業が残ります。
自社システムから出力する形なら、出力の仕組みを作る費用が初期にかかる代わりに、販売管理に入れた内容を改めて打ち込む転記はなくなります。
どちらが合うかは、一日に返すデータの件数と、担当者がその入力にどれだけ時間を割けるかで変わります。

接続テストと取引先ごとの調整

本番の前には、取引先との接続テストがあります。
実際に送受信したデータが取引先の仕組みで正しく読めるかを確かめ、ずれがあれば設定を直す作業です。
テストの支援がベンダーの基本料金に含まれるのか、別の費用になるのかで総額が変わるため、見積りでは独立した項目にしてもらうと比べやすくなります。

取引先が複数ある場合、同じ流通BMSでも、使うメッセージや運用上の取り決めが取引先ごとに違う可能性があります。
取引先が一社増えるたびに設定とテストが発生するのか、追加の作業が少なく済むのかは、二社目以降の負担を左右します。
いま要請が一社だけでも、ほかの取引先から同じ話が来る見込みがあるなら、契約前に聞いておきたい点です。

保守・運用と契約

導入した後も、毎月の利用料や保守、仕様の版が改定されたときの対応などの費用が続きます。
初期費用だけを比べると、運用が始まってからの負担を見落とします。
見積りを依頼するときは、初期にかかる作業と、毎月・毎年続く費用を分けて出してもらうと、方式ごとの違いが見えやすくなります。

契約期間や、途中で方式を変えるときの条件も費用の一部です。
最初は小さく始めて、取引量が増えたら仕組みを広げたいと考えている場合、その時点で契約をどう変えられるかが分からないと、後で想定外の出費になることがあります。

Web-EDI・ASP/SaaS・自社改修を、作業の負担で比べる

3方式の比較表

費用項目が並んだら、それを誰が担うかで方式を比べます。
方式の違いは、料金の高い安いより、どの作業を自社で持ち、どれを事業者に任せるかの違いとして見ると、自社に合うかを判断しやすくなります。

ASP/SaaSは、ネットワーク、ハードウェア、ソフトウェアの環境、システムの運用をプロバイダーがまとめて提供する形です³。
自社でサーバーや通信の仕組みを持たずに済む代わりに、サービス事業者との契約と月々の利用が中心になります。

Web-EDIは、Web上の画面を通じて受発注のデータをやり取りする方式で、流通BMSの標準仕様でも対応が記載されています²。
画面の使い勝手や、データを自社のシステムへ取り込めるかどうかは提供元によって異なります。
取引先が用意する画面なのか、別の提供元のサービスなのかを確かめた上で比べることになります。

自社改修は、自社の販売管理や基幹システムに、流通BMSでのやり取りを組み込む形です。
受注データの取込から出荷・請求データの出力までを自社の仕組みの中で完結させられる一方、改修と保守を自社またはベンダーとの契約で担うため、初期の負担は大きくなり得ます。
具体的な費用の構成は、改修を依頼するベンダーに内訳を出してもらって初めて分かります。

表の中で判断が最も分かれるのは、基幹システムとの連携をいま必要とするかどうかです。
受注件数が少なく、担当者が画面を見て処理できる量であれば、連携のための費用をかけずに始める考え方があります。
反対に、受け取った注文を毎日販売管理へ打ち直している状態なら、連携の有無が日々の転記の量を左右し、初期費用をかける理由になります。

取引先ごとの個別対応の行は、どの方式でも「確認」が残ります。
これは方式の弱点というより、個別の取り決めが取引先の側で決まるためです。
方式を選べば個別対応がなくなるわけではないので、取引先が増える見込みがある場合は、追加のたびに何が起きるかを方式ごとに聞き比べることになります。

ロゴ許諾製品の見方

ASP/SaaSなどの製品を探すと、流通BMS協議会のロゴマーク使用許諾製品の一覧に行き当たります。
掲載されているのは、協議会が対応するバージョンと通信手順を認めた製品で、各製品には対応するBMSのバージョン（基本形・生鮮・百貨店など）と通信プロトコルが明記されています³。

この一覧は、流通BMSの仕様に合っているかを確かめる入口として使えます。
一方で、一覧に載っていることは、料金が安いことや、取引先がその製品を指定していることを意味しません。
一覧から分かるのは、取引先が求める版と通信手順が製品の記載と一致しているかどうかまでで、その先の費用や支援の範囲は見積りで比べることになります。

補助は『小規模』の定義と対象経費で使えるかが決まる

自社が小規模事業者に当たるか

方式の比較と見積りの項目がそろってから、補助を当てはめます。
先に補助の可否を気にすると、使えるかどうか分からない制度に合わせて方式を選んでしまい、取引先の求める範囲とずれることがあるためです。

最初に確かめるのは、自社が「小規模」に当たるかどうかです。
中小企業基盤整備機構の定義では、商業・サービス業の小規模企業者は従業員5人以下とされ、工業・運送業などには別の基準があります⁴。
卸売業なら商業の区分、メーカーなら工業の区分で見ることになり、同じ従業員数でも業種によって当てはまるかが変わります。

ただし、この定義は法律に基づく一般的なものです。
補助金ごとに、対象となる事業者の範囲が公募要領で定められているため、申請を考える制度の要領で自社がどの区分に入るかを改めて確かめます。
小規模企業者に当たることと、その制度の対象経費に自社の費用が入ることは、別々の判断です。

小規模事業者持続化補助金の条件

小規模事業者向けの制度としてよく名前が挙がるのが持続化補助金で、補助上限は最大250万円です⁵。
ただ、対象となる経費は販路開拓の取組にかかるもの（チラシ、広告、店舗改装など）で、制度ページではソフトウェアやシステムの導入が対象経費として明記されていません⁵。

そのため、流通BMSへの対応費用がこの制度で補助されるとは言えません。
取引先の要請に応えて受発注の手段を変えることが、販路開拓の取組として計画に位置づけられるかどうかは、公募要領と相談先の判断によります。
申請には商工会議所・商工会への相談と計画書の確認が必須とされているため⁵、見積りの内訳を持って相談に行けば、対象になり得るかを具体的な費用で聞けます。

デジタル化・AI導入補助金の条件

もう一つの候補は、デジタル化・AI導入補助金のインボイス枠（インボイス対応類型）です。
この枠では、インボイス制度に対応し、会計・受発注・決済のいずれかの機能を1種類以上持つソフトウェアが必須とされ、ハードウェアだけの申請はできません⁶。
補助額50万円以下の区分では、小規模事業者のソフトウェアの補助率は4/5以内です⁶。

「受発注」の機能という条件は流通BMSと近く見えますが、流通BMSに対応するEDIの費用がそのまま対象になるかは、制度ページの記載からは判断できません。
検討しているサービスがインボイス制度への対応と受発注の機能という条件を満たすのか、申請の手続き上どんな要件があるのかは、ベンダーと事務局に確かめる事項です。
ここで条件を満たさないと分かれば、補助を前提にしない計画へ早めに切り替えられます。

見積り後に当てはめる順

補助の検討は、見積りを起点にすると迷いにくくなります。
対象経費に入るかどうかは、何にいくらかかるかが決まらないと聞きようがないからです。

時期の問題も見落とせません。
補助金は公募ごとに申請を受け付ける期間が決まっており、その期間や結果が出る時期が、取引先の求める切替時期と合うとは限りません。
補助を待つために移行が遅れれば、取引先への返答そのものが遅れてしまいます。
補助は使えれば負担が軽くなるものとして扱い、使えなくても進められる計画を別に持っておくと、取引先にも期限を約束しやすくなります。

補助が使えない・間に合わない場合に負担を抑える進め方

メッセージ範囲を絞る

補助が使えない、あるいは時期が合わない場合でも、移行の負担を抑える余地はあります。
ここで挙げるのは、これまでの比較から考えられる進め方の例です。
どれが使えるかは、取引先が認める範囲とベンダーの契約条件で決まります。

一つ目は、最初に対応する範囲を、取引先が求める最小限に絞ることです。
たとえば取引先が当面は発注と出荷のデータだけを求めているなら、請求をデータで返す準備は後に回せるかを相談します。
範囲が狭ければ、設定やテストの対象が減り、見積りの項目も少なくなります。
後から範囲を広げるときに追加の費用がどう掛かるかは、最初の見積りの段階で聞いておきます。

自社設備を持たない形から始める

二つ目は、自社でサーバーや通信の仕組みを持たない方式から始めることです。
ASP/SaaSであれば、ネットワークやシステム運用を事業者が提供するため³、初期に自社で設備を整える作業を避けられます。
取引先がWeb-EDIの画面を用意しているなら、それを使う形も候補になります。

その代わり、月々の利用料が続くことや、契約を変えるときの条件は事前に確かめておきます。
初期の支出を抑えても、何年か使い続けた合計で見ると負担の大きさが入れ替わることもあります。
比べるときは、初期費用だけでなく、使い続けると想定する期間の利用料を足した額で並べると判断がぶれにくくなります。

連携は後から検討する

三つ目は、基幹システムとの連携を最初から作り込まず、取引量が増えてから検討することです。
受注件数が少ないうちは、受け取ったデータを画面で確認して処理する形でも回る場合があります。
件数が増えて、販売管理への転記や出荷データの入力が担当者の負担になってきた段階で、取込や出力の仕組みを足すかを判断します。

この進め方では、最初に選んだサービスが後から連携を追加できるかを確かめておかないと、連携したくなったときに方式ごと乗り換えることになりかねません。
段階的に進めるつもりなら、将来の連携の可否と、そのときの追加費用の考え方を、最初の比較の段階で聞いておくことが手戻りを防ぎます。
また、FAXなど現在の手段をしばらく併用しながら移る形が取れるかは、取引先の判断によります。

取引先とベンダーに確認する項目を、順番に並べる

取引先への確認

ここまでの検討を実際の問い合わせに移すと、取引先へは次のことを聞くことになります。
最初に挙げた3点を、見積りに使える粒度まで細かくした形です。

• 対応するメッセージの範囲（発注だけか、出荷・請求まで返すか）
• 方式の指定（Web-EDIの画面を使うか、EDIサービスで接続するか）と通信手順
• 前提とする仕様の版
• 本番の切替時期と接続テストの時期
• 取引先独自の取り決め（個別仕様）の有無
• FAXなど現在の手段を併用できる期間

このうち個別仕様の有無は、取引先によって答えが大きく違うところです。
あるかないかだけでなく、仕様書などの形で受け取れるかを聞いておくと、ベンダーに見積りを依頼するときにそのまま渡せます。

ベンダーへの確認

ベンダーへは、方式の比較と費用の内訳に関わることを聞きます。

• 対応するBMSのバージョンと通信手順（ロゴマーク使用許諾製品の記載と照合する）
• 見積りの内訳（初期の設定、接続テストの支援、毎月の利用料、保守）
• 取引先が増えたときの追加の作業と費用
• 基幹システムとの連携を後から追加できるか
• 契約期間と、変更・解約の条件
• インボイス制度への対応と受発注の機能の有無（補助の検討に使う）

最初の項目は、候補を絞る入口になります。
取引先が求める版と通信手順に対応していない製品は、ほかの条件がよくても選べないため、内訳の比較に入る前にここで外せます。

並行して進める手順

取引先への確認とベンダーへの見積り依頼は、並行して進められます。
取引先の回答を待つ間に、ベンダーには「この範囲なら」という仮の前提で見積りを依頼し、回答が来たら前提を差し替えます。
こうすると、取引先の回答が出そろった時点で、すでに比べられる見積りが手元にある状態になります。

複数の取引先から要請がある場合は、各社の範囲・方式・期限・通信手順を一覧にすると、一つのサービスでまとめられそうか、取引先ごとに分かれるかが見えてきます。
まとめられる見込みがあれば、二社目以降の追加費用を軸に見積りを比べられます。

取引先への返答には期限があり、対応範囲・方式・補助の三つを同時に整理するのは、受発注や経理と兼任している担当者だけでは手が回りにくいためです。

取引先から届いた要請の内容と、いまの受注から請求までの流れを並べて、見積り依頼に載せる作業項目と、取引先へ追加で聞くことを整理できます。無料相談で要件を整理する

要点の整理

返答の前に確かめること	何を・どの方式で・いつまでに（本番とテストの時期）を取引先ごとに聞く
費用の分け方	6業務に沿って、受信と取込・出荷と請求の送信・接続テスト・保守を別項目にし、初期と継続を分ける
方式の比べ方	自社で持つもの、基幹システム連携、取引先ごとの個別対応、契約・保守の4軸で比べる
ロゴ許諾製品	対応バージョンと通信手順の照合に使う。料金や取引先の指定を示すものではない
補助の当てはめ	見積り後に、小規模の区分・対象経費・申請時期を公募要領と相談先で確かめる
補助に頼れない場合	範囲を絞る、設備を持たない方式から始める、連携は取引量に応じて検討する

見積りがそろっても、補助の対象になり得るか、段階的に進めるならどこから始めるかは条件が絡み合い、一人では決めにくいためです。 集めた見積りと取引先の回答を同じ軸で並べ直し、補助なしでも進められる形と、相談先へ持っていく質問を確かめられます。

よくある質問

FAXや電話で受発注している会社が、流通BMS対応を求められた場合、最初に取引先へ聞くことは何ですか。

何を（どのメッセージの範囲か）、どの方式で（Web-EDIの画面か、EDIサービスでの接続か）、いつまでに（本番の切替時期と接続テストの時期）の3点です。
FAXから移る場合は、切り替え期間中にFAXでの受注を併用できるかも合わせて聞いておくと、社内の段取りを組みやすくなります。

従業員5人以下の卸売業は、持続化補助金を流通BMS対応に使えますか。

中小企業基盤整備機構の定義では、商業・サービス業で従業員5人以下は小規模企業者に当たります⁴。
ただし、持続化補助金の対象経費は販路開拓の取組にかかるもので、制度ページにはソフトウェアやシステムの導入が明記されていません⁵。
使えるとは言えないため、見積りの内訳を持って商工会議所・商工会に相談し、公募要領と照らして判断します。

Web-EDIとASP/SaaSの違いは何ですか。どちらも自社でシステムを持たずに済みますか。

ASP/SaaSは、ネットワーク、ハードウェア、ソフトウェアの環境、システムの運用を事業者がまとめて提供する形で、自社で設備を持たずに済みます³。
Web-EDIはWeb上の画面を通じてやり取りする方式で、標準仕様でも対応が記載されています²。
Web-EDIで自社側に何が必要か、データを自社システムへ取り込めるかは提供元によって異なるため、取引先や提供元に確かめます。

取引先が複数ある場合、方式を一つにまとめられますか。個別仕様はどこで確認しますか。

まとめられるかどうかは、各取引先が求める方式・仕様の版・通信手順・個別の取り決めがそろうかで決まります。
個別仕様の有無は取引先ごとに聞くしかありません。
製品側の対応状況は、ロゴマーク使用許諾製品に明記された対応バージョンと通信プロトコルで照合できます³。

補助金の申請より先に契約・発注してもよいですか。

事前の申請が必要か、いつ以降の発注が対象になるかは制度ごとに異なるため、公募要領と事務局で確かめてから契約するのが安全です。
確かめないまま契約すると、補助の当てが外れるおそれがあります。
取引先の期限に補助の手続きが間に合わない場合は、補助なしで進める計画に切り替えることも考えます。

1. 1　出典：流通システム標準普及推進協議会（GS1 Japan）「流通BMS トップページ（第28回 卸・メーカーの流通BMS導入企業数推計）」（2025年）
2. 2　出典：流通BMS協議会（GS1 Japan）「流通BMS標準仕様（基本形・百貨店版）」（2025年）
3. 3　出典：流通BMS協議会（GS1 Japan）「ロゴマーク使用許諾製品（サービス：ASP/SaaS）」（2026年）
4. 4　出典：独立行政法人中小企業基盤整備機構「中小企業者・小規模企業者の定義」（2026年）
5. 5　出典：中小企業庁（ミラサポplus）「小規模事業者持続化補助金」（2026年度）
6. 6　出典：独立行政法人中小企業基盤整備機構「デジタル化・AI導入補助金2026（インボイス枠・インボイス対応類型）」（2026年）
7. 7　出典：INTERNET Watch（インプレス）「ISDNの『ディジタル通信モード』終了は2024年1月」（2018年）