上周二，你的状态页面红了四个小时。到周五，你已经向每一位受影响的客户发放了服务补偿——这里是一个月费用的 10%，那里是 25%——而你的记账员按照大多数小型 SaaS 公司的做法把它们记了下来：记作一项支持成本，或一项营销让步，落在收入线以下的某个地方。你这个月的收入现在被高估了，你的净收入留存率算错了，而如果贷款方或收购方有一天翻开你的账本，第一个问题就会是你答不上来的那个：你报告的收入里，有多少是你本来真正有权留下的？
这不是个例。现在一次宕机的平均恢复时间是 196 分钟，而中小型企业把一小时的停机成本估算在 8,000 美元左右——这还是在发放任何一笔补偿之前。宕机后你给出的每一笔补偿，都是对客户同意支付的价格的削减，而在 ASC 606 下，这使它成为可变对价：一个会缩减你收入的金额，而不是躺在收入下面的费用。本文解释你的 SLA 在财务上让你承担了什么、准则希望你如何记录它，以及在下次月末结账时该修正什么。
你的 SLA 实际承诺了什么——用美元衡量，而不是几个九
大多数 SaaS 合同用"几个九"来标示正常运行时间：99.9%（每月约 43 分钟宕机）、99.95%、99.99%（约 4 分钟）。对你的账本真正重要的数字不是那几个九，而是附着其上的补偿表。一份典型的企业 SLA 大概是这样写的：正常运行时间低于 99.9% 可获得 10% 的服务补偿；低于 99.0% 为 25%；低于 95.0% 则整月免费。有些合同还会进一步升级，如果正常运行时间连续几个月未达标，就赋予终止权。
这张补偿表有三个特征会塑造会计处理：
补偿是合同约定的价格调整，不是善意姿态。 客户不是付了全价之后收到一份礼物。合同说的是，糟糕月份的价格就是一个更低的价格。价格削减与费用之间的这一区别，就是整个会计问题的核心，而合同在你的记账员打开账本之前就已经给出了答案。
补偿通常有上限，且需要申领，并非自动生效。 许多 SLA 要求客户在 30 天内提出补偿申请，并将补偿总额上限设为一个月份费用的 30% 到 100%。这意味着你在任何一次宕机上的敞口都是有限的、可估算的：你知道补偿表、你知道哪些客户受影响，你也知道你的历史申领率。
现金时点与收入时点并不一致。 针对一月宕机而在二月发放的补偿，通常表现为对某张未来发票的贷项通知单。现金影响落在发票被支付的时候，但收入影响属于一月——你未能兑现承诺的那个期间。在发放补偿的那个月记录它、冲减那个月的收入，会同时错报两个期间。
为什么 ASC 606 把宕机补偿称为可变对价
ASC 606 的核心思想很简单：以你预期有权获得的、作为交付你所承诺之物的交换的对价金额来确认收入。五步模型中的第三步——确定交易价格——正是你的 SLA 登场的地方。交易价格不是订单上的标价。它是标价减去所有可能被退回的部分：退款、返利、折扣、绩效奖金——以及因未达正常运行时间而产生的服务补偿。
普华永道的收入指南将 SLA 补偿明确归入这一类。可变对价必须在合同开始时估计，并在每个报告期更新，使用以下两种方法之一：
- 期望值——各种可能结果按概率加权的平均值。这很适合客户组合：如果历史数据显示每月计费额的 3% 通常以 SLA 补偿的形式退回，那么你每月 100,000 美元计费额的预期补偿就是 3,000 美元。
- 最可能金额——单一最可能的结果。这适合二元情形：一个大客户，其合同要么本月触发 20,000 美元补偿，要么什么都不触发。
然后是约束，这是创始人最常跳过的一部分。你只有在很可能不会发生重大收入反转时，才能将可变对价计入交易价格——也就是确认收入。直白地说：如果你真有把补偿退回去的可能，就不要把那部分当作收入。把它记为退款负债，等当月正常运行时间确定后再调整。注意这个约束对有显著宕机历史的 SaaS 企业意味着什么。如果你的服务在过去十二个月里有四个月未达 SLA，"我们预计什么都不欠"就不是一个站得住脚的估计。你自己的状态页面就是审计师的证据 A。
会计分录：一个有宕机的月份
假设一个客户每月支付 10,000 美元，而你的 99.9% SLA 规定，任何正常运行时间低于目标的月份都可获得 10% 的补偿。一月的正常运行时间是 99.4%。以下是完整周期。
开票时，计费金额照常记入递延收入——为尚未交付的服务收取的现金（或记录的应收款）：
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Receivable:Customer USD
2026-01-01 open Income:SaaS:Subscription USD
2026-01-01 open Liabilities:Deferred-Revenue:SaaS USD
2026-01-01 open Liabilities:Refund:SLA-Credits USD
2026-01-01 * "Customer" "January invoice — 10,000 monthly subscription"
Assets:Receivable:Customer 10000.00 USD
Liabilities:Deferred-Revenue:SaaS -10000.00 USD
2026-01-31 * "Month-end" "Recognize January revenue net of 500 expected SLA credits"
Liabilities:Deferred-Revenue:SaaS 10000.00 USD
Liabilities:Refund:SLA-Credits -500.00 USD
Income:SaaS:Subscription -9500.00 USD
2026-02-05 * "Customer" "Outage credit issued — January uptime 99.4 percent vs 99.9 SLA"
Liabilities:Refund:SLA-Credits 500.00 USD
Assets:Receivable:Customer -500.00 USD走一遍发生了什么。月末，你确认了 9,500 美元的收入，并把 500 美元放进退款负债——这是你对一月宕机将触发的补偿的估计。当实际的贷项通知单在二月发出时，它借记该负债，而不是收入，也不是费用科目。一月的收入第一次就是对的，而二月的收入不受一月宕机的影响。
如果估计与实际不符，差额在不确定性解除的那个期间调整收入。估计 500 美元但实际发放 1,000 美元，因为两个客户申领而不是一个？多出的 500 美元在你得知时减少收入。估计 500 美元而无人申领？将 500 美元释放回收入。负债科目是减震器；收入从不会因常规的调整而重述。
两个值得做对的细节。第一，退款负债与递延收入是分开的：递延收入针对你尚未交付的服务，而退款负债针对已交付但你可能要退还的服务。把它们相互抵销会掩盖两个事实。第二，如果补偿与未来期间相关——比如作为道歉而给予的免费月份，而不是针对过去失败的合同补偿——那是另一种分析，更接近于合同修改或重大权利，它调整的是未来收入，而不是过去。
SaaS 创始人在 SLA 补偿上犯的三个错误
错误 1：把补偿记为费用。 这是最常见的错误，也是危害最大的。把 10,000 美元的宕机补偿借记到"客户支持费用"或"营销让步"，会让收入高估 10,000 美元，并凭空制造出 10,000 美元从未发生的费用。毛利率、收入增长，以及一切以收入为基础的比率都会显得过高。在 ASC 606 下，应付给客户、且并非为换取一项可明确区分的商品或服务而支付的款项，会减少交易价格。为你自己的宕机而给的补偿没有换来任何可明确区分的东西——它减少收入，就是这样。
错误 2：现在确认全额收入，以后再修正。 有些公司把完整的 10,000 美元记为一月收入，然后当贷项通知单发出时把 1,000 美元补偿冲减二月收入。两个月现在都错了：一月过高，二月过低。更糟的是，这个错误会在你的指标中不断累积——一月的净收入留存率看起来很漂亮，二月看起来很疲软，而两者都不反映现实。上面那种退款负债模式的存在，正是为了让每个期间都保持诚实。
错误 3：因为宕机"不会再发生"而估计为零。 约束依据的是概率，而不是乐观情绪。如果你的基础设施去年有三个触发 SLA 的月份，那么预期补偿为零的估计既不是保守也不是激进——它是没有依据的。审计师会用你的事故事件历史来检验这个估计，收购方在尽职调查中也会这么做。一项根据历史申领率确定规模、每月调整的少量常备准备金，既更准确，也远比一个被你的状态页面反驳的自信的零更容易辩护。
这对买家和贷款方阅读的指标意味着什么
把 SLA 补偿放在收入线之上还是之下，会改变 SaaS 公司被估值时所依据的每一个数字：
- MRR 和 ARR 应当扣除预期补偿。如果历史上计费额的 2% 以 SLA 补偿的形式退回，那么 100 万美元的 ARR 头条数字实际上只是 980,000 美元的预期收入。报告毛数字，正是创始人在尽职调查中最终要解释一个"流失问题"的根源，而它其实一直都是补偿问题。
- 净收入留存率 把补偿吸收为收缩。一个去年支付 120,000 美元、今年在宕机补偿后支付 114,000 美元的客户，留存率是 95%，而不是 100%——即使他们从未减少一个席位。
- 毛利率 在你修正错误后反而会上升，这看似矛盾。把补偿从支持费用移到收入抵减项，会同时缩小收入和收入成本，而由于补偿超过任何相关成本，毛利率百分比会上升，同时收入下降。预料到这个提问，并准备好重述后的历史数据。
如果你使用纯文本会计，修正方法是结构性的，而非流程性的：一个专门的 Liabilities:Refund:SLA-Credits 科目、一笔月末分录，用于确认扣除预期补偿后的订阅收入，以及当贷项通知单发出时的一笔调整分录。beancount 关于收入确认模式的文档 涵盖了本文所基于的递延收入会计的一般形态，而退款科目的资产负债表历史，同时充当你对该估计的审计线索。
只需二十分钟的月末清单
- 按客户层级提取正常运行时间。 你的监控已经在计算这个；要求提供针对每个 SLA 阈值的月度数字，而不仅仅是整体平均。
- 列出触发的补偿。 对每个低于阈值的客户，按补偿表计算合同补偿——在检查谁真正申领之前。
- 套用你的申领率历史。 如果历史上约 60% 的触发补偿被申领，你的期望值就是触发总额的 60%。记录这个比率，并每季度重新审视。
- 按扣除估计后的净额确认收入。 确认订阅收入，同时把预期补偿留在退款负债中，如上例所示。
- 调整上个月的估计。 将上个月准备金的实际贷项通知单进行比较；通过当期收入释放或补足差额。
- 调节负债余额。 退款科目应只保留未解决的估计。任何超过你申领窗口（通常 30 到 60 天）的金额都本应已被释放——不断增长的陈旧余额意味着调整被跳过了。
这个月就开始，不要等到下个季度。拉出上个月正常运行时间报告，算出你的 SLA 补偿表说你欠的补偿，并把那个数字与你的账本显示的收入扣减额对比。如果账本显示为零——对大多数早期 SaaS 公司来说，它们确实显示为零——那么你就找到了你的第一笔调整分录，而你的收入每个月都以恰好那个数字被高估着。
