用于 B2B 订单的信用额度门控与按客户设置的付款条款

信用额度闸门能解决什么问题（通俗说明）

B2B 订单在账面上看起来可能很健康，但仍会造成现金紧张。与刷卡不同，很多企业客户是后付的。如果你在发货的同时让发票堆积，一名付款迟缓的客户就能悄悄占用你大量的流动资金。

信用额度闸门是在订单被完全接受前的一个简单安全检查。它把客户已经欠的（以及他们即将欠的）和约定的信用限额做比较。如果新订单会使他们超出限额，系统并不会永远拒单，而是暂停订单以便复核。

挂单通常意味着订单被记录下来，但关键步骤会被阻止，直到有人释放。你仍可以与买家确认细节，并根据政策保留库存。通常不会在释放前发货、开票或永久分配库存。

付款条款改变了风险，因为它影响资金被占用的时长。预付风险低，因为现金先到。Net 30 在花费保持在限额内且发票按时支付时可以接受。Net 60（或自定义条款）会在更长时间内增加暴露。

闸门还能减少团队间的混淆，因为它把“我们能发这单吗？”转为一个对销售、财务和运营都可见且一致的状态。

定义按客户保存哪些信息（限额、条款、暴露）

闸门只有在客户记录包含几项后端规则可信赖的字段时才有效。把列表保持简短，并确保每个值易于解释。

从信用限额开始：限额金额和定义该限额的货币。如果你以多种货币销售，选一个规则并坚持使用。要么在比较前把所有金额换算为基准货币，要么按货币存储限额。

接着，把付款条款以结构化数据存储，不要用自由文本。使用清晰的类型（Prepay、COD、Net 15、Net 30、Net 60），并在相关时存储净天数。这样订单逻辑可以分支而不用猜测。

一个实用的按客户字段集例如：

• 信用限额金额和货币
• 付款条款类型和净天数（如适用）
• 临时覆盖金额（可选）及到期时间戳
• 覆盖备注（为何授予、由谁授予）
• 手动挂起开关（一个“停止”按钮）

以与你实际承担风险的方式来定义“暴露”。很多团队会把未付发票加上尚未付款的未结订单，有时还包括在发货后再开票的待发货项。

最后，保持一小组订单状态以便让挂单可见且可操作。例如：Approved、On hold、Released、Cancelled。

支持限额、条款和订单挂单的数据模型

你的数据模型应该让三个问题容易回答：谁在买、以什么条款买以及他们已经欠了多少。

从承载决策输入的客户记录开始：信用限额、默认付款条款和挂单策略（例如，超限自动挂起、允许但标记或阻止结账）。

订单应同时记录触发条件和结果。存储付款方式、订单总额以及可表示“On hold”的状态（不要把“Pending”过度加载）。添加挂单原因，让人们能区分“超出信用限额”和其他问题（比如地址核验）。

一个最简模式通常包括：

• 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

要可靠计算暴露，你需要应收账款数据（发票或外部同步），以免从订单猜测未付余额。如果尚无开票系统，请在客户记录上存储“未结余额”快照，并从已入账的付款更新它。

把覆盖保存在单独的表里可以避免对主信用限额进行混乱的编辑，并提供审批轨迹。

如何计算信用暴露和可用信用

数学公式需要达成共识并书面记录，然后在应用和财务报表中一致使用。

一个常见基线是：

信用暴露 = 未付发票 + 未结订单价值

然后：

可用信用 = 信用限额 - 信用暴露

在实施前，明确“价值”意味着什么。很多团队使用商品总额减去折扣，然后明确是否包含税费和运费。若包含税费和运费，挂单会更早触发；若排除，则存在在发票最终生成时超限的风险。

一些调整可以避免意外：

• 部分付款只有在现金实际收到时才减少未付发票（不是在付款“发起”时）。
• 贷项通知单和退款只有在发出并批准用于抵扣时才减少暴露。
• 已取消的订单应立即从未结订单价值中移除。
• 退货通常在贷项单批准后才减少暴露，而不是在退货请求时。

时点与公式同样重要。选择明确的更新时点以便数字可预测：

• 在订单创建或订单批准时（选其一并保持一致）
• 在发票发出时（把价值从未结订单转到未付发票）
• 在付款入账时（释放暴露）

如果多货币销售，把暴露按一致的汇率换算为客户的信用货币（例如按发票日的当日汇率）。如果支持母子账户或子公司，决定限额是按法人实体还是在集团内共享，并在客户记录上显示清楚。

逐步：构建会挂起订单的后端规则

闸门最好在每次订单创建或变更时自动运行。

1. 先把订单保存为草稿，即便买家是一键提交。捕捉客户 ID、订单总额、货币以及付款条款快照，以便日后客户档案的变更不会改写历史。

2. 获取客户当前暴露（基于你的定义）。将新订单总额加进去计算预计暴露。

3. 应用简单决策：

• 如果预计暴露在信用限额内，标记订单为 Approved。
• 如果预计暴露超过限额，将订单置为 On hold。

4. 在挂起时记录便于日后解释决策的细节：

• 挂起原因（例如，“Credit limit exceeded by $2,450”）
• 下一步责任人（例如，“AR team” 或具体经理）
• 带有使用输入的审计记录（当时的限额、暴露组成、触发校验的人、时间戳）

5. 在会改变这些数字的事件上重新检查暴露，而不是仅在创建时检查。常见触发器包括会更改单价或总额的编辑、发货（若你的策略把发货视为承诺）、开票和付款入账。

审批与通知，避免挂单被遗忘

挂单只有在能促成快速且可追踪的决策时才有用。

定义谁能释放挂单。很多团队由财务负责信用决策，销售经理作为紧急情况下的备选。用角色和权限明确规定谁能操作，并始终记录谁批准（或拒绝）及其原因。

在审批界面应展示什么

保持界面简短，但包含审批人需要的数字：

• 信用限额、当前暴露、可用信用
• 订单总额及超过限额的程度
• 档案上的付款条款和请求的条款（如不同）
• 一小组客户状态备注（例如，“new account” 或 “past due once”）
• 必填的评论字段

决策后写入审批日志（订单 ID、决策、审批人、时间戳、评论）。这成为审计轨迹并有助于解释延迟。

通知与时间限制

在订单被挂起的瞬间通知相关人员，使用团队实际阅读的渠道（邮件、短信或 Telegram）。添加提醒和升级规则，避免挂单无人处理。一种实用模式是 2 小时提醒、24 小时升级、72 小时无人处理自动取消。

如果完全释放风险太高，允许有条件释放（部分发货、要求订金、缩短付款期限），并记录条件以确保履约和开票遵循同一计划。

当付款到位时，在自动释放与人工释放之间做选择。若付款可靠地匹配发票，自动释放效果好；若付款为部分或来源不明，人工释放更安全。常见折中是：只有当付款完全覆盖逾期余额时才自动释放，否则转给财务。

追踪一些指标以保证闸门健康：被挂起订单数量、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。” 运行一周后再只在能明确命名的情况下添加例外（例如由财务批准的临时覆盖）。

如果你在不手写代码的情况下构建订单应用，AppMaster (appmaster.io) 可以是一个实用选项：你可以可视化建模客户、订单、发票和覆盖，然后把持单逻辑实现为后端业务流程，在创建、编辑、开票和付款时重新计算暴露。

让首个版本保持平稳可预测，并根据财务和运营每天看到的实际情况逐步改进。