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

本指南提供一套简单、达到 CFO 水准的方法，帮你管理公司的流动性。通过构建13周滚动现金预测，你可以按周看清现金跑道，有策略地引导收款与付款，消除财务上的意外。这是一套为你量身打造的系统——而且本页直接提供实际的模型：一个带公式的工作簿加示例数据，以及支撑其前两周的示例 Beancount 账簿（见下方下载）。

有两件事本指南不是：预测是你手动键入的前瞻性估计，而会计实际数是账簿中已经入账的银行流水——所以工作簿把两者分开存放。你把计划的一份副本冻结为带日期的基准，把每个已结周的银行现金键入实际数表，再在差异表上读取两者的差；用来对比的计划永远不会被覆盖。这里没有任何东西会自动同步：工作簿没有宏，也没有外部连接，没有任何步骤会自行从你的银行或 Beancount 拉取数据。

为什么是13周？​

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

• 短期掌控： 它大约覆盖一个业务季度，让你对眼前的流动性有清晰周期。这个时间跨度足够包含2–3个发薪周期、税款缴纳和典型的供应商付款账期，又足够短，能保持高度准确和可执行。
• 收付实现制视角： 预测采用"直接法"，纯粹关注现金流入和流出。这不是权责发生制，也不是盈利能力问题；它关注的是实际会进入或离开你银行账户的钱，确保预测直接对应银行余额。
• 滚动而非静态： 这不是一次性的预算。每周你丢掉刚过去的那一周，在末尾加一周（第13周），并更新你的假设。这让前瞻周期保持恒定，把预测变成一项动态的、每周进行的纪律。

你将构建什么​

1. 一张预测网格： 系统的核心是一张包含13列（第1周到第13周）的表，以及明确定义的分区：期初现金、收入、支出、净现金和期末现金。三张相同行结构的配套表分别保存该计划的冻结基准、你银行记录的实际数，以及两者的差异。
2. 类别映射： 一套简单的系统，把账簿中的交易映射到预测类别（例如，所有来自 Stripe 的付款映射到"客户回款"；Gusto 付款映射到"工资"）。工作簿的供应商映射选项卡已经内置这张映射表，包括银行/信用卡不重复计数的规则——从它开始，不要自己另创一套。
3. 每周节奏： 一套可重复的流程，用于录入实际数、对照你承诺的基准审查差异、重新估计未来几周，以及一组预先定义好的触发器，在财务阈值被触及时采取行动。

下载起始文件​

跳过从空白页开始：本指南附带一个带公式的工作簿加示例数据，以及支撑其前两周的示例账簿。

• 13周预测工作簿（XLSX, v1.1.0）—— cash-flow-forecast-13-week-zh.xlsx。可编辑的假设、公式串联的各周、纯数值的基准快照、实际数表、纯公式的差异表和一个供应商映射选项卡。每个示例数字都是完整的演算示例——用你自己的数字替换它（见下方示例数据 vs. 你的数据）。
• 示例账簿和实际数（Beancount 账簿，.bean）—— sample.bean。一份平衡的示例账簿，其 W1–W2 银行现金正好等于工作簿实际数表前两周所持有的数值。

起始文件如何工作（动手前先读这段）​

工作表。 工作簿（cash-flow-forecast-13-week-zh.xlsx，v1.1.0）有六张表，顺序如下：

• Forecast —— 你的实时计划：13个带日期的周、假设、收入、支出、净现金/期末现金。你可以随意编辑。
• Baseline —— Forecast 第2–29行的纯数值快照，在 B31 标注版本号、在 B32 标注截至日期。它不含任何公式，所以你在别处做任何事都无法改变它。
• Actuals —— 每个已结周银行现金真实变动的金额，由你录入：第3行是状态（complete 或 partial），类别金额与 Forecast 同行，第30行是可选的账单余额。
• Variance —— 只有公式：每个类别和总计的 Actual − Baseline，按周起始日期匹配，另有一个图例解释每个状态词。它从不读取 Forecast。
• Vendor Mapping —— 账簿→类别的映射，附每个来源的银行/信用卡现金计数规则。
• Notes —— 机制、每周审查、情景开关和版本信息，从生成器复制而来，让文件能离线自我解释。

四张周网格共用同一布局：W1–W13 位于 B–N 列，第2行是每周起始日期，期初现金是第10行，收入是第12–14行（总计第15行），支出是第17–26行（总计第27行），净现金第28行、期末第29行。所以在每一张表上，B12 都是 W1 的客户回款。

时间基准。 每周从周一开始，W1 起始于 2026-09-14，到 W13 起始于 2026-12-07（Forecast 第2行；采用此模型时请编辑这些日期——每个公式都是相对周定位的，所以串联能存活——并在捕获基准时把它们带到 Baseline 和 Actuals）。一笔交易属于包含其记账日期的那一周，即周一到周日。

单位。 全程为整数 USD（数字格式 #,##0）。示例公司是一家种子期 SaaS，期初现金 85,000，每周工资在 0 / 11,000 间交替，有月度房租，以及每周900的贷款自动扣款。

哪些是你输入的，哪些是算出来的。 在 Forecast 上，蓝色单元格是手动输入，其余全是公式（Actuals 同理，有它自己的输入，在下方捕获基准和每周审查中描述）：

• 输入项：期初余额 B5（85,000）、开关 B6/B7（1.0）、下限 B8（40,000）、三个收入类别基数、十个支出类别基数，以及 Forecast 上的周起始日期。
• 公式（以 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. 你的数据。 有三处预填内容，三者都是演算示例，不是你的业务：

• Forecast 上的蓝色单元格（示例公司当前计划）；
• Baseline 上的快照，版本 B1，截至 2026-09-11——即前两周结账之前该计划的样貌；
• Actuals 上的 W1–W2 条目（B–C 列），即示例账簿（上方 sample.bean）中的银行现金。W3–W13 留空。

由于示例的 Baseline 和 Actuals 不同，差异表一打开就是一次真实的对比：W1 期末 +500 领先计划，W2 +300（见下方差异审查）。在你自己的第一次审查之前，把这三处全部替换：在 Forecast 上键入你的计划，清空示例 Actuals 条目，并在 B1 之上捕获你自己的基准（步骤见下）。两个开关（B6 缩放所有客户回款，B7 缩放所有预付款）是唯一设计为保持通用的东西，用于情景演练。

从 v1.0.0 升级过来？ Forecast 表的布局没有变化，所以你可以有意识地把计划迁移过来：在旧文件中只复制输入区域——B2:N2（日期）、B5:B8、B12:N14 和 B17:N26——然后以数值形式粘贴到新文件 Forecast 的相同地址，绝不要覆盖公式行。v1.0.0 不保存基准，所以你用实际数覆盖过的任何过去周都没有可恢复的计划：把这些周的银行现金键入 Actuals，并用今天的 Forecast 开始你的第一个 Baseline。

结构（你需要的行）​

你的预测表应按以下行来组织，以捕获所有现金变动。工作簿的布局如下： 下列行位于 Forecast 上（13个带日期的周，含期初现金、三个收入类别、十个支出类别、净额和期末），而 Baseline、Actuals 和 Variance 逐行重复它们；Vendor Mapping 把账簿来源映射到这些类别，包括银行/信用卡不重复计数的规则；Notes 离线解释机制。在 Forecast 上，收入分组为客户回款、新签约/预付款和其他流入；支出分组为工资、承包商、云/托管、软件/SaaS、营销、房租、法律与会计、税费、偿债和一次性支出；总计滚动为 期初 → 总收入 → 总支出 → 净额 → 期末。

• 期初现金余额（必须与上一周的期末现金余额对上）

• 收入（现金流入）

  • 客户回款： 你预期从现有发票（应收账款）中收回的现金。
  • 新签约/预付款： 你预期从13周窗口内成交的新交易中获得的前置付款。
  • 其他流入： 任何其他流入的现金，如退税、利息收入或补助资金。

• 支出（现金流出）

  • 工资： 全部现金成本，包括发给员工的净工资和所有雇主承担的工资税。
  • 承包商与自由职业者： 支付给非雇员的款项。
  • 云/托管（COGS）： 核心基础设施成本，如 AWS、GCP 等。
  • SaaS/工具： 你所有的软件订阅。
  • 营销： 广告投放、代理费和其他品牌相关成本。
  • 房租/办公： 实体办公成本。
  • 法律与会计： 专业服务费。
  • 税费： 销售税缴纳和其他政府付款。
  • 偿债： 任何贷款的本金和利息付款。
  • 一次性支出： 不规律的、不频繁的付款，如年度保险费、押金或硬件/资本支出（笔记本电脑、设备）——任何上方没有专属行的东西都归到这里。

• 净现金流（= 总收入 − 总支出）

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

完整的13周示例（USD）​

下表是示例公司工作簿的 Forecast 表，逐周展示——这是当前计划，在 W1 和 W2 结账后重新预测过，所以那两列现在持有银行实际发生的数据。W1 和 W2 是账簿实际数——它们等于 yarn check:cash-flow-actuals 从 sample.bean 推导出的总计（收入 12,200 / 13,200，支出 9,700 / 17,200，期末 87,500 / 83,500）。W3–W13 是工作簿假设，来自生成器的示例基数（账簿中未入账）。公司在事前承诺的计划单独保存在 Baseline 上，与这些 W1–W2 列不同；下方差异审查对比两者。货币为整数 USD；每周 期末 = 期初 + 收入 − 支出。

滚动机制（工作簿中的实现）​

滚动预测的逻辑简单而强大——在下载文件中，它已经作为公式接在 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个类别行的 SUM —— 例如 B27 = SUM(B17:B26)（第27行）。
• 净现金（第n周）= 总收入 − 总支出 —— 例如 B28 = B15-B27（第28行）。
• 期末现金（第n周）= 期初现金 + 净现金 —— 例如 B29 = B10+B28（第29行）。

Actuals 上存在同样的行，作为纯合计（B15 = SUM(B12:B14)、B27 = SUM(B17:B26)、B28 = B15-B27、B29 = B10+B28、C10 = B29），该周的实际期初现金在 Actuals!B10 键入一次。Actuals 没有开关，也从不引用另一张表。

捕获基准（每个周期一次）​

当你的 Forecast 持有你希望被对照衡量的计划时——在第一周结账之前——做这件事。

1. 把计划复制为数值。 选中 Forecast!B2:N29 并复制。选中 Baseline!B2，粘贴仅数值——Excel：选择性粘贴 → 数值；LibreOffice：选择性粘贴 → 仅数值；Numbers：编辑 → 粘贴公式结果。普通粘贴会把实时公式带过来，"基准"就会悄无声息地跟随之后每一次编辑。
2. 给它加标签。 在 Baseline!B31 键入版本号（例如 B1），在 Baseline!B32 键入今天的日期。两者都在粘贴块的下方，所以之后的捕获永远不会覆盖它们。
3. 对齐各周。 复制 Baseline!B2:N2 并以数值粘贴到 Actuals!B2，让两张表命名同样的13个周起始日期，然后在 Actuals!B10 键入你的起始银行余额。

从此以后，键入实际数、编辑 Forecast 或拨动开关都会重算 Forecast 和 Variance，而 Baseline 保持捕获时的原样。

你的每周一审查（对照此工作簿）​

1. 在实际数表上记录本周——绝不在 Forecast 上。 在第2行日期为刚过去那个周一的那一列，按类别在第12–14行和第17–26行键入该周的银行现金（映射见下）。没有现金变动的地方键入 0：空白单元格意味着"尚未录入"，不是零。把银行账单的期末余额填在第30行；第31行此时应显示 0。任何其他值都是映射错误——通常是计入了信用卡消费或保留了内部划转——而不是银行错误。
2. 检查本周是否完整。 当每个类别行都填上数字后，在第3行键入 complete；如果本周还没结束，键入 partial（下拉菜单提供这两个选项）。只有在某周为 complete、每个类别都已录入、且 Actuals 日期等于同一列的 Baseline 日期时，Variance 才会比较该周。
3. 读取差异。 第3行标注每周的状态；只有 compared 的周显示数字，其他所有状态都显示 n/a，绝不为 0，所以未录入的周无法被误认为"符合计划"。符号为 Actual − Baseline（O 列重复这些值）：收入、净额和期末为正 = 现金多于计划；支出为正 = 花费多于计划。第29行是累计值——它包含所有更早的周——且只有到它为止的每一周都是 compared 时才存在。第32–35行把总计表达为基准的比例（基准为零时显示 n/a）。
4. 在 Forecast 上重新估计未来。 用最新的信息更新未来2–4周的蓝色单元格（新发出的发票、即将到来的供应商付款、已确认的发薪日期）。为保持完整的13周前瞻，滚动 Forecast 窗口：把它的蓝色输入（包括第2行日期）整体左移一列（旧第2周变成第1周），然后清空 N 列并给它新的第13周日期。结转公式会自动重新锚定；Baseline、Actuals 和 Variance 不受影响。

滚动审查周期（一个刻意的步骤，不是每周都做）​

Baseline 和 Actuals 停留在你捕获时的周期上，直到你决定移动它们——通常是在 Forecast 已经滚动了一个月或一个季度之后，或者计划变化得足够大、你想要一把新尺子时。

1. 归档。 保存工作簿的一个副本（例如 cash-flow-forecast-B1.xlsx）。它把旧基准、其实际数及两者的差异保存在一起；工作文件不保留历史。
2. 清空实际输入。 在 Actuals 上，清空 B–N 列的第3、12–14、17–26和30行，以及 B10。C10:N10、第15行和第27–29行、第31行保持不动——它们是公式。
3. 捕获新基准，从今天的 Forecast 用下一个版本号（B2）和今天的日期，然后完全按上方捕获基准所述对齐 Actuals 的日期和期初余额。

绝不要插入或删除周列。如果你重新捕获了基准却忘记给 Actuals 重新标日期，每个受影响的周都会显示 date mismatch，而不是拿一周去对比另一周的计划。

从 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。
• 内部划转： 支票↔储蓄的划转有两条方向相反的银行腿，所以在这个范围内净额为零，被排除在收入和支出之外。示例的 3,000.00 USD（W1）和 1,500.00 USD（W2）划转，否则会让两边都虚增这些金额。
• 推论： 映射银行腿，而不是收入/费用腿。贷款本金不是费用，但是银行流出（示例的 900.00 USD 自动扣款 = 800 本金 + 100 利息，全部计入偿债）；刷卡消费是费用，但还不是银行流出。

收入/支出拆分。 从导出的银行腿中：正腿是收入，负腿是支出，划转腿排除。类别映射（与供应商映射选项卡相同）：Stripe/PayPal 打款 → 客户回款；新客户电汇 → 新签约/预付款；银行利息/补助 → 其他流入；Gusto/ADP → 工资；AWS/GCP → 云/托管；银行支付的 SaaS → 软件/SaaS；房东 → 房租；律所 → 法律/会计；税务机关 → 税费；贷款自动扣款 → 偿债。

• 处理销售税： 尽管销售税不是收入，它是现金流项目。把销售税的收取当作现金收入，把向政府的缴纳当作支出。收入影响体现在你的权责发生制账簿中，但这里的关注点是现金流动。

支撑 W1 的 Beancount 摘录​

下方每一笔记账也存在于随附的 sample.bean 中。单独保存时，这份摘录能通过 uvx --from beancount bean-check，并在你应用上述银行现金范围后得出表中的 W1 收入（12,200）、支出（9,700）和期末（87,500）（把支票↔储蓄的划转从两边排除；计数 Amex 的结算，而非负债消费）。

option "title" "Cash forecast sample — W1 excerpt"
option "operating_currency" "USD"
 
2026-09-13 open Assets:Bank:Checking USD
2026-09-13 open Assets:Bank:Savings USD
2026-09-13 open Liabilities:CreditCard:Amex USD
2026-09-13 open Liabilities:Loan USD
2026-09-13 open Equity:Opening-Balances USD
2026-09-13 open Income:Sales USD
2026-09-13 open Income:Interest USD
2026-09-13 open Expenses:Contractors USD
2026-09-13 open Expenses:Cloud USD
2026-09-13 open Expenses:Software USD
2026-09-13 open Expenses:Marketing USD
2026-09-13 open Expenses:Rent USD
2026-09-13 open Expenses:Interest USD
 
2026-09-13 * "Opening balances"
  Assets:Bank:Checking            80000.00 USD
  Assets:Bank:Savings              5000.00 USD
  Liabilities:CreditCard:Amex      -600.00 USD
  Liabilities:Loan               -20000.00 USD
  Equity:Opening-Balances        -64400.00 USD
 
2026-09-14 * "Stripe" "Customer receipts W1"
  Assets:Bank:Checking            12000.00 USD
  Income:Sales                   -12000.00 USD
 
2026-09-15 * "Contractor" "Contractors W1"
  Expenses:Contractors              1500.00 USD
  Assets:Bank:Checking             -1500.00 USD
 
2026-09-15 * "AWS" "Cloud hosting W1"
  Expenses:Cloud                    2200.00 USD
  Assets:Bank:Checking             -2200.00 USD
 
2026-09-16 * "Bank" "Checking -> Savings sweep"
  Assets:Bank:Savings               3000.00 USD
  Assets:Bank:Checking             -3000.00 USD
 
2026-09-17 * "SaaS vendor" "Amex SaaS charges"
  Expenses:Software                  250.00 USD
  Liabilities:CreditCard:Amex       -250.00 USD
 
2026-09-17 * "SaaS vendor" "Amex SaaS charges"
  Expenses:Software                  170.00 USD
  Liabilities:CreditCard:Amex       -170.00 USD
 
2026-09-18 * "Amex" "August statement settlement"
  Liabilities:CreditCard:Amex        600.00 USD
  Assets:Bank:Checking              -600.00 USD
 
2026-09-19 * "Landlord" "Rent W1"
  Expenses:Rent                     3500.00 USD
  Assets:Bank:Checking             -3500.00 USD
 
2026-09-19 * "Agency" "Marketing W1"
  Expenses:Marketing                1000.00 USD
  Assets:Bank:Checking             -1000.00 USD
 
2026-09-19 * "Bank" "Interest W1"
  Assets:Bank:Checking               200.00 USD
  Income:Interest                   -200.00 USD
 
2026-09-19 * "Lender" "Loan autopay W1"
  Liabilities:Loan                   800.00 USD
  Expenses:Interest                  100.00 USD
  Assets:Bank:Checking              -900.00 USD

完整演算的一周：W1 从头到尾（2026-09-14 – 2026-09-20）​

期初银行现金是 85,000.00（2026-09-13 的支票 80,000 + 储蓄 5,000）——即 Actuals!B10 中的值。账簿的 W1 银行腿，在排除 3,000.00 的划转对之后，进入 Actuals 表的 B 列；每个未列出的类别都键入 0，第3行设为 complete：

结转到 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——正是工作簿 Actuals（以及重新预测的 Forecast 表）上的 W2 列。账单余额 87,500 和 83,500 位于 Actuals!B30:C30，所以第31行对两周都显示 0：这就是你的映射有效的证明。这几周相对计划的表现如何，是另一个问题，由下方 Variance 回答。

复现它（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天，结算于 2026-09-28。）有一个 BQL 限制要知道：此 beanquery 版本无法按符号过滤记账，所以收入/支出拆分裂应用于导出的行——正银行腿归收入，负银行腿归支出，划转对排除——正如检查器所做的那样。

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

1. 拉取实际数（15分钟）： 导出本周 Assets:Bank:* 的记账（运行上方查询，或从你的银行账户下载交易——刷卡消费排除在外；只有结算付款计数），并键入 Actuals 表。确认 Actuals 上本周的期末现金与你的实际合并银行余额（支票 + 储蓄）完全一致——第31行显示 0。这项对账没有商量余地。
2. 审查应收账款（10分钟）： 列出所有未结发票，把它们放入你预期收款的周。保持保守，基于过往表现应用现实的收款滞后。
3. 审查应付账款与工资（10分钟）： 把所有已知即将到期的账单放入其到期周。为整个季度预填你的发薪日期和金额。把非关键支出安排到周五，以在一周内保留现金的选择权。
4. 差异会议（10分钟）： 打开 Variance 表，逐项走过本周的 compared 列：哪些类别变动了、朝哪个方向、以及这对累计期末现金的影响。记录任何重大差异的原因，并决定是否需要调整你今后的预测规则。

准确性与决策​

准确性经验法则​

• 第1–2周： 目标为 ±5–10% 误差。这些日期和金额应当高度确定。
• 第3–6周： 预期 ±10–20% 误差。这段时期是已知账单和基于模式的估计的混合。
• 第7–13周： 预测的这部分是方向性的。它由你的销售管线和固定费用驱动。

置信度代码： 为了让预测更易读，给每个预测行标注一个置信度代码：已承诺（如工资、房租）、可能（如给优质客户的发票）或 上行（如管线中的新交易）。

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

没有行动的预测毫无用处。预先定义好当你触及某些阈值时该做什么。

• 最低现金下限： 例如，你的规则可能是"我们必须始终保持现金 ≥ 下一个完整发薪金额的1.5倍。"如果预测显示你会跌破这个下限，你立即执行预先商定的计划，比如开展收款冲刺并暂停所有可自由支配的支出。
• 跑道护栏： 例如，"如果第13周的期末现金意味着不足X个月的消耗，我们将启动融资计划。"这可能涉及寻求投资条款清单、为客户提供预付款折扣，或动用信用额度。
• 大额流出规则： 例如，"任何单笔超过当前现金余额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 表上实际的假设单元格——无需额外接线。

学习与避免错误​

差异审查（让学习复利）​

工作簿替你完成差异的记录账：差异 = 实际数 − 基准，按类别和总计，针对每周其 Actuals 为 complete 且日期与 Baseline 相同的周。你的工作是解释这些数字。审查时，给重大差异的原因打标签：收款延迟、范围滑移、计划外供应商采购、时点偏移。如果同一类型的差异反复出现，改变你模型的底层规则。例如，如果回款持续晚一周，就把你的默认收款滞后假设从21天改为28天。

完整对比（随附示例）。 基准 B1 于 2026-09-11 从 85,000 的期初捕获；实际数是示例账簿的银行现金。符号遵循 Variance 表：收入、净额和期末为正 = 现金多于计划，支出为正 = 花费多于计划。

按 Variance 表的呈现方式来解读：

• W1, +500。 客户回款比计划的 11,800 高 200（Variance!B12 = +200），AWS 计费 2,200 而计划 2,500（Variance!B19 = −300：花费更少，有利）。85,000 + 12,200 − 9,700 = 87,500 实际，对比 85,000 + 12,000 − 10,000 = 87,000 计划。
• W2, +300。 收入恰好落在计划上，但银行支付的 SaaS 账单是 600 而计划 400（Variance!C20 = +200：花费更多，不利）。本周净额为 −200，所以累计期末领先从 +500 缩小到 +300（Variance!C29）：87,500 + 13,200 − 17,200 = 83,500，对比 87,000 + 13,200 − 17,000 = 83,200。
• W3 及以后，not observed。 什么都没录入，所以每个单元格都显示 n/a——不是一个让人安心的 0。
• 以百分比计（第32–33行）：W1 收入 +1.67%、支出 −3.00%；W2 收入 0.00%、支出 +1.18%。

由此得出两个标签：AWS 估计偏高，银行支付的 SaaS 行计划低了 200。两者都是对 Forecast 假设的修正——基准 B1 保持原样，这样下个季度你仍能看到原始计划偏了多远。

常见陷阱（避免这些）​

• 覆盖计划： 把实际数键入 Forecast 单元格（或每周重新粘贴 Baseline）会毁掉你本应被对照衡量的计划。实际数去 Actuals；基准只在你刻意滚动周期时才改变。
• 混淆权责发生制与现金： 这个预测只针对现金。已确认收入、折旧和其他权责发生制概念属于你的主账簿，不属于这里。
• 忘记不规律的年度性支出： 年度保险费、大额 SaaS 续费、季度税款可能成为巨大的意外。一旦你得知它们，就安排进你的预测。
• 忽视销售税现金： 即使它是一笔过渡性负债，在你缴纳之前现金就在你的银行账户里。把流入和流出都建模。
• 不对账： 如果 Actuals 上本周的期末现金与你的实际合并银行余额（支票 + 储蓄；信用卡余额排除）不符，你就有一个映射错误——通常是计入了刷卡消费或保留了划转。在你能信任预测之前，必须修复它。
• 没有明确的负责人： 指定一个人负责每周更新预测。为休假指定一名副手。

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 的期末现金数字，外加一份本季度预期前5大流入和流出的项目符号清单。
3. 备注： 几条关于自上次更新以来已变化的关键假设、以及你已经触及或预期会触及的任何触发器的项目符号。