跳转到主要内容

基于结果的Agentic AI SaaS定价:当客户按成功结果付费时如何确认收入

发布日期 阅读需 1 分钟Mike ThriftMike Thrift
基于结果的Agentic AI SaaS定价:当客户按成功结果付费时如何确认收入

你的AI智能体一个月可以完成10,000次尝试,但如果只有7,200次达到客户对成功的定义,那么根据合同你仍然没有赚到任何收入。这就是基于结果的定价背后的会计张力:模型可能持续忙碌,但你卖出的承诺可能以完成的结果来衡量。

随着agentic软件从回答问题转向处理退款、处理发票、防止欺诈以及完成其他工作流程,越来越多的SaaS合同将费用与系统实现的结果挂钩。这种商业模式可以使价格与客户价值保持一致,但也可能使收入确认、账单对账和预测变得困难得多。

ASC 606下的关键问题不仅仅是“智能体运行了多少次?”而是“合同向客户承诺了什么,该承诺何时转移?”

从承诺开始,而非计量方式

结果定价可以描述多种不同的安排。两份合同可能都按成功交易收费,但需要不同的会计结论。

随时履约承诺

在随时履约安排中,供应商承诺在整个期间内提供AI服务。客户因在需要时具备该能力而受益,无论是否收到大量请求。按月平台费、无限访问或主要由客户最终用户驱动的使用量通常指向这个方向。

核心服务的收入通常随时间确认,当服务在整个期限内均匀提供时,使用基于时间的进度衡量方法。按结果的费用可能仍是可变对价,但这并不意味着只在现金开票时才确认。

指定数量的结果

在消费型安排中,承诺更接近于“交付25,000个已完成的结果”。每个合格的结果都会减少客户剩余的权益。一旦交付了所购数量,客户就需要做出新的购买决策以获取更多容量。

这种结构可以支持产出法:随着供应商转移每个成功结果,确认分配给该结果的收入。当合同规定客户不会从未成功尝试中获得任何已完成服务时,这些尝试不会消耗客户已购的权益。

混合承诺

许多实际合同结合了两种模式。客户可能为托管的平台支付固定的月访问费,并另行支付每笔已验证的重复发票预防费用。访问费和结果费不应仅仅因为它们出现在同一张发票上就被迫采用单一的确认模式。

固定访问承诺可以在服务期内确认收入。如果合同支持该结论并且可变对价可以分配到相关期间或结果,则结果费可以在满足成功标准时确认。

PwC在其SaaS指南中描述了同样的实际区别:订阅模式通常提供持续访问,而消费模式则执行定义的任务或交付特定产出以换取费用。定价方案中的标签并非决定性因素。已执行合同中的权利、义务和客户利益才是。

ASC 606决策树

对每份重要合同使用以下顺序。记录结论,而不是依赖计费系统的默认收入表。

1. 定义成功结果

“成功”需要足够客观,使双方都能确定供应商何时赚取了费用。对于发票处理智能体,合同可能要求满足以下所有条件:

  • 收到发票并匹配到正确的采购订单。
  • 所需的控制措施完成且无需人工升级。
  • 会计分录已过账到客户指定的系统。
  • 该交易在定义的审查窗口期内未被冲销。

如果成功取决于诸如“满意自动化”之类的模糊表述,则供应商可能没有可靠的基础来记录结果费。先写出测试,再写会计分录。

2. 识别客户获得的内容

询问客户获得的是:

  • 在指定期限内对智能体的持续访问;
  • 有限数量的已完成结果;
  • 使用平台的增量权利;或
  • 访问、实施、支持和结果的捆绑。

这是履约义务的问题。同一个智能体在一份合同中可以是随时履约服务,在另一份合同中可以是指定产出服务,因为承诺和客户权利不同。

3. 确定安排是否为系列

随时履约的SaaS服务通常被评估为一系列实质上相同且具有相同转移模式的不同的每日或每月服务。如果结果费特别与系列中的某个明确期间相关,则可变对价分配例外可能允许在该期间内确认收入,即在该期间内发生合格结果时。

例如,一项服务可以提供12个月的无限制访问,并在每次成功欺诈干预发生的月份收取$3。如果费率固定,成功定义可衡量,且费用与该月的服务相关,则在合格干预发生时确认结果费可能真实反映转移。

当费用取决于累计年度绩效、追溯折扣、跨期调整或年度最低限额时,结论就不那么直接了。这些特征可能阻止费用归属于某个明确的单一服务期间。

4. 测试发票实务简便方法

发票实务简便方法可以允许按供应商有权开票的金额确认收入,前提是该金额与截至当日转移给客户的价值直接对应。对于符合条件的随时履约安排,按每次结果发生时收取的固定金额可能满足该模式。

不要将简便方法视为每份基于使用量的合同的捷径。当合同包含固定费用、实质性最低限额、变化的结果费率或重大的前期或后期费用时,该方法不太可能适用。大额预付款也可能与开票日转移的价值不对应。

5. 应用可变对价限制

当发票简便方法和分配例外都无法解决问题时,估计可变对价并仅包含可能不会发生重大收入冲销的金额。每期更新该估计。

早期AI产品通常缺乏足够的历史数据来自信地预测成功率、异常率、客户接受度和冲销。这种不确定性是会计事实,而不是确认乐观情况的理由。从当前合同数据、类似工作流程、试点结果和已知失败模式中建立有记录的估计,然后在产品运营过程中重新审视。

实例:固定访问加已验证结果

假设供应商签署一份12个月的协议,条款如下:

  • 每月$10,000的平台费,用于托管访问、监控和支持。
  • 每笔发票$12,前提是智能体端到端处理、正确过账并通过30天冲销检查。
  • 无最低发票数量。
  • 每月账单基于已验证的结果日志。

平台费描述了随时履约服务。如果客户在一年中均匀获得访问,且没有其他事实改变结论,则供应商每月确认$10,000收入。

12金额是基于结果的可变对价。如果合同成功标准清晰,费率固定,且金额特别与该月的服务相关,则供应商可以在每个合格结果完成时确认12金额是基于结果的可变对价。如果合同成功标准清晰,费率固定,且金额特别与该月的服务相关,则供应商可以在每个合格结果完成时确认12。仍处于30天审查窗口内的结果可能需要政策决策:合同可以定义为过账时成功、验收时成功,还是仅在冲销窗口关闭后成功。一致使用合同事件。

如果3月有800个结果合格,则结果收入为9,600。因此,在考虑税费、退款、积分或其他合同条款之前,3月的收入为9,600。因此,在考虑税费、退款、积分或其他合同条款之前,3月的收入为19,600。银行存款可能在4月发生;现金时间不会将3月收入移至4月。

对于预付的有限结果合同,初始分录会有所不同。如果客户为10,000个成功结果预付120,000,则在收到付款时记录现金和合同负债。每个合格结果转移时确认120,000,则在收到付款时记录现金和合同负债。每个合格结果转移时确认12收入,并减少负债。如果未使用的结果到期,则根据合同和适用的收入政策评估破损,而不是仅仅因为期限结束就释放全部余额。

简单来说:

客户预付10,000个成功结果
  借  现金                         $120,000
  贷  合同负债                     $120,000
 
800个结果以每个$12合格
  借  合同负债                       $9,600
  贷  基于结果的收入                $9,600

确切的账户名称和时间需要与供应商的会计政策和合同分析相匹配。重要的纪律是将预付款、已验证的生产、发票和银行结算保持为可见的独立事件。

结账所需的数据

基于结果的收入无法仅从银行对账单中结清。创建月度证据包,将合同与总账联系起来。

合同条款

存储签署的条款、每结果价格、成功定义、期限、续约和结转权利、最低限额、到期规则、退款条款、验收窗口以及任何费率层级。将修订记录为带日期的版本,而不是覆盖原始条款。

结果账本

对于每个可计费的结果,保留稳定的标识符、客户、智能体或工作流程、尝试时间戳、完成时间戳、成功状态、失败原因、人工升级状态、冲销或争议状态、适用费率以及源系统参考。目标不是为收集遥测数据而收集。而是证明哪个合同事件创造了获得对价的权利。

对账层

按以下顺序对账:

  1. 智能体事件日志到客户面向的使用或结果报告。
  2. 结果报告到发票。
  3. 发票到应收账款。
  4. 应收账款和积分到银行结算。
  5. 已确认收入和合同负债到收入表。

调查差异,而不是将其强行计入收入。失败的工作流程可能从计费导出中消失,但仍存在于基础设施日志中。重复的结果可能被计费两次但支付一次。开票后的冲销可能需要信用备忘录和收入调整。每个差异都应有负责人和解决说明。

与收入对应的单位经济性

收入确认告诉你何时报告费用;它不告诉你工作流程是否盈利。按结果类型跟踪模型和基础设施成本、编排、人工审查、客户支持、争议和返工。最近对agentic工作流程的分析强调,在某些高风险工作流程中,人工监督可能是比模型令牌更大的可变成本。如果你的价格基于成功结果,你的利润率报告应使用相同的成功结果单位。

应避免的常见错误

将每次尝试视为收入

一次尝试、令牌捆绑、API调用或工作流程启动不一定是承诺的服务。如果客户仅为已验证的结果付费,则尝试属于运营指标,直到合同成功事件发生。

将发票记为收入

一张发票可以创建应收账款、合同负债或收入,具体取决于已交付的权利和履约情况。预付余额不自动是已赚取收入。即使系统集成,也要保持计费表和收入表分离。

忽视实施和入职

数据映射、集成、配置和工作流程设计可能是帮助供应商履行SaaS承诺的活动,或者它们可能向客户转移单独的服务。不要假设“免费实施”没有会计后果。确定客户是否可以独立受益于该工作,以及该工作是否与托管服务不同。

对每个工作流程使用单一成功率

一个智能体同时分类发票、处理退款和防止重复支付,可能具有不同的成功定义、价格、审查负担和冲销模式。在合同和经济性分离的地方,保持结果类型分离。混合它们可能隐藏无利可图的工作流程并削弱可变对价估计。

忘记客户数据权利

合同可能规定供应商可以使用客户数据来改进服务。实际权利很重要。仅用于履行合同服务的狭窄权利可能是履约的一部分,而更广泛的权利可能引发关于非现金对价、数据使用、隐私和合同承诺的单独问题。在启动前将异常数据条款发送给会计和法律审查人员。

实用政策模板

在推出新的基于结果的计划之前,在简短的会计备忘录中回答以下问题:

  • 精确承诺的服务是什么?
  • 什么事件证明成功转移?
  • 承诺是随时履约、指定数量的结果还是混合?
  • 服务是否是以相同转移模式构成的系列?
  • 发票金额是否直接对应于转移的价值?
  • 可变对价分配例外是否适用?
  • 如果不适用,什么估计和限制支持交易价格?
  • 实施、支持、数据权利、续约选项或最低限额是否构成独立问题?
  • 哪个运营系统对结果计数具有权威性?
  • 月度报告如何与发票、应收账款、合同负债和现金对账?

在定价页面上线前,让财务、产品、工程、销售运营和法律就定义达成一致。容易计费的合同不一定容易入账。

简化你的财务管理

基于结果的定价使干净、版本化的记录变得特别有价值:合同、合格事件、收入表和银行活动应讲述相同的故事。Beancount.io 提供透明、版本控制和AI就绪的纯文本会计,随着定价模型的演变为你的团队提供持久的审计追踪。免费开始,让财务逻辑从合同到结账保持可见。

分享这篇文章