你一月份的付款来自 Lemon Squeezy，八月份的付款来自 Paddle，现在你的会计师在问一个两个后台都无法单独回答的问题：你今年实际赚到了多少订阅收入？旧服务商按一套费用表、一种付款节奏收费，并以其自有实体开具了一套税务发票。新服务商做同样的工作，但报告不同、费用明细不同、单据也不同。两者之间隔着一笔递延收入余额、一批在一个平台上售出却在另一个平台上服务的年度订阅计划，以及一次必须把两套互不兼容的账簿编织成一套可信账目的年终结算。真正让记录商户迁移悄悄失败的，正是这次编织——而不是几天就能搞定的 API 集成。
这是当下成千上万卖家面临的现实决策。Stripe 于 2024 年 7 月收购了 Lemon Squeezy，而 Lemon Squeezy 在 2026 年 1 月的更新中表示，它的未来是一条通往 Stripe Managed Payments（Stripe 自家的记录商户产品）的便捷迁移路径。目前没有公布任何截止日期，Lemon Squeezy 也仍在运作，但不想被别人牵着鼻子走、按别人的时间表被迁移的卖家们，正在评估那些独立服务商：Paddle 和 Polar，两者都是真正的记录商户，都采用 5% 加 50 美分的标价费率。如果你是他们中的一员，计费切换是简单的那部分。让账目在切换过程中保持可信，才是真正的工程。
记录商户在你的账目上到底是什么
记录商户是你产品的法定销售方，而不只是你的支付处理商。当客户通过 Paddle、Polar 或 Lemon Squeezy 购买时，信用卡账单上显示的是服务商的名字，税务发票由服务商自己的某个实体开具，而在德国、日本或德克萨斯州的销售税和增值税登记属于服务商，不属于你。服务商负责计算、征收、申报和缴纳这些税款，承担拒付责任，然后把剩余部分作为付款发送给你。
这个法律结构决定了你的会计记录是什么样子。买方发票记录的是服务商向你的客户进行的销售——那是他们的发票，不是你的。你这一方的交易由卖方侧记录来体现：一张描述你向服务商供货的反向发票，以及记录每笔付款金额的汇款通知。你的收入是一笔扣除了服务商费用后的付款，按服务商的时间表到账，而非连续到账。每个服务商对这些单据的版本都不一样，这也正是为什么在同一年里同时使用两个服务商，会把你的记录一分为二。
你必须一次性决定总额还是净额的口径
在你动任何一个平台之前，先确定迁移迫使你必须为之辩护的那一项会计政策：你是把客户支付的全额确认为收入（总额），还是只确认你收到的付款（净额）？
根据 ASC 606，这就是主要责任人还是代理人的问题，而判断标准是控制权——不是谁开具了发票，也不是谁的名字在信用卡账单上。指引见 ASC 606-10-55-36 至 55-40：如果主体在将特定商品或服务转移给客户之前控制了该商品或服务，它就是主要责任人，并按总额报告收入；如果它的承诺仅仅是安排另一方提供该商品或服务，它就是代理人，只按净额报告其费用或佣金。对于通过经销式记录商户销售产品的软件供应商来说，同样的分析决定了谁是你的客户。如果你的客户是最终用户，收入就是最终用户价格，服务商的分成则是收入线以下的销售成本。如果你的客户是服务商本身，收入就是服务商支付给你的价格——也就是那笔付款。
无论哪种方式，毛利都相同。报告的收入则不同，而这个数字会影响你的增长率、你在融资或收购中的收入倍数，以及你董事会阅读的每一个期间对比。大多数通过市场平台和经销商销售的软件供应商最终采用总额口径，但只要你的分析站得住脚，任何一种答案都可以辩护。真正站不住脚的是漂移：在上半年把 Lemon Squeezy 的付款按净额记账，在下半年却因为新服务商的报告让总额更容易做，就把 Paddle 的付款按总额记账。选定一种政策，把你的控制权分析写成一份审计师能读懂的备忘录，并对整个年度两家服务商的付款完全一致地适用它。
一年被劈成两半的五处接缝
1. 订阅不会迁移，客户得重新订阅。 支付处理商之间没有自动的令牌迁移。已保存的银行卡通常无法以可用形式从记录商户导出，所以要为订阅者在新平台上重新输入支付信息做好准备——或者在做出承诺之前，以书面形式确认新服务商能否为你迁移活跃订阅和已保存的银行卡。在每位客户重新订阅之前，旧平台会继续向他们计费，这意味着两套系统要并行运行数月，每个月的结算都要核对两条付款流。
2. 老价格和续订基准必须手工重建。 每一个活跃订阅都带有价格、续订日期，而且往往还有一个不再销售的保留（grandfathered）计划。新平台对这些一无所知，除非你重新创建：产品、价格、仅有现有客户持有的旧计划、试用行为、优惠券、含税规则和续订基准。漏掉一个保留价格，一位忠实客户就会被按新费率扣费——这既是支持灾难，也会记入你之后必须冲回的收入。
3. 年度计划会产生递延收入的切换。 一位客户在三月购买了 1,200 美元的年度计划，付款给了旧服务商，但你是在接下来到次年二月的每个月逐月赚取这笔收入。在切换日期，这笔现金中有一部分仍未赚取，无论哪个平台服务剩余月份，它都作为递延收入留在你的资产负债表上。新服务商的报告永远不会显示那笔负债——它只知道通过自己完成的销售——所以迁移必须明确地把余额结转过来，否则你的下半年收入会因你已经收到的钱而被高估。
4. 退款和拒付横跨切换日期。 八月就五月的销售发出的退款存在于旧服务商的系统中，按旧费用规则处理，而它所冲回的收入可能已被分摊到两个季度中确认。各服务商作为记录商户都会承担拒付，但会计分录——冲回收入、记录任何不可退还的费用、调整你已收到的付款——落在你的账目里，而各服务商的调整报告对它们的格式处理各不相同。
5. 付款时间、币种和税务单据同时变化。 各服务商的付款周期不同，所以同一周的销售在切换前后可能落在不同月份的银行对账单上。跨境卖家会面临新的外汇条目和新的费用明细。而且每个服务商都按其自己的登记申报自己的税务，而美国卖家可能会在当年收到每个平台各自独立的付款报告。这些都不是错误；它们是两套各自正确的系统在格式上的分歧，而你的结算必须把它们全部归一到一个会计科目表上。
财务安全的迁移操作手册
按顺序逐项完成，不要压缩并行运行期。
1. 把切换日期设在期间边界上。 月中切换会把订阅期、按比例分摊和付款批次劈在接缝两侧。月末或季末切换能让你得到干净的前后客户群，以及一次包含整个过渡期的结算。
2. 冻结并导出旧平台上的一切。 锁定旧服务商已经计费的会计期间。导出完整计划目录、每一个活跃订阅及其价格和续订日期、完整发票历史，以及每一份带费用明细的付款报告。至少在一个完整的审计周期内，把旧账户保持为只读而非删除——审计师和税务机关会专门询问迁移年度的情况，因为他们预料到了这条接缝。
3. 重建计划目录，包括你已不再销售的计划。 旧版和保留计划必须在新系统里存在，第一位被迁移的客户才能在那里续订。记录每一个从旧计划 ID 到新计划 ID 的映射；那张映射表就是审计轨迹，解释了为什么同一客户七月的发票看起来和六月不同。
4. 先让新客户上到新平台。 让新服务商先并行处理新销售，同时现有订阅在旧平台上跑到续订，然后按自然边界分批迁移——续订日、月末，绝不在周期中途。每一批在下一次迁移开始前都要完成自己的核对。一次性大爆炸式切换会把所有重新订阅的失败、所有保留价格遗漏和所有按比例分摊的边缘情况都集中到一次结算里。
5. 把两份付款报告映射到同一个会计科目表上。 在第一次包含两家服务商的结算之前，构建翻译表：每份报告上的每一条费用行、税务行、调整和退款代码都映射到你的某个账簿科目。两家服务商永远不会使用相同的标签。没有映射，你的记账员每个月都会以不同的方式自行发明一套。
6. 明确地调整递延收入。 在切换日期逐计划核对未赚取余额，并把旧平台记录与你的账簿之间任何差异作为一笔有文档记录原因的明确调整入账——而不是拿个数字凑平。从切换起，无论哪位服务商服务该客户，都按计划确认剩余余额。
切换月在账簿中是什么样子
一旦你用独立的费用跟踪把两家服务商区分开，而不是让两者都直接记入收入，记账连接就很直接了。按总额确认每一笔付款——客户支付的全额作为收入，服务商的分成作为销售费用——并继续按原始时间表确认切换前的递延余额。Beancount 文档涵盖了下面使用的账簿语法，如果其中有你不熟悉的。
假设一位客户在三月中旬通过 Lemon Squeezy 购买了一个 1,200 美元的年度计划。三月的付款在扣除 5% 加 50 美分费用（60.50 美元）后到账，到六月三十日你已确认了四个月的收入（400 美元），剩下 800 美元未赚取。七月一日是你的切换日期，七月份通过 Paddle 卖出了一笔新的 49 美元月度订阅。在纯文本账簿中，这看起来像这样：
2026-01-01 open Income:SaaS:Subscriptions
2026-01-01 open Liabilities:Deferred-Revenue
2026-01-01 open Expenses:MoR-Fees:LemonSqueezy
2026-01-01 open Expenses:MoR-Fees:Paddle
2026-01-01 open Assets:Checking
2026-03-15 * "Annual plan sale via Lemon Squeezy, buyer paid 1200.00"
Assets:Checking 1139.50 USD
Expenses:MoR-Fees:LemonSqueezy 60.50 USD
Liabilities:Deferred-Revenue -1200.00 USD
2026-06-30 * "Recognize June portion of annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USD
2026-07-15 * "Monthly plan sale via Paddle, buyer paid 49.00"
Assets:Checking 46.05 USD
Expenses:MoR-Fees:Paddle 2.95 USD
Income:SaaS:Subscriptions -49.00 USD
2026-07-31 * "Recognize July portion of pre-cutover annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USD三个细节承载了整个迁移。第一，每家服务商的费用记入各自的子账户，所以年终总计能准确显示每个平台花了你多少钱，两套费用表永不混杂。第二，三月销售在七月的确认分录不因切换而改变——递延收入是你的负债，按你的时间表赚取，它不在乎是哪个平台收的现金。第三，每一条分录都对应一份具体的付款报告：第一条对应三月的 Lemon Squeezy 汇款通知，第三条对应七月的 Paddle 付款。当你的会计师问这一年的收入是如何赚取的，每个数字都恰好指向一家服务商的单据。
有意识地缝合接缝
记录商户迁移是披着一个名字的两项工程：转移计费，你的工程师几周就能完成；以及转移账簿，你的会计师要与之共处一年。计费工程在最后一位客户重新订阅时结束。账簿工程则在以下条件全部满足时结束：两家服务商的每一笔付款都与银行对上，每一条费用行都映射到一个会计科目表，递延收入余额干净地跨过切换日期，审计档案里的总额对净额备忘录在一种政策下覆盖了全年的两半。把切换安排在期间边界上，让新销售跑在新平台上、旧订阅跑向续订，并在审计师看过迁移年度之前保持旧系统可读。做到这些，这次切换就会成为下一年财务报表里的一个脚注，而不是没人能解释的差异。
