客户授信审批流程图（额度与账期）
客户授信审批流程图：申请与主体核验、企业征信报告与同业付款证明、评分与额度建议、分级授权层级、担保安排、ERP 中的额度维护，以及账户存续期内的定期复审。
什么是客户授信审批流程图（额度与账期）流程
几乎每家公司都说自己会做信用审核。真追问下去，通常的答案是：有人在开户那一刻看过一次征信评分，之后那个数字就再没被动过，而客户的订货量已经翻了两番。常见的失效都由此而来。敞口只按应收账款余额来算，于是在手订单和已发货未开票的部分都落在额度之外，真实数字往往是批准额度的两倍。额度躺在一封审批邮件里，而不是落在客户主数据上，所以实际上没有任何东西拦得住那张订单。账期是销售在谈判收尾时谈定的，信用部门被叫来事后追认。而拒绝被当成一条死路，于是这个账户凭着一段关系照样悄悄发了货。这些都不是评分模型的问题，而是流程的问题：谁来决定、依据什么证据、用谁的权限，以及决定作出之后会怎么样。
本图覆盖的是授信决策本身，止步于额度上线并进入复审的那一刻。设定额度和执行额度不是一回事：拿一张实际订单去比对一个已经存在的额度，属于从订单接收到履约、开票、收款核销的更大商务循环，也就是 /zh/templates/订单到收款流程 上的订单到收款流程，授信审批在那张图里只是一个方框，本页就是把那个方框展开。发票一旦存在之后发生的一切——开具与发出、按账期跟踪、催收、争议、还款计划和坏账核销——属于 /zh/templates/应收账款流程 上的应收账款流程。采购侧的镜像流程问的是另一个问题、扛的是另一种风险，是交付不了而不是收不回钱：一家供应商是否可用，见 /zh/templates/供应商审批流程 上的供应商审批流程；这家供应商要被查到多深，见 /zh/templates/供应商风险评估 上的供应商风险评估。在既没有额度、也没有台账托底的情况下签字承担一项剩余风险，其通用模式是 /zh/templates/风险接受决策 上的风险接受决策；在本图里，这份差事由授权层级来承担。本图还假定客户档案已经存在——建档、签约与开票设置属于 /zh/templates/客户导入流程 上的客户导入流程，本页展开的正是那张图里的信用与筛查分支。
多数成文的信用政策留作默认的三个决策，在这里被明确画了出来。“是否在授权额度内？”被放在“授信决策？”之前而不是之后回答，这样案子会送到真正有权签字的那个人手里，而不是谁在工位上就找谁；而且它对照的数字是总敞口，不是眼前那一张订单。“授信决策？”刻意做成三个出口：按申请批准、附担保批准、拒绝。中间那条分支是给边缘案子准备的，而只有批准和拒绝两个出口的模型无处安放它们，于是就把分析员悄悄推去同意自己并不放心的额度。被拒绝的那条路也没有断：它走向“提供预付款或款到发货方案”，终止于“仅以预付方式交易”，因为一次让销售拿不出任何替代方案的拒绝，正是两周后会被推翻的那一次。最后一个阶段是循环而不是直线：“到期复审或触发条件命中？”在情况没有变化之前会一直回到监控，而“降额、维持还是撤销？”把下调后的额度送回循环，而不是送出流程。
本流程图涵盖的内容
本模板包含
- 五条泳道——客户、销售、信用分析员、信用经理、财务总监——铺在五个阶段上：申请、核验、评估、决策与担保、额度与复审。
- 在任何人为核查花钱之前先设一道申请闸门：请求连同申请的额度与账期一并记录，随后“申请材料是否齐全？”要么放行，要么送去催补并重新提交。
- 先确认身份，再谈信用。“核验法人主体与股权结构”和“主体与合规筛查是否通过？”排在征信报告之前，筛查命中直接终止于“因合规原因拒绝”，而不是被当作一个信用差的评分处理。
- 信用分析员泳道里的取证链条——“调取企业征信报告”“审阅财务报表与同业付款证明”，再到“评分并提出额度与账期建议”——让建议带着自己的底稿走到决策面前。
- 授权层级与担保这条支线：“是否在授权额度内？”把超权限的案子经由“上报上一级审批权限”绕行，而三选一的“授信决策？”把中间那个答案送往“明确所需的担保方式”和“担保是否已落实并核验？”，担保迟迟不到位的会汇入被拒绝的那条路，而不是悄悄照旧放开额度。
- 四个终点而不是一个：“因合规原因拒绝”；给被拒绝或担保未落实的客户的“仅以预付方式交易”；干净地通过重新评估之后的“额度维持至下次复审”；以及“降额、维持还是撤销？”用尽了较温和的选项之后的“授信额度已撤销”。
何时使用本模板
- 你们正在编写或修订信用政策，需要用一页说清楚谁负责取证、谁有权批多大的额度，以及额度批完之后会怎么样。
- 你们的授信额度都是各个账户开户时定的，此后再没有任何东西重新检验过，哪怕客户的订货量已经翻倍。
- 账期是销售在谈判过程中就谈定的，信用部门被叫来事后确认，于是审批变成了一道没人能拒绝的手续。
- 你们正在 ERP 里配置信用管理，希望在把授权层级、订单冻结行为和复审触发条件写成系统规则之前，先把它们谈定。
- 刚发生了一笔坏账，会上被追问的是：额度是谁批的、依据什么证据、上一次有人看它是什么时候。
运作方式
把泳道改成你们自己的岗位
把客户、销售、信用分析员、信用经理和财务总监换成你们真实存在的岗位。在小型财务团队里，分析员和经理是同一个人，那就把泳道合并，而不是留一条从不做事的空泳道；在共享服务中心的模式下，分析工作在异地完成而决策留在本地，这个交接恰恰值得画出来。无论怎么合并，都要让准备材料的人和批准的人分开，因为这一条是审计师或信用保险公司最先要看的东西。
把授权层级写成数字
“是否在授权额度内？”在你附上数字之前是空的。为每一级设定一个对应岗位而不是对应姓名的金额上限，为每一级指定一位代理人，免得整条链条卡在一次休假上，并写明币种。最要紧的是定义这个数字对照的是什么：总敞口，也就是已入账的应收余额，加上未交付的在手订单，再加上已发货但尚未开票的部分，而不是眼前那一张订单。再补上一批不看金额、一律上报的情形，比如全新设立的主体、境外客户，或者曾经被冻结发货的客户。
定义什么算一份完整的申请
在分析员动手之前，先定好“申请材料是否齐全？”背后那套材料必须包含什么：工商登记的企业全称与统一社会信用代码、集团母公司、收货地点与开票主体、带具体数字的额度与账期申请、预计月度订货金额、两家同业付款证明人，以及对你们打算做的各项核查的授权。任何被设为选填的字段都会是空的，而分析员会用一个假设去补那个空。写明谁来催、催几次，以及一份停滞的申请到什么时候就关闭，而不是一直挂着。
写清证据清单和权重
“评分并提出额度与账期建议”应当能被另一位分析员依据同一份档案复现出来。写下你们用哪家征信机构、每个评分区间对你们意味着什么，额度是怎么从营业收入、净资产还是预计月度采购额推出来的，以及对老客户而言内部付款记录如何压过外部视角。写明证据薄弱时分析员可以怎么做——通常是给一个较小的起步额度加一次提前复审，而不是直接拒绝——并要求把推理过程随建议一并留档。
把担保落到具体做法上
“明确所需的担保方式”需要一份带责任人的清单。列明你们接受的工具——母公司或实际控制人担保、保证金或部分预付款、信用证、信用保险、合同中的所有权保留条款——并为每一种写明谁起草、谁核对签署人是否有权签字、原件由谁保管、谁盯着有效期。同时记下每一种的局限：一笔担保的价值不会超过担保方自己的资产负债表，而保险公司可以在很短的时间内下调对该买方的承保限额，这等于悄悄压低了你自己的额度。
设定复审触发条件，走一遍，然后发布
为“到期复审或触发条件命中？”上的每一个风险等级挂一个复审节奏，并列出会把复审提前拉出来的事件：一次逾期付款、一份被打破的还款计划、征信评分下滑、被列入失信被执行人名单、一次提额申请、股权变更、年报逾期未报、一个突然不再下单的账户。然后带着整张图，和一位分析员、信用经理以及一位销售一起走一遍，用两个真实客户来走，其中一个要是被拒绝过的，按他们实际的做法改正，再发布该版本，让大家知道自己读的是哪一版。
常见问题
客户授信审批流程包含哪些步骤？
一套可落地的顺序是：客户提出赊销账期申请，销售记录下申请的额度与账期，申请材料被检查是否齐全，有缺项就去催补。法人主体及其股权结构被核验并做合规筛查，筛查命中会以合规理由终止该案，而不是被当成一个信用问题。随后由信用分析员调取企业征信报告，审阅公开的财务报表与同业付款证明，对客户评分并提出额度与账期建议。这份建议要对照分级授权层级检验，超出本级的上报一级，然后做三选一的决策：按申请批准；附担保批准，担保可以是母公司担保、保证金、信用证或信用保险；或者拒绝并给出预付款替代方案。批准的额度要落在 ERP 的客户主数据上，此后该账户进入监控，按节奏或按触发条件复审，一旦状况恶化就下调额度、维持观察或撤销。
客户授信额度应该怎么定？
常见的方法有四种，多数信用团队会同时用其中两种。第一种是取客户净资产或营运资金的一个比例，数据来自公开的财务报表，适用于经营多年的公司。第二种从贸易量倒推：预计月度采购额乘以以月为单位表示的账期，再为客户实际超出账期的天数留出一段余量。第三种是征信机构给出的建议额度，用来做合理性交叉验证不错，但它是按一般债权人算的，而不是专门针对你的敞口。第四种适用于老客户，就是他们自己的付款记录和历史最高已结清余额，这一条胜过任何外部数据。无论用哪一种，都要把额度对照总敞口而不是仅仅对照应收余额；新客户先低起步、早复审，别在证据薄弱的时候为一个大数字争论不休。
本页与应收账款流程有什么不同？
两者在发票处相交，此外几乎没有交集。本页讲的客户授信审批，决定的是一个客户到底能不能欠你钱、能欠多少、以什么账期、以什么担保，用的是身份核验、企业征信报告、公开财务报表与同业付款证明，以及分级授权层级；它在额度上线到客户主数据并进入复审时结束。/zh/templates/应收账款流程 上的应收账款流程则从发票存在的那一刻开始：开具与发出、按账期跟踪、催收阶梯、争议与红字发票、还款计划、清收与坏账核销。如果你们的问题是逾期发票没人稳定地催，那要看的是那一页；如果你们的问题是额度从一开始就没定对、或者从来没被真正执行过，那就是这一页。两者都嵌在更大的 /zh/templates/订单到收款流程 上的订单到收款流程里，授信审批在那里只是一个方框，而本图把它展开。
客户过不了信用审核时可以要求哪些担保？
没通过审核很少是谈话的终点，这也正是本图设有附担保批准这条分支的原因。常见的选项是母公司或实际控制人担保、保证金或部分预付款、信用证或银行保函、贸易信用保险，以及写进合同条款的所有权保留。每一种都有值得写下来的局限。担保的价值不会超过担保方自己的资产负债表，而且必须由有权作出该担保的人签字。保证金最干净，但也最难谈成。信用证很适合出口订单，对客户来说成本不低。信用保险按损失的一定比例赔付，受制于保险公司对该买方自行核定的限额，而且保险公司一看到状况恶化就会收缩承保，有时比你察觉得还早。无论接受哪一种，都要在放开额度之前确认它确实已经落实，并盯住它的有效期。
客户授信额度应该多久复审一次？
按敞口设定节奏，而不是因为政策这么写就把所有人都一年审一次。常见的做法是：额度最大的以及列入关注名单的每季度一次，中间一档每半年一次，长尾每年一次，其余人由一层轻量的征信自动监控预警覆盖。不过真正保护你的并不是排期复审，而是事件触发条件。把它们逐条写明，并在它们出现的当天就行动——一次逾期付款或一份被打破的还款计划、征信评分下滑、被列入失信被执行人名单、保险公司下调承保限额、一次提额申请、股权变更、年报逾期未报或干脆没报，以及一个不作任何说明就停止下单的账户。在本图里，这些触发条件和日历喂给的是同一个决策，所以一个额度绝不会仅仅因为日期到了才被复审。复审有一件事不该承担：它不是拿到更大额度的通道——提额申请要重新走一遍分级授权，因为更大的敞口需要有权签这个字的那一级。
此流程所处的位置
在大多数组织中，此流程会交接给订单履行流程图模板——从下单到交付。
它是订单到收款中的一个步骤。
第 1 步: 客户授信审批流程图（额度与账期） 当前位置
客户授信审批流程图：申请与主体核验、企业征信报告与同业付款证明、评分与额度建议、分级授权层级、担保安排、ERP 中的额度维护，以及账户存续期内的定期复审。
第 2 步: 订单履行流程图模板——从下单到交付
五泳道的订单履行流程图模板：订单校验、信用审核、库存分配与缺货订单、拣货与包装、发运、交付，以及开票与订单关闭。
第 3 步: 签收凭证流程图（ePOD 从交付到开票）
第 4 步: 开票到收款流程图
第 5 步: 应收账款流程图（从开票到收款）
第 6 步: 银行对账流程图