2022年，如果你问一位SaaS创始人他们本月将实现多少收入，答案会是一个电子表格公式：席位数量乘以价格，并根据合同剩余天数按比例分摊。今天，如果你问一位AI原生创始人同样的问题，诚实的答案是“这取决于我们的客户使用了多少模型”。当客户将某个功能投入生产时，令牌消耗量可能在一周内翻倍；而当他们暂停一项实验时，消耗量可能会持平。没有固定的席位数量作为预测的基础。
这种从订阅模式到消耗模式的转变不仅仅是定价决策。这是一个会计问题，并且完全落在了ASC 606的范畴内——这是自2018年以来一直规范SaaS的相同收入确认准则，只是应用于一个不那么可预测的输入。如果处理不当，你面临的不是一个四舍五入的误差；而是在尽职调查期间，当最不容许犯错时，需要重述一整年的财务报表。
为什么基于令牌的定价模式打破了旧的规则
传统的SaaS收入确认相对宽松。客户为年度计划支付12,000美元，你每月确认1,000美元，最大的判断是合同修改是否需要重新分配。对价是固定的。履约义务——随时间提供软件访问——是直接明了的。审计师已经见过成千上万份类似的合同。
AI和基于使用量的定价模式消除了固定的部分。客户根据处理的令牌数量、进行的API调用、完成的推理运行或消耗的计算秒数付费。这种对价在设计上是可变的，ASC 606专门用一整个章节——ASC 606-10-32-11至32-13中的“可变对价”指南——来解决这个问题。核心挑战不是哲学上的，而是实际操作上的：当你结账时，你真正不知道客户最终会欠多少钱，那么在一个期间内你应该确认多少收入？
对于一家早期AI公司来说，这在变得容易之前会变得更难。一个成熟的SaaS企业可以依靠多年的使用历史来自信地估计消耗量。而一个八个月前才推出基于令牌的定价模型的公司，则没有这样的可比数据。随着客户从试点转向生产，使用量可能会大幅波动，上季度的模式可能对本季度的情况说明甚少。
决定一切的两种合同形式
在你正确确认哪怕一美元的基于使用量的收入之前，你需要知道你实际属于哪种结构——因为它们的会计处理方式不同。
纯消耗，无承诺最低消费。 客户购买一池信用点或同意按单位消耗付费，没有最低限制。如果该安排是一项直接的服务（你提供对托管模型的访问，而不是许可客户独立利用的知识产权），你通常不能使用ASC 606-10-55-65中狭义的“基于IP使用量的特许权使用费”例外——该例外是为专利特许权使用费等许可安排而设，而非托管API。相反，你应使用预期价值法或最可能金额法估计可变对价，但须受制于一项约束，即一旦不确定性消除，你不应确认可能导致“重大冲回”的金额。
承诺最低消费加超额部分。 客户承诺每月最低使用量为2,000美元，如果超出则支付更多。在这种情况下，最低消费部分类似于固定对价——在客户收到价值时按系统性基础确认——而任何超出最低消费的部分都是可变对价，需遵循相同的估计和约束规则。这种混合模式在AI定价中屡见不鲜：基础平台费加上按量计费的推理服务。
了解你属于哪种形式会改变你的日记账分录、披露附注以及你的审计师对你的估算应抱有的谨慎程度。
大多数AI公司实际使用的实用性权宜方法
好消息是：ASC 606为这种情况内置了一个捷径，并且大多数结构良好的基于使用量的合同都符合其条件。
“开票权”实用性权宜方法（ASC 606-10-55-18）允许你完全跳过估计合同总对价。如果你在每个期间开具的发票金额直接对应于客户在该期间收到的价值——例如，你每1,000个令牌收费0.002美元，客户使用了400万个令牌，你开具8美元的账单——你就可以简单地将这8美元确认为该期间赚取的收入。无需预测，无需约束分析，也无需在每次结账时重新估算。
关键在于“直接对应”这个短语。如果你的定价存在分级，即单位费率随使用量增加而下降，或者捆绑折扣无法清晰地对应到使用发生的期间，那么这种权宜方法就可能失效——开票金额不再代表该期间的价值，你将不得不回到完整的可变对价估算。在假设该权宜方法统一适用于所有合同之前，请特别注意用此标准审查你的定价结构。
大多数基于消耗的AI合同也符合ASC 606-10-25-14下的系列处理条件：你不需要将每个API调用作为其自身的微型履约义务进行核算，而是将整个使用流视为一个随时间满足的单一履约义务。这就是使开票权宜方法在管理上可行之处——你无需追踪成千上万个单独的义务，你只需追踪一项具有可变价格标签的持续服务。
预付积分：递延收入与损耗问题
许多AI平台销售预付积分包——预付500美元购买代币，并在接下来的几个月内使用。这种结构很受欢迎，因为它能改善现金流并锁定客户承诺，但它引入了创始人常忽略的两个会计义务。
**未使用余额的递延收入。**预付包款项到账的那一刻，它还不是收入。这是一项负债——你欠客户服务或退款。收入只有在代币实际消耗时才从递延收入项转移到利润表。创始人如果在收款当天将全部500美元入账，则属于虚报收入，并需要冲销，通常是在最糟糕的时机：融资尽职调查期间，审计师会重新编制计划，并将差额从已向投资者推销的期间中剔除。
**永不使用的积分损耗。**有些客户购买了积分包，但在到期前从未全部用完。那些未使用的余额——损耗——并非简单地是你在积分到期当天确认的免费资金。根据ASC 606，你需要根据历史兑换模式估算损耗率，并按比例确认估计的损耗，作为实际使用收入的一小部分提升，而不是等到到期时一次性入账。如果你还没有兑换历史（对于新的积分计划很常见），保守的做法是等待获得历史数据，在此期间只在到期时确认损耗，并在获得几批数据后重新审视该政策。
约束原则真正重要的场合
对可变对价的“约束”听起来很抽象，直到你经历一个季度，某个大客户的使用量飙升4倍后又恢复原状。ASC 606要求你仅在极有可能不会在以后需要重大冲回的情况下，才将可变对价纳入收入估算。实际上，这意味着：
- 新定价模型的第一年： 倾向于保守。确认承诺的最低金额和实际使用量时要自信；对于超出已开票/实际使用量的任何预测，则要持真正怀疑的态度，因为你没有可供参照的同类合同。
- 随着使用历史的积累： 你的约束可以放宽，因为你现在有了更可靠的依据（该客户的使用量在连续六个月内都在X和Y之间波动），可以进行更准确的估算。
- 在每次结算时： 重新估算。可变对价不是一个“一劳永逸”的数字——它会在每个报告期随着新信息的到来而重新审视，累计追溯调整会通过当前期间进行。
对于管理数百或数千份合同的财务团队来说，操作上的解决方案是在结算前而不是结算后，就将你的计费系统和收入确认账本对齐——这样使用数据可以自动核对，而不是每个月末都需要手动审计追踪。
即使规模很小，这也很重要
如果你是一个两人AI工具初创公司，只向少数客户按代币计费，很容易将这一切视为“等到A轮融资时再处理的事情”。这是一个真正的风险。收入确认错误是SaaS融资尽职调查中最常见的发现之一，而基于使用量的定价会使审计师希望看到记录的判断点数量倍增：哪些合同使用了开票权宜之计，你假设的损耗率是多少以及原因，以及你如何处理客户使用量激增的那个季度。
从第一天起就做好机制——即使规模很小——意味着你以后不会在截止日期压力下重建18个月的收入历史。这也意味着你内部用于制定定价和招聘决策的数字是准确的，而不是被不该存在的未确认递延收入所夸大。
让你的账目像你的定价模型一样清晰
基于使用量和代币的定价在会计处理上确实比固定月度订阅更复杂，但这种复杂性是可审计的——它只需要你在过程中记录你的合同结构、约束依据和损耗假设，而不是事后再补。Beancount.io的纯文本记账使这种文档追踪变得清晰：每一笔收入确认分录、递延收入余额和损耗调整都存在于版本控制的文本中，你（或你的审计师）可以逐行追踪，而不是埋藏在黑箱计费平台中。免费开始使用，让你的账本和你在其上构建的定价模型一样透明。