MoR 遇上用量计费：按 token 卖 AI 时，哪五个地方会断
大多数 Merchant of Record（MoR）服务是为固定月费订阅设计的。当你卖的是预付额度和按量消耗时，这套模型会在五个地方断掉——以及你该向服务商要求什么。
本页目录
MoR 这套模式是围绕固定月费订阅成熟起来的——扣款之前金额就是已知的。用量计费把这个前提反了过来，于是模型会在五个具体位置断裂：预付额度的收入时点、对已扣减余额的部分退款、供应地判定、随充值金额放大的拒付敞口，以及对方财务批不掉的混合账单。
- MoR 能干净地回答「卖了什么、卖给谁、在哪里卖、多少钱」，但前提是金额在扣款前已经确定。
- 额度售出和额度消耗是两个独立事件；只记录购买时现金事件的服务商，等于替你把收入确认的选择权拿走了。
- 在 MoR 模式下部分退款结构上更难，因为发票是服务商以法律卖家身份开出的。
- 争议敞口随客单价放大，而且争议可能在额度已经消耗完之后才到达。
- 混合账单必须把订阅、赠送额度和超额分行列示，否则每个企业客户都会在续费环节卡住。
大多数计费基础设施都带着一个从不明说的假设：客户先同意一个价格，扣款之前金额已知，然后这笔扣款按周期重复。订阅是这样运作的。过去十年里做出来的几乎所有 Merchant of Record（MoR）服务，也是这样运作的。
AI 产品不是。
主要是三种形态，后文会反复用到它们：
- 预付额度包。 图像或视频生成类产品卖 $20 / 1000 credits。用户买下一笔余额，然后不均匀地消耗——或者用到一半就再也不来了。
- 订阅 + 超额。 $99/月的套餐含 100 万 token。用得猛的团队 11 号就烧完赠送额度，剩下的周期全在计量超额上跑。
- 纯按次。 Agent 类产品每次运行 $0.30。一个企业客户一周内产生的波动，比一个 SaaS 席位一年的波动还大。
如果你是这么卖的，并且正在选 MoR，那问题不是「它支不支持用量计费」——基本都会说支持。问题是它会在哪里断。因为断点是可以预判的，而且代价不小。
为什么 MoR 这套模型是为固定订阅设计的
MoR 成为你产品的法律卖家。它接下订单、以自己的名义开具发票、收款，并承担这笔销售的税务义务。正是这个安排，让一个小团队不用在十几个辖区注册 VAT 就能卖向全球。
整个结构依赖于能干净地回答一个问题：卖了什么、卖给谁、在哪里卖的、多少钱。
固定订阅下，这四项在扣款那一刻全部已知。发票可以立即开出，而且下个月它仍然是正确的。
用量计费在五个具体的地方破坏了这种干净。
断点一：销售和交付不在同一个时间发生
客户买了 $500 的额度，钱动了。但什么都还没交付。交付发生在之后，零碎地发生，可能跨越数月，也可能永远不会发生完。
固定订阅下这个时间差不构成任何实际问题。额度制下它就是全部问题。你现在有了两个彼此独立的事件——额度售出和额度消耗——而你的账务、你的税务立场、以及你对自己生意的理解，全都取决于能不能把这两件事分开看。
这个判断不是计费服务商能替你做的，正确的处理方式取决于你的辖区、你的条款和你的审计师。服务商能做的是让这个判断成为可能。
所以要求很具体：它能不能把售出额度和消耗额度作为两条独立数据，按客户、按周期分别输出？能不能在任意日期查询尚未消耗的余额？
只记录购买时现金事件的服务商，等于悄悄替你把这个选择权拿走了。
具体到一个场景。 用户 3 月买了 $20 的额度包，到 6 月用掉了 1000 里的 150，然后就不再打开产品了。财年结账时，账上躺着 850 credits。这算收入吗？算负债吗？算可以确认的未消耗余额吗？无论你的答案是什么，前提都是服务商能按客户、按周期告诉你：卖出了多少、实际消耗了多少。
断点二：对一笔已经用掉一部分的余额退款
客户买了 $500 额度，用掉 $120，然后要求退款。
在普通支付处理商那里这已经很麻烦。在 MoR 模式下结构上更难，因为发票是服务商以法律卖家身份开出的。得有人算残值，有人去冲正一份以服务商名义开出的文件，原始销售上已经申报的税，还要按退款部分做调整。
典型的失败形态是：服务商只能全额退或者不退，于是你被迫在系统外手工处理部分退款——结果就是你的账和法律卖家的账开始分叉。而这种分叉，恰恰是你当初选择 MoR 想要避免的东西。
签约前把三件事问清楚：能不能对已扣减的余额做部分退款；税是不是只就退款部分重算；客户拿到的是一份更正凭证，还是只有一笔没有任何说明的银行退账。
具体到一个场景。 同一个用户要求退款。MoR 已经以自己的名义开出了 $20 的发票，而额度用掉了 15%。得有人算出 $17 的残值，去冲正一份由法律卖家开出的文件，并且只就退款部分调整已经申报的税。如果服务商只能全额退或者不退，这件事你就得手工做——然后你的账和法律卖家的账开始分叉。
断点三：供应地不再是显而易见的
我们刻意不在这里给答案。 额度销售和供应地的正确处理方式，取决于你所在的辖区、你的服务条款和你的审计师。服务商能做的是让正确的处理成为可能——而它有没有一个成文的立场，本身就是一个有用的信号。
数字产品的税，一般取决于客户在哪里。订阅模式下这件事确定一次就定下来了。
额度制下，销售和消耗可能发生在不同的地方。客户在一个国家买下余额，接下来六个月里慢慢花掉，其中一部分是在另一个国家生活时花的。哪个事件决定供应地？有什么证据支撑这个判定？
我们刻意不在这里给答案——它取决于涉及的辖区，而且会变。我们要说的是：这是一个你的服务商应该有成文立场的问题，而没有立场本身就是一种信息。真正跨境做过额度制产品的服务商，一定被迫想过这件事。没想过的，那就只能由你来发现了。
具体到一个场景。 用户在新加坡买了 $500 的额度，之后搬去德国，剩下的 60% 在接下来六个月里于德国消耗完。哪个事件决定供应地——购买，还是每一次消耗？ 有什么证据支撑这个判定？服务商应该答得上来；答不上来，就说明它真正跨境跑过的额度制业务量有限。
断点四：争议敞口随充值金额放大
$49 的月订阅产生一笔 $49 的可争议交易。一次性充值 $2,000 API 余额的客户，产生的是一笔 $2,000 的。
光是这一点还算可控。更麻烦的是时间。卡组织的争议可能在扣款 60 天甚至更久之后才到达，那时候额度可能已经消耗干净了。算力交付了，你这边的成本也付出去了。如果争议成立，钱照样要走。
所以问题是：合同上这笔损失由谁承担；服务商实际会替你提交什么证据；以及——最多人忘了问的一条——消耗日志能不能作为数字服务的交付凭证被接受？
一个争议应对流程是为订阅调校的服务商，提交的会是注册记录和扣款凭证。对一笔逐步扣减的余额来说，那是错的证据。
具体到一个场景。 一个企业客户一次性充值 $2,000 跑 Agent 工作流，三周内消耗掉 4 万次调用。第 58 天，持卡人发起争议。算力已经交付，你的推理成本已经付出去了，额度也消耗干净了。如果争议成立，钱照样要走。 所以要问清楚谁承担，以及消耗日志能不能被接受为交付凭证。
断点五：账单得过得了对方财务那一关
这条听起来像是外观问题，其实不是。这是单子卡住的地方。
一张混合账单要体现：基础订阅、带单位和数量的计量用量、计量开始前被消耗掉的赠送额度、每一行的税务处理、以及法律卖家的主体信息。对方财务要能在不发邮件问你的情况下批掉它。
如果服务商只能出一个总额，你的每一个企业客户都会在你最希望他们扩大用量的那一刻慢下来。自助消费者购买没人看发票，但真正给你带来收入增长的那批账户，每一行都有人看。
具体到一个场景。 对方财务收到一张 $3,247.80 的发票，上面只有一行「API usage」。采购批不了一个自己还原不出来的数字，于是发票被退回给你的对接人，对接人发邮件问你，这笔款就滑过了一个账期。这不是美观问题，是结构问题——每一个计量行都要有单位、数量和单价。
选 MoR 时该向服务商要求什么
如果你按消耗卖，在接入之前把下面这些摆到任何 MoR 面前。
计量与报表
- 售出额度和消耗额度作为独立数据输出，按客户、按周期
- 未消耗余额可按任意日期查询
- 用量记录能通过 API 取，而不只是在后台能看到
资金流转
- 支持对已扣减余额做部分退款，且只就退款部分重算税
- 客户收到的是更正凭证，不是单纯的银行退账
- 对跨境消耗的预付额度，有成文的供应地立场
风险
- 书面约定拒付责任归属
- 消耗日志被接受为争议应对中的交付证据
- 存在专门针对计量类产品的争议应对模板
账单
- 订阅、赠送额度、超额分行列示
- 每一个计量行都显示单位和数量
- 逐行税务处理 + 法律卖家主体信息
任何服务商都可以说自己支持用量计费。上面这些问题，区分的是真正跑过的和只是配置过的。
如果你按消耗定价，上面这些问题值得摆到任何一家服务商面前——包括我们。
Waffo Pancake 在这里的位置
Waffo Pancake 以 MoR 身份运营，计费覆盖订阅、用量额度和动态定价（price snapshot）三种模型。把边界说清楚：Pancake 不提供内置的用量计量——消耗量由你在自己系统里埋点，或者接外部计量服务，Pancake 负责把这个数字变成订单、收款、发票和已申报的税。
如果你的 AI 产品按消耗定价，想拿上面这些点对着自己的模型过一遍，可以看看计费与订阅是怎么跑的、AI 场景的接入方式，或者先从MoR 到底做了什么开始。
本文仅为一般信息，不构成税务、法律或财务建议。税率、登记门槛和合规要求会随时间和辖区而变化。在做出决策前，请就你的具体情况咨询合格的专业人士。
常见问题
MoR 能支持用量计费吗？
有的能，但很多做不好。MoR 这套模式是围绕固定费率的 SaaS 订阅成熟起来的——扣款之前金额就是已知的。用量计费把这个前提反过来了：金额只有在消耗之后才知道。选型时要具体问：预付额度余额怎么管、周期内超额怎么算、针对已消耗部分的退款怎么处理、订阅行和计量行混在一起的账单长什么样。
预付额度的收入，是在购买时确认还是消耗时确认？
这是额度制产品最核心的会计问题，而且不是计费服务商能替你决定的，取决于你所在的司法辖区、你的服务条款和你的审计师。从操作层面能确定的是：你的 MoR 必须能把「售出额度」和「消耗额度」拆成两条独立数据，按客户、按周期分别给出。如果服务商只记录购买时的现金事件，你就失去了做这个判断所需要的数据。
客户用掉一部分额度后要退款，怎么办？
得有人算出残值，还得有人去冲正一张由法律卖家开出的发票。在 MoR 模式下，这个卖家是服务商，不是你。签约前确认三件事：能不能对已消耗的余额做部分退款、退款部分的税会不会重新计算、客户收到的是一份更正后的凭证还是只有一笔没有说明的银行退账。
为什么用量计费的拒付风险更大？
争议敞口会随客单价放大。一次性充值大额 API 余额的客户，产生的是一笔远大于月度订阅的可争议交易；而且争议可能在额度已经消耗完之后才到达——服务已经交付，钱照样要走。要问清楚：这笔损失合同上由谁承担、服务商实际会替你提交哪些证据、以及消耗日志能不能被接受为交付凭证。
订阅加用量的混合账单上该有什么？
要足够让对方财务不用来问你就能批掉。也就是说：基础订阅单独一行、计量用量要写清计费的单位和数量、计量开始前被消耗掉的赠送额度、每一行的税务处理、以及法律卖家的主体信息。如果服务商只能出一个总额，你的每一个企业客户都会在付款环节卡住。
用量计费和按量计费有区别吗？
实践中是一回事，都指按实际消耗计算金额，而不是按事先约定的固定价格。商业上真正有区别的是预付和后付：客户是先买一笔额度再逐步扣减，还是先消耗再按账期开票。这两种模式在税务、退款和信用风险上是完全不同的问题。
Waffo Pancake 是面向开发者和独立创始人的 Merchant of Record(代销商)平台——我们在 173 个国家处理全球支付、税务与合规,让你专注于做产品。这些指南由我们团队基于一线支付与计费经验撰写。
了解 Waffo Pancake →
