受発注システムの比較｜4タイプの選定軸と2028年の期限から逆算する判断

受発注システムの比較表を16製品ぶん並べても、自社に残る候補はたいてい1つか2つです。製品の優劣で絞られるのではなく、発注側と受注側のどちらが入れるのか、取引先が何社いるのか、既存のEDIが何の回線に乗っているのかという前提で、検討の対象そのものが入れ替わるからです。この記事では製品一覧ではなく選定軸のほうから、4タイプの適性と分岐点、2028年12月31日というEDIの期限から逆算する考え方、比較表に載らない評価軸、受託開発へ倒す条件を順に整理します。

まとめ：受発注システムの比較で先に決める4つの判断

結論から示します。比較を始める前に決めるのは次の4点で、この順に潰していくと候補は自然に絞られます。

• 立場：自社が発注側として入れるのか、受注側として入れるのか。両者は使う画面も課金対象も違い、候補製品が入れ替わります。
• 相手の数と量：取引先が数十社で明細が少ないならWeb受発注型、数社の大口で日次の明細が数百行を超えるならEDI型が現実的な線です。
• 期限：ISDN回線に乗ったレガシーEDIを使っているなら、2028年12月31日という動かせない終了日から逆算して比較の締切を決めます。
• 標準機能との距離：パッケージの標準機能で吸収できない業務要件が3つ以上あるなら、比較を打ち切って受託開発の見積もりに切り替えたほうが早く着地します。

逆にこの4点を決めずに「おすすめ10選」型の記事から入ると、EC通販向けとBtoB卸向けの製品が同じ表に並んだまま検討が進み、要件定義の段階でやり直しになります。そもそも受発注システムが何を担う仕組みなのかを先に押さえたい場合は、受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準で全体像を確認してください。

比較を始める前に決める2つの前提｜発注側か受注側かと取引先の社数

比較作業がぶれる原因は、製品選びより手前にあります。誰のための仕組みを入れるのかが曖昧なまま、機能の多さで並べてしまう状態です。

発注側が導入する場合と受注側が導入する場合で候補が入れ替わる

同じ「受発注システム」という名前でも、発注側が主語のときと受注側が主語のときでは別物と考えたほうが実態に近くなります。発注側、つまり仕入れる立場で入れるなら、価値は発注業務そのものの効率化です。複数の仕入先へバラバラに出していた注文を1画面へ集め、発注履歴と納期回答を追える状態にするのが主目的になります。

受注側、つまり売る立場で入れる場合は目的が変わります。FAXや電話で入る注文を担当者が転記せずに済む状態にするのが狙いで、回収先は自社の入力工数と誤入力の削減です。このとき製品を使うのは主に取引先であり、使い勝手を評価すべき相手が社内にいないまま選定が進みます。

両方を1つの製品でまかなえるかという問いには、条件つきで可能と答えられます。販売管理一体型の製品には発注側の機能も受注側の機能も入っていますが、片方は「ついている」水準にとどまることが多く、業務量が多いほうを主軸に据えて選ぶのが安全です。なお、自社のEC受注や複数モールの一元管理が主題なら、企業間の受発注とは別レーンの話になります。そちらは受注管理システムの比較｜4タイプ別の料金レンジと機能軸・カスタム開発の判断基準で料金レンジまで整理しています。

取引先の社数と1社あたりの取引量で決まるWeb型とEDI型の分岐

立場が決まったら、次は相手の数と量です。ここが型を分ける最大の分岐点になります。判断の目安は3つの数字で、取引先の社数、1社あたりの月間注文明細行数、そして注文の発生頻度です。

取引先が数十社から数百社あり、1社あたりの注文が月に数回で明細も数十行までなら、ブラウザで発注してもらうWeb受発注型が向きます。相手に何かを導入させる必要がなく、URLとIDを配れば運用に乗るためです。一方、取引先が数社に集中していて、1社あたり日次で数百行の明細が流れるような取引では、人が画面へ入力する前提そのものが破綻します。ここはシステム同士をつなぐEDI型の領域になります。

両方が混在するなら、実務では併存させます。上位の大口だけEDIでつなぎ、残りはWebとFAXで受ける構成です。このとき見るべきは、1つの製品が両方の入口を持ち、同じ受注データとして後工程へ流せるかどうか。入口ごとにデータが分かれると、担当者が突き合わせる作業が残ります。

4タイプの比較｜EDI型・Web受発注型・販売管理一体型・業界特化型

市場に出ている製品は、機能の組み合わせで見ると4つの型に整理できます。それぞれ「何を解くために作られたか」が違うため、向く取引も違います。

EDI型：標準仕様に沿って基幹システム同士を直結する型が向く取引

EDI型は、注文データを人が介さずシステム間で受け渡す仕組みです。流通小売の領域では流通BMSという標準仕様が整備されており、2007年4月の公開から版を重ねて、2026年8月時点では基本形 Ver.2.2系が現行の系列にあたります。メッセージはXML形式で、通信プロトコルとしてJX手順、ebXML MS、EDIINT AS2が用意されています。

この型の強みは、量が増えても人手が増えない点にあります。日次で数千行の明細が流れても、処理するのはシステムです。反面、導入の負荷は4タイプで最も重くなります。相手と項目を合わせ、商品コードの対応表を作り、テスト取引を回してから本番へ切り替える工程が要るためです。

中小企業の取引でも標準化の動きはあり、中小企業庁の次世代企業間データ連携調査事業で策定された中小企業共通EDIは、国連CEFACTに準拠した共通辞書を用いて業種をまたいだ接続を狙う仕様です。実証事業では受発注の双方で約50%程度の業務時間削減効果が確認されています。EDIそのものの流れや商流上の位置づけを先に押さえたい場合は、EDI取引とはを参照してください。

Web受発注型：取引先にブラウザで発注してもらう構成が向く取引の条件

Web受発注型は、自社が発注画面を用意し、取引先にログインして注文してもらう形です。相手側に導入作業がほとんど発生しないため、立ち上がりが速いのが特徴になります。数十社から数百社の取引先へ一斉に展開するなら、現実的な選択肢はほぼこの型に絞られます。

比較で見るべきは、取引先ごとに表示内容を出し分けられるかどうかです。BtoBの取引では、相手によって単価も、買える商品も、最低ロットも違います。全社に同じカタログを見せる仕様の製品だと取引先ごとの条件を反映できず、結局は電話での確認が残るという結末になりがちです。標準機能で持つ製品と上位プランでのみ対応する製品に分かれる部分でもあります。

もう1つは、スマートフォンで注文できるかという点。現場から発注する業態では、パソコンの前に戻ってから入力する運用は定着しません。端末側をブラウザ版で止めるかストア配信型まで踏み込むかの判断は、受発注管理システムのアプリとは？スマホ発注のUI要件とWeb版との使い分けで条件を示しています。提供形態（クラウド型・ASP型など）による選び方は、Web受発注システムの提供形態と選び方で整理しています。

取引先向けの発注画面をECサイトとして持つ場合の基盤選びは、受発注システムとは比較の軸が変わります。BtoB EC基盤としての4タイプ比較は、BtoB ECサイトの比較｜4タイプの選び分けと掛売・取引先別価格の判断を参照してください。

販売管理一体型：受注から在庫引き当てと請求までを1つの製品で回す型

販売管理一体型は、受発注を単独の機能ではなく販売管理の入口として持つ製品群です。受注が入ると在庫が引き当てられ、出荷指示が出て、締め日に請求書が起票されるところまで1つの製品でつながります。データの受け渡しを作らずに済むため、後工程の手戻りが減ります。

この型を選ぶ判断は、既存の基幹システムをどうするかとセットになります。すでに販売管理を別製品で回しているなら、一体型を入れると機能が二重になり、どちらをマスタの正とするかで運用が割れがちです。逆に、販売管理そのものを刷新する時期に来ているなら、受発注だけ別製品を足すより一体型でまとめたほうが総額は下がります。

見落とされやすいのが、在庫の引き当てタイミングです。注文が入った瞬間か、出荷指示を出した時点かで欠品の出方が変わります。受発注と在庫を連携させる設計の考え方は、受発注と在庫管理を連携する仕組みにまとめました。

業界特化型：商習慣が標準機能に入っている代わりに拡張が効かない型

業界特化型は、特定業界の取引ルールを前提に作られた製品です。製造業向けなら内示と確定注文の二段構え、医薬品卸向けなら業界共通の流通ネットワークとの接続、建設資材向けなら現場直送と分納といった具合に、他業界では使わない仕組みが標準で入っています。

この型が刺さるのは、自社の取引がその業界の標準的な形に収まっているときです。標準に収まっていれば、他の型で作り込みが必要な部分がそのまま動きます。逆に独自の運用が多い企業では、特化型ゆえの前提が邪魔をして回避策が増えかねません。

もう1つの注意点は事業の広がりへの追随で、1つの業界に閉じた製品は別業界の取引が増えたときにその部分を吸収できません。業界別の要件の具体像は、製造業向け受発注システムの選び方や医薬品業界の受発注システムで扱っています。

2028年12月末のINSネット終了から逆算するEDI型比較の実務

既存のEDIを持つ企業にとって、比較検討は自由なタイミングで始められません。回線側に期限が設定されているためです。

ISDN依存のレガシーEDIに残された移行期間と作業量の見積もり

NTT東日本・西日本のINSネットは、2024年8月31日で新規申込受付が終了し、サービス提供は2028年12月31日をもって終了します。理由として利用者の減少に加え、2029年以降は提供に必要な設備部材が枯渇する見込みが示されており、延長を前提にできる期限ではありません。

ISDN上でJCA手順などの旧来型EDIを回している場合、この日を過ぎると通信そのものが成立しなくなります。2026年8月時点で残っているのは2年4か月ほど。ここから逆算すると、比較検討に割ける時間は思うほど長くありません。EDIの移行は自社だけで完結せず、接続先1社ごとに項目の突き合わせとテスト取引が必要になるためです。

作業量の見積もりは接続先の社数を基準に置きます。1社あたり、仕様確認とマッピング設計、テスト、並行稼働を合わせて1〜3か月程度が実務的な感覚で、10社なら順に進めて1年以上かかる計算です。相手にも都合があり希望どおりの順番では進まないため、製品比較そのものは移行完了予定の1年前には終えておきたいところ。

補完策で延命する場合に残る通信の制約と、移行先を決める判断の順序

ディジタル通信モードは2024年1月から地域ごとに段階的な終了が進み、移行が間に合わない利用者向けに「切替後のINSネット上のデータ通信（補完策）」が用意されました。ただし当面の対応策という位置づけで、申込受付は2024年8月31日で終了、提供も2028年12月31日で終わります。

補完策には技術的な制約も明記されています。従来のディジタル通信モードより伝送遅延が生じて処理時間が増大するため、利用する機器によっては通信に影響が出る場合があるという内容です。夜間バッチで大量のデータを送る運用では、この遅延がバッチの終了時刻を押し出し、翌朝の出荷準備に間に合わないという形で表面化します。

判断の順序は、現在の接続方式と接続先を洗い出し、相手が対応可能な通信手順を確認し、そのうえで自社側の製品を選ぶ流れです。製品を先に決めると、主要取引先の手順に対応しておらずやり直しになりかねません。

EDIではなくBtoB ECへ寄せる判断をした場合に、他社の導入事例から要件を読み取る手順はBtoB ECサイトの事例｜卸売・商社・メーカー別の型と要件の逆算手順で扱っています。

流通BMSへの対応をうたう製品で確認する版番号と通信手順の範囲

製品カタログの「流通BMS対応」という表記は、それだけでは対応範囲を示しません。確認したいのは3点です。第一に、対応している版番号。基本形 Ver.2.2系と百貨店版では扱えるメッセージが違い、インボイス制度への対応はVer.2.1の系列で更新された経緯があります。

第二に、通信プロトコルの対応範囲です。流通BMSにはJX手順、ebXML MS、EDIINT AS2の3つがあり、取引先が指定してくる手順に製品が対応していなければ接続できません。小売の大手は手順を指定してくることが多いため、主要な接続先の指定を先に集めてから製品側の対応表と突き合わせる進め方が確実です。

第三に、標準メッセージ以外の項目をどこまで持てるか。拡張領域を使えるのか、使えるとして後工程の基幹システムまで運べるのかは製品ごとに差が出ます。ここが足りないと、標準の枠内で表現できない情報だけが別の連絡手段に残ります。

比較表に出てこない4つの評価軸｜取引先の負担とマスタ・締め時間

比較サイトの機能表に並ぶのは、どの製品も似た項目です。差が出るのは表に載らない部分で、導入後に効くのは次の4つ。

取引先側に発生する費用と作業を見積書に載らないコストとして数える

受注側が導入するとき、請求書が届くのは自社にだけです。しかし作業が発生するのは取引先側で、アカウント登録、担当者への周知、FAX運用からの切り替え、繁忙期に新しい画面を覚える負担がのしかかります。この部分は見積書のどこにも現れません。

これを数値化するには、取引先1社あたりの初期作業時間を仮に置いてみるのが手早い方法です。説明と初期設定で2時間、慣れるまでに3時間と置けば、100社で500時間ぶんの負担を相手に求める計算になります。この総量が大きいほど、製品の「相手にとっての分かりやすさ」の重みが増します。

製品によっては、取引先側にもアカウント課金が発生する料金体系があります。自社の負担で持つのか相手に求めるのかで、展開のしやすさは変わります。無料で始められるツールから検討する場合の限界については、無料の受発注ツールの限界で条件を整理しました。

選定を終えたあと、アカウントの発行単位や取引先マスタの整備をどう進めるかは受発注システムを取引先に展開する方法で扱っています。

取引先別単価と商品コードの読み替えにマスタ設計が耐えるかを見る

BtoBの受発注でシステムが行き詰まる最大の原因は、単価とコードの扱いです。同じ商品でも取引先ごとに単価が違い、数量帯によって段階的に変わり、期間限定の特価が乗り、さらに取引先が自社とは別の商品コードで注文してきます。

確認するのは、これらをマスタとして持てるかどうか。取引先別単価を管理できず注文のたびに手入力する製品では、システムを入れても確認の電話は減りません。商品コードの読み替え表を持てるかも同様で、無ければ取り込みのたびに変換作業が挟まります。

さらに見ておきたいのが、単価ルールが重なったときの優先順位です。取引先別単価と数量帯別単価と期間特価が同時に該当したとき、どれを採るかを設定できるのか。ここが固定されている製品は、自社の商習慣を製品側へ寄せる前提になります。

締め時間と納品リードタイムの設定自由度が現場の運用を左右する理由

受発注の運用は時刻で回っています。何時までの注文をその日の出荷に含めるか、翌日納品にできる地域はどこまでか、土日と祝日をどう飛ばすか。これらを製品側で自由に組めるかどうかで、現場に残る例外処理の量が決まります。

比較の際は、自社の締め時間が製品の標準設定に収まるかを確認します。1日1回の締めしか設定できない製品に対して実務では午前と午後の2便を回している、という食い違いはよく起こる話です。倉庫が複数あって拠点ごとに締め時間が違う場合も、拠点別の設定を持てるかが分かれ目になります。

納期回答も同じ構造です。在庫があれば即答できるのか、担当者が確認してから返す運用のままか。自動化できる製品を選べば問い合わせ対応は減りますが、在庫データが受発注システム側から見える構成が前提になります。

電子帳簿保存法に沿った取引データの保存と検索要件への対応の範囲

受発注システムを通した注文は電子取引にあたり、注文書や請求書のデータは電子のまま保存する扱いになります。国税庁が示す検索要件では、取引年月日・取引金額・取引先の3項目で検索できる状態が求められます。

製品比較では、この検索機能が標準で備わっているか、保存期間ぶんのデータを持ち続けられるかを確認します。クラウド製品には、直近1年ぶんだけを画面で参照でき、それ以前は追加費用というプランもあり、保存義務のある期間との差は契約前に埋めておきたい点です。

もう1つは解約後のデータの扱いで、契約が切れると参照できなくなる製品なら手元に残す運用が要ります。エクスポートの形式と粒度、明細まで出せるかを比較項目に入れておくと後で困りません。

比較の材料としてベンダーの導入事例を読む場合は、数値の前提条件を先に確認してください。公開事例の数値を自社の見込み値へ置き換える手順は受発注管理システムの導入事例の読み方｜効果指標の前提条件と自社での再現判定で扱っています。

パッケージ比較から受託開発へ倒す条件と、併用で解く現実的な構成

比較を続けても決まらない場合、候補ではなくパッケージという解き方が要件に合っていない可能性があります。切り替えの線を決めておくと、検討が長引きません。

パッケージの標準機能で足りなくなる3つの業務要件と見極めの手順

実務で標準機能からはみ出しやすいのは、大きく3種類です。1つ目は単価と請求の条件で、複雑な単価ルール、支払サイトの取引先別設定、リベートや歩引きといった精算が該当します。2つ目は在庫の見せ方で、引当済みと未引当、他拠点在庫、入荷予定分をどこまで取引先に開示するかという制御。3つ目は既存の基幹システムとの連携方式で、リアルタイムの残高照会が必要か、日次のファイル連携で足りるかによって難度が変わります。

見極めの手順は単純です。候補製品のデモや試用で、この3種類について自社の実データを流します。標準設定で表現できるものを○、設定の工夫で回避できるものを△、追加開発が必要なものを×と分けて数え、×が3つ以上の製品は候補から外します。△が多い製品も要注意で、運用でカバーする約束は現場で守られないためです。

この判定を全候補で行うと、候補は1つか2つに収束します。すべての製品で×が3つ以上になるなら、製品の問題ではなく自社の業務がパッケージの想定から離れているというシグナルです。費用感の目安は受発注システム開発の費用相場と外注先の選び方で確認できます。

SaaSを土台に差分だけ作る併用構成と、全面受託へ踏み切る判断の線

受託開発へ倒すといっても、すべてを作る必要はありません。よく採るのは、取引先が触れる発注画面と通知を既製のSaaSに任せ、商習慣が集中する単価計算と在庫引き当てだけをAPI連携で自社側に持つ併用構成です。作る範囲が小さいぶん、初期費用も改修の負荷も抑えられます。

全面的な受託開発に踏み切る線は、次の3つのいずれかに当てはまるときです。第一に、受発注の仕組みそのものが競争力の源泉である場合。第二に、既存の基幹システムとの結合度が高く、切り離すと二重入力が大量に出る場合。第三に、取引先ごとに接続方式がばらばらで、変換処理の集約が主要な要件になっている場合。

どの構成を採るにせよ、判断の材料は比較の過程で集めた×の中身になります。何が標準機能に収まらなかったのかを記録しておけば、そのまま要件定義の一次資料として使える状態です。自社の業務に合わせた受発注の仕組みづくりについては、受発注システム開発で対応範囲を掲載しています。

よくある質問

受発注システムの比較で最初に見るべき項目はどれですか？

機能一覧より先に、自社の立場と取引先の分布を確認してください。発注側として入れるのか受注側なのか、取引先が何社で1社あたりどれくらいの明細が流れるのか。この2点が決まるだけで、検討すべき型は4つのうち1つか2つに絞られます。機能の比較はそのあとで十分です。

受発注システムのシェアやランキングは選定の参考になりますか？

導入社数の多さは、その製品が想定する取引形態が世の中に多いという事実を示すだけで、自社に合うかとは別の話です。ランキング上位にEC通販向けの製品が並んでいても、BtoB卸の取引には接点がありません。参考にするなら順位そのものではなく、自社と同じ業種・規模での導入事例が載っているかを見てください。

受発注システムとEDIはどちらを選べばよいですか？

対立する選択肢ではなく、EDIは受発注システムの接続方式の1つと捉えるのが実態に合います。少数の取引先に大量の明細が流れるならEDI接続、多数の小口ならWeb画面と、同じシステムの中で入口を使い分けるのが現実的です。基準は相手の数と量であって、技術の新しさではありません。

ISDN終了への対応はいつまでに始めればよいですか？

接続先が10社を超えるなら、2026年中に製品の選定を終えておきたい時期です。INSネットの提供終了は2028年12月31日で、補完策も同日に終わります。移行は接続先1社ごとにテスト取引が必要で相手の都合にも左右されるため、社数×1〜3か月を目安に逆算してください。

比較段階で取引先に確認しておくことはありますか？

主要な取引先には、対応可能な通信手順と、Web画面での発注に応じてもらえるかを事前に聞いておきます。EDIでは相手が指定する手順に製品が対応していなければ接続が成立しません。上位数社の回答を集めてから絞ると、選定後の手戻りを防げます。

関連記事

• 受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準：仕組みの定義と機能の全体像、種類ごとの違いの整理です。
• 受注管理システムの比較｜4タイプ別の料金レンジと機能軸・カスタム開発の判断基準：EC多店舗一元管理を含む受注側の製品比較と料金の相場です。
• Web受発注システムの提供形態と選び方：クラウド型・ASP型など提供形態ごとの違いと選定の観点です。
• 受発注システム開発の費用相場と外注先の選び方：受託開発へ倒した場合の費用の内訳と依頼先の見極め方です。
• 製造業向け受発注システムの選び方：内示や生産管理連携など製造業固有の要件の扱いです。