B2B注文の与信ゲートと顧客別支払条件

与信ゲートが解決すること（平易な説明）

B2Bの注文は見た目は健全でも、キャッシュフローの問題を引き起こすことがあります。カード決済と違って、多くの法人顧客は後払いを選びます。請求書が積み上がるまま出荷を続けると、支払いが遅い一社が目に見えない形で運転資金の大部分を占有してしまうことがあります。

与信ゲートは、注文が正式に受け付けられる前のシンプルな安全チェックです。顧客が既に負っている金額（とこれから負う予定の金額）を合意された与信限度と比較します。新しい注文で限度を超える場合、システムは注文を永久に拒否するわけではなく、審査のために一時保留にします。

保留にするというのは通常、注文自体は記録されるが主要な工程がブロックされることを意味します。バイヤーと詳細を確認したり、方針によっては在庫を確保することは可能です。一般的に行わないのは、保留が解除されるまでは出荷、請求、または在庫の恒久的な割当てを行うことです。

支払条件は、資金がどれくらい長く拘束されるかを変えるため、リスクを変化させます。前払いはリスクが低いです。Net 30は支出が限度内で請求が期日通り支払われるなら問題になりにくいですが、Net 60やカスタム条件はより長期間のエクスポージャーを増やします。

ゲートはまたチーム間の混乱を減らします。"これを出荷して良いか"という問いを、営業、財務、オペレーションが見える一貫したステータスに変えるからです。

顧客ごとに保存すべき項目（限度、条件、エクスポージャー）

ゲートが機能するには、顧客レコードにバックエンドルールが信頼できるいくつかのフィールドが必要です。項目は短くし、各値を説明しやすくしてください。

まずは与信限度：限度金額とその通貨です。複数通貨で販売する場合は、比較の前にすべてを基準通貨に換算するか、通貨ごとに限度を保存するかを決めて一貫させてください。

次に、支払条件は自由記述ではなく構造化データとして保存します。タイプ（Prepay、COD、Net 15、Net 30、Net 60 等）を明確にし、該当する場合はネット日数も保存してください。こうすれば注文ロジックが推測なしに分岐できます。

実用的な顧客ごとのセット例：

• 与信限度の金額と通貨
• 支払条件の種類とネット日数（該当する場合）
• 一時的オーバーライド金額（任意）と有効期限タイムスタンプ
• オーバーライド理由メモ（誰がなぜ付与したか）
• 手動保留スイッチ（「停止」ボタン）

「エクスポージャー」は、実際にリスクをどう扱っているかに合わせて定義してください。多くのチームは未払い請求書に未確定の注文を加え、場合によっては出荷済みで請求後に請求するケースを含めます。

最後に、保留が見えていて行動できるように注文ステータスは少数に抑えてください。例えば：Approved、On hold、Released、Cancelled のようにします。

限度・条件・注文保留のために必要なデータモデル

データモデルは「誰が買っているか」「どの条件か」「既にいくら負っているか」の3つの質問に答えやすくするべきです。

まずは顧客レコードに、意思決定に必要な入力を持たせます：与信限度、デフォルトの支払条件、保留ポリシー（例：限度超過で自動保留、許可してフラグのみ、チェックアウトをブロック）など。

注文はトリガーと結果の両方をキャプチャすべきです。支払方法、注文合計、"On hold"を表現できるステータスを保存し、住所確認等の他の問題と区別できるように保留理由を追加します。

最小限のスキーマ例：

• Customers: credit_limit, payment_terms_code, hold_policy, credit_status
• Orders: total_amount, payment_method, status, hold_reason, held_at
• Invoices / AR: invoice_total, open_balance, due_date, status (open/paid/void)
• Credit overrides: customer_id, override_amount_or_limit, expires_at, approved_by
• Audit log: entity_type, entity_id, changed_fields, changed_by, changed_at, note

エクスポージャーを確実に計算するには、売掛金データ（請求書または外部同期）が必要です。請求書がない段階で注文だけから推測すると誤差が出ます。まだ請求機能がない場合は、顧客に「未精算残高」のスナップショットを保存し、支払があるたびに更新してください。

オーバーライドは別テーブルに保持しましょう。主与信限度の直接編集を防ぎ、承認の記録を残せます。

与信エクスポージャーと利用可能与信の計算方法

計算式は合意して文書化し、アプリと経理レポートで一貫して使ってください。

よくある基本式は：

Credit exposure = unpaid invoices + open order value

そして：

Available credit = credit limit - credit exposure

「価値」が何を意味するかを事前に定義してください。多くのチームは商品合計から割引を差し引いた額を使い、税や送料を含めるかどうかを明示します。税や送料を含めると保留が早く発生しますし、除外すると請求確定時に限度を超えてしまうリスクがあります。

いくつかの調整で驚きを防げます：

• 部分支払は、支払が実際に受領されたときにのみ未払い請求書を減らします（支払が"開始"された段階ではありません）。
• クレジットノートや返金は、発行かつ利用承認されたときにのみエクスポージャーを減らします。
• キャンセルされた注文は未確定注文の値から直ちに除外します。
• 返品は返金承認後にエクスポージャーを減らします（返品要求時ではありません）。

タイミングは式と同じくらい重要です。数値が予測可能になるように更新ポイントを決めてください：

• 注文作成時もしくは注文承認時（どちらかに統一する）
• 請求書発行時（未確定注文から未払い請求書へ値を移す）
• 支払の記録時（エクスポージャーを解放する）

複数通貨で販売する場合は、顧客の与信通貨にエクスポージャーを換算する一貫したレート（例：請求日の日次レート）を使ってください。親アカウントや子会社をサポートする場合は、限度を法的主体ごとかグループ共有にするかを決め、顧客レコードに表示してください。

ステップバイステップ：注文を保留するバックエンドルールの構築

ゲートは注文作成や変更のたびに自動で実行されると効果的です。

1. バイヤーがワンクリックで送信しても、まず注文をドラフトとして保存します。顧客ID、注文合計、通貨、支払条件のスナップショットをキャプチャしておき、後で顧客プロファイルが編集されても履歴を書き換えないようにします。

2. 顧客の現在のエクスポージャーを取得し（定義に基づく）、新しい注文合計を加えた予測エクスポージャーを計算します。

3. シンプルな判定を適用します：

• 予測エクスポージャーが与信限度以内なら注文をApprovedにします。
• 予測エクスポージャーが限度を超えるなら注文をOn holdにします。

4. 注文を保留にする場合、後で判断が分かりやすいように詳細を記録します：

• 保留理由（例：「与信限度を$2,450超過」）
• 次のアクションの担当者（例：「ARチーム」または特定のマネージャ）
• 当時の入力値（限度、エクスポージャーの構成要素、チェックをトリガーした人、タイムスタンプ）を含む監査記録

5. 数字を変えるイベントで再チェックを行ってください。作成時だけでなく、合計を変える編集、出荷（出荷をコミットとみなす場合）、請求、支払の記録といったトリガーで再評価します。

承認と通知：保留が放置されない仕組み

保留は迅速で追跡可能な決定に繋がる場合にのみ有用です。

保留を解除できる人を定義してください。多くのチームは与信判断を財務が行い、緊急時のバックアップとして営業マネージャーを置きます。ロールと権限を明確にし、誰が承認（または却下）したかとその理由を必ず記録しましょう。

承認画面に表示すべき項目

画面は短く保ちつつ、承認者が必要とする数字を含めます：

• 与信限度、現在のエクスポージャー、利用可能与信
• 注文合計と、限度をどれだけ超えるか
• 登録されている支払条件と要求された条件（異なる場合）
• 顧客のステータスの簡単なメモ（例：「新規アカウント」や「過去に延滞あり」）
• 必須のコメント欄

決定後は承認ログ（注文ID、判断、承認者、タイムスタンプ、コメント）を残します。これが監査証跡となり遅延の説明に役立ちます。

通知と時間制限

注文が保留になったらすぐに、チームが実際に見るチャネル（メール、SMS、Telegramなど）で適切な人へ通知してください。リマインダーとエスカレーションを追加して保留が黙って放置されないようにします。実務例としては2時間後のリマインド、24時間でエスカレーション、72時間で自動キャンセルといったパターンがあります。

完全な解除がリスク大なら、条件付き解除（部分出荷、デポジット必須、短い支払条件等）を許可し、その条件を記録してフルフィルメントと請求が同じ計画に従うようにします。

保留後の運用フロー：何が起きるか

保留注文は通常の注文と同様に扱いますが、ただ一つの違いがあります：保留が解かれるまでは先に進めません。

営業、オペレーション、財務は同じ保留シグナルを見られるようにしてください。"On credit hold"のようなステータスと理由フィールド（例：「与信限度を$1,240超過」）を付け、短い内部メモを残して人が推測しなくて済むようにします。

倉庫ルールは厳格に：保留注文はピッキング、梱包、割当てを行わないでください。在庫を確保する場合は保留解除後に確保するか、短期間だけ予約するようにして、保留注文が支払済み注文の邪魔をしないようにします。

顧客への連絡は中立的で実務的にし、次のステップを明確に伝えます。例：

• 「定期的なアカウント確認のため、注文を一時保留しています。支払予定を確認するか、部分出荷を依頼してください。」
• 「支払が確認でき次第出荷できますし、与信調整でも対応可能です。どちらがよいでしょうか？」
• 「利用可能与信内に収まる商品を分割出荷できます。」

支払が届いたら自動解除するか手動解除するかを選びます。自動解除は請求に対して入金が確実にマッチする場合に有効です。支払が部分的または不明瞭な場合は、手動解除がより安全です。一般的な折衷案としては、延滞残高を全額カバーする支払のみ自動解除し、それ以外は財務へ回す方法があります。

ゲートが健全か監視するためにいくつかの指標を追跡してください：保留注文数、24時間以内に解除された割合、平均解除時間、保留理由の上位要因。

例：閾値を超えた卸売注文のシナリオ

卸売顧客 BrightSide Supplies はNet 30の支払条件で与信限度が50,000です。

未払い請求書の合計が38,000あります。新たに15,000の注文を出しました。

予測エクスポージャーは38,000 + 15,000 = 53,000です。53,000は50,000の限度を超えるため、その注文は保留され財務に回されます。営業は注文を確認できますが、ピッキング、出荷、請求はエクスポージャーが下がるまで行えません。

財務が取り得る対応としては、デポジットを要求してエクスポージャーを下げる、注文を利用可能与信に収まるよう削減する、あるいは有効期限付きオーバーライドを理由書きとともに承認するなどがあります。

本番投入前のクイックチェックリスト

本番でゲートを有効化する前に短いプレフライトを行ってください。数時間のテストで後の数日の手戻りを防げます。

小規模で多様なテストセット（5～10顧客）から始めましょう：Net 30で低い限度の顧客、高い限度の顧客、前払いの顧客、複数の未払い請求書がある顧客、チェックアウト後に注文を編集することが多い顧客など。

確認すべきは二つです：

• エクスポージャーの計算が経理の期待と一致するか（含める項目／除外する項目を含む）
• 保留ルールが正しいタイミングで実行されているか：注文作成時とエクスポージャーを増やす可能性のある編集時（数量変更、価格変更、送料追加、割引削除）

保留注文を一件、端から端まで実演してみてください。保留理由が明確か、出荷と請求が意図通りに動くか、通知が適切に届くか、支払の反転で再保留（またはフラグ）が安全に行えるかを確認します。

よくある失敗とその回避法

多くの問題は技術的なものではなく、ルールが間違った数値を参照したり、人がルールの抜け道を覚えてしまうことから起きます。

よくある失敗点：

• エクスポージャーを未払い・確定分ではなく、単に注文の総額で扱ってしまうこと。
• 承認済みでも未出荷の注文を無視してしまい、同一顧客が短時間に複数の大口注文を出せるようにすること。
• 承認後の金額変更を許して与信再チェックを行わないこと。
• オーバーライドを承認者や理由なしで許可してしまうこと。
• 例外を増やしすぎてゲートが事実上任意のものになること。

防止策はシンプルに：エクスポージャーを一文で定義し、金額が変わる編集のたびにゲートを再実行し、オーバーライドには理由と承認者を必須にし、例外の種類は少なく保つことです。

次のステップ：注文アプリにゲートを実装して改善する

まずは実際のリスクを防ぐ最小構成から始めてください：「この注文後のエクスポージャーが顧客の限度を超える場合、注文をOn holdにする」。1週間運用してみて、ルールの例外は明確に名前が付けられる場合にのみ追加していきます（例：財務承認済みの一時オーバーライド）。

手作業でコードを書く代わりに注文アプリを構築する場合、AppMaster (appmaster.io) のようなツールが実用的です：顧客、注文、請求書、オーバーライドを視覚的にモデリングし、作成・編集・請求・支払時にエクスポージャーを再計算するバックエンドビジネスプロセスとして保留ロジックを実装できます。

最初のリリースは地味で予測可能に保ち、財務やオペレーションが毎日目にする課題に応じて改善していってください。