客户要下单，AI 如何先核对信用额度与应收账龄？

接单前的信用核对，销售一般是在 ERP 的额度、应收和回款记录之间来回点，再翻 CRM 看合同条款和结算方式。麻烦出在几份记录的时点和口径不一样，算出来的额度余量可能是两个数，最后还是得人来拍。下面说清 AI 核对客户信用额度时该看哪些记录、按什么顺序核、哪些结论不能由 AI 直接下，以及这一段怎么做验收。

本文中的 ERP、CRM 与回款记录是通用流程示例；是否包含银行或资金系统数据，取决于企业已有资源、授权和项目评估，不表示产品默认直连任何银行。

核心观点

信用核对做不做得成，取决于三份记录能不能对上：额度是多少、已经占了多少、回款记录能否在已配置的数据源中查到。AI 可以在员工权限内把这三份记录查齐，把冲突和缺项明确标出来；放不放单、要不要暂停供货、额度调不调，仍由有权限的员工和原系统决定。星云 PLUS AI 系统连接器可连接经评估的现有系统能力。具体数据源、字段和接入方式要结合企业现有资源确认；产品定位是不换系统、沿用员工权限、关键操作人确认、调用审计。

为什么信用核对总在接单前后卡一下

销售问的通常是一句话：这个客户现在能不能再接一单。回答这句话要动到三四个地方，每个地方的记录时点都不一样。

核对失败多半出在业务键上。客户主体在 CRM 是一个名称，在 ERP 是另一个编码；合同号在销售那边是一种说法，到 ERP 变成销售订单号。业务键对不上，后面的数字再准也用不上。

接单节点通常需要尽快核对。这一段要做的事很具体：把该看的记录一次查齐，把对不上的地方标出来，让判断有人接着做。

额度、占用、逾期是三件事

信用额度常常被当成一个数字，实际至少要分三组看：能用的上限、已经压上去的部分、该回来但没回来的部分。三组数据的来源和口径都不在一处。

调额过程常被漏掉。销售临时申请提额，审批还在走，系统里的正式额度没变。AI 查到的额度是旧值，销售手上的口头结论是新值，两边都没有错，结论却对不上。核对时要把「已经生效的额度」和「在审批中的调额」分开写清楚。

占用数据的分歧通常出在口径。按订单确认时点算，占用的是一批数据；按发货或开票时点算，占用的是另一批。AI 能做的把两套算法各自的结果列出来、标明来源单据，选哪套口径要业务侧定，定完还得回到原系统一致。

回款记录容易被误读。客户说款已经汇出，企业已配置且员工获授权的数据源中也能看到相关记录，ERP 里却还是未核销。这时额度占用确实存在，原因是核销流程还没走完。把「未到账」和「已到账未核销」混成一句「还没收到钱」，会直接影响后续催收动作该不该发。

账龄要看口径。按开票日算、按到期日算，落在不同区间的金额会不一样。核对时不只要给出账龄数字，还要标明是哪套口径、统计到哪一天。

同一个客户，为什么两个系统给出两个结论

客户身份与指标口径没有对齐时，同一个客户在不同系统里本来就是两个对象。这一层在线上文章《AI 工作台联查 ERP 与 CRM，为什么同一个客户会出现两种答案？》里讲过做法，放到信用核对上同样是先对齐主体和口径，再谈数字。

常见的不一致有几种来源。主体不一致时，CRM 记的是集团层面的客户，ERP 记的是具体签约的法人或分公司，额度挂在哪个层级没有统一。时间不一致时，一边按下单时点统计，另一边按发货或开票时点统计，同一天的余量差出一截。币种和税率不一致时，外币合同与本币额度之间少了汇率口径，金额一换算就出现差异。核销时点不一致时，银行侧已经记账，ERP 侧的应收还没冲销。

处理顺序上，先把主体对齐成同一个业务键，再把每份数字的口径和统计截止时间标出来，最后才谈谁对谁错。顺序反过来，很容易在两个都不算错的数字之间反复争论。

核对一遍的具体顺序

把这一段跑顺，通常是固定几件事按顺序做。顺序不必复杂，每一步的输入和输出说清就行。

1. 定客户主体与业务键。确认 CRM 客户与 ERP 客户编码、合同号与销售订单号之间怎么对应，对应关系不明的先挂出来。
2. 拉授信额度与变更记录。区分已生效额度和在审批中的调额，注明生效日期。
3. 拉占用数据。按业务侧认可的口径统计未交付订单、已发货未开票、已开票未收款三项。
4. 拉应收与账龄。标明账龄口径、统计截止时间，并把超期部分单独列出。
5. 拉合同结算条款。确认账期、票种、折扣与特殊约定，字段里没有的以合同正文或附件为准。
6. 标出冲突与缺项。业务键对不上、两个系统数字不一致、字段缺失、权限不足看不到的部分，逐条写出来。

第六步常被省掉，而这一段要交付的正是它。一份只列数字的核对结果，看起来干净，实际把判断责任又推回给了销售；一份标明「这三条对不上、那两项看不到」的结果，销售拿到就知道该找谁补充。

哪些判断不能交给 AI

这一段能自动化的部分是查询、比对和汇总。涉及额度、放单和催收的决定属于业务动作，落到原系统里就会改变业务事实，需要有人接手。

新增、修改、删除和审批这几类关键操作默认要求员工确认，企业也可以按具体业务能力配置成「必须确认」或「允许自动执行」。企业 AI 连接器的查询、校验和预填可以自动化，页面预填不等于提交成功，最终以页面回执或目标系统的实际结果为准。

权限和确认是两件事。员工被授权调用某项查询能力，仍然由 ERP、CRM 等目标系统按他的个人账号判断能看哪些客户和哪些字段；员工确认了核对清单，也仍然要读原系统的最终结果。把人工确认当成权限校验的替代品，两类风险会混在一起。

这一段怎么验收

信用核对场景的验收，看的是核对结果能不能被别人复核。

记录这一层从调用侧留起：员工与 AI 身份、调用入口、业务能力、目标系统、时间、耗时、结果以及输入输出摘要都进审计，审计保存期限由企业自行配置。查询类记录有一个很实际的用途，客户或内审问某项数据是谁在什么时候看到的，答案要能从记录里找出来。

这一段也要考虑撤权。授权被撤回后，后续调用被禁止，尚未完成的那次调用会中止，界面上的可见性不参与这个判断。销售岗位调整或离职时，信用核对的查询能力同样要跟着收回。

结语

接单前的信用核对，交付的是一份能复核的依据清单：额度、占用、回款、合同条款各自从哪来，哪几条对不上，哪些看不到。这份清单的目标，是减少逐系统查找，并让后续复核能回到相应来源记录。要开始这一段，先挑一批业务键清楚、合同条款稳定的客户做样本，把权限边界和异常表现验证一遍，再按结果、权限、确认、审计、异常逐项验收，之后扩展到更多客户和更多系统。

常见问题

AI 核对信用额度会绕过 ERP 的权限吗？ 不会。连接器先判断员工能否调用这项查询能力，ERP 与 CRM 再按员工个人账号判断功能和数据权限。AI 不因为入口统一而获得员工账号之外的额外数据范围，数据范围也不会因为走了 AI 而放大。

客户信用数据分散在 ERP 和 CRM，需要先做数据整合吗？ 不一定以数据整合为前提。可以在员工权限内分别查询两个系统，再按客户主体和业务键把结果组织到一份清单里，冲突的地方标出来交给人判断。是否需要在系统之间建立主数据映射，以项目评估为准。

AI 能直接帮我们调整额度或冻结客户吗？ 不建议。调整额度、冻结客户、发起催收这类动作会改变业务事实，默认需要员工确认并由原系统执行。AI 适合做的是把依据查齐、把风险点标出来，让有权限的人更快做决定。

这一段要跑多久才算验收通过？ 不设固定周期。验收看的是结果能否逐项对照、权限是否与原系统一致、缺项和异常能否说明清楚，以及记录是否可追溯。样本范围和正式周期要按客户数量、系统条件和账号权限评估，具体以项目交付与验收为准。

了解星云 PLUS AI 系统连接器与安全与治理。相关阅读：跨系统客户口径对齐、AI 汇总 CRM 与 ERP 信息。