BtoB ECの構築で最初に整理すべきなのは、画面のデザインや商品点数ではなく、法人取引の約束事のうちどれをシステムに載せるかです。掛け払い（後払い）、取引先ごとに異なる価格、発注者と承認者が分かれた発注フロー、締め日ごとの請求書発行。これらは一般消費者向けのECにはない要件で、どこまで自動化するかによって、使うべき仕組みも費用も大きく変わります。
この記事は、電話・FAX・メールで受けている法人からの注文をWebで受けられるようにしたい卸売業やメーカー、既存の取引先向けに発注サイトを用意したい事業者の方に向けて書いています。BtoB ECで実装が必要になる代表的な機能、取引条件の整理の仕方、構築方式の比較、与信や請求で起きやすい失敗とその避け方までを、順を追って説明します。
結論としては、すべての取引条件を最初から網羅しようとせず、取引先の大半に共通する条件を標準として実装し、例外的な条件は人の確認を挟む形で始めるのが安全です。
BtoB ECと一般的なECの違い
BtoB ECは、Webで注文を受けるという点では一般的なECと同じですが、前提となる取引の形が異なります。違いを整理すると、設計で考えるべきことが見えてきます。
| 観点 | 一般的なEC（BtoC） | BtoB EC |
|---|---|---|
| 購入者 | 不特定の個人 | 契約済みの取引先企業とその担当者 |
| 価格 | 全員に同じ販売価格 | 取引先ごと・数量ごとに異なる価格 |
| 支払い | カード決済など即時決済が中心 | 掛け払い（月末締め翌月払いなど）が中心 |
| 発注の流れ | 購入者が一人で決める | 発注者が作成し、上長や購買部門が承認する場合がある |
| 帳票 | 領収書・購入明細 | 見積書、納品書、請求書、取引先指定の帳票 |
| 会員登録 | 誰でも登録できる | 審査を経た取引先だけが利用できる |
| 注文の傾向 | 少量・単発が多い | 定番品の繰り返し発注、大口、ケース単位 |
この違いから分かるのは、BtoB ECの中心は「商品を見つけて買う体験」より「決まった取引条件を正確に処理すること」にあるという点です。カタログ表示や検索も必要ですが、発注の正確さと事務処理の負担軽減が、取引先にとっても自社にとっても価値の大部分を占めます。
BtoB ECで実装が必要になる主な機能
取引先との関係や業種によって必要な機能は変わりますが、多くのBtoB ECで検討対象になるのは次の機能です。
取引先と担当者の管理
BtoB ECでは「会社」と「その会社の担当者」を分けて管理します。一つの取引先に複数の担当者がいて、それぞれ発注できる範囲や承認の権限が異なることが多いためです。取引先単位で価格や支払い条件、配送先を持ち、担当者単位でログインと権限を持たせる構造にします。担当者の追加や削除を取引先側で行えるようにするか、自社の営業担当が代行するかも、運用の負担に関わるので早めに決めます。
取引先別価格・数量別価格
価格の持ち方は、BtoB ECの設計で最も複雑になりやすい部分です。代表的なパターンは次のとおりです。
- 取引先ごとに掛け率を設定し、定価から計算する
- 取引先ごと・商品ごとに個別の単価を持つ
- 取引先をランク分けし、ランクごとの価格表を適用する
- 数量に応じて単価が下がる段階価格を設定する
- 期間限定の特価やキャンペーン価格を上書きする
実際にはこれらが組み合わさっていることが多く、どの価格が優先されるかのルールを明文化しないと実装できません。現在の価格表がExcelや営業担当の頭の中にある場合は、まずそれをルールとして書き出す作業から始めます。
掛け払いと与信
掛け払いは、取引先ごとの支払い条件（締め日、支払日、支払い方法）を持ち、注文時点では決済せず、締め日にまとめて請求する仕組みです。重要なのは与信の扱いです。取引先ごとに取引上限額を設定し、未入金額と今回の注文額の合計が上限を超える場合は、注文を保留して担当者が確認する流れを用意します。与信の判断と回収を外部に任せる企業間決済のサービスもあり、自社で与信管理の体制を持たない場合は選択肢になります。
発注承認フロー
取引先の社内で、発注者が作成した注文を上長や購買部門が承認してから確定させたいという要望はよくあります。承認フローを実装する場合は、承認者の設定、承認待ちの通知、差し戻し、一定金額以上のみ承認を求める条件などを決めます。取引先ごとに必要性が異なるため、承認フローを「使う・使わない」を取引先単位で切り替えられるようにするのが一般的です。
見積もり・帳票・請求書発行
大口の注文や特注品では、注文の前に見積もりを依頼したいという要望が出ます。見積もり依頼をECから受け、自社で金額を確定して返し、取引先がそれを承認すると注文になる流れを作ると、メールでのやり取りが減ります。納品書や請求書の発行は、販売管理や会計の仕組みと役割分担を決めたうえで、どちらで発行するかを決めます。請求書の発行・送付の自動化については、請求書の発行・送付を自動化する：販売管理と会計の連携設計で詳しく扱っています。
再発注と注文画面の使いやすさ
BtoBの注文は、同じ商品の繰り返し発注が多くを占めます。取引先の担当者にとって便利なのは、商品を一から探すことではなく、過去の注文履歴から数量だけを変えて再発注できること、よく使う商品をお気に入りや定番リストとして登録しておけること、品番を直接入力して素早く注文できることです。ケース単位や最低発注数量の制約がある場合は、入力時にその場で知らせる仕組みにしておくと、注文後の修正連絡が減ります。納期の目安や出荷状況を注文履歴から確認できるようにすると、取引先からの「届くのはいつか」という問い合わせも減らせます。
権限と取引先ごとの表示範囲
取引先によっては、扱える商品が契約で限られている場合や、特定の取引先専用の商品がある場合があります。商品の表示範囲を取引先単位で制御できるようにしておくと、誤発注や価格の見せ間違いを防げます。担当者単位では「発注はできるが価格は見せない」「承認のみ行う」「請求書だけを確認する経理担当」といった権限の違いが出ることもあります。最初は必要最小限の権限の種類で始め、取引先からの要望を受けて増やす方が、設定の複雑さを抑えられます。
構築前に取引条件を整理する手順
BtoB ECの要件は、取引条件の整理ができていればかなりの部分が決まります。次の手順で整理を進めます。
- 取引先を一覧にする：現在の取引先と、それぞれの注文頻度、注文方法（電話・FAX・メール）、担当営業を一覧にします。
- 取引条件を棚卸しする：取引先ごとの価格の決め方、支払い条件、締め日、配送条件、最低発注数量、送料の扱いを書き出します。
- 共通の型を見つける：棚卸しした条件のうち、大多数の取引先に当てはまる型を見つけます。全取引先の条件をそのまま実装しようとせず、型に収まらない取引先を例外として扱います。
- 例外の扱いを決める：型に収まらない取引先については、EC上で注文を受けたあと人が確認する、当面はEC対象外にする、などの方針を決めます。
- 他システムとの役割分担を決める：在庫、出荷、請求、会計のどこまでをECで持ち、どこからを既存の販売管理や基幹システムに任せるかを決めます。
- 先行して使う取引先を選ぶ：最初から全取引先に展開せず、協力的で注文頻度の高い数社で先に使ってもらい、運用を固めてから広げます。
手順3が特に重要です。営業担当が個別に交渉してきた結果、取引条件が取引先の数だけ存在するという状態は珍しくありません。これをすべてシステムで表現しようとすると、費用が膨らむだけでなく、条件の変更があるたびに改修が必要になります。システム化を機に条件を整理し、標準化できるものは標準化することも検討してください。
架空の例：業務用資材の卸売業
たとえば、飲食店向けに業務用の消耗品を卸している会社を考えます。取引先は数百社あり、注文の大半はFAXで届きます。価格は取引先のランクで決まる基本価格に、一部の大口取引先だけ個別単価が上書きされています。支払いは月末締め翌月末払いが大半で、一部の取引先だけ20日締めです。この会社では、ランク別価格と月末締めを標準として実装し、個別単価は商品と取引先の組み合わせで登録できるようにし、20日締めの取引先は請求処理を人が確認する運用にしました。こうした線引きにより、最初のリリースで扱えない取引先を最小限にしつつ、仕組みを複雑にしすぎずに済みます。
構築方式の比較と選び方
BtoB ECの構築方式は、おおむね次の四つに分かれます。
| 方式 | 向いている状況 | 注意点 |
|---|---|---|
| BtoB向けのクラウド型サービス | 取引条件が一般的で、早く始めたい | 価格ルールや承認フローの柔軟性はサービスの機能範囲に依存する |
| 汎用ECプラットフォームの拡張 | BtoCも同時に運営しており、基盤を共通にしたい | BtoB特有の機能はアプリや追加開発で補う必要がある |
| パッケージ＋カスタマイズ | 基幹システムとの連携が必要で、標準機能の多くが合う | カスタマイズが増えるとバージョンアップが難しくなる |
| 個別開発 | 独自の価格体系や承認フロー、基幹システムとの密な連携が中心 | 開発と保守の体制を継続的に確保する必要がある |
判断の目安は、取引条件の整理結果です。整理した型が一般的なBtoB ECサービスの機能で表現できるなら、サービスの利用が最も早く確実です。表現できない条件が業務の中心にある場合、または既存の販売管理・基幹システムとのデータ連携が密に必要な場合に、カスタマイズや個別開発を検討します。汎用ECプラットフォームでどこまで対応できるかの考え方は、Shopifyでは足りないとき：カスタム開発が必要になる要件とはも参考になります。
既存の販売管理・基幹システムとの連携
BtoB ECを構築する企業の多くは、すでに販売管理システムや基幹システムで受注・請求・在庫を管理しています。ECはその入口を増やすものなので、データをどう渡すかが重要になります。
- 商品マスタと価格：販売管理側を正として、ECに定期的に配信するのが一般的です。EC側で価格を編集できるようにすると、二重管理になります。
- 取引先マスタ：取引先の追加や条件変更は販売管理側で行い、ECに反映します。EC独自の情報（ログイン担当者、承認設定）だけをEC側で持ちます。
- 受注データ：ECで確定した注文を販売管理に取り込み、以降の出荷・請求は従来の流れで処理します。
- 在庫：販売管理や倉庫側の在庫をECに表示する場合は、更新頻度と表示の仕方（在庫数をそのまま見せるか、「在庫あり」「残りわずか」のように見せるか）を決めます。
連携の設計で見落とされやすいのが、注文番号の対応づけと、取り込み後の変更の扱いです。EC側の注文番号と販売管理側の伝票番号を相互に参照できるようにしておかないと、取引先からの問い合わせに答えるたびに両方の画面を探すことになります。また、販売管理に取り込んだ後で数量変更や納期変更が発生した場合、その変更をECの注文履歴にも反映するのか、ECは「注文を受けた時点の記録」として扱うのかを決めておく必要があります。取引先が注文履歴を見て再発注する使い方を想定するなら、最終的な出荷内容がEC側でも確認できる方が混乱は少なくなります。
既存システムにAPIがない場合は、CSVファイルの受け渡しを定時に自動実行する方法から始めることもできます。連携方式の選び方はSaaS同士をつなぐ方法：iPaaS・API開発・CSV連携の選び方で比較しています。
取引先への展開と社内の運用体制
BtoB ECは、公開すれば自然に使われるものではありません。取引先に使ってもらうための展開計画と、社内の運用体制をあわせて準備します。
展開は、先行導入の数社で一か月程度運用し、注文の取り込みや請求の突き合わせに問題がないことを確認してから、取引先のグループごとに広げていくのが安全です。案内の際は、ログイン情報の発行手順、操作の説明資料、問い合わせ窓口を用意し、営業担当が訪問や電話のついでに操作を案内できるようにしておきます。FAXでの注文を急に断るのではなく、一定期間は並行して受け付け、EC経由の注文が増えた段階で切り替えを相談する方が、取引先との関係を損ねません。
社内では、EC経由の注文を誰が確認するか、保留になった注文（与信超過、承認待ちの長期化、在庫不足）を誰がどの順番で処理するか、取引先からの操作に関する問い合わせを誰が受けるかを決めておきます。受注担当、営業担当、経理担当の役割が曖昧なままだと、保留の注文が放置され、取引先の不満につながります。運用開始後は、EC経由の注文比率や保留の件数、問い合わせの内容を定期的に振り返り、画面の改善や取引条件の見直しにつなげます。
よくある失敗とその避け方
BtoB ECの構築では、次のような失敗が起きがちです。
- 取引先が使ってくれない：作ったものの、取引先は慣れたFAXや電話で注文を続ける、という状況です。取引先にとってのメリット（24時間注文できる、過去の注文から再発注できる、納期や出荷状況が見える）を明確にし、営業担当が導入を案内する計画を立てます。先行導入する取引先の声を聞いて改善することも効果があります。
- 価格ルールの実装が膨らむ：例外的な価格条件を一つずつ実装していった結果、開発が終わらない、または誰も全体のルールを説明できなくなります。手順3で述べたように、型と例外を分け、例外は人の確認で吸収する方針を決めます。
- 与信の確認が漏れる：掛け払いで注文を受け続け、未入金が膨らんでから気づくケースです。取引上限額の設定と、上限超過時の保留の仕組みを最初から入れておきます。
- 承認フローが現場に合わない：取引先ごとに承認の運用が違うのに、一つの形に固定してしまうと使われません。承認の有無と条件を取引先単位で設定できるようにします。
- 締め処理の確認がされない：EC上の注文と販売管理の請求データが一致しているかを確認する手順がないと、請求漏れや二重請求が起きます。締め日ごとの突き合わせを運用に組み込みます。
構築前のチェックリスト
開発会社への相談やサービスの比較の前に、次の項目を確認しておくと話が早く進みます。
- 取引先の数、注文頻度、現在の注文方法を把握している
- 価格の決め方（掛け率、個別単価、ランク、数量別）を書き出している
- 支払い条件と締め日のパターンを整理している
- 与信の上限や確認の手順を決めている
- 発注承認が必要な取引先と、その条件を把握している
- 商品マスタ・取引先マスタの正をどのシステムで持つか決めている
- 見積書・納品書・請求書のうち、ECで発行するものを決めている
- 最初に使ってもらう取引先の候補がいる
よくある質問
Q. BtoCのECサイトとBtoB ECは一つのシステムで運営できますか？
運営できます。ただし、価格の出し分け、会員の審査、掛け払いなど、BtoB特有の機能をどこまで同じ基盤で扱えるかを確認する必要があります。BtoBの取引条件が複雑な場合は、受注の入口を分け、商品や在庫のデータだけを共通化する方が運用しやすいこともあります。
Q. 掛け払いを導入すると、未回収のリスクが心配です。
取引先ごとの取引上限額と保留の仕組みを用意すること、与信と回収を代行する企業間決済サービスを利用することの二つが主な対策です。自社でどこまでリスクを持つかは、経理や経営の判断になります。契約や債権管理に関する制度面は、専門家に確認してください。
Q. 取引先別価格を見せ間違えることはありませんか？
ログインした担当者に紐づく取引先の価格だけを表示する設計にし、価格計算のルールを一か所にまとめて実装することが基本です。リリース前には、代表的な取引先ごとに価格が正しく表示されるかを受入テストで確認します。
Q. 最初はどのくらいの機能で始めるべきですか？
注文の受付、取引先別価格の表示、過去の注文からの再発注、注文の販売管理への連携があれば、FAXや電話からの移行効果を確かめられることが多いです。承認フローや見積もり依頼は、先行導入した取引先の要望を見て追加しても遅くありません。
Otsumuに相談できること
取引条件が比較的シンプルで、取引先の大半が同じ価格ルールと支払い条件で取引している場合は、BtoB向けのクラウド型サービスを選び、社内で設定と取引先への案内を進めれば十分です。この記事の取引条件の棚卸しとチェックリストを埋めるところまでは、自社で進めることをおすすめします。
外部の力を借りた方がよいのは、取引条件の型が見えず整理の段階で止まっている、既存の販売管理や基幹システムとのデータ連携が必要、既製サービスでは表現できない価格ルールや承認フローが業務の中心にある、といった状況です。どこまでを標準にし、どこを人の確認で吸収するかの線引きは、業務とシステムの両方を見て判断する必要があります。
Otsumuは、取引条件の整理から一緒に行い、既製サービスで足りる部分と個別に作るべき部分を分けたうえで、目的に必要な機能に絞って開発します。最初から全取引先に展開するのではなく、先行導入する取引先で検証しながら広げる進め方も支援できます。EC関連の開発についてはEC・通販システム開発をご覧ください。費用は範囲に応じて個別にお見積もりします。
FAX注文をWebに移したいが何から始めるべきか分からない、という段階からご相談いただけます。30分の無料相談で、現状の取引の流れをお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01