BtoB ECの機能とは？取引先別価格・掛売・承認フローの要否と実装コストの判断

BtoB ECの機能を調べると、取引先別価格・掛売・承認フロー・見積依頼・分納といった項目が並んだ一覧に行き当たります。困るのはその先。どれが自社に要るのか、どれを削ってよいのかは、機能名を眺めても決まりません。判断を分けるのは、いま自社が取引先とどう値決めをして、どう回収して、誰が発注しているかという取引の実態のほうです。この記事では、BtoB EC固有の機能を一つずつ取り上げ、要否を決める条件と、標準搭載で収まる範囲・追加開発に落ちる分岐点を整理します。作り込んでも使われない機能の線引きまで踏み込みます。

まとめ：BtoB ECの機能で先に決める3点と、費用が跳ねる境界

機能の要否は、価格の決まり方・代金の回収方法・発注する側の手続きという3点でほぼ決まります。まず3点を紙へ書き出すこと。それだけで機能一覧の大半は要否が付き、使われない機能への支払いを避けられます。

費用が跳ねる境界は4か所。取引先別価格を掛率で処理できるか個別単価が要るか、与信の残高チェックを即時にするか日次の取り込みで足りるか、承認が1段か多段か、1つの注文を複数回に分けて出荷するかどうか。ここを越えると多くの製品で標準機能の外に出ます。

市場側の前提も押さえます。経済産業省が2025年8月26日に公表した令和6年度電子商取引に関する市場調査では、2024年の国内BtoB-EC市場は514.4兆円、EC化率43.1%、業種別最大の卸売は128兆8,684億円でした。EC化率が4割を超えた段階での論点は、どの機能をECに載せ、どれを基幹システムに残すかという線引きです。

BtoCカートに無いBtoB EC固有機能の全体像と要否を決める順序

まず、BtoB固有と呼ばれる機能が何に由来するのかを押さえます。ここが分かると、項目名ではなく自社の取引条件から要否を判定できます。

取引慣習がそのまま機能要件に変わるBtoB ECサイトの構造

BtoB ECの固有機能は、企業間取引の商習慣を一つずつシステムに写し取ったものです。対応関係を並べると次のようになります。

左側が自社に当てはまらなければ、右側の機能は要りません。全社一律の定価で売り、代金を都度決済で回収し、発注者が社長1人という商売なら、BtoC向けのカートに会員限定の商品出し分けを足すだけで足ります。

会員登録の審査と非公開運用で分かれる商品と価格の公開範囲の設計

BtoC ECと同じく即時に会員登録できる設計にすると、単価が競合他社に見える事故が起きます。公開範囲は、ログイン前に何を見せるかで3通りです。

• 完全クローズド：ログインしないとサイトが見えない。既存取引先の受発注を移す場合に選ぶ
• 商品は公開・価格は非表示：新規の引き合いを取りたいが単価は伏せたい場合に選ぶ
• 全公開：定価販売の間接資材や、新規開拓を主眼に置く場合に選ぶ

クローズド寄りにするほど、申込から利用開始までのステータス管理が要ります。申込受付・与信審査中・承認済・取引停止を持ち、承認前のIDには価格を出しません。型の選び分けはBtoB ECとは？種類と構築方法、BtoCとの違いから受託開発目線の選び方まで解説で先に決めてから機能へ入ると手戻りがありません。

機能一覧を上から順に潰さないための、要否判断で先に見る3つの起点

ベンダーの機能一覧は50項目を超えることも珍しくありません。全部に○×を付ける進め方は時間の浪費で終わります。見る順序を決めてください。

1つ目は、いまの受注業務がどこで詰まっているか。FAXの転記なのか、単価の問い合わせ電話なのか、在庫の在り処を聞かれることなのか。詰まっている箇所に対応する機能だけが導入初日から効きます。2つ目は取引先数と品目数の掛け算です。取引先50社・品目500点と、500社・50,000点では同じ取引先別価格でも設計が別物になります。3つ目は基幹システム側にすでにある機能。与信も締め請求も販売管理が持つなら、EC側に作り直す必要はありません。受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準と機能が重なる領域は、どちらへ寄せるかを先に決めます。

取引先別価格と数量ブレイクの方式ごとに変わる作り込みの深さと費用

BtoB EC固有機能の中で、費用と保守負荷に最も効くのが価格です。ここだけは方式の違いまで踏み込んで決めてください。

掛率方式と得意先別単価方式で変わる価格マスタの持ち方と保守の手間

取引先別価格の方式は大きく2つ。掛率方式は「A社は定価の70%」と取引先ごとに係数を1つ持つ作りで、マスタは300社なら300レコードで済みます。得意先別単価方式は「A社のこの品番は1,180円」と取引先と商品の組み合わせで持つため、300社・5,000点で全組み合わせなら150万行です。

行数自体はデータベースの負荷として大きくありません。効いてくるのは保守のほう。定価を改定したとき、掛率方式なら定価マスタを直せば全社へ反映されますが、得意先別単価方式では150万行のどれを直すかという運用設計が要ります。誰がいつ何を根拠に単価を書き換え、誰が承認するのかまで決まっていないなら、全面採用は見送ってください。

実務でよく収まるのは併用です。7割の取引先を掛率で処理し、条件が特殊な主要取引先だけ個別単価を持たせる。適用ロジックには「個別単価が無ければ掛率」という優先順位が要ります。併用に対応しない製品もあるため、選定時に確認してください。

数量ブレイクとケース単位の発注が価格計算の条件に足す2つの分岐

数量ブレイクは、10個以上で単価を下げる段階単価です。分かれるのは、その段階を全社共通で持つか取引先ごとに持つかという点。取引先ごとに段階を変えられる製品は多くありません。

もう1つの分岐が入数です。1ケース12本の商材で、バラ売りを認めるのか、ケース単位に丸めるのか、端数をどう扱うのか。ケース単価とバラ単価が別にある業種では、注文画面で単位を切り替えると単価と在庫数の両方が連動する必要があります。ケースで在庫を持ってバラで売るなら、在庫数の換算をどこで行うかまで決めてください。

期間特価や個別の見積単価まで含めた価格の適用順序と検証の手順

価格の要素が増えると、優先順位を明文化しない限り画面ごとに違う金額が出ます。典型は上から、見積で提示した単価、期間限定の特価、得意先別単価、掛率で計算した価格、定価。

この順序は仕様書に1行で書けますが、テストは組み合わせの数だけ要ります。見積単価と期間特価が両方ある取引先で、期間の終了日をまたいだ注文がどちらになるか。数量ブレイクに乗った状態で個別単価が設定されていたらどうなるか。受け入れテストはこの組み合わせ表から作ってください。金額が1円違えば請求のやり直しになるため、他のどの機能よりテストの密度を上げる箇所です。標準対応の範囲はBtoB ECサイト比較｜4タイプの選定軸と製品比較の打ち切り条件の選定軸と合わせて確認します。

掛売と請求書払いでEC側に必要な機能と締め請求までの守備範囲

代金の回収は、EC側と基幹側の境界が最も曖昧になる領域です。どこまでをECに持たせるか、機能単位で切り分けます。

与信限度額のチェックを注文のどの時点で発火させるかの設計判断

与信枠の管理でまず決めるのは、チェックを走らせる時点です。候補は3つ。カートに入れた時点で警告する、注文確定の直前に判定する、出荷指示の段階で止める。注文確定時が一般的ですが、受注から出荷まで日数が空く商材では、出荷時にもう一度見ないと枠を超えます。

残与信は与信限度額から売掛残高と受注残高を引いた額です。難しいのは売掛残高の入手経路のほう。消し込みは会計や販売管理の側で行われるため、EC単独では正しい残高を持てません。夜間バッチで前日残を取り込む方式は実装が軽い代わりに当日入金が反映されず、都度APIで基幹へ問い合わせる方式は正確でも基幹側にAPIが無ければ改修が要ります。

超過時の挙動も先に決めます。注文を止めるか、承認待ちにして営業が判断するか、前払いへ切り替えるか。与信そのものの管理手法は与信管理システムの比較｜4タイプの選び分けと信用調査データ連携・受注時チェックの判断で扱っており、EC側は判定結果を受けて発注を制御する分担が無難です。

締め請求と支払通知の発行に要るインボイス制度の記載事項と対応

BtoBは20日締め翌月末払いのような締め請求が中心です。EC側に持たせるかの判断材料は締日のパターン数。全社共通で月末締め1本なら基幹に任せて問題ありません。10日・20日・月末が混在し支払サイトも30日と60日が混ざるなら、支払期日を出すためEC側にも締日マスタが要ります。

請求書を発行する側に回るなら、適格請求書の記載事項を満たす必要があります。記載事項は登録番号、税率ごとに区分した対価の額と適用税率、税率ごとに区分した消費税額等。出店者が並ぶマーケットプレイス型では、免税事業者が混じると買い手の負担が変わります。免税事業者等からの課税仕入れに係る経過措置は、2026年10月1日以降の控除割合が50%へ下がります。発注前に売り手の登録状況を判別できる表示を用意してください。請求業務をどのシステムで持つかは請求管理システムとは？機能・会計/販売管理との違いから選び方と受託開発の判断まで解説の整理が使えます。

2026年度末の約束手形の廃止を見込んだ支払方法マスタの設計

支払方法のマスタに手形を残すかどうかは、期限のある判断です。政府は2021年6月に5年後の約束手形の利用廃止という方針を示し、全国銀行協会は2021年7月に手形・小切手機能の全面的な電子化に向けた自主行動計画を策定。紙の約束手形は2026年度末での利用廃止が目標とされ、銀行界は2027年度初から電子交換所での交換を廃止する方針です。

これから構築するBtoB ECで、支払方法の選択肢に手形を新規実装する理由はありません。振込・口座振替・電子記録債権・クレジットカードで組んでおきます。既存取引先に手形が残る場合も、EC上の選択肢からは外して基幹側の個別対応にするほうが移行の手戻りが少なくて済みます。

承認フローと見積依頼、再注文で要否が分かれる取引実態の見極め

ここから先は、要ると思って作ったのに使われない機能が出やすい領域です。要否の条件を厳しめに置きます。

買い手企業の社内稟議をEC側に載せるべきでない3つの取引条件

承認フローの実装は、次の3条件のいずれかに当てはまるなら見送ってください。買い手側に購買・稟議システムがあり社内承認がそちらで完結している場合、承認者が普段ECにログインしない役職者である場合、承認ルールが取引先ごとに違い共通化できない場合。3つ目は特に厄介で、金額の閾値も段数も取引先ごとに違うため、汎用の承認エンジンは設定作業が終わりません。

代わりに機能させやすいのが、ID単位の権限だけで済ませる設計です。発注できるIDと、価格と在庫を見るだけのIDを用意し、承認は取引先の社内で完結してもらう。実装量は承認エンジンの数分の1で、運用の説明も1行で終わります。それでも多段の承認をEC上で回すなら、汎用のワークフロー基盤を別に立てて連携する道もあるでしょう。判断軸はワークフローとは？承認フローの仕組み・システム化の判断基準と選び方で整理した内容がそのまま使えます。

見積依頼から受注までを往復させる機能の実装コストと内訳の見方

見積依頼は、カートに入れて確定するだけの注文機能とは構造が違います。依頼を受け、単価を決め、回答し、承認を経て注文に変換される往復が発生するためです。実装コストは次の内訳で膨らみます。

1. ステータス管理：依頼中・回答済・承認待ち・失効・受注済の遷移
2. 有効期限：期限切れの見積から注文が起きない制御
3. 明細単位の調整：行ごとの単価変更に対応する画面
4. 回答側の管理画面：営業が単価を入力して差し戻す画面
5. 帳票出力：見積書のPDF生成と、承認済み見積の注文への引き継ぎ

標準で提供されるのは1と2までのことが多く、3以降は追加開発に回ります。特に4は自社の営業が使う画面なので、既存の見積業務に合わせる作り込みが避けられません。見積が月に数件なら、EC上は依頼を受けるだけにして、回答はメールと見積管理システムとは？機能・内製とパッケージの違いと導入判断を解説で扱う仕組みに任せるほうが安く付きます。

再注文と定期発注の機能が効く商材と、効かない商材との線引き方

再注文は、実装が軽い割に利用率が高い機能です。効くのは同じ品番を繰り返し買う商材で、消耗品・資材・定番部品・事務用品が該当します。前回注文のコピーとお気に入り登録だけで、発注作業は数分から数十秒になります。

実務で最もよく使われるのが注文パッドです。品番と数量を並べて直接打ち込む一覧画面のこと。手元の注文書やExcelから品番を貼り付けられる作りにすると、発注担当者は商品ページをほとんど見ません。CSVの取り込みまで対応させると、月次でまとめて発注する取引先の負担が下がります。

逆に効かないのは、都度仕様が変わる商材です。図面から起こす加工品、寸法指定のある建材、ロットや使用期限の指定が要る医薬品や食品。前回と同じ注文が成立しないため、再注文のボタンは押されません。この場合は指定条件を漏れなく入力させる機能へ予算を寄せます。

出荷分割と複数納品先への対応でEC側に要る在庫と配送の機能範囲

物流側の機能は、1つの注文が1回の出荷で終わるかで作りが変わります。後から直すと影響範囲が広く、初期に決める箇所です。

分納と直送を扱うために注文と出荷を分けて持つデータ構造の設計

BtoC向けのカートの多くは注文と出荷を1対1で持っています。分納、明細ごとの直送、複数拠点への同時納品は、この構造では表現できません。注文1件に出荷をn件ぶら下げ、出荷ごとに送り状番号と出荷日と納品書を持つ形へ変える必要があります。

納品先マスタも要ります。1つの取引先に納品先が複数あり、それぞれ住所・担当者・受け入れ時間帯を持つ構造です。建設資材のように現場へ直送する商材では納品先が毎回変わるため、注文時に届け先を追加できるかも要件になります。

分納したときの請求を出荷のたびに立てるのか締めでまとめるのかも、販売管理側の仕様に合わせて決めます。卸売の受発注と掛売、多倉庫在庫を扱う考え方は卸売業の販売管理システムとは？受発注・掛売・多倉庫在庫に対応する選び方が詳しく、EC側の設計もその前提に合わせます。

欠品と入荷待ちの状態を取引先にどこまで見せるかの表示の設計方針

在庫の見せ方は3段階です。実数をそのまま出す、在庫あり・残りわずか・在庫なしに丸める、表示自体をしない。実数を出すと問い合わせは激減しますが、競合が取引先として登録できる型のサイトでは在庫水準が読まれます。クローズドな運用なら実数、開放型ならしきい値表示が落とし所です。

欠品時の挙動も決めます。注文を止めるか、入荷待ちで受けるか、代替品を出すか。入荷待ちにするなら予定日の精度が問われ、仕入先の納期回答を取り込む仕組みまで要ります。精度に自信が無いなら、取り寄せ・納期別途連絡の1状態にとどめるほうが安全でしょう。

標準搭載と追加開発の境界で決まる費用差と、作らなくてよい機能

ここまでの機能を費用の観点で1枚に落とし、作らないと決めてよい機能を言い切ります。

ASPの標準機能で収まる範囲と、追加開発へ落ちていく分岐点の見方

BtoB特化型のASPやパッケージは、固有機能の中核を標準で持ちます。境界は次のあたりです。

右列に3つ以上当てはまるなら、ASPを改造して近づけるより受託開発のほうが総額で安くなる公算が高まります。追加開発の見積が膨らむのは機能単体の複雑さではなく、基幹システムとの接続がセットで付くため。残与信の即時計算も分納の請求連携も、EC単体では完結しません。

機能を盛るほど使われなくなる、実装を見送ってよい機能の判断軸

ここは言い切ります。次の機能は、BtoB ECの初回リリースから外して構いません。

• 多段の承認フロー：買い手の社内手続きであり、売り手のECが肩代わりする必然性が薄い
• レコメンドと関連商品：買う品番が決まっている発注者には邪魔になる
• ポイントとクーポン：与信と掛売のある取引で値引き原資の管理が二重化する
• ファセット検索：品番の直接入力が速く、実際に使われるのは検索窓と注文パッド
• 凝った商品ページ：スペック表とPDFカタログがあれば足りる商材が多い

外してはいけないのは、注文パッド、前回注文からの再注文、価格の正しさの3点です。利用率は、発注担当者が電話やFAXより速いと感じるかで決まります。買い物の楽しさを設計しても発注は増えません。単価が1回でも間違えば、その取引先は電話に戻ります。予算はこの3点に寄せてください。

RFPに機能要件を書くときの粒度と、先に決めておくべき前提条件

ベンダーに渡す要件へ「取引先別価格に対応していること」と書くと、見積は当てになりません。掛率と読む会社と、個別単価の一括メンテ画面まで含めて読む会社では金額が数倍変わります。書く粒度はこの水準です。

取引先300社・品目5,000点。取引先の7割は定価からの掛率で、残り3割に品目別の個別単価がある。個別単価は掛率より優先する。数量ブレイクは全社共通の3段階。単価改定は年2回、CSVで一括更新する。締日は10日・20日・月末の3パターン、支払サイトは30日と60日。与信限度額は販売管理システムが持ち、EC側は前日残を夜間バッチで取り込んで判定する。分納あり、直送は明細単位で指定する。

ここまで書ければ見積のばらつきは大きく減ります。先に決めるのは、価格マスタの主管がECか基幹か、価格改定の頻度と担当部署、締日のパターン数、納品先の最大数、承認の要否の5点。固まらないまま製品選定へ進むと、選定後に要件が動いて追加費用が出ます。例外が多く販売管理システムとの接続まで含めて設計するなら、ECシステム開発のように受発注と基幹連携をまとめて引き受ける形で相談するほうが見通しが立ちます。

よくある質問

要件定義の段階で繰り返し出てくる質問をまとめます。

BtoB ECに最低限必要な機能はどれですか？

既存取引先の受発注をECへ移す前提なら、ログインしないと価格が見えない会員制、取引先別の価格表示、品番と数量を直接入力できる注文パッド、注文履歴からの再注文、そして掛売の注文データを販売管理システムへ渡す連携の5つです。これだけでもFAXと電話の受注は置き換わります。承認フローと見積依頼は要否が分かれるため、最低限には含めません。

BtoC向けのECカートにBtoBの機能を後付けできますか？

取引先が数十社で、価格が掛率で表現でき、支払いが都度決済かシンプルな請求書払いに収まるなら実用になります。難しくなるのは、企業単位のアカウントに複数の担当者IDをぶら下げる構造と締め請求の管理です。BtoC向けカートの標準機能の外にあり、拡張機能で無理に埋めると保守が複雑になります。製品タイプ別の向き不向きは比較記事で整理しています。

取引先ごとの価格設定はどこまで細かく設定できますか？

製品によって差が大きい部分です。掛率だけの対応、掛率と得意先別単価の併用、数量ブレイクとの組み合わせ、期間特価や見積単価の優先適用、という順に対応範囲が広がります。自社に要る階層を先に確定させ、その組み合わせで金額が正しく出るかを選定時のデモで実データを使って確認してください。カタログの機能名では判断できません。

掛売の与信管理はECだけで完結できますか？

完結しません。売掛残高の消し込みは会計や販売管理の側で行われるため、ECは残高を受け取って判定する立場になります。EC側は、限度額の参照、受注残を加味した残与信の計算、超過時の注文制御まで。取り込みを夜間バッチにするか即時参照にするかで、当日入金の反映速度と実装費用が変わります。

承認フローは必ず入れる必要がありますか？

必要ない場合のほうが多いというのが実務上の答えです。買い手の社内稟議は購買システムで完結していることが多く、承認者がECにログインしない運用では機能が空回りします。発注できるIDと閲覧だけのIDを分ける権限設計で足りるかを先に検討し、足りない場合に限って実装を検討してください。

関連記事

• BtoB ECとは？種類と構築方法、BtoCとの違いから受託開発目線の選び方まで解説：機能の前に決める型と構築方法の整理です。
• BtoB ECサイト比較｜4タイプの選定軸と製品比較の打ち切り条件：要否が固まった後の製品タイプ選定に使います。
• BtoB ECサイトの事例｜導入パターン別の読み方と自社要件の逆算：公開情報から機能要件を逆算する手順です。
• 受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準：EC以外の受け口と機能が重なる領域です。
• 請求管理システムとは？機能・会計/販売管理との違いから選び方と受託開発の判断まで解説：締め請求をどこで持つかの判断材料です。