Web受発注システムの選び方｜調達担当者が取引先も含めて失敗せず切り替える方法

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

B2B EC-COLUMN

紙・電話・FAX発注の困りごととシステム化で変わること

社内から届いた発注依頼を注文書に書き写し、FAXで送り、返事が来ない分は電話で確かめる。
このやり方を続けていると、写し間違いと確認漏れが気になり始めます。
Web受発注システムへの切り替えは有効な選択肢ですが、システムの違いは一つではありません。
自社側の作り方の違い（SaaS・フルスクラッチ・ハーフスクラッチ）と、取引先とデータをつなぐ仕組みの違い（web-EDI・中小企業共通EDI）は、別々の軸です。
料金と機能に加えて、取引先が乗れる仕組みかどうかを比較条件に入れ、並行稼働の期間を区切って社内と取引先の双方に移していく。
これが、選んだあと実際に運用まで届くシステム選びの中心になります。

いまの発注業務で、手が止まるのはどこか

発注業務が紙・電話・FAX・メールの混在で回っているとき、手間の正体は「作業が多いこと」よりも「同じ情報を何度も書き写していること」にあります。
製造部門や店舗から上がってきた依頼を見ながら、自社の注文書の様式に品番と数量を入力する。
これが一度目の転記です。
送信先ごとに宛名や送付状を変え、FAXで流すか、メールにPDFを添付して送る。
ここまでは自社の中だけの作業なので、間違えても気づける余地があります。

問題は、送った先でもう一度同じ情報が入力されることです。
取引先の担当者は、受け取ったFAXやPDFを見ながら自社の受注システムや台帳に打ち直します。
二度目の転記がここで起きますが、発注側からは見えません。
品番の枝番が一桁違っていても、数量の単位が箱とバラで食い違っていても、たいていは納品されたものを見て初めて分かります。
そのときには、返品や追加手配の連絡がもう一往復増えています。

確認漏れのほうは、記録が一か所にまとまっていないことから生まれます。
送信したかどうかはFAXの送信記録に、返事が来たかどうかはメールの受信箱に、電話で受けた納期回答は手元のメモに残ります。
数量変更や納期変更の依頼が電話で入ると、どれが最新の注文内容なのかを判断する材料が、この三か所に散らばったままになります。
「先週の分はどうなりましたか」と聞かれて調べ直す時間は、この散らばりに対して払っているコストです。

Web化で消える作業と、残る作業

Web受発注システムに切り替えると、この流れのどこが変わるのかを先に押さえておくと、機能一覧を見たときの判断が速くなります。
発注側が画面に入力した内容が、そのまま受注側の画面に注文として現れる形になれば、取引先での打ち直しがなくなります。
先ほど数えた転記のうち、二度目が構造的に消えるということです。
品番と数量の食い違いは、そもそも書き写す場面がなくなるので発生しません。

もう一つ変わるのが、状態の確認です。
注文が相手に届いているか、受注として受け付けられたか、出荷されたかが画面上の状態として見えるなら、「届きましたか」と尋ねる電話をかける理由がなくなります。
変更の履歴も同じ注文番号にぶら下がるので、最新がどれかを三か所から探し直す作業も減ります。
減るのは作業量というより、「探す」「確かめる」ために発生していた往復です。

一方で、残るものもはっきりしています。
一度目の転記、つまり社内の依頼を発注データに起こす作業は、依頼の受け取り方を変えない限り残ります。
数量の桁を打ち間違えるといった入力そのものの誤りも、画面が変わっただけでは防げません。
そして最も効いてくるのが、取引先の側です。
切り替えに乗らない取引先が残れば、その分はFAXと電話のまま並走します。

つまりこの検討は、「どのシステムを買うか」の前に「どの取引先まで乗せられるか」が効いてくる種類の意思決定です。
この順番を踏まえたうえで、まずシステム側にどんな違いがあるのかを整理します。

Web受発注システムの提供形態の違い（開発方式とデータ連携の仕組み）

開発方式で見る3つの型：SaaS・フルスクラッチ・ハーフスクラッチ

Web受発注システムを比較していると、「クラウド型」「自社専用に開発」といった言葉が並びます。
Web受発注システムを提供する竹田印刷（TS-BASE）は、構築方法をSaaS（クラウド型）、フルスクラッチ（一から開発）、ハーフスクラッチ（既存システムに一部追加開発）の3区分で整理しています³。
これは同社が自社ブログで示した整理であり、業界の標準規格として定められた分類ではありませんが、見積もりを取るときに事業者側が前提にしている考え方をつかむには使えます。

この軸が答えているのは、「自社の画面や業務の進め方を、どこまで自社の形に寄せるか」という問いです。
すでにある仕組みをそのまま使うのか、自社の業務フローに合わせて作るのか、その中間を取るのか。
ここで決まるのは主に自社側の話であって、取引先との間でデータがどう流れるかは、実は別の問題です。

データ連携の仕組みで見る違い：web-EDIと中小企業共通EDI

取引データを企業間で交換する仕組みはweb-EDIと呼ばれ、これに対応したクラウド型の販売管理システムが多く提供されています⁴。
EDIは企業間で取引データをやり取りする仕組みを指す言葉で、注文・納品・請求といった帳票のやり取りをデータで行うものです。
ここで押さえておきたいのは、web-EDIでつながる相手は、同じ仕組みに対応している相手だということです。

業界や系列ごとに使っている仕組みが違う場合に持ち出されるのが、中小企業共通EDIです。
これは企業間ごとに異なる環境下でもデータで受発注できる仕組みとして、2016年度に中小企業庁の事業としてスタートしたものです⁴。
取引先が自社と同じシステムを導入していなくても、データとしてつなぐ道が用意されている、という位置づけになります。

この二つの軸を混ぜて考えると、比較の途中で判断がぶれます。
SaaSを選んだからといって、取引先とデータで直接つながるとは限りません。
逆に、自社専用に開発したシステムであっても、外部とのデータ連携の仕組みを備えていればつながります。
「自社側をどう作るか」と「取引先とどうつなぐか」は、見積書の上では一枚に見えても、確認すべき内容が別なのです。

比較検討の実務では、まずデータ連携の側を先に確認したほうが、話が早く進みます。
取引先がつながる仕組みが限られていれば、自社側で選べる開発方式もその範囲に絞られるからです。

出典：株式会社竹田印刷（TS-BASE運営）「Webの受発注システムの選び方とコストの目安」（2026年・同社ブログによる整理）／株式会社OBC「ご存じですか？受発注業務を効率化する「企業間取引を電子化」する方法」（2026年）

コスト・機能以外に見るべき比較条件

料金は「一社の目安」であって相場ではない

費用感をつかもうとすると、最初に目に入るのが金額の例です。
竹田印刷（TS-BASE）は、SaaS型受発注システムの一例として、イニシャルコスト30〜50万円、ランニングコスト10〜20万円という目安を同社調べとして示しています³。
ただしこれは、自社製品を提供する一事業者が経験から示した一例です。
SaaS型受発注システム全体の市場相場として第三者に確認されたものではないので、社内稟議に「相場はこのくらい」と書いてしまうと、実際の見積もりと合わなくなる可能性があります。

金額の桁よりも判断を分けるのは、何に対して課金されるのかという点です。
利用者のID数で決まるのか、つないだ取引先の数で決まるのか、月間の発注件数で決まるのか。
ここが事業者ごとに違うため、同じ月額表示でも、自社に当てはめた金額は大きく変わります。
いまの発注件数と取引先数を出したうえで、繁忙期に件数が増えたときや、対象の取引先を広げたときに費用がどう動くかを見積もりの段階で聞いておくと、稼働後に前提が崩れずに済みます。

機能範囲は、受注者側が使う画面まで含めて見る

機能の一覧を読むとき、発注側の画面だけを見て判断すると、導入後に想定外が出ます。
Web受発注システムは、自社が注文を出す画面と、取引先が注文を受ける画面の両方があって初めて回ります。
取引先側の画面は含まれているのか、含まれているとして、取引先にIDの発行や費用負担が発生するのかは、契約条件として確認しておく対象です。

取引先に費用や手間が生じる形だと、切り替えの交渉はそこから始まります。
相手にとっては、自社の業務が楽になるとは限らないのに手間が増える話になりかねないからです。
受注側の操作が一日何件分の作業になるのか、納期回答を返す手順がどれだけ短いのかは、機能表の行数ではなく実際の画面で見たほうが判断できます。

会計・在庫との連携で、どの転記が残るかが決まる

三つ目が、既存の会計システムや在庫管理システムとのつながり方です。
発注データが受発注システムの中だけで完結すると、発注残の管理や仕入計上のために、結局そこから数字を書き写すことになります。
先ほど消えたはずの転記が、社内の別の場所で復活する形です。

確認したいのは、連携があるかないかではなく、どの形式で渡るかです。
CSVを書き出して手で取り込むのか、システム同士が接続されているのか、取り込みの単位は注文単位か日次の締め単位か。
ここが決まると、切り替え後に自分の手元で何の作業が残るのかがはっきりします。
既存の会計・在庫側の仕様も併せて確認しないと成立しない話なので、自社の情報システム担当や既存システムの保守窓口にも、同じ質問を投げておくと見積もりの往復が減ります。

取引先（受注者側）の対応状況の見極め方

業界全体の電子受発注システム導入状況

取引先が対応できるかどうかを考えるとき、まず知っておきたいのは、業界全体がまだ移行の途中だという前提です。
中小企業庁は、電子受発注システムの導入率を2023年めどに当時の約2割から約5割へ引き上げることを目指すとしていました¹。
この約2割という水準は2021年9月時点のもので、約5割は目標値です。
現在の個々の取引先がどうなっているかを示す数字ではありません。

それでもこの数字が役に立つのは、計画の立て方を決めるからです。
政策として引き上げを目指す段階にあったということは、対応済みの取引先と、これからの取引先が混在している状況を前提に切り替えを設計しておくほうが現実的だ、ということです。
全取引先が一斉に乗る前提の計画を立てると、乗れなかった分の扱いが決まっておらず、切り替え当日に慌てることになります。

システムが違う取引先ともつながる仕組みがあるか

取引先がすでに別の電子受発注システムを使っている場合、それは障害ではなく、つなぎ方の問題になります。
中小企業庁が開発を進めるデータ連携基盤は、業界やサプライチェーンの系列ごとに異なる電子受発注システムに接続し、入力データを自動変換するものとして報じられています¹。
これは2021年時点の報道による政策・基盤整備の説明なので、現在どの事業者のどの製品が対応しているかは個別に確認が必要ですが、「相手と同じ製品を入れないとつながらない」という前提では考えなくてよい、という方向は見えます。

同じ考え方に立つのが、先に触れた中小企業共通EDIです。
この仕組みの実証事業では、12のプロジェクトの平均で51.4%の業務時間削減効果が得られたとされています²。
ただしこの実証は、自動車・水インフラ・農林水産・輸出・卸小売・サービスの6業界、北海道・東京・静岡・愛知・大阪の5地域という範囲で行われたものです²。
平成28年度の実証事業の平均値であり、自社の発注業務で同じ削減幅が出ることを示す数字ではありません。
業務時間が半分近くまで下がった事例が実証として確認されている、という水準で受け取るのが妥当です。

実際の見極めは、取引金額と発注件数の上位から順に当たるのが効率的です。
件数の多い数社で回る方式を選べば、効果の大半はそこで取れます。
聞く内容は、いま使っている受注の仕組みがあるか、あるとすればどの形式でデータを受け取れるか、なければWeb画面での受注入力に人手を割けるか、の三点で足ります。

この表のうち判断が分かれるのは二段目です。
相手にシステムがない場合、発注側のシステムの画面を使ってもらうのが一般的な進め方になりますが、そのぶん受注入力の手間が相手に移ります。
相手の受注件数が少なければ負担は小さく、多ければ「だったら今までどおりFAXでほしい」と言われます。
ここを事前に見ておくと、交渉の材料を金額ではなく作業量の話として用意できます。

導入後、社内・取引先にどう定着させるか

並行稼働期間の目安

システムを決めたあと、最後に残るのが切り替えの進め方です。
販売管理システムのデータ移行実務では、月次締め処理を2回跨ぐことを安全ラインとし、6〜8週間の並行稼働期間を設けることが多いとされています⁵。
これはDX・開発支援を行うriplaが販売管理システム全般の移行について示している実務上の考え方で、Web受発注システムだけを対象に検証された数字ではありません。
ただ、考え方としてはそのまま使えます。

締め処理は月に一度しか回ってきません。
1回通しただけでは、うまくいったのがその月の事情なのか、毎月成り立つのかを区別できません。
2回目を通して初めて、発注残の繰り越しや月をまたぐ納品の扱いが、たまたまではなく再現するかを確かめられます。
自社の締めが月末なのか20日なのか、あるいは取引先ごとに違うのかによって、必要な期間は変わります。
6〜8週間という幅は、そこから逆算するための出発点として置くのが使い方です。

社内・取引先への展開手順

並行稼働で最も揉めるのは、期間の長さではなく「どちらを正とするか」を決めていないことです。
新旧の両方で注文を出している期間に内容が食い違ったとき、どちらの記録を事実として扱うのかが決まっていないと、確認の電話が一往復増えます。
期間の始まりに合わせて、正とする側を一つ決め、社内と取引先の双方に同じ言葉で伝えておく。
これだけで、並行稼働中に発生する問い合わせの性質が「どちらが正しいのか」から「入力を直してください」に変わります。

進め方としては、次の順で組むと無理がありません。

1. 取引先ごとに、いまの発注方法（FAX・メール・電話）と月の発注件数を書き出す
2. 件数の多い数社に切り替えの相談をし、受注側の画面を実際に見てもらう
3. その数社だけで並行稼働を始め、正とする側と、食い違いが出たときの連絡先を決めておく
4. 月次締めを2回通したうえで、従来の方法を止める日を決めて社内外に通知する
5. 残る取引先を、件数の多い順に同じ手順で追加していく

全社一斉に切り替えないのは、後戻りできる範囲を残すためです。
数社で先に回せば、社内の依頼の受け取り方や、会計・在庫への取り込み手順で直すべき点が、件数の少ないうちに見つかります。
そこを直してから範囲を広げれば、同じ問い合わせを取引先の数だけ受けずに済みます。

社内の定着については、発注担当者の操作研修よりも、依頼元への周知のほうが効きます。
発注依頼が従来どおりメールや口頭で上がってくる限り、一度目の転記は残り続けるからです。
依頼の様式を発注システムの入力項目に合わせておくと、書き写す作業そのものを減らせます。
ここは製品の機能というより、社内の手順の決め方の問題なので、システム選定と並行して進められます。

ここまでで、何を比較し、誰に確認し、どう移していくかまでは形になりました。
残るのは、自社側のシステムをどの作り方で用意するかという判断です。

取引先ごとに発注の出し方が違うと、どの方式なら全社を乗せられるのかは、製品資料を読み比べるだけでは決まりません。<br>受発注の仕組みを実際に構築してきた相手と、現状の棚卸しから一緒に見たほうが、候補を絞る段階が短く済みます。

いまの発注手順のどこに転記と確認が残っているか、取引先のうちどこまでをWebに乗せられそうかを整理し、検討の候補になる方式と確認すべき条件を絞り込めます。無料相談で要件を整理する

比較で確認したい3つの条件（料金体系・機能範囲・会計/在庫連携）

見積もりを依頼する前に、自社の発注件数と既存システムの仕様に当てはめて各社へ確認する条件として並べています。

• 月額と初期費用が何に対してかかるのか（利用者のID数か、取引先数か、発注件数か）を、自社の数字に当てはめて見積もりで確認する

• 取引先が使う受注側の画面と操作が含まれているか、取引先にID発行や費用負担が生じるかを契約条件として確認する

• 既存の会計・在庫管理システムへ発注データがどの形式で渡るか（手動のCSV取り込みか、システム間の接続か）と、取り込みの単位を確認する

取引先の多くが自社の受注システムを持たない場合は、機能範囲のうち受注側の操作の手間を先に見たほうが、切り替えの交渉が進みます。

開発方式から見る3つの型と、選ぶときの目安

開発方式	何をどこまで自社に合わせるか	検討しやすい場面
SaaS（クラウド型）	提供されている標準機能をそのまま使う	標準機能で自社と取引先の運用が足りるとき
フルスクラッチ	業務フローに合わせて一から作る	独自の業務フローを維持したいとき
ハーフスクラッチ	既存システムをベースに一部だけ追加する	標準機能と個別要件の両方を取りたいとき

SaaS（クラウド型）：標準機能に自社を寄せられるかで決まる

判断が分かれるのは「注文書の項目」と「取引先の受け方」

SaaSは、インターネット経由でサービス事業者が提供するシステムをそのまま利用する方式です³。
既存の標準機能で自社と取引先の運用が足りるのであれば、検討しやすい選択肢になります。
ただし費用は事業者ごとに個別の確認が必要で、先に触れた金額の例も一事業者が示した目安である点は変わりません。

足りるかどうかを実際に判断する材料は、二つあります。
一つは、いま使っている注文書の項目です。
社内の管理番号、指定納入場所、検収条件、荷姿の指定といった欄が、標準の入力項目で表現できるか。
表現できない項目があるとき、それを備考欄で運用できるのか、それとも受注側がその欄を見落とすと業務が止まるのかで、重みが変わります。

もう一つは、取引先の受け取り方です。
標準機能の範囲で相手が受注処理を完結できるなら問題ありませんが、相手の社内で別の帳票に落とし直す必要があるなら、そこで新しい転記が生まれます。
自社の作業が減った分を取引先に渡しただけ、という形にならないかは、導入前に相手の画面で確かめておく価値があります。

合わない項目が出たときの分岐点は、自社の運用を標準側に寄せられるかどうかです。
その項目が取引や品質の管理に必要なのか、以前からの様式が続いているだけなのかを区別できると、寄せられる範囲が見えてきます。

フルスクラッチ：守る業務フローを特定できるかが前提

「独自」が競争力なのか、慣れなのかを分ける

フルスクラッチは、自社の業務フローに合わせて一から開発する方式です³。
独自の業務フローを維持したい場合に選ばれますが、開発期間も費用も個別見積りによるため、検討の初期に金額の目安を置くことはできません。

この方式を検討するとき最初にやることは、守りたい業務フローを名指しで特定する作業です。
「うちは特殊だから」という言い方のままでは要件が書けず、見積もりも出ません。
特殊さの正体が、複数拠点からの発注をまとめて一枚の注文にする社内ルールなのか、取引先ごとに異なる検収の締め日なのか、承認の経路なのか。
具体的な業務名まで落とすと、そのうちのいくつかは標準機能でも扱えることが分かる場合があります。

もう一つ見ておきたいのが、作ったあとをどう維持するかです。
自社専用に作るということは、取引先の仕組みが変わったときや、会計システムを入れ替えたときの改修も自社の判断と費用で行うということです。
発注業務は取引先の都合で変化する部分があるので、その変化に誰がどのくらいの期間で対応するのかを、開発の見積もりと一緒に確認しておく必要があります。

ハーフスクラッチ：追加する部分を先に絞り込む

要件を絞れていないと見積もりが出ない

ハーフスクラッチは、汎用的な既存システムをベースに一部機能を追加開発する方式です³。
標準機能と個別要件のバランスを取りたい場合に選ばれます。
SaaSでは足りない項目がいくつかある一方、全部を作り直すほどではない、という状態に当てはまります。

この方式で見積もりを取るには、追加する部分がどこかを先に特定している必要があります。
ベースとなる標準機能で何ができるかを確かめ、そのうえで足りない箇所を列挙するという順番になるため、検討の手間は前倒しで発生します。
逆に言えば、ここまでで整理してきた「いまの発注業務で転記と確認が残っている箇所」「取引先ごとの受け取り方」「会計・在庫への渡し方」が書き出せていれば、その資料がそのまま要件の下地になります。

判断の目安としては、追加したい機能が自社の発注業務の中心にあるのか、周辺にあるのかを見ます。
中心の業務フローに手を入れるならフルスクラッチとの比較になり、会計側への出力形式や社内の承認経路といった周辺であれば、ハーフスクラッチの範囲で収まる可能性があります。
いずれにしても、追加開発の部分は標準機能のようにあとから他社事例で補えないので、稼働後に誰が保守するかは契約時に決めておくところです。

要点の整理

軸	基準
いまの発注業務の把握	転記が何回あり、どこで確認の電話が発生しているかを取引先ごとに書き出す
システムの見方	開発方式（SaaS・フルスクラッチ・ハーフスクラッチ）と、データ連携の仕組み（web-EDI・中小企業共通EDI）は別の軸として確認する
比較条件	料金体系・機能範囲・会計/在庫連携に加え、取引先が乗れる仕組みかを条件に入れる
金額の扱い	公開されている金額は一事業者の目安。自社の発注件数と取引先数に当てはめて見積もりを取る
取引先の確認	取引金額・発注件数の上位から、受け取れるデータ形式と受注入力の人手を個別に確認する
切り替えの進め方	並行稼働の期間と、どちらの記録を正とするかを開始前に決めておく

並行稼働の期間をどこに置くか、どちらの記録を正とするかといった運用の決めごとは、機能一覧や見積書からは読み取れません。<br>自社の締め処理と取引先の顔ぶれに当てはめて初めて決まる部分です。 自社の締めのサイクルに合わせた切り替えの進め方と、取引先へ案内する前に決めておくべき項目を確認できます。

よくある質問

Web受発注システムと中小企業共通EDIは同じものですか

別の軸の言葉です。
Web受発注システムは自社が注文を出し、取引先が受ける仕組み全体を指すのに対し、中小企業共通EDIは企業間ごとに異なる環境下でもデータで受発注できるようにする仕組みで、2016年度に中小企業庁の事業として始まりました⁴。
自社がどの開発方式でシステムを用意するかという話と、取引先とどの仕組みでデータをつなぐかという話は、分けて確認してください。

取引先が電子受発注に対応していない場合、発注方法を分けて運用してもよいですか

問題ありません。
電子受発注システムの導入率は2021年9月時点で約2割とされ、中小企業庁は2023年めどに約5割へ引き上げる目標を掲げていました¹。
対応済みの取引先とそうでない取引先が混在する前提で組むほうが現実的です。
ただし社内では、どの注文がどの方法で出されたかを一覧で分かる状態にしておかないと、発注残の確認が二か所に分かれてしまいます。

並行稼働の期間中に注文ミスが起きた場合、どちらの方法を優先すべきですか

期間の開始前に、どちらを正とするかを決めておくことが要点です。
決め方そのものに正解はなく、新旧どちらを正としても運用は成り立ちますが、決まっていない状態で食い違いが起きると、事実確認のやり取りが増えます。
正とする側と、食い違いが出たときの連絡先を、社内と取引先の双方に同じ言葉で伝えておいてください。

小規模な取引先が多い場合でもSaaS型は導入しやすいですか

自社側の導入のしやすさと、取引先側の使いやすさは別に見る必要があります。
SaaSは既存の標準機能で自社と取引先の運用が足りる場合に検討しやすい方式です³が、受注側の画面操作やID発行、費用負担が取引先に発生する形だと、件数の少ない相手ほど負担感が大きくなります。
受注側の画面を実際に見てもらったうえで、相手の月間受注件数に対して操作の手間が見合うかを確認するのが先です。

1. 1　出典：日刊工業新聞社「中小企業庁が中小企業の電子受発注実現へ開発する「データ連携基盤」の全容」（2021年）
2. 2　出典：中小企業庁「企業間のデータ連携で、受発注の業務コストを削減する！（ミラサポplus）」（2020年）
3. 3　出典：株式会社竹田印刷（TS-BASE運営）「Webの受発注システムの選び方とコストの目安」（2026年）
4. 4　出典：株式会社OBC「ご存じですか？受発注業務を効率化する「企業間取引を電子化」する方法（OBC360°）」（2026年）
5. 5　出典：株式会社ripla「販売管理システムのデータ移行を成功させる5ステップ」（2026年）