你在三月签下了五份年度合同，60,000 美元进了你的 Stripe 账户。你的仪表盘闪闪发光，你的银行余额看起来威风凛凛——而你的会计刚刚告诉你，三月的收入是 5,000 美元。谁都没错。你看到的是两个不同的数字，它们恰好住在同一个 Stripe 账户里：你收到的现金，和你实际赚到的收入。在你把这两者对上之前，Stripe 发给你的每一笔提现都是你的账本必须解开的一道谜题。
本指南展示的是：那些按年收款但按月确认收入的 SaaS 公司，如何对账 Stripe 提现，而不重复计算收入、不错误列报递延收入、也不被那个掩盖了整个缺口的指标所欺骗。
为什么 Stripe 提现是收入的错误起点
Stripe 提现看起来像收入。它以一笔单独的存款进入你的银行账户，上面有日期，感觉就像这个月的盈利。它这些都不是。提现是一种净额结算：毛收款减去手续费，减去退款，减去争议扣款，按 Stripe 的提现时间表（而不是你的）打包在一起。
如果你把提现记为收入，这会造成两种不同的扭曲。
第一，你少报了收入。如果客户为一个年度套餐付了 12,000 美元，Stripe 会留下大约 348 美元加 30 美分，然后付给你剩下的。把提现入账就把净额记成了你的销售额，并把手续费埋在你永远无法分析——也无法干净地抵扣——的地方。
第二，对按年收款来说危险得多，你错误列报了时间。整整 12,000 美元在一月的一笔提现里到账，但在权责发生制会计下，你在提供服务的过程中按月赚取它，每月 1,000 美元。把提现记成一月收入，一月看起来辉煌灿烂，而二月到十二月看起来死气沉沉，即便这个业务每个月做的事完全一样。
解决办法是把提现当作它本来的样子——一笔现金转账——并在一条完全独立的轨道上确认收入，这条轨道由你的合同驱动，而不是你的存款。
创始人混淆的三个数字：签约额、开票额与收入
每一笔按年收款的对账都始于把三个数字分开：
- 签约额（Bookings） 是已签合同的总价值。客户在一月签下一份 12,000 美元的年度合同：一月的签约额就是 12,000 美元。签约额是一种承诺，既不是现金，也不是盈利。
- 开票额（Billings） 是你开票并收取的金额。如果合同按年预付开票，一月开票额就是 12,000 美元。如果按月开票，一月开票额就是 1,000 美元，即便签约额是 12,000 美元。
- 收入（Revenue） 是你通过提供服务已经赚到的。一份十二个月合同的一个月赚取十二分之一：无论哪种情况，一月的收入都是 1,000 美元。
开票额与收入之间的楔子就是递延收入（也叫未实现收入），这是你资产负债表上的一项负债，代表你还欠着尚未提供的服务。一月收取 12,000 美元并确认 1,000 美元，你就带着 11,000 美元的递延收入进入二月。这项负债不是问题——它是你的账本诚实的证明。它每月释放 1,000 美元，直到合同结束。
简单说：签约额告诉你销售做得怎么样，开票额告诉你现金做得怎么样，而收入告诉你业务实际表现如何。一旦你让其中一个冒充另一个，对账就崩了。
构建驱动按月确认收入的递延收入明细表
递延收入明细表是整个过程的核心引擎。它是一张简单的逐合同表格——客户、合同开始日期、期限长度、合同总价值、每月确认金额、迄今已确认收入、剩余递延余额——它是唯一应该触发收入分录的文件。
对于一份从 1 月 1 日开始的 12,000 美元年度套餐，分录长这样：
收款时（一月）：
借 Stripe 清算账户 $12,000
贷 递延收入 $12,000
每月，一月–十二月：
借 递延收入 $1,000
贷 订阅收入 $1,000注意缺了什么：提现在收入分录里根本不出现。现金收款贷记递延收入，一项负债。收入在之后诞生，一次一个月，来自明细表。
有两条纪律决定明细表的成败。第一，每一份新的年度合同、续约和扩展，都必须在其开始的当月进入明细表——一份漏记的合同就是永远无法确认的收入。第二，每月把明细表与总账对账：期初递延余额，加新增开票，减已确认收入，必须等于期末递延余额。如果对不上，就是有东西绕过了明细表——通常是退款、周期中途的变更，或者有人把一笔提现直接记成了收入。
用清算账户对账提现本身
明细表负责收入的时间安排，而你还得处理流经 Stripe 的钱。干净的方法是设一个 Stripe 清算账户——一个资产账户，代表“坐在 Stripe 里的现金”。
每一笔 Stripe 事件都按毛额过入清算账户：
向客户收款 $1,000：
借 Stripe 清算账户 $1,000
贷 递延收入 $1,000
这笔收款上 Stripe 手续费 $29.30：
借 手续费 $29.30
贷 Stripe 清算账户 $29.30
$970.70 的提现进入你的银行：
借 银行活期账户 $970.70
贷 Stripe 清算账户 $970.70退款和争议扣款以相同方式过账，方向相反。当提现划转结清时，该笔提现所涉项目的清算账户净额归零——这正是它成为对账工具、而不只是一种记账惯例的原因。任何非零的残留都意味着有手续费、退款或调整没被记录。
要把每笔提现与其内容挂上钩，用 Stripe 的提现对账报告，它逐项列出某笔提现里的每一笔收款、退款、手续费和调整，并核实毛额减手续费减退款等于银行存款。要逐笔提现地做，而不是逐月地做：提现经常跨月，逐月打包正是“银行永远对不上 Stripe”这类谜团的来源。如果你的量很小，用清算账户按每周节奏做，能在小额差异还容易追溯时就抓住它们。
调整：那些破坏明细表的周期中途变更
年度合同很少十二个月一动不动，每一次变更都需要一笔针对递延明细表的调整分录：
- 升级和席位扩展会增加剩余递延余额。一个客户在还剩六个月时从每年 12,000 美元升级到 18,000 美元，会在未确认余额之上大约增加 3,000 美元的新递延收入（六个月乘以每月多出的 500 美元）。
- 降级会缩减它。在还剩六个月时降低套餐，你要把差额移出递延收入——通常作为未来发票的抵免，而不是现金退款，但即便没有钱流动，它仍需要一笔分录。
- 按比例折算（Prorations） 是机制所在：Stripe 用未使用时间的抵免来处理订阅变更，这些抵免精确告诉你该在旧套餐和新套餐之间转移多少递延收入。
- 取消并退还预付时间的款项减少递延收入，绝不减少当月的收入。退还一份 12,000 美元套餐里未使用的六个月，是借记递延收入 6,000 美元——把它记到本月收入上会少报一个本身毫无过错月份。
- 年度续约上的失败付款要从反方向留意：没有收到现金就意味着没有新的递延余额，所以明细表绝不能对一个已停止有资金支撑的合同继续确认收入。
实用规则：Stripe 里没有任何一项订阅变更可以不在同月匹配一次明细表更新。让两者漂移的团队，每个季末都要靠发票 PDF 重建发生了什么。
那个掩盖一切指标的 SaaS 指标：仪表盘 MRR 不是收入
整个安排掩盖的陷阱在这里。你的 Stripe 仪表盘显示 MRR 漂亮地攀升——年度套餐转换成月度等值，升级立即增加扩展 MRR，图表向右上方倾斜。创始人很自然地开始把那个数字当成“我们每月赚的钱”。
它不是。MRR 是一个标准化运行率指标：如果什么都不变，活跃订阅的月度价值。已确认收入是你在权责发生制会计下这个月实际赚到的。它们持续背离——本月收取的年度预付款几乎不是本月的收入，一次月中升级带来的扩展 MRR 只有半个月的盈利，而仪表盘上的任何数字都不知道你的递延明细表、你的退款或你的调整。
这种背离在你被它咬到之前是看不见的。应税所得跟随已确认收入，而不是 MRR，所以一个签约额巨大的季度可能产生一笔让盯着仪表盘的创始人措手不及的税单。而收购方和贷款方尽调的是 GAAP 收入，不是 MRR——每一美元其实是未确认开票额的“收入”，都会在估值对话中被调整出去。
两个数字都留着，但绝不要让一个干另一个的活。一个有用的每月健康检查：当月的已确认收入，加上你递延余额的变动，应该能对上开票额。如果 MRR 说你增长了而那个等式说不是，相信等式。
你的 Stripe SaaS 每月结账清单
每月跑一遍这个清单，各个部分就能保持环环相扣：
- 把提现与银行对上。 导出提现对账数据，确认毛额减手续费减退款等于每一笔存款，并通过清算账户过账划转。
- 按每笔提现将清算账户归零。 任何残留余额都是一笔未记录的手续费、退款、争议或调整——在月末之前找到它。
- 滚动递延明细表。 加入新合同和续约，过账当月确认分录，并确认期初余额加开票额减已确认收入等于期末余额。
- 调整周期中途变更。 把 Stripe 里的每一次升级、降级、按比例折算、取消和退款，匹配到一次明细表调整。
- 把 MRR 与已确认收入对账。 解释仪表盘运行率与已赚收入之间的缺口；对任何你无法用一句话解释的东西都要追查。
- 单独审阅手续费和退款。 毛收入、手续费和退款各自讲述自己的故事——把它们轧差就掩盖了全部三个。
坚持这么做，月末就从一场法证式挖掘变成例行公事：提现这一侧证明你的现金是完整的，明细表这一侧证明你的收入是赚来的。
让你的 SaaS 收入随时经得起投资人审视
随着你按年收款的规模扩大，每月把已确认收入、递延余额和 Stripe 现金绑在一起，正是让你的数字对会计、税务机关和未来收购方可信的原因。Beancount.io 提供纯文本会计，让你对自己的财务数据拥有完全的透明度和控制权——没有黑箱，没有供应商锁定。免费开始使用，看看为什么开发者和财务专业人士正在转向纯文本会计。
