「NetSuiteだけで、小売からのEDIの発注を受けられるのか」
取引先の小売から「発注はEDIで受けてほしい」と言われた卸売やメーカーで、よく出る問いです。
EDI（電子データ交換）は、企業間の注文書や請求書を、決められた形式のデータでやりとりする仕組みです。
紙やFAXの代わりに、システム同士でデータを送り合います。
NetSuiteはEDIの通信そのものを標準では受け持ちません。
通信と変換はEDIサービスに任せ、NetSuiteには受注や請求の記録を置く。
この分け方が基本です。
では、NetSuiteとEDIサービスの間は、どうつなぐのか。
選択肢は3つあり、多くの会社には出発点になる1つがあります。
📌 この記事で分かること
- 流通BMSとEDIの基本と、いま見直しが進む理由
- NetSuiteとEDIの役割の分け方
- 取引先EDIとつなぐ3つの選択肢と、出発点
- 流通BMSの業務ごとに、NetSuiteのどの記録になるか
- 事前に決める4つのことと、よくある3つの失敗
流通BMSとEDIの基本
流通BMSとは
流通BMS（流通ビジネスメッセージ標準）は、小売と卸・メーカーの間でやりとりするデータの、業界共通の標準です。
流通BMSは、一般財団法人流通システム開発センターの登録商標です。
GS1 Japan（流通システム開発センター）は、流通BMSを、メッセージと通信の方式に関するEDIの標準仕様と説明しています。
発注・出荷・受領・返品・請求・支払の6つの業務で、8種類の標準メッセージが定められています（GS1 Japan、2026年9月23日確認）。
通信の方式には、JX手順・ebXML MS・AS2の3つが採用されています（ユーザックシステム）。
どれを使うかは、取引先の小売が決めます。
従来のEDIと、見直しが進む理由
流通BMSより前から使われてきたEDIもあります。
電話回線を使うJCA手順などで、「従来型EDI」と呼ばれます。
従来型EDIの多くは、NTTのINSネット（ISDN）の上で動いてきました。
NTT東日本は、INSネットの新規申込の受付を2024年8月31日に終えました。
提供そのものも、2028年12月31日に終えると発表しています。
出典はNTT東日本のニュースリリースです（2026年9月23日確認）。
同じ発表では、INSネットの「ディジタル通信モード」が2024年1月に終わったことにも触れています。
その後のデータ通信は「補完策」として提供されてきましたが、これもINSネットの提供終了とともに終わります。
そのため、流通BMSなどインターネットを使うEDIへの切り替えを、取引先から求められる会社が出ています。
基幹システムを入れ替える時期と、EDIの見直しが重なることもあります。
従来型EDIの取引先が残っている会社は、次の3つを押さえておきます。
- 取引先が、いつまでに、どの方式へ切り替える予定か
- いまのEDIサービスが、切り替え先の方式に対応しているか
- 基幹システムの入れ替えと、EDIの切り替えを同じ時期に行うか
両方を同時に変えると、問題が起きたときに原因を切り分けにくくなります。
どちらを先にするかは、取引先の予定から逆算して決めます。
Web-EDIとの違い
取引先の小売が用意したWebの画面で、発注を確認して入力する方式もあります。
これがWeb-EDIです。
Web-EDIは、画面を見て手で扱う方式です。
システム同士が直接つながるわけではないため、NetSuiteへの登録は別の手間になります。
NetSuiteとEDIの関係｜通信と記録を分ける
Oracleのヘルプは、NetSuiteでEDIを扱うときにEDIパートナーと組む前提で説明しています。
たとえば出荷の通知は、NetSuiteのデータをEDIパートナーが読み取り、EDIの文書に変換します。
出典はOracle NetSuiteのヘルプです（2026年9月23日確認）。
役割は、次のように分かれます。
| 役割 | 受け持つところ |
|---|---|
| 取引先との通信（JX手順・AS2など） | EDIサービス |
| 流通BMSの形式と自社の形式の変換 | EDIサービス |
| 受注・出荷・請求などの記録 | NetSuite |
| 在庫の引当・売掛金の管理 | NetSuite |
ベンチャーネットが確認した範囲では、Oracleのヘルプに流通BMSへの対応の記載はありませんでした。
日本の流通BMSを扱うなら、日本のEDIサービスと組み合わせる設計が現実的です。
NetSuiteの側で準備しておくこと
EDIサービスを使う場合でも、NetSuiteの側で整えておくことがあります。
- 品目：EDIの商品コードと照合できるよう、品目の情報をそろえる
- 顧客：取引先の小売ごとに、店舗や納品先をどう持つかを決める
- 価格：発注の単価とNetSuiteの価格が違ったときの扱いを決める
悩ましいのは納品先です。
小売の店舗や物流センターの数だけあります。
顧客を1社として持ち、納品先を住所で分けるのか。
店舗ごとに別の顧客として持つのか。
請求の単位と合わせて決めておきます。
日本のEDIサービスとNetSuiteの動き
EDIサービスの側にも、NetSuiteとつなぐ動きがあります。
データ・アプリケーション（DAL）は2026年8月31日、EDIの製品ACMSとNetSuiteの連携に向けた技術検証を完了したと発表しました。
国内のEDIのデータをNetSuiteへ渡し、販売と購買の管理で使えることを確かめたとしています（DAL ニュースリリース）。
これは技術検証の発表です。
製品として使える時期や接続の方法は、提供元に聞いてください。
取引先EDIとつなぐ3つの選択肢
NetSuiteと取引先EDIをつなぐ方法は、大きく3つです。
| 選択肢 | 中身 | 向く会社 | 注意点 |
|---|---|---|---|
| A. EDIサービス＋取込 | 日本のEDIサービスが通信と変換を行い、NetSuiteへCSVやAPIで取り込む | 流通BMSや従来型EDIの取引先が複数ある | 取込の仕組みは別に作る |
| B. 汎用の連携基盤 | EDIの機能を持つ連携基盤で、変換から取込までを一続きにする | 海外の取引先のEDIもある | 流通BMSの手順に対応しているかを見る |
| C. 個別開発 | 通信・変換・取込を自社用に作る | 特殊な取引先の要件がある | 手順の変更のたびに直す |
多くの会社にとって、出発点はAです。
流通BMSの通信の方式は複数あり、取引先ごとに違います。
この部分は、日本のEDIサービスに任せるほうが安全です。
日本のEDIサービスには、社内の形式への変換や、基幹システムとの連携を案内するものがあります（DAL ACMS、ユーザックシステム）。
NetSuiteへの取込を、どの形式で受けられるかを提供元に聞いてください。
Aの取込は、CSVかAPIか
Aを選ぶと、NetSuiteへの取込はCSVかAPIのどちらかになります。
- CSV：EDIサービスが出力したファイルを、決まった時刻に取り込む
- API：データが届くたびに、NetSuiteに登録する
APIは、システム同士がデータをやりとりするための窓口です。
発注が1日に数回まとまって届くなら、CSVで足ります。
即日の出荷のため、届いた発注をすぐ引き当てたいなら、APIが向きます。
CSVでの取込はNetSuiteのCSVインポート、連携の手段の一般論はNetSuite連携ガイドにあります。
国内の連携ツールを使う場合は、国内iPaaS比較もご覧ください。
Bの汎用の連携基盤を選ぶときに聞くこと
海外の取引先ともEDIでやりとりする会社は、Bを検討することがあります。
その場合は、次の4つを提供元に聞きます。
| 聞くこと | 理由 |
|---|---|
| 流通BMSの通信の方式（JX手順・ebXML MS・AS2）のどれに対応しているか | 取引先ごとに方式が違うため |
| 流通BMSのメッセージの形式を、あらかじめ用意しているか | 自社で形式を作ると、保守が重くなるため |
| 日本語で、障害の問い合わせができるか | 発注が止まると、出荷も止まるため |
| NetSuiteへの取込の部品を持っているか | 取込を別に作る手間が変わるため |
流通BMSへの対応は、製品ごとに違います。
対応する方式とメッセージを公式の資料で見てから選びます。
流通BMSの業務と、NetSuiteの記録
流通BMSの業務は、NetSuiteでは次の記録に対応させるのが基本です。
卸・メーカーの立場（小売から発注を受ける側）で並べます。
| 流通BMSの業務 | データの向き | NetSuiteの記録 | 決めておくこと |
|---|---|---|---|
| 発注 | 小売 → 自社 | 受注（Sales Order） | 商品コードと取引先コードの対応 |
| 出荷 | 自社 → 小売 | 出荷（Item Fulfillment） | 出荷の単位と、梱包の情報 |
| 受領 | 小売 → 自社 | （出荷との差異の確認に使う） | 数量の差をどこで直すか |
| 返品 | 小売 → 自社 | 返品（Return Authorization） | 返品の理由と、在庫へ戻すか |
| 請求 | 自社 → 小売 | 請求書（Invoice） | 請求の締めの単位 |
| 支払 | 小売 → 自社 | 入金（Customer Payment） | 入金の消込の単位 |
受領のデータが、請求の食い違いを防ぐ
表の中で見落とされやすいのが受領です。
受領は、小売が実際に受け取った数量を知らせるデータです。
出荷した数量と、小売が受け取った数量は、ずれることがあります。
受領の数量にもとづいて請求する、と取り決めている取引先もあります。
受領を取り込まずにいると、自社の請求と小売の支払が合いません。
出荷から請求までの流れを図にすると、次のとおりです。
差異の理由は、欠品・破損・数え違いなどです。
理由ごとに、請求を直すのか、次の出荷で埋めるのか。
取引先と取り決め、差異を誰が直すかも決めておきます。
商品コードの対応を、どこで持つか
流通BMSでは、商品をJANコードなどの共通のコードで表すのが一般的です。
JANコードは、商品に付ける日本の共通の商品番号です。
NetSuiteの品目番号とJANコードの対応は、どちらかで持ちます。
- NetSuite側で持つ：品目にJANコードを登録し、取込のときに照合する
- EDIサービス側で持つ：変換のときに、自社の品目番号に置き換える
どちらでも動きます。
守るべきは、対応表を1か所にすることです。
EDIのデータとAI
EDIのデータは、最初から決まった形式で届きます。
紙やFAXの注文書と比べて、AIで点検しやすいデータです。
- 取り込めなかった発注について、商品コードの対応の候補をAIに挙げさせる
- 出荷と受領の数量の差を、取引先ごと・商品ごとにAIに集計させる
- いつもと違う数量の発注を、取り込む前に知らせる
どれも、最後の判断は人が行う前提です。
AIに任せる前に、対応表と取込の仕組みを整えるのが先になります。
事前に決める4つのこと
EDIとつなぐ前に、次の4つを決めます。
① 取引先の一覧と方式
取引先ごとに、流通BMS・従来型EDI・Web-EDI・FAXのどれかを書き出します。
従来型EDIの取引先は、切り替えの予定も聞いておきます。
② 使う業務の範囲
発注だけか、出荷・受領・請求まで使うかを、取引先ごとに決めます。
発注と出荷から始め、受領や請求を後から加える進め方もあります。
③ 取り込むタイミング
発注の締めの時刻と、出荷の締めの時刻から、取込の回数を決めます。
④ エラーの受け手
商品コードの不一致などで取り込めなかったとき、誰に知らせるか。
EDIの発注は、取り込めないまま放っておくと出荷が遅れます。
営業か受注の担当か、受け手を1人に決めておきます。
4つを表にしておくと、EDIサービスの提供元との打ち合わせが早く進みます。
| 決めること | 決める人 | 決まっていないと起きること |
|---|---|---|
| 取引先と方式 | 営業 | EDIサービスの見積もりが出せない |
| 業務の範囲 | 営業・物流・経理 | 取込の仕組みを後から作り直す |
| 取込のタイミング | 物流 | 出荷の締めに発注が間に合わない |
| エラーの受け手 | 受注の担当 | 取り込めない発注が放置される |
よくある3つの失敗
失敗1：取引先ごとに、取込の仕組みを作る
起きること：取引先が増えるたびに、NetSuiteへの取込の仕組みが1本ずつ増える。手順が変わるたびに、複数の仕組みを直す。
原因：取引先ごとの形式の違いを、NetSuiteへの取込の側で吸収しようとした。
避け方：形式の違いはEDIサービスの変換で吸収し、NetSuiteへの取込は1つの形式にそろえます。
失敗2：商品コードの対応表が、2か所にある
起きること：新商品を登録したのに、EDIの発注が取り込めない。NetSuiteとEDIサービスの両方に対応表があり、片方だけ更新されていた。
原因：対応表の持ち場所を決めず、それぞれの担当が便利な場所で管理していた。
避け方：対応表は1か所に決め、新商品の登録の手順に組み込みます。
失敗3：受領のデータを見ずに請求する
起きること：月末に、小売の支払額と自社の請求額が合わない。原因を探すため、出荷の記録を1件ずつ見直す。
原因：出荷した数量で請求し、小売の受領の数量との差を見ていなかった。
避け方：受領のデータを取り込み、出荷との差を請求の前に照らし合わせる手順を作ります。
ベンチャーネットならこう見る｜取引先ごとに3つから選ぶ
「EDIの取引先がいるなら、全部NetSuiteとつなぐべきだ」
そう考える必要はありません。
EDIとNetSuiteは、必ずつなぐものではないからです。
型1：通信と記録を分ける
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、まずこの線を引きます。
変わりやすい通信の手順と形式は、EDIサービスに任せる。
NetSuiteには、受注・出荷・請求の記録を置く。
この線が引けていれば、取引先の方式が変わっても、NetSuiteの側は動かさずに済みます。
型2：標準に合わせる／開発する／残す
線を引いたら、取引先ごとに扱いを3つから選びます。
- 標準に合わせる：取込の形式を1つにそろえ、NetSuiteの標準の記録（受注・出荷・請求書）に載せる
- 開発する：件数が多く、即日の引当が要る取引先は、APIの取込を作る
- 残す：EDIの取引先が1〜2社で件数も少ないなら、EDIサービスの画面で見て手で登録する
取引先ごとの選び方を図にすると、次のとおりです。
取引先がWeb-EDIで、手で入力しても負担が小さい場合も「残す」で足ります。
取引先や件数が増えた時点で、Aの選択肢を検討すれば十分です。
EDIとNetSuiteのつなぎ方は、取引先の方式と件数で変わります。
ベンチャーネットは、取引先の手順と件数を伺ってから、対応の範囲をご相談しています。
NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
卸売の業務全体でのNetSuiteの使い方は、NetSuite 卸売・商社ガイドにあります。
日本固有の要件として、全銀フォーマットでの支払もあわせてご覧ください。
今日できること｜取引先EDIの一覧を作る
次の表を、営業と物流の担当者と一緒に埋めてみてください。
| 取引先 | 方式 | 使う業務 | 月の発注件数／切り替えの予定 |
|---|---|---|---|
| （例）A社 | 流通BMS | 発注・出荷・受領 | 300件／なし |
書き出すと、EDIサービスに任せる範囲と、手で扱ってよい範囲が分かれます。
従来型EDIの取引先が残っていれば、切り替えの時期も見えてきます。
よくある質問
Q1. NetSuiteは、流通BMSに対応していますか
NetSuiteはEDIの通信を標準では受け持ちません。
Oracleのヘルプでは、EDIパートナーと組む前提で説明されています。
ベンチャーネットが確認した範囲では、流通BMSへの対応の記載はありませんでした（第2章）。
Q2. NetSuiteとつながるEDIサービスはありますか
2026年8月にDALがACMSとNetSuiteの連携の技術検証を完了したと発表しています。
技術検証の段階の発表です。
提供の時期や方法は、提供元に確かめてください（第2章2-2）。
Q3. 従来型EDIのままでも、NetSuiteとつなげますか
EDIサービスが従来型EDIに対応していれば同じ考え方でつなげます。
ただし、INSネットの提供は2028年12月31日に終わると発表されています。
つなぐ前に、取引先の切り替えの予定を聞いてください（第1章1-2）。
Q4. 取込はCSVとAPIのどちらがよいですか
発注が1日に数回まとまって届くならCSVで足ります。
届いた発注をすぐ引き当てたい場合は、APIが向きます（第3章3-1）。
Q5. 受領のデータも取り込むべきですか
請求の食い違いを防ぐために取り込むことをおすすめします。
出荷と受領の数量の差を、請求の前に照らし合わせられます（第4章4-1）。
Q6. 取引先が少なくても、EDIとつなぐべきですか
取引先が1〜2社で件数が少なければ手で登録する運用でも足ります。
取引先や件数が増えた時点で、つなぐことを検討します（第7章）。
Q7. NetSuiteの導入とEDIの切り替えは、同時に進めてよいですか
できれば時期をずらすことをおすすめします。
同時に変えると、問題が起きたとき、NetSuiteとEDIのどちらが原因かを切り分けにくくなります。
取引先の切り替えの予定から逆算して、どちらを先にするかを決めます（第1章1-2）。
Q8. 小売の店舗ごとに、NetSuiteの顧客を分けるべきですか
請求の単位に合わせて決めます。
本部にまとめて請求するなら、顧客は1社にして納品先を分ける持ち方が考えられます。
店舗ごとに請求するなら、店舗ごとに持つ方法もあります（第2章2-1）。
まとめ：通信はEDIサービス、記録はNetSuite
- 流通BMSは、6つの業務・8種類のメッセージを定めた業界の標準
- INSネットの終了で、EDIの見直しを求められる会社が出ている
- NetSuiteはEDIの通信を標準では受け持たない。EDIパートナーと組む前提
- 選択肢はEDIサービス＋取込・汎用の連携基盤・個別開発の3つ。出発点はEDIサービス＋取込
- 受領のデータと、商品コードの対応表を見落とさない
- 取引先が少ないうちは、つながない選択もある
小売からのEDIの発注を、NetSuiteだけで受ける必要はありません。
通信はEDIサービスに任せ、まずは取引先ごとの方式と件数を書き出してください。
もう少し詳しく知りたい方へ
流通BMSやEDIとNetSuiteのつなぎ方は、取引先の方式と件数によって変わります。
ベンチャーネットでは、取引先の手順と件数を伺ってから、対応の範囲をご相談しています。
