月底的资金会上，老板问下个月能回多少款，销售报了一个数，财务按这个数安排付款和采购。结果月底实际到账只有六成，该付的付不出去，该备的货没备上，两边的怨气都指向对方。这类场面反复出现，问题不在销售不认真，而在预测的方法本身：把所有应收都当成「应该会回来」的钱，没有区分哪些确定、哪些有把握、哪些只是希望。
一、预测的原料是回款计划，不是记忆
回款预测的地基是每笔应收都挂着计划回款日期，而且计划是活的：客户延期要走审批改日期，而不是销售嘴上答应一个数、系统里还停在原来的日子。计划日期失真，后面所有分层都是空谈。所以做预测之前，先检查两件事：应收是否都挂了计划日期，日期的变更是否有审批记录。这两项不过关，先补基础再谈预测。
二、把下月应收按确定性分三层
- A 层已确认：客户以对账单回签、邮件确认或付款申请等书面方式认可了金额和日期，争议已清零
- B 层有把握：内部流程已走完，验收签收齐、发票已开出，客户财务流程在走，日期是按对方节奏推算的
- C 层存疑：到期提醒才想起的款、客户近三个月有过延期记录的款、日期来自销售口头承诺的款
三层要分开报，不能合并成一个总数。对老板和财务报 A 加 B 的合计，作为资金安排的依据；C 层单独列出来，标注风险原因，作为催收动作的清单。混在一起报一个大数，看起来体面，实际是把风险藏给了自己人。
三、举例说：一套完整的演算过程
假设某公司十二月的计划回款共三百二十万。分层之后：A 层一百四十万，客户已书面确认；B 层一百一十万，发票已开、客户在走内部审批，按历史经验八成能当月到账，折算八十八万；C 层七十万，其中三十万的客户近三个月延期过两次，按五折算十五万，其余四十万按三成算十二万。合计预测是一百四十加八十八加十五加十二，等于二百五十五万。老板按这个数排资金，缺口六十五万提前一个月就看见了，可以安排过桥、催收或者调整采购节奏。如果只报三百二十万，月底差出六十五万，就变成了信任事故。
四、月底复盘偏差率，把预测越做越准
十二月实际到账二百三十万，与预测差二十五万，偏差约一成。逐笔找原因：B 层里有两笔客户审批流程比预期慢了两周，C 层里一笔五折的客户到头来分文未付。把原因记回客户档案，给常拖的客户做一条备注：实际到账平均比承诺晚九天。下个月做预测时，这类客户的折算系数直接下调。偏差率要按月跟踪，连续两个月超过两成，说明问题不在预测方法，而在计划日期本身失真，要回头修计划而不是修预测。
五、预测表每月固定出一次，形成节奏
每月二十五号出下月预测，给财务留出排资金的时间；每月五号复盘上月实际到账与预测的差距。预测表固定五个栏目：客户、计划日期、金额、确定性层级、与上周相比的变化。变化那一栏很重要，A 层变 C 层往往早于逾期发生，层次下滑本身就是预警，比等到逾期再动作要主动得多。
这套分层预测的做法，用 9527CRM 这类轻量级 CRM 的回款计划与应收报表就能落地：每笔应收挂计划日期与确定性层级，系统按月自动汇总出预测表，月底实际到账自动对出偏差率，层次下滑的款项自动标红提醒；由于支持私有化部署，全部回款与预测数据可以随时完整导出与备份，存在企业自己的服务器上，不被厂商锁定，财务做多年资金规划时历史数据一条不丢，管理者要的是可控，不只是一套工具。
