1月の支払金はLemon Squeezyから、8月の支払金はPaddleから振り込まれている。そして今、あなたの会計士が、どちらのダッシュボードも単独では答えられない質問をしてくる。今年、あなたが実際に稼いだサブスクリプション収益はいくらなのか、と。旧プロバイダーは1つの手数料体系、1つの支払サイクル、そして自社の事業体から発行される1つの税務請求書の下で回収していた。新プロバイダーも同じ仕事をするが、レポートも手数料の明細も書類も異なる。その間に横たわるのは、繰延収益の残高、一方のプラットフォームで販売され他方でサービス提供される年間プランの山、そして2つの互換性のない台帳を1つの信頼できる帳簿に縫い合わせなければならない年末決算である。この縫合作業——数日で終わるAPI連携ではなく——こそが、Merchant-of-Record移行が静かに失敗する場所である。
これは今、何千もの販売者にとって現実の決断である。Stripeは2024年7月にLemon Squeezyを買収し、Lemon Squeezyの2026年1月のアップデートは、その将来がStripe自身のMerchant-of-Record製品であるStripe Managed Paymentsへの容易な移行パスであると述べた。期限は公表されておらず、Lemon Squeezyは今も機能しているが、他人のスケジュールで移行させられたくない販売者は、独立系——同じ5パーセント＋50セントの表面料率を持つ本物のMerchant-of-RecordであるPaddleとPolar——を検討している。もしあなたがその一人なら、請求の切り替えは簡単な部分である。その間も帳簿を信頼できる状態に保つことが本当のプロジェクトである。
Merchant of Recordとは、あなたの帳簿上で実際に何なのか
Merchant of Recordとは、単なる決済プロセッサではなく、あなたの製品の法的な販売者である。顧客がPaddle、Polar、またはLemon Squeezyを通じて購入すると、カード明細にはプロバイダーの名前が表示され、税務請求書はプロバイダー自身の事業体から発行され、ドイツ・日本・テキサスにおける売上税やVATの登録はあなたではなくプロバイダーに帰属する。プロバイダーは税を計算し、徴収し、申告し、納付し、チャージバックの責任を吸収し、残額をあなたへの支払金として送る。
この法的構造が、あなたの会計記録の形を決める。購入者向け請求書は、プロバイダーの顧客への販売を証明する——それはあなたの請求書ではなく、彼らの請求書である。あなた側の取引は販売者側の記録によって証明される。すなわち、プロバイダーへのあなたの供給を記述する逆請求書と、各支払額を記録する送金通知である。あなたの収益は、プロバイダーの手数料を差し引いた支払金であり、連続的ではなくプロバイダーのスケジュールで到着する。各プロバイダーのこうした書類の見た目は異なり、それこそが1年で2つを運用すると記録が2つに分割される理由である。
一度だけ下さなければならない総額か純額かの決断
どちらのプラットフォームに触れる前に、移行があなたに弁明を強いる1つの会計方針を決着させよう。顧客が支払った全額を収益として認識するのか（総額）、それとも受け取った支払金だけを認識するのか（純額）。
ASC 606において、これは本人か代理人かの問題であり、答えは支配によって決まる——請求書を発行したのが誰か、カード明細に誰の名前があるかによってではない。指針はASC 606-10-55-36から55-40にあり、企業が特定の財またはサービスを顧客に移転する前に支配しているなら本人であり、収益を総額で報告する。その約束が単に他の当事者がそれを提供するよう手配することだけなら、企業は代理人であり、手数料または報酬のみを純額で報告する。リセラー型のMerchant-of-Recordを通じて販売するソフトウェアベンダーにとって、同じ分析があなたの顧客が誰かを決める。あなたの顧客がエンドユーザーなら、収益はエンドユーザー価格であり、プロバイダーの取り分は収益線の下の販売費である。あなたの顧客がプロバイダー自体なら、収益はプロバイダーがあなたに支払った価格——支払金である。
どちらでも売上総利益は同一である。報告される収益は異なり、その数字は成長率、資金調達や買収における収益マルチプル、そして取締役会が読むあらゆる前期比較に影響する。マーケットプレイスやリセラーを通じて販売するほとんどのソフトウェアベンダーは総額処理に落ち着くが、あなたの分析が支持するならどちらの答えも弁明可能である。弁明できないのは漂流である。年度前半はLemon Squeezyの支払金を純額で計上し、後半は新プロバイダーのレポートが総額を容易にしたからという理由でPaddleの支払金を総額で計上すること。1つの方針を選び、監査人が読めるメモに支配の分析を書き留め、年間を通じて両プロバイダーの支払金に同一に適用せよ。
1年が2つに分かれる5つの継ぎ目
1. サブスクリプションは移行しない。顧客が再登録する。 決済プロセッサ間で自動のトークン移行はない。保存済みカードは通常、Merchant-of-Recordから使用可能な形でエクスポートできないため、購読者が新プラットフォームで支払い情報を再入力することを計画するか、コミットする前に、新プロバイダーがアクティブなサブスクリプションと保存済みカードをあなたのために移行できることを書面で確認せよ。各顧客が再登録するまで、旧プラットフォームが彼らへの請求を続ける。つまり2つのシステムが何ヶ月も並行して稼働し、毎月の決算が2つの支払金の流れを照合する。
2. 既得価格と更新アンカーは手作業で再構築しなければならない。 すべてのアクティブなサブスクリプションは価格、更新日、そしてしばしばもはや販売されていない既得プランを伴う。新プラットフォームはあなたが再現するまでこれを何も知らない。製品、価格、既存顧客だけが保持するレガシープラン、トライアルの挙動、クーポン、税込みルール、更新アンカー。既得価格を見落とすと、忠実な顧客が新料率で請求される——サポート上の惨事であり、その後反転しなければならない収益も計上してしまう。
3. 年間プランは繰延収益のカットオーバーを生む。 3月に1,200ドルの年間プランを購入した顧客は旧プロバイダーに支払ったが、あなたはその収益を翌年2月まで月ごとに稼ぐ。カットオーバー日において、その現金の一部はまだ未稼得であり、残りの月をどのプラットフォームがサービス提供するかにかかわらず、貸借対照表上に繰延収益として残る。新プラットフォームのレポートはその負債を決して示さない——それはそれを通じた販売しか知らない——ため、移行は残高を明示的に繰り越さなければならず、さもなければ後半の収益はすでに回収した金で過大計上される。
4. 返金とチャージバックはカットオーバーをまたぐ。 5月の販売に対する8月発行の返金は、旧手数料ルールの下、旧プロバイダーのシステムに存在する一方、それが反転する収益はすでに2四半期にわたって認識されているかもしれない。各プロバイダーはMerchant-of-Recordとしてチャージバックを吸収するが、会計仕訳——収益の反転、返金不能な手数料の計上、すでに受け取った支払金の調整——はあなたの帳簿に落ち、各プロバイダーの調整レポートはそれらを異なる形で表現する。
5. 支払タイミング、通貨、税務書類がすべて同時に変わる。 支払スケジュールはプロバイダーごとに異なるため、同じ週の売上が切り替え前後で異なる月の銀行明細に着地しうる。越境販売者は新しい外国為替の明細行と新しい手数料の内訳に直面する。そして各プロバイダーは自社の登録の下で自社の税務申告を報告し、米国の販売者は年間を通じて各プラットフォームから別々の支払報告を受け取るかもしれない。これらはどれも誤りではない。2つの正しいシステムが形式で食い違っているのであり、あなたの決算はそれらすべてを1つの勘定科目表に正規化しなければならない。
財務的に安全な移行プレイブック
これらを順番に進め、並行稼働を圧縮してはならない。
1. カットオーバー日を期間の境界に設定する。 月途中のカットオーバーは、サブスクリプション期間、日割り、支払バッチを継ぎ目で分割する。月末または四半期末のカットオーバーは、きれいな前後の母集団と、移行全体を含む1回の決算をもたらす。
2. 旧プラットフォームからすべてを凍結しエクスポートする。 旧プロバイダーがすでに請求した会計期間をロックする。完全なプランカタログ、価格と更新日を含むすべてのアクティブなサブスクリプション、完全な請求履歴、手数料内訳を含むすべての支払レポートをエクスポートする。旧アカウントは少なくとも1回の完全な監査サイクルの間、削除せず読み取り専用に保つ——監査人や税務当局は、まさに継ぎ目を予期して移行年度について具体的に尋ねる。
3. もはや販売していないプランを含め、プランカタログを再構築する。 レガシーおよび既得プランは、最初の移行顧客がそこで更新する前に新システムに存在しなければならない。旧プランIDから新プランIDへのすべてのマッピングを文書化せよ。そのマッピング表は、同じ顧客について7月の請求書が6月の請求書と異なって見える理由を説明する監査証跡である。
4. まず新規顧客を新プラットフォームに載せる。 既存のサブスクリプションが旧プラットフォームで更新に向かう間、新規販売のために新プロバイダーを並行稼働させ、その後コホートを自然な境界——更新日、月末——で移動させる。サイクル途中では決してない。各コホートは次が始まる前に独自の照合を受ける。一斉切り替えは、すべての再登録の失敗、すべての既得価格の見落とし、すべての日割りのエッジケースを1回の決算に集中させる。
5. 両方の支払レポートを1つの勘定科目表にマッピングする。 両プロバイダーを含む最初の決算の前に、翻訳を構築する。各レポートの各手数料明細、税明細、調整、返金コードがあなたの台帳勘定の1つにマッピングされる。2つのプロバイダーは決して同じラベルを使わない。マッピングがなければ、あなたの記帳担当者は毎月異なる方法でそれをでっち上げる。
6. 繰延収益を明示的に調整する。 カットオーバー日において未稼得残高をプランごとに照合し、旧プラットフォームの記録とあなたの台帳の間の差異を、文書化された原因を伴う明示的な調整として計上する——埋め草としてではなく。カットオーバー以降、残りの残高をどのプラットフォームが顧客にサービス提供するかにかかわらず予定どおりに認識する。
カットオーバー月があなたの台帳でどう見えるか
両プロバイダーをそれぞれ別個の手数料追跡で分離し、両方を収益に直接計上させないようにすれば、記帳の接続は単純である。各支払金を総額で認識し——顧客の支払全額を収益として、プロバイダーの取り分を販売費として——カットオーバー前の繰延残高を元のスケジュールで認識し続ける。以下で使う台帳構文に見慣れない点があれば、Beancountのドキュメントがそれを扱っている。
ある顧客が3月半ばにLemon Squeezyを通じて1,200ドルの年間プランを購入したとしよう。3月の支払金は5パーセント＋50セントの手数料（60.50ドル）を差し引いて到着し、6月30日までに4ヶ月分の収益（400ドル）を認識し、800ドルが未稼得で残る。7月1日がカットオーバー日で、7月に新たな49ドルの月額サブスクリプションがPaddleを通じて販売される。プレーンテキストの台帳ではこうなる。
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 USD3つの細部が移行全体を担う。第一に、各プロバイダーの手数料はそれぞれのサブアカウントに計上されるため、年末合計は各プラットフォームがあなたにいくらかかったかを正確に示し、2つの手数料体系は決して混ざらない。第二に、3月の販売に対する7月の認識仕訳はカットオーバーによって変わらない——繰延収益はあなたの負債であり、あなたのスケジュールで稼得され、どのプラットフォームが現金を回収したかは気にしない。第三に、すべての仕訳は特定の支払レポートに結びつく。最初のものは3月のLemon Squeezyの送金通知に、3番目は7月のPaddleの支払に。あなたの会計士がその年の収益がどう稼得されたかを尋ねるとき、各数字は正確に1つのプロバイダーの書類を指す。
継ぎ目を意図的に閉じる
Merchant-of-Record移行は1つの名前をまとった2つのプロジェクトである。請求の移動はエンジニアが数週間で終える。帳簿の移動は会計士が1年間ともに生きる。請求プロジェクトは最後の顧客が再登録したときに終わる。帳簿プロジェクトは、両プロバイダーからのすべての支払金が銀行と一致し、すべての手数料明細が1つの勘定科目表にマッピングされ、繰延収益残高がカットオーバー日をきれいに越えて歩み、監査ファイル内の総額対純額のメモが1つの方針の下で年度の両半分を網羅したときに終わる。カットオーバーを期間の境界に予定し、旧サブスクリプションが更新に向かう間は新プラットフォームで新規販売を実行し、監査人が移行年度を見るまで旧システムを読める状態に保て。そうすれば、切り替えは誰も説明できない差異ではなく、来年の財務諸表の脚注になる。
