Lemon Squeezy、Paddle、Zoho Billingの比較：2026年、Merchant of Recordか自社の請求スタックか

2026年8月更新

機能を1つ比べる前に、まずこの問いに決着をつけてください。すべての販売における売上税とVATの徴収と納付という法的責任を、他社に引き渡したいのか、それとも自社で持ち続けたいのか。これは3つの製品の間にある好みの違いではなく、構造的な違いです。Lemon SqueezyとPaddleはMerchant of Recordです。製品を顧客に法的に販売するのは自社ではなく両社であり、顧客のいるすべての管轄区域で税務登録をするのは自社ではなく両社の事業体で、受け取る手数料の中から自社に代わって納付します。Zoho Billingは、価格だけでなく種類が違います。サブスクリプション管理ソフトウェアであり、顧客が支払うべき金額を計算し、請求書を作成し、督促のシーケンスを実行しますが、販売者としての記録上の主体は自社のままで、販売先のあらゆる場所での税務登録、申告、納付の負担を自社が負います。

この1つの区別が以降の内容の大半を左右するため、価格を1つ見る前に、その仕組みを理解しておく価値があります。率直なトレードオフはこうです。Merchant of Recordは収益に対する割合で課金します。これは単純に聞こえますが、固定のソフトウェア料金と実際の金額で比べると、割合課金は急速に高くなります。ただし、「ソフトウェアのほうが常に安い」という売り文句が示すほど速くも、単純でもありません。本記事は、この分岐点を明示的に試算します。さらに、Lemon Squeezyの技術がStripeの内部に組み込まれたいま、同社が実際にどこに立っているかを確認し、多くの比較が省く論点も取り上げます。支払いのタイミング、チャージバックの責任の所在、そして乗り換えた場合に顧客との関係がどうなるかです。請求エンジンとMerchant of Recordのどちらにするかがまだ決まっていない場合は、より広いベストなサブスクリプション請求ソフトウェアのガイドが、15のプラットフォームにわたってその判断を取り上げています。

重要なポイント

• Paddleは、チェックアウトの取引ごとに5%に50セントを加えた額を課し、すべて込みで、別途の月額プラットフォーム料金はありません。これは本日取得したPaddle自身の料金ページによります。
• Zoho BillingのStandardプランは、年払いで月額$39から、ユーザー3人までで、年間100,000件の請求書、年間請求額100万ドルが上限です。これは本日取得したZoho自身の料金ページによります。
• Stripe自身の標準的なカード決済手数料は、Merchant of Recordではないあらゆる請求ソフトウェアの下に横たわる基礎コストで、国内の決済が成功するごとに2.9%に$0.30を加えた額です（Stripe自身の料金ページによる）。
• Lemon Squeezyの技術がいま組み込まれているStripe Managed Paymentsは、**標準の決済手数料に上乗せして取引ごとに3.5%**を課し、80か国以上で税、VAT、GSTのコンプライアンスをカバーします（Stripe自身のManaged Paymentsのドキュメントによる）。
• TaxJarは、Merchant of Recordにならずにその税務コンプライアンスを再現する方法の1つで、月間200件の注文まで$39/月から始まります。取扱量の多い販売者はすぐにこの上限を超えます（TaxJar自身の料金ページによる）。

TL;DR

本当の違い：Merchant of Recordか、自社で請求スタックを運用するか

多くの候補リストは、これら3つの製品を機能で比べていますが、実際の判断は、法的な責任を誰が負うかにかかっています。

PaddleまたはLemon Squeezyが販売を処理するとき、取引はプラットフォームと顧客の間で成立し、自社と顧客の間では成立しません。領収書を発行するのはプラットフォームで、購入者の管轄区域でVAT、GST、売上税の登録をしているのは自社ではなくプラットフォーム自身の事業体であり、自社に課す手数料の中から納付します。手数料が固定額ではなく収益に対する割合なのはそのためです。ソフトウェアだけでなく、販売先のあらゆる国での、実在し継続する法令遵守の義務を織り込んでいるのです。プラットフォームがすでにカバーしている場所では、税務登録をいっさいする必要がなく、その代わりに、販売そのものとの直接の法的関係を手放します。

Zoho Billingはまったく異なる仕組みで、その違いは機能の少なさではなく、カテゴリーの違いです。取引の法的な権原を持つことはありません。顧客が支払うべき金額を計算し、自社の名義で請求書を作成し、接続した決済ゲートウェイ（通常はStripeまたはPayPal）に請求を渡し、そのゲートウェイが自社の口座に資金を決済します。すべての取引で販売者としての記録上の主体は自社であり、それがすべてです。そのため、自社がネクサスのあらゆる場所で売上税やVATの登録をし、申告をし、納付をします。手作業でも、会計士経由でも、上に重ねた税務自動化ツール経由でも同じです。

ここで1つだけ覚えておくなら、Merchant of Recordが課す割合は、決済手数料への上乗せではなく、40か国で税務登録をしなくて済むことの対価だということです。それが支払う価値のあるものかどうかは計算の問題であり、次のセクションで計算します。

各プラットフォームが本当に適している対象

損益分岐点：各モデルの年間$10K、$100K、100万ドルでの実際のコスト

「Merchant of Recordは規模が大きくなると劇的に高くなる」という主張には、実際の試算の裏付けが必要です。一方向では真実であり、別の方向では誇張されています。以下の数字は、平均取引額$100（一般的なSaaSのサブスクリプションが収まる$20から$200の範囲の中間値）と、顧客の大半が国内であることを前提にしています。自社の取引規模や、請求エンジンと組み合わせる決済処理事業者（Stripeが合わない場合はStripeのベストな代替ツールを参照）によって、すべての数字は変わるため、固定された結論ではなく、再計算するためのモデルとして扱ってください。

Merchant of Recordの経路にかかるコスト

どちらの数字も、各ベンダー自身が公開している計算式からそのまま導いたものです。Paddleは顧客の所在地にかかわらず一律で、Lemon Squeezyは国際取引の構成比に応じて上がります。これは、本コレクションのPaddleとLemon Squeezyの比較で、同じ上乗せ料金を試算した方法と一致します。

自社でスタックを運用すると実際にいくらかかるか

「請求エンジンに切り替えればよい」という主張の多くが見落としていることがあります。Zoho Billingのサブスクリプション料金は、請求額のすべてではないということです。別途請求されるStripeの標準の2.9% + $0.30で決済ゲートウェイが必要で、さらにZoho Billingは請求書上の税額を計算するだけで、登録も納付も代行しないため、税務は社内で、またはTaxJarやAvalaraなどのツールを通じて自社で処理する必要があります。

TaxJarが公開しているティアの上限は月間200件の注文で、取引額$100の場合は年間およそ$240,000にあたり、ここで試算している$100Kのティアをじゅうぶんに超えています。年間100万ドルに達すると、販売者は月におよそ833件の注文を処理することになり、TaxJarの公開されているどちらのティアがカバーする範囲もはるかに超えます。その段階で、事業者は通常、見積もりのみで価格が決まるAvalaraのようなエンタープライズ水準のプラットフォームへ移行します。報告されている第三者の集計データによると、実際のAvalaraの契約は年間$7,404から$69,996と幅が広く、中央値は$19,356付近です。これこそが、「規模が大きくなったときに税務コンプライアンスを自社で持つ費用はいくらか」という問いへの率直な答えです。収益の数字だけでなく、いくつの管轄区域に登録しているかによって決まります。

分岐点を並べて比べる

本記事で示した前提では、年間収益がおよそ**$40,000**を超えたあたりで、2つの経路のコストはほぼ同じになります。その線を下回る範囲では、Merchant of Recordの割合のほうが、単にシンプルなだけでなく、実際に安くなります。固定のソフトウェアのサブスクリプションに、別の決済処理事業者と、別の税務ツールを加えると、小さな収益の5%よりも実際の金額が多くなるからです。それを上回る範囲では、ソフトウェアの経路の優位は本物ですが、タダで手に入るものではありません。税務コンプライアンスの費用が妥当な水準にとどまる場合にしか成り立たず、それは収益ではなく管轄区域の数によって決まります。年間100万ドルで60か国に販売している企業は、ソフトウェアの経路が勝つと決めつける前に、自社のネクサスの構成でこのモデルを再計算すべきです。

Lemon Squeezyの買収：2026年、Stripeによる所有の実際の状況

Lemon Squeezyが候補リストに入っているなら、2回読む価値があります。「終わりかけている」と「通常どおり運営されている」という2つの安易な見方は、どちらも誤りです。

サービスは終了しません。 StripeがLemon Squeezyを買収したのは2024年7月で、現在も既存の料率で取引を処理しており、終了日は発表されていません。Lemon Squeezy自身の経営陣は、終了ではなくStripe Managed Paymentsを今後の道筋として公に説明しており、製品を畳むのではなく、そこへの移行ツールをチームが積極的に構築していると述べています。

新規の登録は制限されており、再開の時期は何度も動いています。 2026年を通じた複数の報道は、新規加盟店のアクセスをウェイトリスト制と説明しており、経営陣は2026年半ばに、招待なしの一般登録が近いと述べています。Lemon Squeezyのサイトには、本記事のために現在の正確な状況を直接確認しようとしたときには到達できなかったため、「ウェイトリスト、まもなく開放」を確定した事実ではなく率直な読みとして扱い、これを前提に計画を立てる前に、直接アクセスを確認してください。

実際の後継サービスは、Lemon Squeezyの現在の料率よりも高く、そのまま置き換えられるものでもありません。 Stripe Managed Paymentsは2026年2月に公開プレビューに入り、Stripe自身のドキュメントによると、標準の決済手数料に上乗せして取引ごとに3.5%を課します。国内でもすべて込みの実効料率は6%を超え、国際取引ではさらに高くなり、Lemon Squeezyの一律5% + 50cを大きく上回ります。機能も同等ではありません。Stripe CheckoutとPayment Linksでしか動作せず、サブスクリプションにはその上にStripe Billingを重ねる必要があり、Stripe Connect、サードパーティの税務連携、顧客オブジェクト上の単発の請求書には対応していません。いまLemon Squeezyを評価している購入者は、同一でより安い後継サービスが待っているプラットフォームを選んでいるのではありません。後継となりそうなサービスのほうが、費用は高く、できることは少ないものを選んでいるのです。

支払いのタイミング

3社とも、本記事のために確認できたページには、詳細で引用しやすい支払いスケジュールを完全には公開していないため、以下の個別の内容は、固定された数字ではなく、直接確認するための枠組みとして扱ってください。

構造的なポイントのほうが、どの個別の数字よりも重要です。Merchant of Recordの場合、支払いは相手側の時計に従い、新規アカウント、リスクによる保留、送金手数料に関する相手側自身のポリシーで決まります。Zoho Billingの場合、決済ゲートウェイが提供する条件をそのまま引き継ぐため、その関係を独立して選べ、後から請求ツールを切り替えても、資金を保管する相手が変わるわけではありません。

チャージバックと紛争対応

これは、誰がMerchant of Recordであるかから直接導かれることです。PaddleとLemon Squeezyは自社とカードネットワークの間に立つため、紛争は法的には両社が争うものであり、すでに課している割合に比べれば小さな1件あたりの手数料がかかります。Zoho Billingはそもそも決済の当事者ではないため、紛争に関する役割がまったくありません。ゲートウェイが手数料を設定し、結果にかかわらずそれを受け取るため、チャージバックへの対応プロセスを構築または購入するのは、すべて自社の負担になります。カードの紛争ではなく、未払いの請求書の回収こそが本当の課題であるチームには、比較している3つのプラットフォームのどれよりも、ベストな売掛金管理ソフトウェアのガイドのほうが直接役立ちます。

乗り換えた場合、顧客とサブスクリプションのデータはどうなるか

この判断の側面は、料金の話がすでに決まった数か月後、あるいは数年後に表れるため、前もって理解しておく価値があります。

PaddleとLemon Squeezyはすべての取引の法的な加盟店であるため、保存された支払い方法、つまり顧客にカード情報を再入力してもらわずにサブスクリプションを更新できるトークンは、自社ではなく、プラットフォーム自身の加盟店アカウントの中にあります。どちらかから乗り換える場合、顧客レコード、サブスクリプションの履歴、請求書のデータはエクスポートできるのが標準的ですが、保存された支払い方法は一般にそれと一緒には移せません。カードのトークンは、加盟店アカウントの間を移動しないためです。実際には、次の移行先で、有効な顧客全員に支払い情報を再入力してもらう必要があるということで、規模の大小を問わず、サブスクリプションの基盤にとって現実の解約リスクです。

Zoho Billingは、その線のもう一方の側にあります。自社が、接続したどの決済ゲートウェイでも、一貫してMerchant of Recordであるため、顧客との決済関係はすでに自社が所有するアカウントの中にあり、Zoho Billing自体からは独立しています。同じゲートウェイを保ったまま、後で別の請求エンジンに移れば、支払い方法はそのまま使えることが多くなります。すでに自社が管理している決済処理事業者との関係の上にある、請求書発行の層を入れ替えるだけで、加盟店アカウントを入れ替えるわけではないからです。

これが、「どちらが安いか」を問いの半分としてしか扱わない理由の最も明確な論拠です。Merchant of Recordの手数料は、今日の利便性を買うものであり、その代償として後の乗り換えの摩擦を負います。多くの事業者にとって妥当な取引ですが、あくまで取引であり、タダで得られる改善ではありません。

導入、リスク、ガバナンス

Merchant of Recordの導入コストは、大半が登録と連携の手順であり、税務と不正のリスクは、その後はプラットフォームが吸収します。Zoho Billingのコストは逆方向に働きます。初日の負担は小さいものの、継続的な負担は大きくなります。ほとんどの企業が社内で構築したことのないコンプライアンス機能を、自社のチームが持つことになるからです。その上限も指摘しておく価値があります。年間請求額が100万ドルに近づく企業は、上限に達する前にEnterpriseの話し合いが必要です。StandardとPremiumは、その線を超えると徐々に劣化するのではなく、動かなくなるからです。自社がMerchant of Recordのままでいることが目標でも、Zoho Billingが適切なエンジンではない場合は、ChargebeeとRecurlyの比較が、より複雑なサブスクリプションのロジックに向けて作られた2つの請求エンジンを取り上げています。

Lemon Squeezyが正解になる場合

• すでに有効なアカウントを持っている。 現在の状況から見て、いますぐ乗り換える必要はありません。
• 顧客のほぼ100%が国内にいる。 そのため、国際取引の1.5%の上乗せが適用されることはなく、現在のウェイトリストも実際に通過できます。
• 将来の移行を見込んで計画できる。 恒久的な移行先と考えるのではなく、おそらくより高い実効料率でStripe Managed Paymentsへ移ることになる前提で進められる場合です。

Paddleが正解になる場合

• 今日からグローバルに販売を始める必要がある。 アカウントのアクセスを待てない場合、あるいは国境を越えた販売が多く、上乗せの重なりを試算しなくて済む一律の料率がほしい場合です。
• 年間収益がおよそ$40,000未満である。 この範囲では、Merchant of Recordの割合は、運用上のシンプルさだけでなく、自社でスタックを運用する固定費にも実際に勝ちます。
• 税務とチャージバックの責任を、完全に自社の手から外したい。 それが、分岐点を超えてもなお割高な料金を払う価値があると判断している場合です。Paddleの料金体系がそれでも合わない場合は、Paddleのベストな代替ツールが、Merchant of Recordの分野をより広く取り上げています。

Zoho Billingが正解になる場合

• すでにZoho Books、Zoho CRM、Zoho Oneを使っている。 請求データを、そのスタックにネイティブに流したい場合です。
• 分岐点をじゅうぶんに過ぎている。 本記事の前提で、およそ年間$40,000を超えており、税務登録を自社で担う意思がある、またはすでに会計士や税務自動化ツールを用意している場合です。
• 直接管理したい。 チェックアウト、督促の文面、決済との関係を自社で管理し、収益に応じて予測しにくく増える割合ではなく、予算を組める透明性のある公開料金を求める場合です。

意思決定フレームワーク

次のステップ

1. 実際の管轄区域の数を数え、実際の平均取引額を見積もってください。 どちらも分岐点を動かし、本記事の$100という前提は、自社の事業に合わないかもしれません。
2. Lemon Squeezyへのアクセスは、直接確認してください。 人づてに読んだウェイトリストの状況を前提に計画しないでください。
3. Zoho Billingの固定料金がすべての費用だと考える前に、実際の税務コンプライアンス層の費用を見積もってください。 TaxJar、Avalara、または会計士の見積もりです。そうなることはほとんどありません。
4. チャージバックの手数料と支払い条件は書面で取り、移行のリスクは、購読者の基盤が大きくなって費用が高くなる前に、いまのうちに検討してください。

関連して挙げておくべき課題が1つあります。本当の摩擦が請求の仕組みではなく、収益データがCRMや商談履歴から切り離されていることにある場合、この3つはどれもそれを解決しません。ReworkのIncomesモジュールは、そのデータを、営業パイプラインの他の情報と同じ顧客レコードに保持します。ただし、計測、日割り計算、税の納付のエンジンではなく、その役割については上の3つのプラットフォームのどれも置き換えません。

---

関連リソース：

• PaddleとLemon Squeezyの比較：2026年、自社のSaaSに合うMerchant of Recordはどちらか
• 2026年のベストなサブスクリプション請求ソフトウェア
• Paddleのベストな代替ツール
• 2026年のベストな売掛金管理ソフトウェア
• ChargebeeとRecurlyの比較
• Stripeのベストな代替ツール

Camelliaは、B2Bおよびデジタルプロダクトのチーム向けに、請求、レベニューオペレーション、財務ツールについて執筆しています。料金は2026年8月にベンダーの料金ページで確認しました。