订单到收款流程图（从接单到收款核销）
六条泳道的订单到收款流程图：订单与主数据检查、信用冻结与解除、发运、签收凭证、开票、收款核销、短付扣款、催收与坏账核销。
什么是订单到收款流程图（从接单到收款核销）流程
订单到收款是公司里唯一真正让钱进来的流程，而它几乎从来不属于某一个人。销售管订单，信用管理管额度，仓库管货，开票管发票，应收管催收——而每一方被考核的又是不同的数字：接单量、敞口、准时发运率、开票张数、应收账款周转天数（DSO）。结果就是一个在每个部门自己的看板上都很健康、端到端却要走七十天的循环。损失很少发生在某条泳道的中间，而是发生在接缝上：一张挂在信用冻结上、却没有人告诉过客户的订单；一次没有签字凭证的交付，于是开票不肯放行；一张因为缺少采购订单号而被客户应付账款门户退回的发票，付款时钟从未启动；一笔被记成逾期余额、被一个根本不知道存在争议的人追了三个月的短付。这里的每一件事，从造成它的那个部门内部都看不见——这也正是为什么把整条循环画在一页上，通常是弄清自己的钱究竟卡在哪里最便宜的办法。
这张图画的是完整循环，因此它在两个地方是刻意画得浅的，而那两处各有一张姊妹图深入展开。仓库那一半——库存分配、缺货订单、分批发运、拣货、打包与向承运商交接——在这里被压缩成一个步骤，完整版在 /zh/templates/订单履行流程 上的订单履行流程图，作业层面的细节则在 /zh/templates/拣货与打包流程。催收那一半——提醒阶梯、分期付款计划、贷项通知单审批权限与坏账准备——在这里被简化为一个催收步骤、一次转交委外催收和一次核销审批，完整版在 /zh/templates/应收账款流程 上的应收账款流程图。客户当初是怎么拿到信用额度的，与一张订单如何对照额度接受检查是两回事，那是 /zh/templates/客户授信审批流程 上单独的一条审批流程。订单存在之前的一切——线索、报价、折扣与条款审批，以及签署的订单——属于报价到收款循环的前半段，见 /zh/templates/报价到收款流程 上的报价到收款流程图；那张图跨越的弧线与本页相同，但把深度放在定价工作上，而不是履行与催收上。而这条循环在采购一侧的镜像——你们是客户、钱是出去而不是进来——见 /zh/templates/采购到付款流程。当问题横跨多个部门时，用本页；当问题落在某一个部门内部时，用那几张之一。
有三处接缝被明确画了出来，因为多数书面程序把它们留给了习惯。信用冻结是一个循环，而不是一道关口：“信用冻结是否解除？”分成三路——已解除、先行预付、拒绝放行——而预付这条路会回来重新检查，而不是离开流程，所以一张靠付款解除冻结的订单，仍然是一张必须有人确认并放行的订单。“是否已取得签收凭证？”被放在发运与开票之间，而不是开票之后，这让发票取决于货已送达的证据，而不是取决于货已发出这一事实。而“是否在到期日前全额付款？”分成三路而不是两路：短付走向“为扣款编码并开立争议”，由能够了结它的人对照订单与签收凭证去核查，沉默则走向催收阶梯。把短付和不付分开，是最能减少无用催收工作量的一项改动，因为两者的成因、责任人和解法都不一样。
本流程图涵盖的内容
本模板包含
- 六条泳道——客户、销售与客服、信用管理、仓储与物流、应收与收款核销、财务经理——横跨五个阶段：订单接收、信用与确认、履行与交付、开票与收款，以及催收与结案。
- 带真实修正循环的订单接收：“订单与主数据是否齐全？”会把不完整的订单退回客户去“补齐缺失的订单信息”，而不是让它继续流进仓库队列；图中还注明了哪些主数据字段应当拦住订单、哪些只应给出提示。
- 信用冻结的解除循环。“信用敞口是否在额度之内？”把超限的订单送去“将订单置为信用冻结”，随后“信用冻结是否解除？”分成三路：已解除、先行预付——这条路会绕回去重新检查——或拒绝放行，终止于“因信用拒绝而取消订单”。
- 一道取决于证据、而不是取决于发运的开票关口。履行被压缩成一个步骤，随后“是否已取得签收凭证？”要么放行开票，要么把订单送去“向承运商追索签收凭证”，再绕回同一道检验。
- 三路分支的“是否在到期日前全额付款？”决策，把付款、短付和沉默分开，于是一笔扣款绝不会被当成逾期余额去处理，一笔真正逾期的余额也绝不会被当成争议搁在那里。随后的“客户的反应？”会把催收开始之后才提出异议的客户送回同一场核查，而不是另开一场。
- 扣款分支与三个终点。短付走向“为扣款编码并开立争议”，随后“对照订单与签收凭证核查”，再由“扣款是否成立？”这道检验要么开出贷项通知单，要么并入催收阶梯；整条循环终止于“发票结清，订单关闭”、经财务经理批准后的“余额已核销”，或那张被取消的订单。
何时使用本模板
- 你们想缩短现金转换周期，需要在有人启动项目之前先看清延迟究竟卡在信用解除、发运、把发票开出去，还是未了结的扣款上。
- 你们要在 ERP 中实施或重新配置订单到收款，希望信用冻结规则、开票触发条件和扣款原因代码先由业务方达成一致，再落成配置。
- 销售和信用管理在为被冻结的订单争执，你们需要把解除权限、响应时限和预付路径画出来，而不是一单一单地去谈。
- 应收账龄表里全是没人说得清的小额残余余额，你们需要把短付路径与逾期路径分开，好让扣款送到能了结它的人手里。
- 你们要为收入循环的内部或外部审计撰写流程说明，需要一张受控的图，说明信用、交付证据、开票和核销这几道控制分别位于哪里。
运作方式
把泳道改成你们自己的组织
把客户、销售与客服、信用管理、仓储与物流、应收与收款核销、财务经理换成你们真实拥有的部门。小型财务团队把信用管理并进应收，不会损失什么；共享服务中心通常需要把开票和催收拆开，因为它们是不同地方的不同团队。如果由第三方物流（3PL）替你们发货，就给 3PL 单独一条泳道，好让你们自身控制的边界清晰可见。批准核销的人，要和催这笔款的人待在不同的泳道里。
把你们的信用政策写进敞口检查
“信用敞口是否在额度之内？”在你说清敞口指什么之前是空的。写明它是否包含未结订单、已交付但尚未开票的货物、尚未收回的发票以及争议中的金额，然后去核对 ERP 实际算的是什么，因为这两者常常不同。记录额度的来源——内部评分卡、征信机构评级、跨法人主体共用的集团额度——以及一个毫无历史的全新客户会怎么处理，通常是预付款或一个小额起步额度，而不是一个空字段。
给信用冻结定一个服务时限和一个责任人
没有时钟的冻结等于丢掉的订单。写明谁可以解除、金额上限是多少，把响应时间按工作小时而不是按天来定，并决定由谁告诉客户订单被冻结了、可以说到什么程度。为超出权限的解除加上升级路径——通常是财务经理或商务总监——并要求每一次解除都填写理由。没有记录理由的冻结订单事后无法复盘，而这些理由里的规律，正是你们的额度需要调整的地方。
决定一张订单凭什么可以开票
本图把发票拦在“是否已取得签收凭证？”被回答之前。想清楚这对你们是否合适：有的企业按发货过账开票，有的按交付确认，有的按客户验收，服务类则按里程碑或按已记录的工时开票。无论选哪一种，都要写下证据存放在哪里，以及在把缺失的凭证当成交付失败之前你们会追多久。抢在证据之前开票，买来的是几天的应收账款周转天数，代价是一个季度之后的扣款。
在需要之前先把扣款原因代码建好
“为扣款编码并开立争议”只有在代码存在且有含义时才成立：价格、数量、短少、破损、促销或返利、运费、退货、重复付款。给每个代码指定一个默认责任人，因为路由核查靠的就是它——价格争议给销售，短少给仓库，返利索赔给签下那份协议的人。设定一个金额门槛，低于它的残余余额不做核查直接清掉；并商定争议未结期间催收是否暂停、暂停多久。
和真正做这件事的人走一遍，然后发布一个版本
把图拿到销售订单台、一位信用管理专员、发运室和一位收款核销会计面前，跟着三笔真实订单走一遍：一笔顺利的、一笔曾挂在信用冻结上的、一笔被短付并产生争议的。把图改成大家实际在做的事，而不是程序上写的事，并给每个步骤补上所用的系统和单据。然后发布该版本并保留此前的版本，让日后打开这张图的人知道自己看的是哪一版、又改了什么。
常见问题
订单到收款流程包含哪些步骤？
收到客户订单，对照订单与主数据做检查；把客户的信用敞口与其额度比对，超限的订单被置为信用冻结，然后被解除、改为预付或被拒绝；订单带着承诺日期得到确认并放行至履行；货物被拣货、打包并发运；取得签收凭证；发票依据交付生成并发出；在到期日对付款做匹配；收款核销、发票结清。在这条主干之外，还有两条决定这个循环是否真的跑得通的分支：短付被编码为扣款，对照订单与签收凭证核查，最终或是开出一张贷项通知单，或是继续追讨；而未付的发票进入催收，随后转交委外催收，最后由一位独立于催收工作的人批准坏账核销。
订单到收款和应收账款有什么区别？
应收账款是订单到收款的收款那一半：发票、付款条件、提醒、争议和现金。订单到收款是整条循环，从客户订单开始，经过信用检查、订单确认、发运与交付证据，发票在这之后才存在。这个区分之所以重要，是因为大多数订单到收款的问题都产生在应收的上游，却落到应收头上：一个错误的收货地址会变成交付争议，一个缺失的采购订单号会变成被客户门户退回的发票，一次没有记录的分批发运会变成一笔扣款。如果你们要的是催收侧的细节——催收日历、分期付款计划、贷项通知单审批权限和坏账核销——请用 /zh/templates/应收账款流程 上的应收账款流程图。如果你们想弄清楚应收为什么总是收到有问题的发票，请用本页，它展示的正是产生这些发票的那些步骤。
什么是信用冻结？谁应当有权解除？
信用冻结是当客户的敞口突破其信用额度、或其账户逾期超过某个设定点时，自动加在订单上的一道拦截。它会让订单停在原地不再走向履行，直到有人做出决定。解除权限应当按金额分级，并归属信用管理而不是销售，恰恰是因为希望这批货发出去的人，不应该是判断客户付不付得起的人。让它成为一道控制而不是一处瓶颈，靠的是三件事：以工作小时计的响应时限、为超出信用管理专员权限的解除定义的升级路径，以及每一次解除都记录理由。理由的分量比看上去大得多——把一个季度的理由拿来复盘，通常会看出两件事之一：某个好客户的额度定得太低，或者某个本不该有额度的客户，额度正在被例行突破。
短付和扣款应该怎么处理？
与逾期发票分开处理，而且要立刻处理。短付是客户在告诉你有什么地方不对，所以有用的反应是核查，而不是再发一封催款提醒。在核销汇款的那一刻就把原因编好码——价格、数量、短少、破损、促销或返利、运费、退货、重复付款——并把案子路由给能了结这一类问题的人：定价给销售，短少给仓库，促销索赔给签下返利协议的那个人。设一个小额门槛，低于它的残余余额不做核查直接清掉，因为追一笔二十元的差额，成本比这笔差额本身还高。然后按原因代码长期跟踪扣款。这些代码作为你们自己订单到收款流程的缺陷报告，价值远高于作为一条催收队列：短少代码在上升，是仓库的问题；价格代码在上升，是定价或合同的问题，不修好就会一直付出代价。
怎么衡量订单到收款循环跑得好不好？
应收账款周转天数（DSO）是那个头条数字，但它单独看会掩盖时间到底花在哪里，而且它随销售量变动的程度不亚于随绩效变动。把循环拆成这张图让人看得见的几段间隔：下单到确认、挂在信用冻结上的时间、确认到发运、发运到取得签收凭证、交付到发票开出、发票到收款核销。再在旁边加上三个质量指标——发票一次准确率、无需人工匹配即自动核销的收款占比，以及扣款占已开票金额的比重并按原因代码拆分。这样衡量之后，最大的那一段延迟往往根本不在客户身上，而是交付到开票、或者一张挂在冻结上的订单、或者账上尚未核销的收款——这些全都在你们自己的控制范围内，而且单看一个 DSO 数字，一个也看不出来。
此流程所处的位置
在大多数组织中，此流程紧随从线索到订单流程图：从采集线索到订单登记之后。
前置流程
- 从线索到订单流程图：从采集线索到订单登记 — 从线索到订单流程图模板：采集与去重、线索打分与 MQL 关口、SDR 触达与销售接受、CPQ 配置、折扣审批、报价接受、信用审核与销售订单登记。