필사 모드: B2B SaaS ビリング & メータリング 2026 完全ガイド — Stripe Billing・Paddle・Lago・OpenMeter・Orb・Chargebee・Recurly・Metronome 深掘り

プロローグ — ビリングは決済ではない

2026年にSaaS創業者が最初にハマる幻想:「決済はStripe Checkoutを一行入れればいい」。

3ヶ月後の現実:プロレーションを誤って返金リクエストが殺到し、EU VATの申告漏れで会計士に怒られ、従量課金に切り替えようとするとStripeだけではメータリングが追いつかず、韓国法人の顧客から「세금계산서(税金計算書)」を出してくれと言われる。

**ビリングは決済ではない。** 決済はビリングの一部品にすぎない。ビリングとは:

- サブスクリプションのライフサイクル — トライアル、アップグレード、ダウングレード、一時停止、解約

- プロレーション — 月の途中でプラン変更したときの日割り計算

- 使用量メータリング — APIコール、トークン、GB単位の集計

- インボイス — PDF発行、適格請求書、会計連携

- 税金 — VAT、GST、米国 sales tax、消費税

- ダニング(dunning) — 決済失敗時のリトライ、カード期限通知

- 売上認識 — ASC 606、MRR/ARR、繰延収益

- マルチ通貨、マルチ決済手段、マルチ法人

2026年にこのすべてを一つのツールでやろうとする試みは、ほとんど失敗する。**ビリングはフルスタック**であり、各レイヤーで強者が違う。

この記事は2026年5月時点のB2B SaaSビリング・メータリング・フルスタックを解剖する。Stripe BillingからPaddle、Lago、OpenMeter、Orb、Metronome、Chargebee、Recurly、Zuora、そして韓国・日本の決済ゲートウェイまで。

1章 · なぜビリングは難しいのか

ビリングが「決済一行」で終わらない理由を、まず押さえる。

**プロレーション(proration)。** ユーザーが5月15日に`Pro`プランから`Business`プランへアップグレードしたら? 残り16日分を日割りで差額請求する必要がある。ダウングレードは? 返金か、クレジットか、次の請求サイクルに反映か。これはポリシー判断であり、ビリングエンジンがそのポリシーをコードで表現できなければならない。

**税金。** EU VATはB2B/B2Cで異なる。米国 sales tax は45州で異なる。韓国は付加価値税10%に加え税金計算書発行が義務。日本は消費税に加え、2023年から適格請求書(インボイス制度)が始まった。グローバルSaaSはここを誤ると脱税犯になる。

**通貨。** USDで請求するとEUの顧客は為替変動に苛立つ。EUR/JPY/KRWで請求すると換算・精算が複雑になる。

**トライアル。** 14日無料、カード登録の要否、トライアル終了後の自動課金、トライアル中のアップグレード。

**アップグレード/ダウングレード。** 即時 vs 次サイクル、シート追加 vs 減、プラン変更時の使用量キャリーオーバー。

**ダニング。** カード決済失敗時のリトライ間隔、何回失敗で解約とみなすか、メールのトーン、ユーザーがカードを更新するセルフサービスページ。

**返金。** 部分返金、クレジットノート、会計上の処理。

**地域規制。** 韓国の電子税金計算書発行義務、EUのSCA(Strong Customer Authentication)、米国のOFAC制裁国遮断、日本のインボイス制度(2023年施行)。

これを全部自前で書くと6ヶ月が消える。**だからビリングが産業になった。**

2章 · 価格モデル5種 — flat-fee, per-seat, usage-based, tiered, hybrid

ビリングツールを選ぶ前に**価格モデル**を決める必要がある。ツールごとに得意なモデルが違う。

**Flat-fee(定額制)。** 月`$99`固定。シンプルで予測可能。Notion Personal Pro、Linear Starterのような小規模チーム向けで一般的。Stripe Billingが最も得意。

**Per-seat(シート単価)。** ユーザー1人あたり`$10/mo`。Slack、Notion Team、Linear Businessが代表。シート追加・減少時のプロレーションが必須。すべてのツールが対応するが、シート扱いのディテールが異なる。

**Usage-based(従量)。** APIコール1万件あたり`$5`、GB単位`$0.10`。Twilio、AWS、OpenAI APIが代表。2023~2026年に最も急成長したモデル。これが**メータリング(metering)**ツールが必要な理由。

**Tiered(階段式)。** 1万件まで`$0.10/件`、1万~10万件は`$0.08`、10万件以上は`$0.05`。ボリュームディスカウント。Twilio、SendGrid、Postmarkがこの形式。あるいは`Starter $29 (10 seats), Pro $99 (50 seats), Enterprise (custom)`のようなパッケージ階層も。

**Hybrid(ハイブリッド)。** ベース料金+使用量超過。`Pro $99/mo (10kコール含む、超過分は1件あたり $0.005)`。PLG SaaSの事実上の標準になった。Datadog、Segment、Linear Businessがこの方式。

**2026年のトレンド: usage-based + hybridがPLG SaaSのデフォルト。** Per-seatはエンタープライズ、flat-feeはインディーSaaSに残った。a16zの2024年調査では、SaaS企業の**41%が従量課金を採用**したと報告されている。

3章 · Stripe Billing — 業界標準

2018年に登場したStripe Billingは、2026年でもSaaSビリングの**事実上の標準**。

**主要機能。**

- **Subscriptions** — サブスクリプションのライフサイクル管理(作成・アップグレード・解約・一時停止)。

- **Invoices** — PDFインボイスを自動生成、メール送付、hosted invoice page。

- **Metered billing** — `usage_records` APIで使用量を報告、周期終了時に自動課金。

- **Customer Portal** — ユーザーがカード変更・プラン変更・解約をセルフでできるホスト型ページ。

- **Stripe Tax** — グローバル税の自動計算・申告補助。2021年ローンチ、2024年拡張。

- **Webhooks** — `invoice.paid`、`customer.subscription.updated`などのイベントフック。

**強み。**

- 開発者体験は最高クラス。SDK・ドキュメント・テストカード・ダッシュボードのすべてが一級。

- カード決済(PSP)+ビリングが統合 — インボイス発行から決済まで一つの流れ。

- グローバル — 40カ国超、135通貨超、Apple Pay・Google Pay・SEPA・iDEAL・Bancontact。

- エコシステム — Zapier・Segment・HubSpot・Salesforce連携が成熟。

**弱み。**

- **従量課金は弱い。** `usage_records` APIは単純なカウンターで、重複除去・次元分離・遅延イベントなど複雑なメータリングは自前。

- **MoRではない。** StripeはPSP — 税金申告・返金・チャージバックの責任はセラー(あなた)。Stripe Taxは計算を助けるが、申告は自分で。

- **エンタープライズ機能は不足。** 複雑な売上認識(ASC 606)、多段階承認、見積〜請求の流れ(quote-to-cash)は弱い。

**価格(2026)。** カード決済2.9% + `$0.30`、Stripe Billingはインボイス金額の0.5%~0.8%追加。Stripe Taxは取引の0.5%。

**主なユーザー。** Notion、Slack、Linear、Vercel、Figma(一部)、Cursor、Anthropic Console。

4章 · Paddle — Merchant of Record(MoR)

Paddleは**MoR(Merchant of Record)**の代表格。Stripeとの最大の構造的違い。

**MoRとは?** Paddleがあなたに代わって販売者になる。顧客はPaddleに支払い、Paddleが税金を処理してあなたに精算する。すなわち:

- **税金申告・納付の責任はPaddle側にある。** EU VAT、米国 sales tax、豪州 GST など、Paddleが処理。

- **チャージバック・返金もPaddle側。** Stripeならあなたが紛争対応するが、Paddleでは Paddle が対応。

- **PCIコンプライアンス負担なし。** Paddleがカード情報を扱う。

**代わりに手数料が高い。** カード決済5% + `$0.50`程度。Stripe(2.9% + `$0.30`)の2倍ほど。その代わり税金・法務の負担を丸ごと持っていく。

**誰に合うか?**

- インディーSaaS、ブートストラップ創業者 — 会計士を雇わずグローバル販売。

- B2C SaaS、デジタルダウンロード — 多国税処理が負担。

- 小規模SaaS — 1人運営、税務申告の時間がない。

**誰に合わないか?**

- 米国・自国内需中心のB2B — 税金負担が小さく、手数料がもったいない。

- エンタープライズ — Net-30 インボイス、ACH・送金決済の方が重要。

**Paddle Billing(2024年ローンチ)。** 旧 Paddle Classic は一回購入中心だったが、2024年の新 Paddle Billingがサブスクリプション・メータリング・カスタマーポータルを完備。Stripe Billing直接競合。

**主なユーザー。** Userlist、Beamer、BrowserStack(一部)、多数のインディーSaaS。

5章 · Lago — オープンソース従量課金ビリング

Lagoは**Y Combinator W21**出身のオープンソース・ビリングエンジン。2021年スタート、MITライセンス。

**ポジショニング。** "オープンソースの Chargebee + Stripe Billing"。従量課金に特化。

**主要機能。**

- **セルフホストまたはクラウド** — Dockerで自前ホスト、または Lago Cloud。

- **Events API** — 使用量イベントを収集(APIコール、GB処理、メッセージ送信など)。

- **Plans & Charges** — プラン・料金・階層・パッケージをコード/UIで定義。

- **Invoices & Credit Notes** — PDFインボイス、クレジットノート、返金。

- **Stripe・Adyen・GoCardless連携** — 決済はPSPに委ねる。

- **Webhooks、GraphQL API、REST API。**

**強み。**

- **オープンソース — コードを見られる、改変できる、セルフホストできる。** EUデータ主権要件を満たし、メータリングの正確性を自分で確認できる。

- **従量課金がファーストクラス** — Stripe Billing の弱点がLagoの強み。

- **開発者フレンドリー** — API・SDK設計がクリーン、ドキュメントが良い。

**弱み。**

- **税は委ねる** — Stripe TaxやAvalaraを別途連携。

- **カスタマーポータルは基本のみ** — カスタムが必要。

- **エンタープライズ機能は発展中** — quote-to-cash、多段階承認は弱め。

**価格(2026)。** セルフホストは無料。Lago Cloudは売上比例で無料スターター枠あり。

**主なユーザー。** Mistral AI、Pinecone、Vercel(社内一部)、その他メータリング・ヘビーなSaaS。

6章 · OpenMeter — Kubernetesネイティブ・メータリング

OpenMeterは**Apache 2.0**オープンソースの使用量メータリング・エンジン。2022年スタート。

**ポジショニング。** "ビリングではなく、メータリング"。ビリングはStripeやLagoに任せ、**使用量集計の正確性とスケールに集中**する。

**アーキテクチャ。**

- **Kafkaバックボーン** — イベントストリームがKafkaに入る。秒間数万~数十万のイベントを処理。

- **ClickHouse集計** — 時系列集計DB。リアルタイム使用量照会・次元分離・重複除去。

- **CloudEvents標準** — イベントフォーマットが標準化されており他システムと互換。

- **Kubernetesネイティブ** — Helmチャート、Operatorでデプロイ。

**なぜ独立したメータリングエンジンが必要か?**

- **遅延イベント** — 使用イベントが1時間遅れて届いても正確に集計。

- **冪等性(idempotency)** — 同じ `idempotency_key` の重複イベントを自動除去。

- **次元集計** — `customer_id × region × model` の多次元集計。

- **スループット** — Stripe `usage_records` API は秒間数十件が限界、OpenMeterは秒間数万。

**誰に合うか?**

- LLM API会社 — トークン単位メータリング、モデル別・顧客別・地域別の次元。

- CDN・クラウドインフラ — GB・リクエスト・時間単位の大規模メータリング。

- IoT・テレメトリ — 数万デバイスからのイベント大量発生。

**Lagoとの違い。** Lagoはビリング+メータリングのフルスタック、OpenMeterはメータリング専用。組み合わせも可 — OpenMeterで集計、Lago/Stripeで請求。

**主なユーザー。** LLMインフラ企業多数、一部のクラウドスタートアップ。

7章 · Orb — 従量課金ビリングのPLGスター

Orbは**Y Combinator W22**出身、2022年スタート。従量課金PLG SaaSに集中。

**ポジショニング。** "Stripe Billingにはできない複雑な使用量価格を扱う"。Stripe Tax・Salesforce・NetSuiteと深く連携。

**主要機能。**

- **複雑な価格** — 階層+パッケージ+グラデーション、多次元価格、コミット+超過(commit + overage)。

- **リアルタイム使用量ポータル** — 顧客が自分の使用量をリアルタイムで見られるダッシュボード。

- **Salesforce + Stripe + NetSuite連携** — RevOpsフルスタックと接続。

- **売上認識** — ASC 606を自動処理、会計連携。

**強み。**

- **複雑な価格モデルをエレガントに** — Stripe Billingの弱点を完全に埋める。

- **エンタープライズRevOpsフレンドリー** — Salesforce・NetSuite・QuickBooksと深く連携。

- **リアルタイム使用量の可視性** — 顧客が自分のコストをリアルタイムで見られる。

**弱み。**

- **価格が高い** — エンタープライズSaaS価格。インディー開発者には過剰。

- **PSPではない** — StripeやAdyenを別に持つ必要。

- **セルフサービスSaaSに最適化** — インボイス型エンタープライズは別フロー。

**主なユーザー。** Vercel、Replicate、Cohere、Anthropic API、その他PLG SaaS多数。

**価格(2026)。** 非公開。売上比例で通常0.5~1%程度。

8章 · Metronome — OpenAI・Anthropic・Databricksが使う

Metronomeは**Y Combinator**出身、2019年スタート。従量課金ビリング・メータリングのフルスタック。

**ポジショニング。** "AI・インフラ企業のためのビリング"。LLM API・クラウドインフラのメータリング・請求を全部こなす。

**ユーザーがそのままポジショニング。**

- **OpenAI** — ChatGPT Plus・Enterprise・APIの請求の一部。

- **Anthropic** — Claude API・Console のメータリング・請求。

- **Databricks** — DBU 使用量請求。

- **Confluent**、**Nylas**、**Twilio Segment**の一部。

**主要機能。**

- **高スケール・メータリング** — OpenAIレベルのトラフィックを処理。

- **複雑なコミット+超過モデル** — `$1M/yr commit, $0.01/1k tokens overage` のようなエンタープライズ案件。

- **売上認識** — ASC 606、多段階承認。

- **Salesforce・NetSuite・QuickBooks連携。**

**強み。**

- **AI・インフラ企業で実証されたスケール** — OpenAI・Anthropicのトラフィックを捌く。

- **エンタープライズRevOpsフルスタック。**

**弱み。**

- **価格が非常に高い** — エンタープライズ価格、インディー・中小は買えない。

- **セットアップが複雑** — 本格的なRevOpsチームが要る。

**Orb vs Metronome。** 似たポジション、違う市場。OrbはPLG SaaSミドルマーケット、MetronomeはAI・インフラ・エンタープライズ。実務では同じ意思決定テーブルに並ぶことが多い。

9章 · Chargebee — サブスクリプションビリングの伝統強者

Chargebeeは2011年にインド・チェンナイで創業。2026年時点で**サブスクリプションビリングの伝統強者**。

**ポジショニング。** "Stripe と Salesforce の間"。中堅~エンタープライズSaaSのサブスクリプションフルスタック。

**主要機能。**

- **Subscription management** — ライフサイクル全体。

- **Smart dunning** — AIベースの決済リトライ最適化。

- **売上認識** — ASC 606、GAAP。

- **Quote-to-cash** — 見積・契約・請求・回収の統合フロー。

- **マルチPSP** — Stripe・Adyen・Braintree・Authorize.Net など。

- **マルチ通貨・マルチ法人。**

**強み。**

- **エンタープライズSaaS実証済** — Freshworks、Calendly、Okta(一部)、数万顧客。

- **PSP非依存** — 決済ゲートウェイを自由に選択・切替。

- **RevOpsフルスタック** — Salesforce・HubSpot・NetSuite・Xero・QuickBooks連携。

**弱み。**

- **従量課金は平均的** — Orb・Metronome・Lagoに比べ弱い。

- **価格が高い** — 中堅SaaS基準で月数千ドルから。

- **セットアップが複雑** — RevOps人員が必要。

**主なユーザー。** Calendly、Freshworks、Okta(一部)、Pinterest(一部)。

10章 · Recurly — もう一つの伝統強者

Recurlyは2009年創業。2026年時点で Chargebee と同じく中堅~エンタープライズ領域。

**ポジショニング。** Chargebeeとほぼ同じ市場。違いは**ディテールと価格交渉**。

**主要機能。**

- サブスクリプションのライフサイクル。

- 売上認識。

- Smart retries(決済失敗時のリトライ)。

- 税自動化(Avalara・Vertex連携)。

- マルチPSP、マルチ通貨。

**強み。**

- **北米・欧州メディア・エンタテインメントに強い** — Sling TV、AccuWeather、FabFitFun。

- **洗練されたダニングロジック。**

- **カスタマーポータルがきれい。**

**弱み。**

- Chargebee とほぼ同じ。従量課金は平均的。

**Chargebee vs Recurly。** ほぼ同じ市場、ほぼ同じ機能。営業交渉・価格・既存連携で決まることが多い。

11章 · Maxio — Chargify と SaaSOptics の合併

Maxioは2022年、**Chargify(ビリング)とSaaSOptics(SaaSメトリクス・財務)の合併**で誕生。

**ポジショニング。** "B2B SaaS CFO のためのフルスタック"。ビリング+SaaSメトリクス(MRR・ARR・LTV・churn)+財務レポートを統合。

**主要機能。**

- **Advanced Billing(旧 Chargify)** — サブスクリプション・従量・ハイブリッド。

- **Advanced Financial Reporting(旧 SaaSOptics)** — MRR・ARR・churn・コホート分析、ASC 606。

- **会計連携** — NetSuite、Sage Intacct、QuickBooks、Xero。

**強み。**

- **CFOフレンドリー** — ビリングと財務レポートが一つに。

- **SaaSメトリクスのフルスタック** — 別途BIなしでMRR/ARRダッシュボード。

**弱み。**

- **従量課金は平均的** — Chargify時代の弱点が残る。

- **開発者体験は平均的** — Stripe・Lagoに比べ劣る。

**主なユーザー。** 中堅SaaS多数、特に財務チーム主導で導入したところ。

12章 · Zuora — エンタープライズサブスクリプションの絶対王者

Zuoraは2007年創業、2018年NYSE上場。**エンタープライズサブスクリプションビリングの絶対王者**。

**ポジショニング。** Fortune 500のメディア・通信・SaaSのサブスクリプション・インフラ。Salesforceに匹敵するエンタープライズツール。

**主なユーザー。** Zoom(上場前)、Box、DocuSign、NCR、GE、Honeywell、Schneider Electric、Sky、The New York Times。

**主要機能。**

- **Zuora Billing** — サブスクリプションライフサイクル。

- **Zuora Revenue** — ASC 606 売上認識のフルスタック。

- **Zuora CPQ** — 見積・契約・価格。

- **Zuora Collect** — 回収・ダニング。

**強み。**

- **エンタープライズ実証済スケール** — 数百万顧客、数十億ドルの売上を処理。

- **Salesforce深連携** — 営業・ビリング・売上認識の流れが滑らか。

- **複雑なビジネスモデル対応** — B2B2C、マーケットプレイス、使用量+コミット。

**弱み。**

- **非常に非常に高い** — 6桁ドルから。

- **セットアップが非常に複雑** — 通常6~18ヶ月、外部コンサル必須。

- **開発者フレンドリーではない** — 営業・コンサル中心の商品。

**誰向け?** 売上`$50M+`のSaaS、またはメディア・通信・ハードウェアでサブスク移行する大企業。

13章 · 会計連携 — Sage Intacct・NetSuite・QuickBooks Online

ビリングはゴールではない。**ビリングデータは会計システム(ERP)に流れる必要がある。**

**QuickBooks Online (QBO)。** インディー・小規模SaaSのデフォルト。米国・カナダのシェア1位。Stripe・Chargebee・Lago すべてネイティブ連携。

**Xero。** QBO 競合、豪州・NZ・英国で強い。インディーSaaSに人気。

**Sage Intacct。** 中堅SaaSの標準。AICPA推奨。SaaS会計のASC 606処理に強い。Chargebee・Maxio・Zuoraと深く連携。

**NetSuite (Oracle)。** 中堅~エンタープライズERPの絶対王者。SaaS・eコマース・製造のすべてをカバー。`$50M~$500M`SaaSの事実上の標準。

**SAP S/4HANA。** Fortune 500 ERP。巨大SaaSは最終的にここに行く。

**FreshBooks。** フリーランス・1人事業者中心。

**戦略。** ビリングツールを選ぶ際は「**わが社のERPとの連携がネイティブか、自前で書くか**」をまず見る。自前連携は必ず壊れる。

14章 · MoR vs PSP — 誰が税・返金責任を負うか

この記事全体で最も重要なポイントを再掲。

**PSP (Payment Service Provider)。** Stripe、Adyen、Braintree、Worldpay。カード処理のみ。セラーはあなた、税申告・返金・チャージバックの責任はあなた。

**MoR (Merchant of Record)。** Paddle、LemonSqueezy、FastSpring、2Checkout、Cleverbridge。**彼らがセラー**。税申告・返金・チャージバック責任を持っていく。手数料は高い。

| 項目 | PSP (Stripe) | MoR (Paddle) |

| --- | --- | --- |

| セラーは誰か | あなた | MoR |

| 税申告の責任 | あなた | MoR |

| 返金紛争 | あなた | MoR |

| チャージバック費用 | あなた負担 | MoR負担 |

| PCIコンプライアンス | あなた(Stripeが大半処理) | MoR |

| 手数料 | 2.9% + `$0.30` | 5% + `$0.50` |

| 自由度 | 高い | 低い(MoR規定に従う) |

**いつMoR?**

- インディーSaaS、1~2人運営。

- グローバルB2C、多国デジタルダウンロード。

- 会計士・税理士を雇う負担が大きい段階。

**いつPSP?**

- 米国・自国内需中心。

- エンタープライズB2B — インボイス・送金・Net-30が重要。

- 売上が十分大きく税務チームを持つ。

15章 · LemonSqueezy — Stripeが2024年に買収

LemonSqueezyは2021年スタートのインディーMoR。2024年7月に**Stripeが買収**。

**ポジショニング。** "インディーSaaS・デジタル製品のMoR"。Gumroad の SaaS 版。

**なぜStripeが買ったのか?** StripeはPSPで、MoR市場(Paddle・FastSpring)がインディーSaaSで成長していた。LemonSqueezy買収でStripeが直接MoR機能を提供 — 2025年に`Stripe Tax + MoR`統合を発表。

**現在(2026)。** LemonSqueezyブランドは維持、Stripeバックエンドとの統合が進行中。新規インディーSaaSはLemonSqueezyかPaddleを比較する。

**Paddleとの違い。** PaddleはB2B SaaS・中堅に強く、LemonSqueezyはよりインディー・1人開発者フレンドリーなUX。

16章 · FastSpring・2Checkout・Cleverbridge — 別のMoR

MoR市場にはPaddle・LemonSqueezyの他にも古参の強者がいる。

**FastSpring。** 2005年スタート。SaaS・ゲーム・デジタル製品。グローバル税処理。Atlassian、Cisco、JetBrainsなどが使用。

**2Checkout (Verifone)。** 2006年スタート、2017年Verifone買収。グローバル決済+MoR。87通貨、45地域の税対応。

**Cleverbridge。** 1995年ドイツでスタート。B2B・B2Cグローバルeコマース。Acronis、Avira、Corel などセキュリティ・ユーティリティソフトに強い。

**戦略。** Paddle・LemonSqueezyの方がモダンだが、FastSpring・2Checkout・Cleverbridgeはより古く、グローバルカバレッジが広い。JetBrainsのように90カ国以上で販売する場合はFastSpringが選択肢。

17章 · 税スタック — Stripe Tax・TaxJar・Avalara・Vertex

ビリングツール選びと同じくらい重要なのが**税スタック**。

**Stripe Tax。** Stripe統合、自動税率計算、登録補助。EU VAT・米国 sales tax・カナダ GST・豪 GST・日本消費税対応。価格:取引の0.5%。**インディー・中小SaaSのデフォルト。**

**TaxJar。** 2013年スタート、2021年Stripeが買収。米国 sales tax 専門、自動申告サービス(AutoFile)。米国50州全部カバー。Stripeが買収したが単独製品として維持。

**Avalara。** 2004年スタート、米国NYSE上場(2022年PEが取得、2024年完全非公開化)。エンタープライズ税自動化の絶対王者。AvaTax、Returns、CertCapture。Fortune 500多数。**Chargebee・Recurly・NetSuite・Zuora が全て連携。**

**Vertex。** 1978年スタート。エンタープライズ税専門。Avalara直接競合。大手製造・小売で強い。

**Sovos。** 2014年の合併で誕生。グローバル税・インボイスコンプライアンス。EU電子インボイス義務化に強い。

**Sphera。** Sovosの子会社。環境・規制コンプライアンス専門。

**戦略。** 売上ステージ別 — `$0~$5M` Stripe Tax、`$5M~$50M` Avalara/Vertex、`$50M+` Avalara フルスタック+自社税務チーム。

18章 · 韓国決済 — Toss・KG Inicis・NICE・KCP・KakaoPay

韓国SaaSはグローバルSaaSと決済フローが違う。**PG(Payment Gateway)とカード会社が分離**しており、税金計算書発行が義務。

**Toss Payments。** Viva Republica(Toss)子会社。2026年時点で韓国PGシェアが急上昇。**韓国PGの中で開発者体験は最高** — Stripe級のSDK・ドキュメント・テスト環境。定期決済、認証決済、簡易決済、海外決済すべて対応。

**KG Inicis。** 1998年スタート、韓国PG第一世代の強者。インディー・中小ECで多用。APIは古いスタイルで連携コストはある。それでも韓国カード会社のカバレッジは最も安定。

**NICE Payments。** 韓国情報インフラ大手NICEグループ。カード認証・定期決済・簡易決済・海外決済。大企業・金融顧客が多い。

**KCP(韓国 Cyber Payment)。** 1996年スタート、NHN子会社。KG Inicisと並ぶ第一世代PG両雄。

**KakaoPay。** 2014年スタート。B2C簡易決済に強く、B2B定期決済にも拡大。Stripe Korea登場前の大選択肢。

**Stripe Korea。** 2022年から韓国進出作業、2024年正式ローンチ。グローバルSaaSの韓国請求を簡単化。ただし**税金計算書発行は別途**必要 — 通常はKISA電子税金計算書システムと連携。

**韓国ビリング標準パターン。**

- グローバルSaaS:Stripe + 韓国法人売上は税金計算書を別途。

- 韓国土着SaaS:Toss Payments + 自前定期決済 + 税金計算書システム(例:Bill36524)。

19章 · 日本決済 — GMO・SoftBank・Stripe Japan・PayPay

日本は韓国と似ていて違う。**消費税+適格請求書(インボイス制度、2023年施行)**が変数。

**GMO Payment Gateway。** 1995年スタート、日本PGシェア1位。カード・コンビニ・銀行振込・電子マネーをカバー。カード会社のカバレッジが安定。

**SoftBank Payment Service。** SoftBankグループ。GMO直接競合。

**Stripe Japan。** 2016年ローンチ。日本のカード(JCB含む)完全対応。日本語ダッシュボード・ドキュメント。SaaS決済のグローバル標準を日本に持ち込んだ。

**PayPay。** 2018年 SoftBank・ヤフー合弁。B2C QR決済シェアが圧倒的。SaaSは通常カード決済で、PayPayはB2C・小売に強い。

**LINE Pay。** 日本・台湾・タイで LINE ベース。日本SaaS B2Bではほぼ使われない。

**Pay.JP。** 日本インディーSaaS PG。JCBカードに強い。

**日本ビリング標準パターン。**

- グローバルSaaSの日本進出:Stripe Japan + 適格請求書発行システム(MoneyForward・freee)。

- 日本土着SaaS:GMO Payment + 自前システム。

20章 · 日本SaaSビリング — freee・MoneyForward・smartHR・Yappli

日本SaaSのビリング・財務スタックは韓国・米国とまた違う。

**freee。** 2012年スタート、東証上場。日本中小企業クラウド会計1位。請求・インボイス・税申告・給与のフルスタック。適格請求書(インボイス制度)発行を自動化した事実上の標準。

**MoneyForward。** 2012年スタート。freee 直接競合。会計・請求・給与・経費精算。中堅~エンタープライズに強い。

**smartHR。** 2015年スタート。HRクラウド1位。ビリングツールではないが、日本SaaSビリングはfreee・MoneyForwardと共にフルスタックRevOpsの一軸。

**Yappli。** 2013年スタート、ノーコードモバイルアプリビルダー。自前ビリング・サブスクリプション管理を日本市場向けに作り込み。

**戦略。** 日本市場進出SaaSはfreeeまたはMoneyForwardとのインボイス連携が必須。韓国・米国の会計ツールでは日本の適格請求書を作れない。

21章 · 韓国SaaS事例 — Channel.io・Allganize・NinjaCart・Toss Payments

韓国でB2B SaaSビリングをどう解いているか。

**Channel.io(チャネルトーク)。** 2014年スタート、日本進出。シートベース+従量のハイブリッド。自前ビリング+Toss Payments・海外はStripe。

**Allganize。** 2017年スタート、エンタープライズLLM。エンタープライズ見積〜請求フロー、自前ビリング+Stripe。

**NinjaCart。** インド発だがグローバル、農業SaaS。多国決済。

**Toss Payments。** PGだが自社でSaaSビリングツールも作る — `Toss Payments`定期決済API。韓国SaaSの事実上の標準になりつつある。

**B2B 韓国SaaSビリング・パターン。**

- シード・シリーズA:Toss Payments+自前ビリングコード(3ヶ月で後悔)。

- シリーズB+:Stripe Korea+Chargebee/Lago+Toss Payments補助。

- グローバル進出:Stripe(グローバル)+Toss Payments(韓国)+税金計算書システム。

22章 · Webhookと冪等性 — ビリング安定性の核心

ビリングが最も頻繁に壊れる地点が**Webhook処理**。

**問題。** Stripe・Paddle・Lagoが`invoice.paid`を送る。あなたのサーバが受けてDBに「有料ユーザー」とマーク。しかし:

- 同じイベントが2回届きうる(Stripeのリトライ)。

- サーバが処理中に死ぬとStripeがリトライ。

- 順序が逆転しうる(`subscription.created`の前に`invoice.paid`)。

**解決:冪等性(idempotency)。**

- **`event.id`をDBに保存。** 処理済みは無視。

- **すべてのハンドラを冪等に。** 同じイベントが10回来ても結果は同じであるべき。

- **イベントキューで非同期処理。** Webhookは即座に200 OKを返し、本処理はバックグラウンドジョブ。

- **リトライ可能な作業として設計。** DBトランザクション・idempotency キーパターン。

**ツール。** Stripe・Paddleはイベントに`id`を付与。Inngest・Trigger.dev・Hatchet・Temporalのようなワークフローツールで、webhookをキュー化し冪等処理するパターンが2026年の標準。

23章 · RevOps — ASC 606、MRR、ARR、Churn

ビリングは単にお金を受け取るだけでなく**会計・財務レポート**につながる。この領域がRevOps(Revenue Operations)。

**ASC 606(売上認識基準)。** 米国会計基準。**現金を受け取っただけでは売上ではない。** サービスを提供した分だけ売上。年間サブスク料金を一括で受け取っても、月ごとに1/12ずつ売上認識する。SaaS会計の核心。

**MRR(Monthly Recurring Revenue)。** 月次定常収益。SaaSの最重要メトリクス。

**ARR(Annual Recurring Revenue)。** MRR × 12。投資家向け標準指標。

**Churn(解約率)。** 顧客数ベース(logo churn)、売上ベース(revenue churn)、純(net)churn(拡張売上考慮)。

**Expansion revenue。** 既存顧客のアップグレード・シート追加。健全なSaaSは net revenue retention が110%以上。

**ツール。** Maxio、ChartMogul、ProfitWell(現在Paddle子会社)、Baremetrics。Stripe Sigma で直接SQLクエリも可能。

**戦略。** シードはStripe Sigma+スプレッドシート、シリーズAからChartMogul・ProfitWell、シリーズB+からMaxio・NetSuite RevOps フルスタック。

24章 · オープンソース代替 — Killbill・Crater・InvoiceShelf

商用ビリングが高ければオープンソースもある。2026年時点で生きている選択肢。

**Killbill。** 2010年スタート、Apache 2.0。**JBoss出身者が作ったJavaビリングエンジン。** エンタープライズスケール。Lagoより大きいサイズを処理できるが、Java+運用負担が重い。

**Lago。** 上で既に扱った。メータリング+ビリングのモダンOSS。

**Crater。** Laravel/PHPベースのインボイスツール。SaaSフルスタックではないが単純請求には良い。

**InvoiceShelf(旧 InvoicePlane)。** PHPインボイス。シンプルなフリーランスツール。

**Cosmos.js、Laravel Cashier** — フレームワーク内蔵のビリングヘルパー。Stripe・Paddle 連携をコードで。

**戦略。** 100%オープンソースに行く理由は(1)EUデータ主権、(2)政府・国防コンプライアンス、(3)セルフホスト方針。それ以外ではSaaSビリングの料金はそこまで高くない — 時間コストの方がずっと大きい。

25章 · 意思決定マトリクス — どのビリングを選ぶか

ここまでの内容を整理する決定テーブル。

| ステージ / モデル | 推奨スタック |

| --- | --- |

| インディーSaaS、B2C、1~2人 | Paddle または LemonSqueezy(MoR) |

| インディーSaaS、B2B | Stripe Billing + Stripe Tax |

| PLG SaaS、シード~シリーズA、従量 | Stripe + Lago または Stripe + Orb |

| PLG SaaS、シリーズB+、AI/インフラ | Stripe + Metronome または Stripe + Orb |

| シートベース中堅SaaS | Chargebee または Recurly + Stripe/Adyen |

| 中堅SaaS+財務フルスタック | Maxio + Stripe |

| エンタープライズ(`$50M+` ARR) | Zuora + Salesforce + NetSuite + Avalara |

| 韓国土着SaaS、B2B | Toss Payments + 自前ビリング、または Stripe + 税金計算書 |

| 日本進出SaaS | Stripe Japan + freee/MoneyForward(適格請求書) |

| 政府・国防・EU データ主権 | Lago/Killbill セルフホスト + 自前PSP |

**3つの核心原則。**

1. **ステージに合わせて始める。** シードでZuoraを入れると12ヶ月消える。Stripe Billingで始め、売上成長に合わせて入れ替え。

2. **従量課金ならメータリングエンジンを別途見る。** Stripe `usage_records` だけでは限界。Lago・OpenMeter・Orb・Metronome の中から。

3. **グローバルならMoRを真剣に見る。** 会計士・税理士不在のインディーSaaSは、Paddle・LemonSqueezy の5%手数料が自由の値段。

26章 · アンチパターン10選

ビリングでよく見るミス。

1. **`paid_at`カラムだけ見て有料ユーザー判定。** 返金・チャージバック・クローバックを取りこぼす。常に`subscription.status`を見る。

2. **Webhookハンドラで同期に重い作業。** Stripeの5秒タイムアウト → リトライ嵐。キューで非同期。

3. **冪等性キーなしのWebhook処理。** 同じイベントで2回課金。

4. **`amount_paid`を売上認識。** ASC 606違反。サービス期間で按分。

5. **税金を後で足す。** 表示価格と請求価格の差で返金嵐。EUはVAT込み表示が義務。

6. **プロレーション自作。** Stripe・Chargebeeがやってくれるのを自前実装してバグ大量。

7. **タイムゾーン無視。** UTC基準の請求日とユーザーのローカルがずれる。

8. **ダニングポリシーなし。** カード期限通知・リトライ方針がないと売上の5~10%が漏れる。

9. **カスタマーポータル未提供。** ユーザーがカード更新・解約できずチャージバック紛争へ。

10. **ビリングデータをERPに送らない。** 四半期決算で会計士が泣く。

27章 · 参考 / References

- [Stripe Billing — 公式ドキュメント](https://stripe.com/docs/billing)

- [Stripe Tax — 公式](https://stripe.com/tax)

- [Stripe — Usage-based billing](https://stripe.com/docs/billing/subscriptions/usage-based)

- [Paddle — Paddle Billing](https://www.paddle.com/billing)

- [Paddle — Merchant of Record explainer](https://www.paddle.com/blog/what-is-a-merchant-of-record)

- [Lago — GitHub](https://github.com/getlago/lago)

- [Lago — 公式ドキュメント](https://docs.getlago.com/)

- [OpenMeter — GitHub](https://github.com/openmeterio/openmeter)

- [OpenMeter — 公式](https://openmeter.io/)

- [Orb — 公式](https://www.withorb.com/)

- [Metronome — 公式](https://metronome.com/)

- [Chargebee — 公式](https://www.chargebee.com/)

- [Recurly — 公式](https://recurly.com/)

- [Maxio (Chargify + SaaSOptics) — 公式](https://www.maxio.com/)

- [Zuora — 公式](https://www.zuora.com/)

- [Killbill — 公式](https://killbill.io/)

- [LemonSqueezy — 公式(Stripe子会社)](https://www.lemonsqueezy.com/)

- [FastSpring — 公式](https://fastspring.com/)

- [2Checkout (Verifone) — 公式](https://www.2checkout.com/)

- [Cleverbridge — 公式](https://www.cleverbridge.com/)

- [Avalara — 公式](https://www.avalara.com/)

- [TaxJar — 公式](https://www.taxjar.com/)

- [Vertex — 公式](https://www.vertexinc.com/)

- [Sovos — 公式](https://sovos.com/)

- [Toss Payments — 開発者ドキュメント](https://docs.tosspayments.com/)

- [KG Inicis — 公式](https://www.inicis.com/)

- [NICE Payments — 公式](https://www.nicepay.co.kr/)

- [KCP — 公式](https://www.kcp.co.kr/)

- [GMO Payment Gateway — 公式](https://www.gmo-pg.com/)

- [SoftBank Payment Service — 公式](https://www.sbpayment.jp/)

- [Stripe Japan — 公式](https://stripe.com/jp)

- [freee — 公式](https://www.freee.co.jp/)

- [MoneyForward — 公式](https://corp.moneyforward.com/)

- [NetSuite — 公式](https://www.netsuite.com/)

- [Sage Intacct — 公式](https://www.sage.com/en-us/sage-business-cloud/intacct/)

- [QuickBooks Online — 公式](https://quickbooks.intuit.com/online/)

- [ChartMogul — SaaSメトリクス](https://chartmogul.com/)

- [ProfitWell(Paddle子会社)](https://www.paddle.com/profitwell)

- [a16z — Usage-based pricing 2024 report](https://a16z.com/the-rise-of-usage-based-pricing/)

- [FASB ASC 606 — 公式](https://www.fasb.org/asc606)

— B2B SaaS ビリング & メータリング 2026、終わり。