あなたのAPIの月次経常収益（MRR）が顧客340社で18,000ドルを超え、Stripeのダッシュボードでは健全な粗利率78%を表示し、会計士から収益認識のスケジュールを見せてほしいと言われました。帳簿を開いても何もありません。入金がStripeのレポートと全く一致しない当座預金口座と、3月に更新をやめた表計算ソフトのファイルがあるだけです。
ここに、Micro-SaaSの簿記が破綻するギャップがあります。ビジネスは一見シンプルに見えます。在庫も倉庫もなく、利益率は小売店を泣かせるほどです。しかし、お金の動きは標準的な「収入から支出を引く」という簿記では捉えきれません。従量課金、前払いクレジットパック、銀行に現金が届く前に差し引かれる決済手数料、代行して徴収される世界各国の税金、そして銀行残高を欺く前受収益。これらを間違えれば、売上を過大計上したり、税金を払い過ぎたり、次なる価格戦略を非現実的な数字に基づいて決めることになります。
このガイドでは、Micro-SaaSやAPIビジネスに実際に適合する簿記、すなわち簿記をクリーンに保つための従量課金制の構造化、月末に混乱せずに決済代行業者を照合する方法、そして粗利率70%超のビジネスであっても、なぜ初日から本物の発生主義会計が必要なのかについて説明します。
Micro-SaaSの帳簿が思ったより難しい理由
従来の中小企業は、現金の受け渡しか請求書の支払いがあった時点で売上を記録します。しかし、Micro-SaaSがそのいずれかに該当することはほとんどありません。小さなAPIやAIツールの典型的な1ヶ月を考えてみましょう。
- 120人の顧客が月額29ドルのスタータープラン（APIコール500回分含む）を利用
- 40人の顧客が月額99ドルのプロプラン（コール5,000回分を含み、超過分は1コールあたり0.02ドル）を利用
- 60人の顧客が前払いクレジットパック（2,000クレジットで49ドル）を購入し、不定期に利用
- 1月に年払いで回収したエンタープライズ顧客が数社
どんな日でも、まだ売上になっていない現金を受け取り、数週間前に回収した売上を認識し、請求書を発行していない決済手数料を支払う義務が生じ、まだ請求していない利用料金を引き渡します。現金主義の帳簿は、これらすべてを「入金、出金」に集約し、ビジネスが実際に成長しているかどうかについてはほとんど何も教えてくれません。
Micro-SaaSを際立たせる3つのポイント
単位あたりの変動費。 すべてのAPIコール、AI生成、Webhook配信には、上流のLLMトークン料金、コンピューティング、帯域幅、再販するサードパーティAPIなど、何らかのコストがかかります。定額制サブスクリプションでは、ヘビーユーザーが平均の50倍を消費し、コホート全体の利益を吹き飛ばすまで、この変動性は隠されたままです。帳簿には、総ホスティング費用だけでなく、ユニットあたりの売上原価（COGS）を表示する必要があります。
顧客ごとの変動売上。 同じ29ドルのプランの2人の顧客でも、超過料金やクレジットのチャージが発生すると、売上は大きく異なる可能性があります。サブスクリプション料金のみを計上し、超過分を付随的なものとして扱うと、最も優良な顧客からの収益を過小計上し、価格帯の設定を誤ることになります。
前払い・前受収益。 クレジットパックや年間プランは、今後数週間から数ヶ月にわたって提供するサービスに対して、今日の現金をもたらします。その現金は、顧客が実際にクレジットを消費するか、サービス期間が経過するまで、負債（未稼得収益）です。これを受け取った時点で収益として計上すると、現在の利益が過大表示され、後で過小表示されることになり、ローン、バリュエーション、実態と一致する納税申告書が必要になった瞬間に重要になります。
元帳で扱える請求モデルの選択
選択する請求モデルは、価格設定の決定であると同時に、簿記上の決定でもあります。それぞれが、異なる認識、照合、税金イベントを作り出します。
定額制
誰もが利用量に関係なく同じ料金を支払います。簿記は簡単です。顧客ごとに毎回の請求書が1枚ずつ発行され、売上は期間全体にわたって均等に認識されます。問題は会計ではなく経済的なもので、ヘビーユーザーを助長し、ライトユーザーからの収益機会を逃します。定額料金は、消費量を測定する学習段階として機能しますが、単位あたりのコストを把握すると、めったに持続しません。
純使用量ベース（コール、トークン、シート時間あたりの従量課金）
消費量を測定し、事後請求します。収益とコストが連動するため、表計算ソフトでは満足のいくものですが、支出を見積もることのできないエンタープライズ顧客にとっては恐ろしいものです。簿記の観点から言えば、純粋な使用量ベースでは、月末ごとに未請求の売上（サービスは提供したがまだ請求していないもの）が発生します。未収金として計上する必要があります。また、元帳が信頼できる堅牢なメータリングも必要です。請求書はカウンターと同じくらい正確だからです。
ハイブリッド：サブスクリプション基本料金＋無料利用枠＋超過従量課金
これが、ほとんどのMicro-SaaSやAIツールで出現したデフォルトです。毎月のサブスクリプションには、クォータ（クレジット、コール、生成）が含まれており、クォータを超えた消費には、多くの場合、実際のコストの2倍から4倍の単位あたりの超過料金が請求されます。
運用上有利な理由は、購入者は標準的な利用については予測可能性を得られ、ベンダーはヘビーユーザーからより多くの収益を獲得でき、ライトユーザーを怖がらせることもなく、超過料金がコストをはるかに上回る価格であるため、売上総利益率を保護できるからです。帳簿上、ハイブリッド請求では、顧客ごとに2つの収益源が発生します。定期的に認識されるサブスクリプション収入と、超過が発生した時点で認識される変動的な超過収入です。これらは別々の元帳勘定に保管してください。後で「MRRのうち本当に変動する割合は？」と尋ねられたとき、請求書を調べることなく答えが得られます。
実用的なプランのスケッチ：
- スターター 月額19ドル — 生成500回分含む、超過分は1回0.05ドル
- プロ 月額49ドル — 生成2,000回分含む、超過分は1回0.04ドル
- スケール 月額99ドル — 生成6,000回分含む、超過分は1回0.03ドル
各層の顧客の約80%が制限に達しないように、各クォータを設定します。製品は事実上無制限に感じられますが、制限に達する20%がインフラへの資金提供元となります。
プリペイドクレジットパック
顧客はクレジットを前払いで購入し、時間をかけて費やします。クレジットは、現金収入のタイミングを改善し（配信前に入金）、残高が少なくなったときに自然なアップセルのきっかけを与えてくれます。ただし、クレジットを販売するたびに、初日に前受収益が発生します。借方に現金、貸方に負債（例：Liabilities:UnearnedRevenue:CreditPacks）を計上し、クレジットが消費されるにつれてIncome:CreditUsageに移動させます。1,000パックを各49ドルで販売し、その月の収益として49,000ドルを計上することは、銀行口座にとっては問題ありませんが、損益計算書にとっては間違っています。
変換によく使用される一般的な構造：
- 500クレジットで14ドル（有効期限なし）
- 2,000クレジットで49ドル（14%割引）
- 10,000クレジットで199ドル（29%割引、優先処理）
- 月次自動補充：1,500クレジットで月額39ドル（同等のパックより10%ボーナス）
定期的にチャージするパック購入者は、月次自動補充の最良の候補です。クレジットあたりの計算を明確にして、アップグレードがそれ自体で売れるようにしましょう。
成果報酬型
サポートチケットの解決、リードの転換、ワークフローの完了など、成功した成果ごとに課金します。成果が測定可能で価値がある場合は魅力的ですが、成果が実際に発生したことを追跡・証明するためのインフラが必要です。簿記の観点では、各「成果」は、ある時点で満たすパフォーマンス義務であり、すべての請求書を裏付けるための監査証跡が必要です。
決済代行業者の照合：お金が実際にどこへ行くのか
Stripe、Paddle、Lemon Squeezy、またはFungiesやDodo PaymentsなどのMerchant of Record（MoR）を使用している場合、銀行口座に着金する現金は、ダッシュボードに表示される数字と決して一致しません。典型的なStripeのペイアウトは次のようになります。
- 総売上: 12,400ドル
- マイナスStripe手数料（2.9% + 1回あたり0.30ドル、0.5%の請求手数料）: -412ドル
- マイナス返金: -180ドル
- マイナス係争・チャージバック: -45ドル
- 銀行への正味ペイアウト: 11,763ドル
この11,763ドルを「収益」として計上すると、収入が637ドル過少になり、処理コスト、返金率、係争リスクが財務諸表から完全に隠れてしまいます。
照合のパターン
銀行の入金ではなく、プロセッサのレポートに照合します。月末に：
-
プロセッサの決済レポートをインポートします — 製品/プラン別の総売上、手数料、返金、係争、徴収された税金。評判の良いプロセッサは、これらの列を毎日分解したCSVまたはAPIエクスポートを提供します。
-
総売上を適切な収益勘定に計上します。 サブスクリプション基本料金、超過料金、クレジットパックの利用分はそれぞれ別の勘定になります。これは、誰かが差し引く前に顧客が実際に支払った収益です。
Assets:Bank:Checking $11,763
Expenses:ProcessorFees:Stripe $412
Assets:AccountsReceivable:RefundsPending $180
Expenses:Disputes:Chargebacks $45
Income:Subscriptions:Starter
Income:Subscriptions:Pro
Income:Usage:Overage
Income:CreditPacks:Redeemed勘定科目名はご自身で決めていただいて構いませんが、原則は固定されています。売上は総額、手数料と返金は差し引き、銀行には純額が入金されます。
-
手数料は収益の純額ではなく費用として計上します。 決算手数料は収益を集めるためのコストであり、収益の減算ではありません。純額にすると、実際の手数料率が不明確になり、コホート分析が不可能になります。
-
Merchant of Record が徴収する税を正しく処理します。 あなたがMerchant of Record（MoR）を通じて販売する場合、MoRが法的な販売者となり、VAT、GST、米国の売上税の徴収・納付を処理します。MoRの決済レポートの「税」欄は、あなたが納付する義務のあるものではありません（あなたの義務ではありません）。それでも、総売上をレポートに結び付け、純額を銀行に結び付けるためには、それを記録する必要があります。総収入から差し引く創設者もいれば、MoRが送金する際にゼロになる通過勘定に計上する方がすっきりします。
-
返金とチャージバックは別々に追跡します。 返金は収益の取り消しです。チャージバックは、さらに紛争手数料が加算されます。これらをまとめてしまうと、「返金率は上昇しているか？」という問いに答えることができず、不正パターンを早期に発見することもできません。
よくある照合ミス
ペイアウトを収益として計上する。 個人開発者に最もよくあるエラーです。収入を過小評価し（手数料が消えるため）、利益率を過大評価し、年末に1099-Kと帳簿の間に不一致が生じます。
保留中のペイアウトを無視する。 請求済みだがまだ支払われていないプロセッサ残高は、売掛金です。1月31日に帳簿を締める場合、Stripeが1月29日から31日までのペイアウトをまだ行っていない場合、その収益は2月ではなく1月のものです。
接続アカウントのアプリケーション手数料を忘れている。 マーケットプレイスを運営していたり、管理された支払いに加えてアプリケーション手数料を取っている場合、アプリケーション手数料はあなたの収益であり、基礎となる請求はあなたの収益ではありません。あなたの分だけを記帳します。
クレジットパックの売上を前受収益に照合していない。 すべてのクレジットパックの売上には、クレジットが使われるにつれて解消される、対応する負債エントリが必要です。繰延残高は毎月増加しているが認識収益は増加していない場合、顧客が消費するよりも速くパックを販売していることになります。これはキャッシュフローにとっては有用なシグナルですが、販売時の収益として計上していると見えません。
粗利率70%超でも、本物の帳簿が必要な理由
ハイマージンなソフトウェアビジネスに高度な簿記は不要だと思いがちです。ホスティングは安く、在庫もなく、利益は自動的に出るように思えます。しかし、3つの現実がすぐにそれを正します。
実際に原価（COGS）に含まれるもの
Micro-SaaSやAPIビジネスにとって、COGSは「ホスティング」ではありません。それは、使用量に直接比例してスケールし、顧客ゼロ人を維持する場合には存在しないであろうすべてのコストです。
- 上流のAPIおよびLLMトークンコスト（OpenAI、Anthropic、または自社のGPU推論）
- 従量制インフラストラクチャ（リクエストごとのコンピューティング、送信帯域幅、画像生成秒数）
- 再販する第三者データまたはエンリッチメントAPI
- 埋め込みコンポーネントのシートあたりのライセンスコスト
使用量に応じて拡張しないホスティング（静的フロントエンド、管理ダッシュボード、固定データベース）は、運用費であり、COGSではありません。この分割を正しく行うことで、プランや顧客ごとの真の粗利益を計算できます。500世代を含む29ドルのスタータープランは、平均的な使用状況でLLMとコンピューティングに1.50ドルかかるかもしれませんが、2,000世代を使用するパワーユーザーがいる同じプランでは12ドルかかる可能性があります。両方の「売上総利益」が帳簿上同じように表示される場合、適切な価格設定をすることはできません。
単位あたりのCOGSの3〜5倍で超過料金をターゲットにします。世代全体のコストが0.003ドルの場合、超過料金は0.01〜0.015ドルに設定します。これにより、超過料金で70〜80%の売上総利益率が維持され、モデルコストが急上昇したり、顧客が自動化を発見したりした場合に身を守ることができます。
前受収益は銀行残高を欺く
年間前払いやクレジットパックを販売するMicro-SaaSは、現金は潤沢でも利益が上がっていないように見えたり、その逆に見えたりすることがあります。 1月に年間プロプランを40件、各990ドルで販売し、39,600ドルを徴収したとします。現金主義では、1月は過去最高の月です。発生主義では、1月に3,300ドルを稼ぎ、36,300ドルの将来のサービス債務があります。1月のキャッシュを1月の利益と同じように使ってしまうと、12月には不足します。
これは、発生主義会計が修正し、債務を果たした時点で収益を認識します。年間セールスを予約する：
- 借方：現金、貸方：前受収益（負債）
- 毎月、借方：前受収益、貸方：サブスクリプション収入（12分の1）
同じロジックがクレジットパックにも当てはまります。 購入時ではなく、使った時点で収益が発生します。 それはより多くの作業ですが、ビジネスが成長しているかどうかを知るのと、ただお金が動いているのを見ているのでは、大きな違いです。
事業の単位経済が次の決断を左右する
投資家も、貸し手も、そして価格を引き上げるべきかどうかを夜の11時に決めているあなたでさえ、皆同じ質問をします。
- 純収益維持率（既存顧客の支出は時間の経過とともに増加しているか）は?
- プラン別の売上総利益率は?どの層がどの層に助成されているか?
- 真のCOGSとプロセッサー料金を含めた場合の顧客獲得コストの回収期間は?
- 前受収益はいくらか、またそれは今後2ヶ月分の債務をカバーしているか?
これらはどれも、当座預金の残高からは答えられません。必要になるのは、サブスクリプションと超過料金、総額と純額、獲得収益と前受収益、COGSとOPEXを区別する元帳です。プレーンテキスト会計は、これらのカテゴリがユーザー管理のファイル内の明示的なアカウントであり、gitでバージョン管理され、いつでも監査可能であり、定義が予告なく変更されるダッシュボードに埋もれることはないという点で優れています。
機能する最小限の勘定科目表
200行の勘定科目表は必要ありません。上記の質問に答えるのに十分な構造が必要です：
Income:Subscriptions:Starter/Pro/ScaleIncome:Usage:OverageIncome:CreditPacks:Redeemed（パック販売自体はまずLiabilities:UnearnedRevenue:CreditPacksに）Expenses:COGS:Inference（LLM/モデルコスト）Expenses:COGS:MeteredInfra（リクエストごとのコンピューティング、帯域幅）Expenses:COGS:DataAPIs（再販されるサードパーティAPI）Expenses:ProcessorFees:Stripe（またはPaddle / MoR）Liabilities:UnearnedRevenue:AnnualPlansとLiabilities:UnearnedRevenue:CreditPacksAssets:AccountsReceivable:ProcessorPending（未払い分）
まずはそこから始めましょう。現在の構造では答えられない質問が出てきたら、後からアカウントを追加します。
ワンオパーソンSaaSの月次決算
適切に帳簿を締めるために財務チームは必要ありません。月に一度、1時間でできる反復可能なチェックリストが必要です。
-
決済プロセッサの決済レポートを取得します 月全体の粗利益を商品別に計上し、手数料、返金、税金を明記します。
-
銀行の入金を照合します。 銀行の各ペイアウトは、元帳の決済バッチと一致している必要があります。請求済みだがまだ支払われていない保留中のバッチにフラグを立てます。
-
前受収益スケジュールを更新します。 各年間プランとクレジットパックについて、利益の対象となる部分を負債から収益に移します。クレジットパックに有効期限がない場合は、失効したクレジット（12〜18か月以上前の未使用パック）のブレークーッジ・ポリシーを検討し、文書化します。ここが会計上の判断が入る部分です。
-
未請求の使用量を未収計上します。 超過料金を後払いで請求する場合は、月末時点での未請求額を見積もるか、メーターを読み取り、未収収益として計上します。
-
売上原価（COGS）を照合します。 上流のAPI請求書（OpenAI、クラウドプロバイダーなど）を支払日ではなく、対象期間に照合します。前月のトークンに対する請求額が5日に2,400ドルある場合は、前月のものとして計上します。
-
支払いの失敗とチャーンレートを確認します。 再試行される予定の請求失敗はまだ売上損失ではありません。それらを一時的なものとして扱います。再試行期間が終了したら、それらを償却し、チャーンレートを正確に記録します。
-
前受金と未収金の残高を調整します。 前受負債は、特定の顧客とサービス期間に結びついたすべてのドルと照合できる必要があります。合計がスケジュールからずれている場合、何かが2回計上されたか、まったく計上されていません。
財務部門なしでの税金とコンプライアンス
米国の顧客にのみ販売し、州の経済的実質的関連性（ネクサス）の基準を下回っている場合は、Stripe統合で管理できます。しかし、グローバルに販売すると、税務コンプライアンスは倍増します。 EUでの顧客レートでのVAT、オーストラリアでのGST、カナダでのHST、米国各州でのSaaSの扱い、そして登録義務を引き起こす遠隔販売のしきい値など、知らなかった税金が発生します。
Merchant of Record（MoR）は、その複雑さを吸収します。彼らは管轄地域ごとに税金を徴収・納付し、準拠した請求書を発行し、チャージバックを処理し、売り手の記録となるため、外国のVAT申告書を提出する必要がなくなります。トレードオフは、Stripeの2.9%+$0.30に加えて別途税計算アドオンがかかるのに対し、MoRの手数料は通常4〜5%プラス固定額と高くなります。初日からグローバルに販売している小規模チームにとって、MoRの手数料は、自分で行うエンジニアリングと会計にかかる時間よりもほぼ常に安く、間違えた場合のコストを考えるとはるかに安価です。
直接Stripeに留まる場合も、最低限、EUの顧客がいる場合はEUのVAT（VAT OSS）に登録し、Stripe Taxを有効にして計算し、四半期ごとにOSS申告を行い、州ごとの米国の経済的ネクサスを追跡し（多くの州では$100,000の売上基準）、販売するすべての管轄区域で準拠した記録を維持します。計算せずに支払うだけでは、正しい価格を提示するのに役立ちますが、義務を果たすことはできません。
また、所得税も計画しましょう。プロセッサーのペイアウトは手数料が差し引かれる前の総額です。そのため、1099-Kフォームにはより高い金額が反映されます。純預金のみを計上した場合、フォームと申告書が一致せず、説明に余分な時間がかかります。総額で計上すれば、整合性は算数で済みます。
クリーンな帳簿がもたらすもの
Micro-SaaSにとってクリーンな帳簿は、単にコンプライアンスを維持するだけではありません。それらはビジネスを運営するために必要な答えを与えてくれます。真のCOGSを考慮した場合に最適なプランはどれか、クレジットパックとサブスクリプションのどちらがより良い投資回収をもたらすか、無料枠を増やすべきか超過料金を上げるべきか、そして「儲かっている」月が実際には年間前払いが隠れているだけなのかどうか。
サブスクリプションと超過料金、COGSとOPEX、獲得収益と前受収益、総額と純額を、12回目の月ではなく、最初の月に分離します。1年分のペイアウトとホスティング費用の再分類は、実際に元帳を作り直すことになるため、創業者にとっては大変な作業です。
財務管理の簡素化
あなたのMicro-SaaSが、不安定な従量課金制から本格的なハイブリッド価格エンジンへと移行するにつれて、明確な財務記録を維持することで、価格設定の決定が誠実になり、税金の季節も穏やかになります。 Beancount.io は、財務データを完全に透過的かつ完全に制御できるプレーンテキスト会計を提供します。あらゆるサブスクリプションプラン、クレジットパック、処理手数料、COGS はすべて、あなたが所有する元帳でバージョン管理されます。 無料で始めましょう 開発者や金融の専門家がプレーンテキスト会計に切り替えている理由をご覧ください。