BtoB受発注サイトの開発｜取引先専用の発注サイトで決める価格・権限・受注後の業務

取引先ごとの価格が数種類の価格グループにまとまり、取引先数・商品数が既製品のプランの上限に収まるなら、BtoB向けの既製の発注サイトで足ります。個別単価・最低発注数・与信の確認・今の販売管理との受け渡しで毎日のように例外が出るなら、「既製品＋販売管理とつなぐ部分だけの開発」か「個別開発」を検討してください。どちらの場合も、取引先Aのログインで取引先Bの注文や価格が開けないことを、完成の条件に入れて発注してください。

この記事は、卸売・メーカー・法人向けサービスで取引先の注文をFAX・メール・電話で受けていて、取引先にログインして注文してもらう窓口へ移したい事業責任者・営業事務責任者に向けたものです。社内の受注台帳や注文の状態管理をどう作るかは受発注システムの開発を依頼するにはで扱っています。この記事は、社外の取引先が使う注文の窓口に絞ります。

AI革命の受託開発の公開価格は、小規模な既存改修が30万円〜、PoC（本番前の検証開発）が300万円〜、本開発は個別見積です（すべて税別、クラウド利用料などの実費は別）。PoCの300万円は本番システム一式の価格ではありません。

既製のBtoB向け発注サイトで足りるかを先に確かめる

出典: Bカート公式サイト

取引先がログインして注文するサイトは、月額で使える既製品がいくつもあります。最初に確かめるのは「取引先ごとの価格をどこまで細かく分ける必要があるか」と「受けた注文を今の販売管理へどう渡すか」の2点です。

確認すること	既製品で足りやすい	連携の開発、または個別開発を検討する
取引先ごとの価格	数種類の価格グループ（掛け率）にまとまる	取引先×商品ごとの個別単価が多く、価格グループに束ねられない
取引先ごとに見せる商品	全取引先にほぼ同じ商品を見せる	取引先ごとに扱える商品・地域・ブランドが違う
発注単位・最低数量	商品ごとに単位が決まっていて、取引先で変わらない	取引先ごとにケース入数・最低発注数・締め時刻が違う
受注を確定する人と時点	注文ボタンで確定してよい（在庫・与信の確認が不要か、後で人が見れば足りる）	与信枠・在庫・納期を見て、受注担当が確定・差し戻しを決める
今の販売管理との受け渡し	CSVを手作業で取り込めば足りる、または販売管理ごと置き換えてよい	販売管理は残し、注文・在庫・出荷・請求の情報を毎日やり取りする必要がある
取引先側のログインの管理	取引先1社に1アカウントで足りる	取引先の中に複数の担当者・拠点があり、見てよい範囲が違う

既製品のうち、取引先ごとの価格に関わる制限を公式ページで確認したものは次のとおりです（2026年10月10日に各社公式ページで確認）。

製品と種類	公式の価格	発注サイトとして使うときの制限（公式の記載）	1年目の費用の例（公式価格からの計算）	出典
Bカート（BtoB専用の発注サイト型）	初期80,000円。月額ライト9,800円（商品500・会員50まで）〜プラン300 79,800円（商品・会員30,000まで）。大規模は個別見積。税別	価格グループ・表示グループは標準10まで（11以上はオプション）。取引先によるCSVでの注文はプラン30以上。注文承認・受注CSVの取り込みはオプション	ライト: 80,000円＋9,800円×12か月＝197,600円。CSV注文を使うプラン30: 80,000円＋29,800円×12か月＝437,600円（オプション・独自ドメイン月3,000円などは別）	料金プラン／機能一覧
Shopify（汎用のネットショップ＋B2B機能）	年払いの月額 Basic 3,650円／Grow 10,100円／Advanced 44,000円。Plus 368,000円/月〜。税込・税抜の区分は料金ページで確認できず	2026年4月から Plus 以外のプランでもB2B機能を追加費用なしで使える。ただし有効なB2B用の価格表（カタログ）は3つまでで、会社・拠点ごとにカタログを直接割り当てられるのは Plus のみ	価格表を3種類にまとめられるなら Advanced 44,000円×12か月＝528,000円。取引先ごとの価格表が必要なら Plus 368,000円×12か月＝4,416,000円〜（アプリ・決済手数料は別）	料金／B2B機能のプラン別の違い／2026年4月の変更

この2つ以外にも、BtoB向けのパッケージや受発注専用のサービスがあります。公開価格を確認できなかったものはこの表に入れていないため、各社に確認してください。

表から分かるのは、取引先ごとの価格を何種類に束ねられるかで、既製品の費用が大きく変わることです。Shopifyでは価格表が3種類を超えると Plus が前提になり、年間の利用料だけで441万6,000円〜になります。Bカートは価格グループ10までが標準です。自社の価格表が「掛け率3種類＋一部の取引先の特別単価」程度で済むのか、「取引先ごとに全商品の単価が違う」のかを、まず数えてください。

3つの進め方の違い

進め方	中身	合う場合	注意すること
既製品をそのまま使う	発注サイトは既製品。受けた注文はCSVで販売管理へ手作業で取り込む	価格と商品の出し分けが製品の標準機能に収まり、注文数が手作業の取り込みで回る	注文承認や受注CSVの取り込みがオプションになる製品がある。月額とオプションの合計で比べる
既製品＋つなぐ部分だけ開発	発注サイトは既製品。商品・価格・取引先の情報と注文データの受け渡しを開発する	発注サイトは標準機能で足りるが、販売管理との二重入力や取り込み漏れが問題	既製品側のCSV・API・Webhook（注文が入ったら知らせる仕組み）の仕様と、販売管理側の取り込み制限を先に確認する
個別開発	発注サイト自体を作る	価格・単位・受注確定の決まりが製品の設定で表せない。または既存の社内システムの一部として作りたい	他社の情報が見えない作りとその確認試験、取引先のアカウント管理、公開後の保守まで見積に含める

一般的な既製品と個別開発の選び方は既製品か個別開発かの判断で扱っています。

発注サイトを作らない方がよい場合

取引先がWebに移ってくれる見込みが立たない場合は、先にFAXやメールの注文を読み取って入力する手間を減らす方が効果が出ます（FAX受発注の自動化）
困っているのが社内の注文の状態管理（変更・分納・請求数量が追えない）なら、取引先向けの窓口より先に社内の受注台帳を整える方が先です（受発注システムの開発を依頼するには）
一般消費者向けのネット販売、カード決済の仕組みそのもの、倉庫・配送の最適化までを1つの発注サイトでまとめて作り替えたい場合は、範囲と費用の桁が変わります。この記事の対象外です

取引先専用の発注サイトを使う人と画面

発注サイトは「取引先が注文する画面」だけでは動きません。自社の受注担当と、価格や取引先を管理する人の画面が要ります。見積を頼む前に、3者の画面をどこまで最初に作るかを決めてください。

説明用の画面一覧（架空の構成例。実案件の画面ではありません）

使う人	画面	その画面でやること	事前に決めること
取引先の発注担当	ログイン	自社の担当者として入る	1社1アカウントか、担当者ごとか
取引先の発注担当	商品一覧・注文入力	自社向けの価格と商品だけを見て注文する	見せる商品の範囲、価格の決まり方、発注単位・最低数量
取引先の発注担当	注文履歴・状態	自社の注文と、受付・確定・出荷の状態を見る	どの状態まで見せるか、差し戻しの理由をどう見せるか
取引先の管理者	担当者の追加・停止	自社の担当者を増やす・退職者を止める	取引先側でできるようにするか、自社が代行するか
自社の受注担当	受注一覧・確認待ち	与信や在庫で止まった注文を確定・差し戻しする	自動で確定する条件と、人が見る条件
自社の受注担当	代理入力	FAX・電話で来た注文を同じ台帳に入れる	移行期間中に代理入力を残すか
自社の管理者	価格表・掛け率・個別単価	取引先ごとの価格を登録・変更する	価格を正として持つのは販売管理と発注サイトのどちらか
自社の管理者	取引先・公開範囲	取引先の登録、見せる商品、与信枠を管理する	新規取引先の申し込みを受けるか、招待制にするか

最初の範囲を小さくするなら、取引先側の「商品一覧・注文入力・注文履歴」と、自社側の「受注一覧・確認待ち」から始め、価格表の管理は当面、販売管理から取り込む形にする方法があります。取引先の管理者が担当者を自分で追加する画面は、取引先の数が増えてから足しても間に合います。

価格・発注単位・受注確定を架空データで確かめた

取引先ごとの価格と受注確定のルールは、言葉で決めたつもりでも、実際の注文に当てると食い違いが出ます。そこで、架空の商品3点・取引先2社のデータで、価格の決まり方と注文の受け付けを判定する小さなプログラムを書き、2026年10月10日に実行しました。

前提（架空データ）

商品: P-100 業務用洗剤（標準単価2,400円・1ケース4個）、P-200 ペーパータオル（180円・1ケース40個・最低2ケース）、P-300 ゴム手袋（950円・1ケース20個）
取引先A: 価格グループの掛け率0.80、与信枠30万円、全商品を表示。P-100だけ特別単価1,800円
取引先B: 掛け率0.90、与信枠10万円、P-300は販売対象外

結果（架空データ・判定ロジックだけの確認。Web画面・データベース・通信での試験ではありません）

確かめたこと	入力	判定
価格の優先順位	取引先AがP-100（標準2,400円）を見る	特別単価1,800円が、掛け率（2,400円×0.80）より優先された
掛け率	取引先AのP-200／取引先BのP-100	144円（180円×0.80）／2,160円（2,400円×0.90）
正常な注文	取引先A: P-100を8個、P-200を80個	14,400円＋11,520円＝25,920円。「受付済み（在庫・納期の確定待ち）」
ケース単位に合わない注文	取引先A: P-200を50個（40個単位）	差し戻し「40個単位（ケース）で注文」
販売対象外の商品	取引先B: P-300を20個	差し戻し「この取引先には販売対象外」
与信枠を超える注文	取引先B: P-100を40個＝86,400円。売掛残20,000円	合計106,400円が与信枠10万円を超えるため、自動で確定せず「受注担当の確認待ち」
他社の注文が見えないか	取引先Aが取引先Bの注文番号を指定／取引先Bが取引先Aの注文番号を指定／存在しない番号を指定	3つとも同じ「見つかりません」の応答になり、自社の注文だけが表示された

この確認で見えた、発注前に決めておくべき点は次の3つです。

差し戻した注文にも注文番号を振るか。 今回のプログラムでは差し戻した注文にも番号を振りました。取引先に「注文番号は来たのに注文は通っていない」と見えると問い合わせが増えるため、差し戻しの注文を番号付きで残すか、入力画面で止めて番号を振らないかを決めます
与信枠を超えたら止めるか、人に回すか。 止めると取引先は注文できず、人に回すと受注担当の確認作業が増えます。どちらにするかで受注確定の流れと受注担当の画面が変わります
他社の注文番号と、存在しない番号を同じ応答にするか。 他社の注文番号のときだけ「権限がありません」と表示すると、その番号の注文が存在することが相手に分かります。今回は両方を同じ「見つかりません」にしました

この確認は判定の考え方を確かめただけです。価格の端数処理（今回の数字では端数が出ていません）、消費税の計算、数量割引、締め日、最低ケース数を下回る注文は試していません。実際の価格表と過去の注文で同じ確認を行うのは、開発の中で行う作業です。

受注確定の条件表（説明用の例）

「取引先が注文ボタンを押した時点」と「自社が受注を確定した時点」は別のものとして扱う方が、後の食い違いが減ります。次の表は説明用の例です。自社の条件に書き換えて使ってください。

状態	この状態になる条件	取引先に見える表示	次に動く人
差し戻し	発注単位・最低数量に合わない、販売対象外の商品がある	理由と直し方	取引先
受付済み	入力の条件をすべて満たした	受け付けました（確定前）	自社の仕組み（在庫・与信の確認）
確認待ち	与信枠を超える、在庫が足りない、指定納期に間に合わない	確認中	自社の受注担当
確定	在庫・納期・与信の確認が済んだ	確定・出荷予定日	自社の出荷担当
取消・変更	確定前の取引先からの取消、または受注担当の判断	取消済み・変更内容	決めた担当者（確定後の変更を誰が受けるか）

他社の注文や価格が見えないことを完成の条件に入れる

出典: IPA 安全なウェブサイトの作り方（アクセス制御）

社外の会社が使う画面で一番避けたい事故は、取引先Aに取引先Bの注文・価格・取引条件が見えてしまうことです。メニューやリンクに出さないだけでは防げません。

IPA（情報処理推進機構）の「安全なウェブサイトの作り方」は、ログイン後でも、画面のURLや送られてくる値に含まれる注文番号などをそのまま使ってデータを取り出す作りだと、他人の情報を閲覧・操作されるおそれがあると説明し、根本的な対策として「認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする」ことを挙げています。注文番号であれば、その番号がログイン中の利用者に見せてよい注文かを毎回確かめる作りです（IPA 安全なウェブサイトの作り方 1.11 アクセス制御や認可制御の欠落）。ウェブアプリの代表的な危険をまとめた OWASP Top 10 の2025年版でも、この「アクセス制御の不備」が1番目に挙げられ、許可したもの以外は拒否する、サーバー側で確かめる、アクセス制御の確認をテストに含める、失敗を記録する、といった対策が示されています（OWASP Top 10:2025 A01 Broken Access Control）。

発注サイトに置き換えると、検収のときに次のような確認を求めることになります。

検収の確認例（手順と期待する結果。実施結果ではありません）

確認すること	手順	期待する結果
他社の注文を開けない	取引先Aでログインし、画面のアドレスや検索欄に取引先Bの注文番号を入れる	存在しない番号と同じ「見つかりません」になる
他社の価格が出ない	取引先Aで商品一覧・注文書のPDF・CSVの出力・メール通知を確認する	画面以外の出力にも取引先Bの単価や商品が含まれない
停止した担当者が入れない	自社または取引先の管理者が担当者を停止し、その担当者でログインする	ログインできない。過去の注文は自社側の受注一覧に残る
取引先の管理者の権限が自社内に限られる	取引先Aの管理者で担当者を追加する	取引先Aの担当者しか追加・閲覧できない
価格を変えても確定済みの注文は変わらない	価格表を変更した後に、変更前に確定した注文を開く	注文時点の単価のまま表示される
失敗したアクセスが記録される	上の他社の注文を開く操作をした後で、記録を確認する	誰が・いつ・どの番号を開こうとしたかが残る

開発会社に見積を頼むときは、この種の確認試験が見積に含まれているか、誰が実施して結果をどの形で受け取るかを聞いてください。既製品を使う場合も、取引先ごとの表示を設定で分けたあと、同じ確認を自社で行う価値があります。

取引先側の担当者アカウントを誰が管理するか

取引先の中で担当者が入れ替わると、退職者のアカウントが残ったままになるおそれがあります。取引先の数が少ないうちは自社の管理者が追加・停止を代行し、取引先が増えたら取引先の管理者に任せる、という段階の分け方があります。どちらにしても「取引先から退職の連絡を受けたら誰が何日以内に止めるか」は、運用の決まりとして文書に残してください。

今の販売管理を残したまま、発注サイトとつなぐ

在庫・出荷・請求を今の販売管理や会計で続ける場合は、どの情報をどちらが正として持ち、どちら向きに、どのくらいの間隔で渡すかを決めます。

説明用の受け渡し表（架空の構成例）

情報	正として持つ側	渡す向き	間隔の例	失敗したときの担当
商品・標準単価	販売管理	販売管理 → 発注サイト	1日1回	自社の管理者
取引先ごとの価格・掛け率	販売管理か発注サイトのどちらか一方	正の側 → もう一方	変更のたび	自社の管理者
取引先・与信枠・売掛残	販売管理	販売管理 → 発注サイト	1日1回〜都度	自社の経理・受注担当
注文	発注サイト	発注サイト → 販売管理	注文のたび、または1日数回	自社の受注担当
出荷予定日・出荷済み	販売管理	販売管理 → 発注サイト	出荷のたび	自社の出荷担当
請求	販売管理・会計	発注サイトには渡さないか、履歴だけ見せる	締め日	自社の経理

つなぎ方は、販売管理が受け付ける方法で決まります。CSVの取り込みしかできない販売管理なら、発注サイトから販売管理の形式に合わせたCSVを作る部分を開発します。販売管理の提供元がAPI（システム同士で直接データをやり取りする窓口）を公開していれば、それを使う方法が候補になります。販売管理のデータベースへ直接書き込む作り方は、提供元が想定していない更新になるため、提供元に確認しないまま前提にしないでください。発注前に、販売管理のCSVの項目仕様、一度に取り込める件数、取り込みの操作を誰がしているか、提供元に改修を頼む必要があるかを確認してください。

取引先がサイトで注文したデータは、国税庁の電子帳簿保存法の一問一答（電子取引関係、令和8年7月版）の問2で、インターネット上のサイトを通じた取引情報の授受として電子取引に当たると説明されています。注文データを電子のまま、取引年月日・金額・取引先で探せる形で残すかを要件に入れ、具体的な保存方法は税理士や国税庁の資料で確認してください。

取引先に使ってもらうまでの移行

出典: GMOクラウドEC 公式サイト

発注サイトは、取引先が使い始めて初めて効果が出ます。全取引先が一度に移る前提は置かず、移行期間の運用を最初から設計に入れておきます。

一部の取引先から始める。 注文の頻度が高く、Webで注文してくれそうな取引先数社から始め、使われ方を見て画面を直します
FAX・電話の注文は自社の担当が代理入力する。 移行期間はFAXの注文も同じ台帳に入れ、取引先がどちらで注文しても状態を一か所で追えるようにします。既製品にも営業担当が電話・FAXの注文を代わりに入力する機能を案内しているものがあります（GMOクラウドEC BtoB）
取引先にとっての利点を先に伝える。 注文の状態や出荷予定日が電話しなくても見える、過去の注文から繰り返し注文できる、といった取引先側の手間が減る点を案内に書きます
初回のログイン情報の渡し方を決める。 招待メールで本人に設定してもらうのか、自社が仮の情報を発行するのかを決めます

自社でAIを使って進められること、開発会社に頼むこと

ChatGPTやClaudeなどの生成AIで、発注サイトの画面の試作や、上で紹介したような判定プログラムまで社内で作れます。開発会社に頼む前に自社で進めておくと、相談で決める範囲が絞れ、外注する部分も小さくできます。

自社でAIを使って進めやすいこと	開発会社に頼む方がよいこと
今の注文書・FAXの様式から、取引先に入力してもらう項目の一覧を作る	実際の価格表と過去の注文で、価格・単位・与信の判定が今の運用と一致するかを確かめる
架空の取引先・商品データで、注文画面と受注一覧の試作を作って現場に見せる	取引先ごとに見える範囲を分ける作りと、他社の情報が見えないことの確認試験
受注確定の条件表と差し戻しの文言の案を作る	販売管理との受け渡しで、どちらを正とするか・失敗したときの再送と担当を決めて実装する
販売管理のCSVの項目を並べて、対応表の下書きを作る	取引先・価格・過去の注文のデータ移行と、移行後に数字が合っているかの確認
取引先向けの案内文と、よくある問い合わせの案を作る	公開後の障害対応、バックアップと復旧、価格の決まりが変わったときの改修

AIで作った試作がある場合は、そのまま本番で使える部分と、ログイン・権限・データの持ち方・テストを足す部分を分けて考えます。社内でAIを使った開発を続けながら、権限や販売管理との連携のように責任の重い部分だけを任せる進め方も選べます。

費用の目安

AI革命の受託開発の公開価格は次のとおりです（すべて税別。クラウドの利用料、外部サービスのAPI利用料、既製品の月額、ソフトウェアのライセンス料などの実費は別）。

依頼の形	公開価格	発注サイトでの当てはまり方の例
小規模な既存改修	30万円〜	既製の発注サイトと今の販売管理のあいだのCSVの受け渡しを整える、受注の取り込み画面や確認画面を足す
PoC（本番前の検証開発）	300万円〜	一部の取引先・一部の商品で発注サイトを試作し、価格の当て方・受注確定の流れ・他社の注文が見えないことを確かめる。検証内容の整理、設計・開発、評価結果のまとめまで
本開発	個別見積	本番で使う取引先専用の発注サイト。取引先数、価格表の種類、つなぐシステム、データ移行、権限の要件を確認して見積もる

PoCの300万円は検証を始めるための価格で、本番の発注サイトの完成価格ではありません。本開発の金額は、上の画面一覧のどこまでを最初に作るか、価格の決まりの複雑さ、販売管理とのつなぎ方、移すデータの量で決まります。既製品＋つなぐ部分だけの開発を選ぶ場合は、既製品の利用料（たとえばBカートのプラン30なら1年目437,600円、税別）と、つなぐ部分の開発費を合わせて比べてください。業務システムの費用の内訳は業務システム開発の費用でも整理しています。

開発会社によって見積に含む範囲は違います。他社の情報が見えないことの確認試験、取引先アカウントの初期登録、データ移行、販売管理側の設定変更、公開後の取引先からの問い合わせ対応が含まれているかを揃えてから比べてください。

取引先に入力してもらいたい項目と、今の受注管理を相談する

初回相談は無料・30分（オンライン）です。要件が決まっていなくても大丈夫です。取引先に入力してもらいたい項目と今の受注の流れを伺い、相談後に依頼範囲の候補と費用の目安を相談メモでお返しします。

公開できる関連事例（発注サイトの事例ではありません）

AI革命が公開している受託開発の事例に、BtoBの発注サイトはありません。ただし、発注サイトで問題になる論点と近いものを扱った事例が2つあります。

薬局の複数店舗・数千人分の記録管理：権限と確認の工程を持つ記録管理です。発注サイトでいえば、使う人ごとに見てよい範囲を分け、確定する人を決める部分に近い設計です
通信事業の請求データの取り込み・集計・確認画面：数万件の請求情報を取り込んで集計し、確認できる画面を作った案件です。発注サイトでいえば、受けた注文を取り込み、受注担当が確認する画面に近い作業です

いずれも業種と業務が異なるため、発注サイトの実績として扱わないでください。発注サイトについては「対応できる範囲」として、取引先がログインする注文画面と自社の受注画面の新規開発、取引先ごとの価格・商品の出し分け、他社の情報が見えない権限の設計と確認試験、既製品や販売管理とのCSV・API連携、データ移行を引き受けられます。カード決済を付ける場合は、決済サービスに任せる部分と作る部分を分けて設計します。どの方法でつなぐかは、相談の中で一緒に決めましょう。2つの事例の公開範囲と対応範囲はAI革命の受託開発ページで確認できます。

相談の前に揃えておくと早いもの

全部揃っていなくても相談できます。手元にあるものだけで構いません。

取引先の数と、Webで注文してくれそうな取引先の数の見込み
価格の決まり方（掛け率の種類の数、特別単価がある取引先・商品のおおよその数）
発注単位・最低数量・締め時刻が取引先ごとに違うかどうか
受注を確定するタイミングと、確定前に誰が何を見ているか（在庫・与信・納期）
使っている販売管理・会計の名前と、CSVの項目一覧や仕様書の有無
今の注文書やFAXの様式（取引先名・単価を伏せた形で十分です）
AIで作った試作や、検討中の既製品があれば、その名前

取引先の実名入りの価格表や注文データ、本番のパスワードやAPIキーは、初回の相談フォームには書かないでください。

よくある質問

掛売の請求書は、発注サイトから出すべきですか？

今の販売管理や会計で請求書を出しているなら、そのまま販売管理側に残す方が、締め・入金消込・会計とのつながりを変えずに済みます。発注サイトには請求の履歴を見せるだけにするか、何も渡さないかを決めます。発注サイトで請求書まで出すと、請求のもとになる記録が2か所に分かれ、数字が合わないときにどちらを直すかで迷うことになります。

カード払いの取引先と掛売の取引先が混ざっていても作れますか？

作れます。カード払いの部分は決済サービス（Stripeなど）に任せ、掛売の取引先は与信枠の確認と締め請求で受ける、という分け方ができます。取引先ごとに支払い方法を固定するか、注文のたびに選べるようにするかで画面と受注確定の条件が変わるため、どちらにするかを先に決めてください。

既製品で始めて、後から個別開発に移せますか？

移せます。ただし、取引先・価格・過去の注文のデータをどの形式で取り出せるかは製品ごとに違うため、契約前に確認してください。取引先のログイン用パスワードは移せない場合があり、その場合は移行時に取引先へ再設定を依頼する前提で計画します。既製品の時期に決めた受注確定の条件表や項目の対応表は、そのまま個別開発の要件として使えます。

新規の取引先からの申し込みも、発注サイトで受け付けたいのですが。

申し込みの受付と、取引を始めてよいかの審査は分けて考えます。申し込みはサイトで受け、与信の審査と価格グループの割り当ては自社の担当が行い、承認するまで商品や価格を見せない、という流れにすると、既存の取引先向けの価格が申し込み段階の会社に見えることを防げます。

取引先の数が少なくても、発注サイトを作る意味はありますか？

取引先の数より、1件の注文で確認や問い合わせがどれだけ発生しているかで判断します。取引先が数社でも、注文のたびに単価・在庫・納期の確認の電話が往復しているなら、注文の状態が見えるだけで手間が減ることがあります。一方、注文が定型で確認の手間が少ないなら、既製品の小さいプランか、今の受注の仕組みへの小さな改修で足りるかを先に確かめてください。