EC-CUBEでBtoBの掛売・与信管理をどう設計する？与信限度額・請求書払いの考え方

この記事でわかること
「取引先ごとに、掛けの上限を決めたい」「請求書払いに対応したい」「与信の枠を超えた注文を止めたい」——BtoB-ECでは、掛売や与信限度額の管理が必要になることがあります。この記事で扱うのは、誰にいくら与信するかという与信判断そのものではなく、企業側ですでに決めている与信限度額や取引条件を、EC上でどう扱うかの設計です。与信枠をいつ使い、いつ戻すのか、残高をどこで管理するのか、といった考え方を解説します。

まず整理：掛売と与信は別のもの

「掛売」と「与信」は、混同されることがありますが、指しているものが異なります。

掛売に対応するだけなら、支払方法として「請求書払い」を用意することになります。一方、与信管理まで行う場合は、取引先ごとの限度額や、現在いくら使っているか（利用額）を管理する仕組みが必要になります。この記事では、主に後者の、与信限度額や利用額をEC上でどう扱うかを扱います。

設計の核：与信枠を「いつ使い、いつ戻すか」

与信管理をEC上で扱うとき、最初に決めておきたいのが、「与信枠を、いつ使ったとみなし、いつ戻すのか」です。ここが、与信管理の設計で核になる部分です。

たとえば、与信枠を消費するタイミングには、次のような選択肢があります。

• 注文が確定した時点
• 出荷した時点
• 請求が確定した時点

どの時点で「与信枠を使った」とみなすかによって、現在の利用額の意味が変わります。さらに、キャンセル、返品、注文の変更、入金があったときに、与信枠をどう戻すのかも、あわせて決めておく必要があります。これらを整理しないまま「現在の利用額」という数字を持たせても、その数字が何を表すのかが曖昧になってしまいます。

つまり、与信管理は、単に「限度額を超えたら止める」という機能ではなく、業務の中で与信枠がどう動くかを設計することが出発点になります。

与信限度額・利用額の管理（設計例）

与信限度額を管理する場合の設計例として、取引先ごとに「与信限度額」と「現在の利用額」を持たせる構成が考えられます。これはEC-CUBEの標準項目ではなく、要件に応じて設計・追加する例です。

• 取引先ごとの与信限度額
• 現在の利用額（前述の「いつ使うか」の定義に沿って更新する）
• 限度額と利用額を比較する仕組み

注文の際に、利用額が限度額を超えていないかを確認し、超える場合の扱い（注文を止める、承認に回す、など）を設計します。データ構造の考え方は、DB構造・Entity設計の解説もご覧ください。

未回収残高の正本を、どこに置くか

与信の利用額は、売掛残高（未回収の金額）と関係します。ここで論点になるのが、売掛残高や入金の情報を、どのシステムで管理するかです。

売掛残高や入金情報を基幹システム（販売管理・会計など）で管理している場合は、EC側だけで与信の利用額を管理するのではなく、どのシステムを正本（マスタ）とするかを整理する必要があります。基幹側を正本にしてECに連携する、EC側で一部を持つ、といった役割分担を、あらかじめ決めておかないと、EC側の利用額と、実際の売掛残高が食い違うことがあります。連携の設計については、基幹・在庫システムを連携する方法で解説しています。

これは、価格の正本をどこに置くか（複雑価格の設計）と、同じ考え方です。

掛売（請求書払い）の実装

掛売に対応する場合、支払方法として「請求書払い」を用意することになります。あわせて、次のような点を整理します。

• どの取引先に、請求書払いを許可するか
• 支払サイト（締め日・支払期日）の管理
• 請求書の発行を、EC側で行うか、基幹側で行うか

請求書払いに対応することと、与信限度額を管理することは、別の要件です。請求書払いだけが必要なのか、与信限度額の管理まで必要なのかを、切り分けて考えることが大切です。

承認フローとの関係

与信超過時の扱いとして、「承認に回す」という設計をする場合は、承認フローと組み合わせることになります。たとえば、与信枠を超える注文は、管理者の承認を経てから確定する、といった設計です。承認フローの設計については、承認フローの設計の記事をご覧ください。

EC-CUBEでの実装の考え方

与信管理や掛売は、EC-CUBEの標準機能にそのまま含まれているものではありません。実装する場合は、次の切り分けで考えます。

• 標準機能で対応できる範囲（請求書払いの支払方法の追加など）
• プラグインを検討する範囲
• 個別開発を検討する範囲（与信限度額の管理、基幹連携など）

まず、自社にどのような掛売・与信の要件があるかを整理したうえで、どの範囲をどう実装するかを決めることが大切です。

SaaSとの違い

SaaS型のECにも、請求書払いや与信に関する機能が用意されていることがあります。標準的な掛売であれば、SaaS型で対応できることもあります。一方、取引先ごとの与信限度額の管理や、基幹システムと連携した売掛残高の管理が必要になると、SaaS型では制約が出ることがあります。掛売・与信の要件によって、適した選択肢が変わります。

掛売・与信設計で注意したいこと

• 請求書払いと与信管理を、同じものと考えない：請求書払いは支払方法、与信管理は限度額などの管理で、必要な設計が異なります。
• 基幹システムとの同期を整理する：売掛残高や入金を基幹で管理している場合、どこを正本にするかを決めておかないと、残高が食い違うことがあります。
• 与信枠の使用・解放のルールを決める：キャンセルや返品、入金のときに利用額をどう戻すかを決めておかないと、利用額が実態と合わなくなることがあります。

まとめ

EC-CUBEでBtoBの掛売・与信管理を設計するには、掛売（請求書払い）と与信管理を分けて考えたうえで、与信枠を「いつ使い、いつ戻すか」を業務から決めることが出発点になります。そして、与信の利用額や売掛残高を、EC側と基幹システムのどちらで管理するか（正本をどこに置くか）を整理することが大切です。この記事で扱ったのは、企業側で決めた与信ルールをEC上でどう扱うかであり、与信判断そのものではありません。

私たちサンクユーは、BtoB-ECの掛売・与信まわりの設計や、基幹システムとの連携に対応しています。「請求書払いに対応したい」「与信の枠をシステムで管理したい」といった段階から、ご相談いただけます。まずは、現在の掛売・与信の運用をお聞かせください。