用途：帮助选择并运营循环计费引擎——把订阅与用量转成发票、重试失败付款（催收/dunning）、处理按比例计费（proration），并可选做收入确认；它运行在自有支付网关之上，你仍是记录卖方（seller of record）。这与 Merchant of Record（承担全球税务责任）是不同决策。
主要能力：先收集上下文（决策类型、定价模型、团队阶段、约束、是否需自管税务），再路由或直接回答。决策类型包括：选哪家引擎、Stripe Billing 自建 vs 专用引擎、为现有计费加用量/计量/混合定价、迁移计费平台、催收/按比例计费/ASC 606 收入确认等运营需求。
选型要点：已在 Stripe、简单固定或按席位订阅、小团队，可用 Stripe Billing（成本较低，约计费额的 0.7%，无需额外集成，但缺少深度催收分析、收入确认与灵活目录建模）。目录复杂、混合/用量定价、想自动化完整收入生命周期，则选专用引擎（Chargebee/Recurly/Maxio），它们编排你的网关（常为 Stripe），你保留收单方并叠加计费深度。按主导模型选：订阅为主并加用量超额、要全生命周期选 Chargebee；高量订阅、优先降流失与回收可变发票选 Recurly；B2B SaaS 需把用量计费接入 RevOps 与收入确认报告选 Maxio；企业需 GAAP 合规全球记录系统选 Zuora；用量计量即产品选 Orb（或 Metronome）；要开源可控、自托管选 Lago；SMB 已在 Zoho 套件内选 Zoho Billing。
运营现实：催收优于打折，多数流失是非自愿的（卡失败），应开启按拒付类型感知的重试与卡到期提醒；按比例计费的信用类型与时点取决于发票状态，提交前用估算 API 预览并在沙箱/测试时钟验证；用量计费需幂等、去重的计量，避免重复事件导致错误发票。迁移计费引擎需重新令牌化支付方式、迁移订阅状态与发票历史、重接 webhook 与收入确认，仅在结构性原因下迁移。
限制：计费引擎不是 Merchant of Record，税务仍由你注册、申报与缴纳；免费层有累计上限（如 Chargebee 免费 Starter 覆盖累计约 25 万美元计费额，之后按 0.75% 计）；标价不等于总拥有成本，收入确认、留存分析、高级集成常为单独附加项（约 200–2000+ 美元/月），还需叠加网关约 2.9% + 30 美分的费用；自托管（Lago）以运维成本换费用，需自管 Postgres/Redis、升级、扩展与可用性。资料基于 2026-06 研究，费用、套餐与功能深度会变化，需向各厂商核实。相关技能包括 /sales-chargebee、/sales-merchant-of-record、/sales-checkout、/sales-swell、/sales-membership、/sales-integration、/sales-do。