现金流预测：13 周滚动预测法

本指南提供一套简单、CFO 级别的方法来管理公司流动性。通过建立 13 周滚动现金预测，你可以按周看清现金跑道，有策略地安排回款与付款，消除财务意外。这套方法是为创始人设计的——本页直接给出模型：带公式和示例数据的工作簿，以及它前两周背后的示例 Beancount 账本（下载见下文）。

先说清两件事：预测是你逐项输入的前瞻性估计，而账务实际值是已记入账本的银行变动——下面的周一流程是把后者手工抄录覆盖到前者之上。这里没有任何自动同步：工作簿没有宏也没有外部连接，没有任何步骤会自动从你的银行或 Beancount 拉取数据。

为什么是 13 周？​

13 周预测是运营现金管理的黄金标准，主要原因有三：

• 短期可控： 覆盖约一个业务季度，让你对即时流动性一目了然。这个跨度足够包含 2–3 个发薪周期、税款缴纳和典型的供应商账期，又足够短，保持高度准确和可执行。
• 收付视角： 预测采用「直接法」，只看现金流入和流出。这与权责发生制和盈利能力无关，只关心什么会真正进出你的银行账户，确保预测与银行余额直接挂钩。
• 滚动而非静态： 这不是一次性预算。每周去掉刚过去的一周，在末尾新增一周（第 13 周），并更新假设。前瞻窗口始终保持不变，预测变成每周的动态功课。

你要搭建什么​

1. 一张电子表格： 系统的核心是一张表，13 列（第 1 周到第 13 周），分区明确：期初现金、收款、支出、净现金流、期末现金。
2. 分类映射： 把账本交易映射到预测分类的简单规则（例如所有 Stripe 回款映射到「客户收款」；Gusto 发薪映射到「工资」）。工作簿的 Vendor Mapping 表已经内置了这套映射，包括银行/信用卡不重复计算规则——直接用它，不要自己重造。
3. 每周节奏： 更新预测、跟踪差异（预测 vs. 实际）的固定流程，以及一组预先定好的触发动作：一旦触及资金阈值就执行。

下载起始文件​

跳过空白起步：本指南附带公式工作簿（含示例数据）以及它前两周背后的示例账本。

• 13 周预测工作簿（XLSX，v1.0.0）— cash-flow-forecast-13-week-zh.xlsx。假设可编辑、周与周之间公式勾稽，另有供应商映射表；把蓝色示例单元格换成你自己的数字。
• 示例账本与实际值（Beancount 账本，.bean）— sample.bean。配平的示例账本，含与工作簿前两周完全对应的 W1–W2 银行实际值。

动手前先读懂起始文件​

工作表。 工作簿（cash-flow-forecast-13-week-zh.xlsx，v1.0.0）有三张表：

• Forecast ——13 个带日期的周、假设、收款、支出、净现金/期末现金。
• Vendor Mapping ——账本→分类映射表，每个来源的银行/信用卡计数规则。
• Notes ——机制、情景开关和版本号，与生成器一致，离线也能看懂文件。

时间口径。 周从周一开始，W1 始于 2026-09-14，W13 始于 2026-12-07（Forecast 第 2 行；采用模型时修改这些日期即可——所有公式都是相对周引用的，勾稽不断）。一笔交易归入其记账日期所在的周，周一到周日。

单位。 全篇整数 USD（数字格式 #,##0）。示例公司是一家种子期 SaaS，期初 85,000，工资每周在 0 / 11,000 之间交替，按月付租，每周 900 贷款自动扣款。

哪些格子你填、哪些格子算。 蓝色单元格是手工输入，其余全是公式：

• 输入：期初余额 B5（85,000）、开关 B6/B7（1.0）、下限 B8（40,000）、收款基准 12–14 行、支出基准 17–26 行，以及第 2 行的周日期。
• 公式（以 B 列第 1 周为例——之后每周列字母顺移）：期初 B10 = $B$5（第 2–13 周改为承接上周，即 C10 = B29）；收款合计 B15 = B12*$B$6+B13*$B$7+B14；支出合计 B27 = SUM(B17:B26)；净额 B28 = B15-B27；期末 B29 = B10+B28。
• 重算模式为自动，文件设置了 fullCalcOnLoad，Excel、LibreOffice 和 Numbers 每次打开都会重算（文件不存公式缓存值）。改一个蓝色格子，13 周全动——比如把回款开关 B6 调到 1.2，W1 收款就从 12,200 变成 14,600，W1 期末现金从 87,500 变成 89,900。
• 随时用 yarn generate:cash-flow-forecast 重新生成干净文件（生成器：scripts/generate-cash-flow-forecast.py，写入器 openpyxl 3.1.5；--verify 会重新打开文件，断言每个合计数都是真公式）。

示例数据 vs. 你的数据。 每个蓝色格子里的都是示例数字——是做好的例题，不是你的生意。请逐周换成你自己的数；只有两个开关（B6 缩放全部客户收款，B7 缩放全部预付款）是故意通用的，用来玩情景。示例账本 W1–W2 的实际值按构造就等于工作簿 W1–W2 的示例预测，所以那两周预测与实际差异为零：这是对账要达到的样子，不是说你的账也一样。

结构（你需要的行）​

预测表应该按以下行来搭，才能覆盖全部现金变动。这就是下载文件里 Forecast 表的布局（收款 12–14 行，支出 17–26 行，合计 10/15/27–29 行）——把它当地图读，不要当第二份规范。

• 期初现金（必须等于上周的期末现金）

• 收款（现金流入）

  • 客户收款： 预计从已有发票（应收账款）收回的现金。
  • 新签约/预付款： 预计 13 周窗口内新签单带来的预付现金。
  • 其他流入： 其他一切现金流入，如退税、利息收入或补助。

• 支出（现金流出）——表里 10 行（17–26 行）：

  • 工资： 全部现金成本，包括员工实发和雇主承担的工资税。
  • 承包商： 付给非雇员的款项。
  • 云/托管（COGS）： AWS、GCP 等核心基础设施成本。
  • SaaS/工具： 所有软件订阅。
  • 营销： 广告投放、代理商费用及其他品牌开支。
  • 租金/办公： 实体办公成本。
  • 法律与会计： 专业服务费。
  • 税费： 销售税上缴及其他政府性缴费。
  • 债务偿付： 贷款本金加利息。
  • 一次性： 笨重、不常发生的支付，如年度保费、押金、硬件/资本开支（电脑、设备）——上面没有单列的都进这里。

• 净现金流（= 收款合计 − 支出合计）

• 期末现金（= 期初现金 + 净现金流）

滚动机制（工作簿里已经搭好）​

滚动预测的逻辑简单而强大——下载文件里已经是 Forecast 表上的公式（括号内为行号）：

• 期初现金（第 1 周）= 期初余额假设——单元格 B10 = $B$5。
• 期初现金（第 n 周）= 期末现金（第 n−1 周）——如 C10 = B29（第 10 行，第 2–13 周）。
• 收款合计（第 n 周）= 客户收款 × 回款开关 + 预付款 × 预订开关 + 其他——如 B15 = B12*$B$6+B13*$B$7+B14（第 15 行）。
• 支出合计（第 n 周）= 上面 10 个分类行求和——如 B27 = SUM(B17:B26)（第 27 行）。
• 净现金流（第 n 周）= 收款合计 − 支出合计——如 B28 = B15-B27（第 28 行）。
• 期末现金（第 n 周）= 期初现金 + 净现金流——如 B29 = B10+B28（第 29 行）。

每周一早上的固定动作（对照这个工作簿）：

1. 滚动窗口： 整体前移一周——每周的蓝色输入整列左移一列（旧第 2 周变成新第 1 周），清空最后一列，在第 2 行填上新第 13 周的日期。承接公式（C10 = B29 等）会自动重新锚定；抽查一下新第 1 周的期初是否等于上周期末。
2. 填入实际值： 按下面的映射，把上周的银行实际变动手工抄进上周的蓝色预测格（查数、拆分、粘贴——手工做）。然后确认该周的期末现金格等于你真实的合并银行余额（Assets:Bank:Checking + Assets:Bank:Savings）：对不上就是映射错了，不是银行错了。
3. 重估未来： 用最新信息更新未来 2–4 周的蓝色格子（新开的发票、临近的供应商付款、确认的发薪日）。

从 Beancount 到预测的映射​

银行现金口径（防止重复计算的规则）。 每周实际值只取 Assets:Bank:* 上的分录——一个口径同时堵住两个坑：

• 信用卡： 刷卡记在 Liabilities:CreditCard:* 上，没有动银行现金，所以刷卡时不算。现金只在还款时流出一次（银行→信用卡的还款）。把刷卡加上还款都算，就把同一笔开销算了两次。示例账本里，W1 有 420.00 USD 的 Amex SaaS 刷卡（只是负债，忽略），旁边是 600.00 USD 的 8 月账单还款（要算）。W1 按「银行流出 + 刷卡」算出来是 10,120.00 USD——正好多 420.00；工作簿里算的是 9,700.00。
• 内部转账： Checking↔Savings 的归集有借有贷两条银行分录，在这个口径里轧差为零，所以收款支出两边都不进。示例里 W1 的 3,000.00 USD 和 W2 的 1,500.00 USD 归集，否则会把两边同时虚增这些金额。
• 推论： 映射看银行分录，不看收入/费用分录。贷款本金不是费用，但是银行流出（示例里 900.00 USD 自动扣款 = 800 本金 + 100 利息，全进债务偿付）；刷卡是费用，但还不是银行流出。

收付拆分。 从导出的银行分录起：正数为收款，负数为支出，转账分录剔除。分类映射（与 Vendor Mapping 表一致）：Stripe/PayPal 回款 → 客户收款；新客户电汇 → 新签约/预付款；银行利息/补助 → 其他流入；Gusto/ADP → 工资；AWS/GCP → 云/托管；银行直付的 SaaS → 软件/SaaS；房东 → 租金；律所 → 法律/会计；税务机关 → 税费；贷款自动扣款 → 债务偿付。

• 销售税怎么处理： 销售税虽然不是收入，但是现金流项目。代收的销售税记收款，上缴政府记支出。收入影响在权责账里，但现金的变动只看这里。

例题周：W1 全程（2026-09-14 – 2026-09-20）​

期初银行现金 85,000.00（2026-09-13 日 Checking 80,000 + Savings 5,000）。剔除 3,000.00 归集对之后，账本 W1 的银行分录如下：

滚入 W2。 C10 = B29，所以 W2 期初 87,500.00。它的银行分录：收款 8,000（Stripe）+ 5,000（预付款）+ 200（利息）= 13,200.00，支出 11,000（Gusto 发薪）+ 1,500 + 2,200 + 600（银行直付 SaaS）+ 1,000 + 900 = 17,200.00；净 −4,000.00，期末 83,500.00——正好是工作簿的 W2 列。这两周预测与实际差异按构造为零；这就是映射有效的证明，从 W3 起每周用一次的办法照做。

复现（2026-09-09 验证，Beancount 3.2.3 + beanquery 0.2.0）​

uvx --from beancount bean-check public/downloads/cash-flow-forecast/sample.bean
yarn check:cash-flow-actuals

检查器跑 bean-check（账本自带的 balance 断言证明每周期末现金）、下面的导出查询，以及一个独立的 Python 滚算，断言三方一致——W1 12,200.00 / 9,700.00 / 87,500.00，W2 13,200.00 / 17,200.00 / 83,500.00：

SELECT date, narration, account, position
FROM date >= 2026-09-14 AND date <= 2026-09-20
WHERE account ~ "^Assets:Bank" ORDER BY date;
 
SELECT sum(position) AS net
FROM date >= 2026-09-14 AND date <= 2026-09-20
WHERE account ~ "^Assets:Bank";
 
SELECT sum(position) AS bank_cash
FROM close ON 2026-09-21 WHERE account ~ "^Assets:Bank";

（W2 把日期平移 7 天，closing 用 2026-09-28。）一个 BQL 限制要知道：这个 beanquery 版本不能按正负过滤分录，所以收付拆分做在导出结果上——银行正分录进收款、负分录进支出、归集对剔除——检查器就是这么做的。

每周更新节奏（30–45 分钟）​

1. 拉实际值（15 分钟）： 导出本周记在 Assets:Bank:* 上的分录（跑上面的查询，或从银行下载流水——刷卡消费不算，只有还款算）。确认上周「期末现金」与你真实的合并银行余额分毫不差（Checking + Savings）。这个对账没得商量。
2. 过应收（10 分钟）： 列出所有未结发票，按预计回款周归位。保守一点，按历史经验加合理的账期滞后。
3. 过应付和发薪（10 分钟）： 把已知账单按到期日归位。整个季度的发薪日和金额一次填好。非关键支出排到周五做，保住周内的现金选择权。
4. 差异会（10 分钟）： 对比上周预测和实际，记下重大差异的原因，决定要不要改预测规则。

准确度与决策​

准确度经验值​

• 第 1–2 周： 误差目标 ±5–10%。这些日期和金额应该高度确定。
• 第 3–6 周： 误差预期 ±10–20%。这段是已知账单加规律性估计的混合。
• 第 7–13 周： 这部分是方向性的，靠销售 pipeline 和固定费用驱动。

置信标记： 给每行预测打个置信标记，读起来更轻松：已锁定（如工资、房租）、大概率（如好客户的发票）、增量（如 pipeline 里新单）。

触发器与动作（提前定好）​

没有预案的预测毫无用处。触及阈值时做什么，提前定好。

• 最低现金红线： 比如你们的规矩是「现金任何时候 ≥ 下一个完整发薪额的 1.5 倍」。预测一旦跌破，立刻执行预定方案，比如集中催收加暂停一切可支配开支。
• 跑道护栏： 比如「如果第 13 周期末现金意味着烧钱只够 X 个月，就启动融资计划」。可以是拿 term sheet、给客户预付款折扣，或者动用信用额度。
• 大额支出规则： 比如「单笔非工资支出超过当前现金 5% 的，必须提前两周审批，并有备选方案」。

模板与情景​

简单分类（种子期 SaaS 版）​

• 收款： 客户收款、其他流入（利息、退款、补助）
• 支出： 工资（实发 + 雇主税）、承包商、云/托管（COGS）、软件/SaaS（OpEx）、营销（投放/品牌）、租金/办公、法律/会计、税费、债务偿付、一次性/年度费用
• 计算项： 净现金流、期末现金

模板（下载里已经搭好；照抄可得空白版）​

下表就是 Forecast 表的样子——行一样、公式一样，照着在空表里重搭就行。下载文件第 2 行已经填好各周起始日（W1 2026-09-14 到 W13 2026-12-07），每个合计都连着公式；冻结第 3 行以下、第 A 列右侧（文件里是 B4），效果一样。

情景开关（保持轻量）​

不用复杂模型也能做简单情景规划。在表顶给关键变量加个「开关」格。比如：

• 回款放缓开关 B6: [1.0]（调到 1.2，就是回款慢 20% 的情景——每周收款合计按 COL15 = COL12*$B$6+COL13*$B$7+COL14 重算）
• 新签约开关 B7: [1.0]（调到 0.8，就是新签约比计划少 20%）

这就是 Forecast 表上现成的假设格——不用另接线。

学习与避坑​

差异跟踪（让学习复利）​

给刚过去的一周加两列：「上周预测」和「实际」。算出差异。复盘时给大差异打原因标签：回款延迟、范围蔓延、计划外采购、时间错位。同一种差异反复出现，就改模型的底层规则。比如回款总晚一周，就把默认账期假设从 21 天改成 28 天。

常见坑（别踩）​

• 权责现金混为一谈： 这个预测只看现金。确认的收入、折旧和其他权责概念归主账，不管这里。
• 忘了笨重的大额年付： 年度保费、大额 SaaS 续费、季度缴税都可能是巨雷。一知道就排进预测。
• 漏了代收代缴的销售税现金： 就算是过手负债，在上缴之前钱趴在你的银行账户上。流入流出两边都要建模。
• 不对账： 预测期末现金和真实合并银行余额对不上（Checking + Savings；信用卡余额不算），说明映射错了——多半是刷卡也算了，或者归集没剔除。不修好就别信这个预测。
• 没指定负责人： 指定一个人，每周负责更新预测。休假也要有人替补。

Beancount 速查关联​

• 科目表： 现金桶子分干净（如 Assets:Bank:Checking、Assets:Bank:Savings、Liabilities:CreditCard:Amex）。每周实际值只取 Assets:Bank:* 分录——信用卡账户的存在是为了让还款有出处，不是第二个流出来源。
• 别拿利润表来对： Fava 的利润表是权责口径——刷卡当时就记费用、贷款本金不算——所以和现金预测天生对不上，这是设计使然。现金口径的检查就是上面的 bean-query 导出加滚算（yarn check:cash-flow-actuals），每周必须和期末现金对上。
• 留档： 大额一次性事项，把发票 PDF 收到 Beancount 的 documents/ 文件夹，并在预测备注列里链过去。

董事会/投资人一页纸​

1. 图： 13 周期末现金折线图，加一条最低现金红线。
2. 表： W1–W13 期末现金小表，加本季度 Top 5 最大流入流出清单。
3. 备注： 几条关键假设相对上次的变化，以及触发过/将触发的阈值。