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~$500MSaaSの事実上の標準。

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つの核心原則。

ステージに合わせて始める。 シードでZuoraを入れると12ヶ月消える。Stripe Billingで始め、売上成長に合わせて入れ替え。
従量課金ならメータリングエンジンを別途見る。 Stripe usage_records だけでは限界。Lago・OpenMeter・Orb・Metronome の中から。
グローバルならMoRを真剣に見る。 会計士・税理士不在のインディーSaaSは、Paddle・LemonSqueezy の5%手数料が自由の値段。

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

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

paid_atカラムだけ見て有料ユーザー判定。 返金・チャージバック・クローバックを取りこぼす。常にsubscription.statusを見る。
Webhookハンドラで同期に重い作業。 Stripeの5秒タイムアウト → リトライ嵐。キューで非同期。
冪等性キーなしのWebhook処理。 同じイベントで2回課金。
amount_paidを売上認識。 ASC 606違反。サービス期間で按分。
税金を後で足す。 表示価格と請求価格の差で返金嵐。EUはVAT込み表示が義務。
プロレーション自作。 Stripe・Chargebeeがやってくれるのを自前実装してバグ大量。
タイムゾーン無視。 UTC基準の請求日とユーザーのローカルがずれる。
ダニングポリシーなし。 カード期限通知・リトライ方針がないと売上の5~10%が漏れる。
カスタマーポータル未提供。 ユーザーがカード更新・解約できずチャージバック紛争へ。
ビリングデータをERPに送らない。 四半期決算で会計士が泣く。

27章 · 参考 / References

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