BtoB EC の価格・与信・承認をどう持つか：取引先別価格と掛売りの設計

BtoB EC の相談では、画面や商品ページよりも先に、こんな話が出てきます。「取引先ごとに価格が違う」「請求は月末締めの掛売り」「注文は上長の承認が要る」。BtoC の EC にはない、この 3 つをどこに持たせるかで、EC の作り方が大きく変わります。

この記事では、取引先別価格、掛売りの与信、購買承認の 3 つについて、設計の段階で決めておきたい論点を整理します。サービスを選ぶ段階の話ではなく、選んだ後に困らないための決めごとの話です。

BtoB-EC は、もう特殊な領域ではない

経済産業省が 2026 年 10 月 21 日に発表した令和7年度デジタル取引環境整備事業（電子商取引に関する市場調査）によると、2025 年の BtoB-EC の市場規模は 560兆870億円で、前年比 8.9% 増でした。EC 化率は 45.9% で、前年から 2.8 ポイント上昇しています（ネットショップ担当者フォーラムの報道）。

企業間の取引の半数近くが EC 経由になっているということです。電話や FAX の注文を EC に置き換える動きは、これから始める会社にとっても、すでに始めた会社にとっても、現実の経営課題になっています。

3 つとも「後から足す」と作り直しになりやすい

取引先別価格、掛売りの与信、購買承認は、注文・出荷・請求のすべてに関わるため、EC を作った後に足すと、注文データの持ち方から見直すことになりやすいと私たちは考えています。大事なのは、機能があるかどうかより、その機能の中で何を決めるかです。

1. 取引先別価格：優先順位と、改定時の既注文を決める

取引先ごとに単価が変わる場合、同じ商品に複数の価格が候補として存在します。定価、取引先のグループ（ランク）の単価、その取引先だけの特別単価です。ここで決めておきたいのは次の点です。

• 価格の優先順位：特別単価があれば最優先、なければグループ単価、それもなければ定価、のように順序を決めます。順序が曖昧だと、価格表を更新するたびに「なぜこの価格になったのか」を説明できなくなります
• 有効期間：価格は期間つきで持つほうが扱いやすいと私たちは考えています。改定を前もって登録でき、いつの注文がどの価格だったかを後から追えます
• 価格改定時の既注文：改定日をまたいで、すでに受けた注文や、カートに入れたままの商品を、旧価格と新価格のどちらで確定するかを決めます。注文を受けた時点の価格を注文に写して保存しておくと、後の改定が過去の注文に影響しません
• 価格の正はどこか：基幹システムに価格マスタがあるなら、EC 側にコピーして別々に更新すると、どちらが正か分からなくなります。同期の向きと頻度を先に決めます

まず、自社の単価パターンが何通りあるかを数えます。数えた結果が「グループ単価だけで足りる」のか、「取引先ごとの特別単価と期間つきの改定が必要」なのかで、既存サービスで足りるか個別開発が要るかの分かれ目が見えてきます。

2. 掛売りの与信：どこで止め、いつ更新するか

BtoB EC では、その場のカード決済ではなく、請求書払い（月締めの掛売り）が中心になります。ここで EC が引き受ける範囲を決める必要があります。与信限度額の管理や締め請求・入金消込の分担には、EC 基盤の機能で持つ、決済代行の掛売りサービスに出す、既存の販売管理システムへ受注データを渡す、という分け方があります。既存の取引先が中心なら、販売管理へ返す方式が摩擦の少ない選択になると私たちは見ています。与信も請求も現行の運用のまま、注文の入口だけが EC に変わるためです。

どの方式でも、設計では次の点を決めます。

• 与信枠を超える注文の扱い：注文を受けない、受けたうえで保留にして営業が確認する、のどちらにするか。私たちは、取引先との関係を考えると「保留にして確認する」を最初の選択肢にするほうが多いと考えています
• 与信枠の更新タイミング：注文の確定時に枠を使うのか、出荷時か、請求時か。入金で枠が戻るのはいつか。更新が遅れると、枠が余っているのに注文できない、あるいは超過しているのに注文できてしまう状態が起きます
• キャンセル・返品の戻し方：使った枠をいつ戻すか。ここも枠の更新と同じ時点の話として決めます
• 新規取引先の初回：既存の取引先なら基幹システムの与信情報を使えますが、新規は初回の審査をどう通すかが別の課題になります。外部の掛売りサービスや信用調査データとの接続を検討する余地が出ます

3. 購買承認：誰が、いくらから、何を承認するか

購買承認は、担当者が入れた注文を上長が承認してから確定する流れです。承認フローを標準で持つ製品もあれば、追加で補う製品もあります。機能の有無とあわせて、設計として決めておきたいのは次の点です。

• 金額帯別の承認権限：一定額までは担当者の発注で確定し、超えたら上長、さらに超えたら部門長、のように段階を分けるか。金額は注文単位か、期間の累計か
• 承認者の不在時：代理承認者に回すのか、一定時間で差し戻すのか。承認が止まると、現場は結局電話で注文し直します
• 承認中の価格と在庫：承認を待つ間に価格が改定された、在庫がなくなった、という場合の扱い。1 の「注文時の価格を保存する」と同じ考え方で、承認時点で再計算するのか、注文時点の条件を保つのかを決めます
• 取引先側の権限設計：企業単位で配送先と支払条件を持ち、担当者単位で発注権限や上限金額を分けられるか

既存サービスで足りる条件と、個別開発が要る条件

ここまでの論点を数えると、判断の目安が見えてきます。

既存サービスで足りる可能性が高い条件

• 取引先別の価格が、数通りのグループ単価で表せる
• 与信と請求は現行の販売管理システムに任せ、EC は注文の入口だけを担う
• 承認は 1 段階で、金額による分岐がない

個別開発を検討する条件

• 取引先ごとの特別単価に有効期間があり、改定の前倒し登録や、既注文の価格保持が必要
• 与信枠を EC 側でリアルタイムに更新し、超過時の保留・解除まで EC で完結させたい
• 金額帯や部門ごとに承認権限が変わる、代理承認が要る
• 基幹システムの価格マスタ・与信情報と、双方向に同期する必要がある

後者に複数当てはまる場合は、最初から設計を前提に進めるほうが、後からの作り直しを避けやすいと私たちは考えています。

まとめ

• 取引先別価格は、優先順位・有効期間・改定時の既注文・価格の正の置き場所を決める
• 掛売りの与信は、EC が引き受ける範囲を決めたうえで、超過時の扱いと枠の更新タイミングを決める
• 購買承認は、金額帯別の権限、不在時の扱い、承認中の価格と在庫の扱いを決める
• 自社の条件を数えて、既存サービスで足りるか、個別開発が要るかを見極める

「個別開発を検討する条件」に 2 つ以上当てはまる場合は、機能比較に入る前の、価格・与信・承認の決めごとを整理する段階からご相談ください。Urchin&Company の「ECサイト構築」では、BtoB の取引先別の価格や掛け売り、見積もり・承認フローなど、企業間取引の条件を扱う EC を、要件定義から設計・開発しています。