3月に年間契約を5件成約し、Stripeアカウントに60,000ドルが入金されました。ダッシュボードは輝き、銀行残高は英雄的に見えます——そして経理担当者は、3月の収益は5,000ドルだったと言います。誰も間違っていません。あなたは、たまたま同じStripeアカウントに存在する2つの異なる数字を見ているのです。回収した現金と、実際に稼いだ収益です。この2つを照合するまで、Stripeが送ってくる入金はすべて、あなたの帳簿が解かなければならない謎かけです。
このガイドでは、年払いで請求しながら月次で収益認識するSaaS企業が、収益を二重計上したり、前受収益を誤表示したり、そのギャップ全体を覆い隠す指標に騙されたりすることなく、Stripe入金を照合する方法を紹介します。
なぜStripe入金は収益の出発点として間違っているのか
Stripeの入金は収入のように見えます。銀行口座に1回の入金として到着し、日付が付いており、その月の稼ぎのように感じられます。しかしそのどれでもありません。入金は純額の決済です。総請求額から決済手数料を引き、返金を引き、係争による引き出しを引いたもので、あなたのスケジュールではなくStripeの入金スケジュールでまとめられています。
入金を収益として計上すると、2つの別々の歪みが生じます。
第一に、収益を過少に計上します。顧客が年間プランに12,000ドルを支払った場合、Stripeは約348ドルと30セントを保持し、残りを支払います。入金を計上すると、純額が売上として記録され、手数料は分析もきれいに控除もできない場所に埋もれてしまいます。
第二に、年払い請求にとってはるかに危険なことに、タイミングを誤表示します。12,000ドル全額が1月に1回の入金で到着しますが、発生主義会計では、サービスを提供するにつれて月1,000ドルずつ稼いでいきます。入金を1月の収益として計上すると、1月は素晴らしく見え、2月から12月は死んだように見えます——ビジネスが毎月まったく同じことをしていたにもかかわらず。
解決策は、入金をそれが本来あるべきもの——現金移動——として扱い、預金ではなく契約によって駆動される完全に別のトラックで収益を認識することです。
創業者が混同する3つの数字：Bookings、Billings、Revenue
すべての年払い請求の照合は、3つの数字を区別することから始まります。
- Bookings（受注） は、署名された契約の総額です。顧客が1月に12,000ドルの年間契約に署名すると、1月のBookingsは12,000ドルです。Bookingはコミットメントであり、現金でも稼ぎでもありません。
- Billings（請求） は、請求して回収するものです。契約が年払い前払いで請求する場合、1月のBillingsは12,000ドルです。月払いで請求する場合、Bookingは12,000ドルでも、1月のBillingsは1,000ドルです。
- Revenue（収益） は、サービスを提供することで稼いだものです。12か月契約の1か月は12分の1を稼ぎます。どちらの場合も1月の収益は1,000ドルです。
BillingsとRevenueの間のくさびが前受収益（unearned revenueとも呼ばれます）であり、まだ提供していないサービスを表す貸借対照表上の負債です。1月に12,000ドルを回収し、1,000ドルを認識すると、11,000ドルの前受収益を2月に繰り越します。この負債は問題ではなく、帳簿が誠実であることの証明です。契約が終了するまで毎月1,000ドルずつ取り崩されます。
簡単に言えば、Bookingsは営業がどうしているかを、Billingsは現金がどうしているかを、Revenueはビジネスが実際にどう機能したかを教えてくれます。どれか一つを別のものの代わりにした瞬間に、照合は崩壊します。
月次認識を駆動する前受収益スケジュールを構築する
前受収益スケジュールは、プロセス全体のエンジンです。契約ごとのシンプルな表——顧客、契約開始日、契約期間、契約総額、月次認識額、認識済み収益、残存前受残高——であり、収益仕訳をトリガーすべき唯一の文書です。
1月1日に始まる12,000ドルの年間プランの場合、仕訳は次のようになります。
On collection (January):
Dr Stripe clearing $12,000
Cr Deferred revenue $12,000
Each month, January–December:
Dr Deferred revenue $1,000
Cr Subscription revenue $1,000欠けているものに注目してください。入金は収益仕訳のどこにも現れません。現金回収は前受収益という負債に貸方記入します。収益は後で、スケジュールから1か月ずつ生まれます。
スケジュールを機能させるか壊すかの2つの規律ポイントがあります。第一に、すべての新しい年間契約、更新、拡張は、開始した月にスケジュールに載らなければなりません——スケジュールから漏れた契約は、永遠に認識されない収益です。第二に、毎月スケジュールを総勘定元帳と照合します。期首前受残高＋新規請求額−認識収益＝期末前受残高でなければなりません。そうでなければ、何かがスケジュールを迂回しています——通常は返金、期中の変更、または誰かが収益に直接計上した入金です。
クリアリング勘定で入金そのものを照合する
スケジュールが収益のタイミングを扱う一方で、Stripeを通じて移動するお金を依然として会計処理する必要があります。クリーンな方法はStripeクリアリング勘定——「Stripe内に置かれている現金」を表す資産勘定です。
すべてのStripeイベントは総額でクリアリング勘定に記帳されます。
Customer charged $1,000:
Dr Stripe clearing $1,000
Cr Deferred revenue $1,000
Stripe fee of $29.30 on that charge:
Dr Processing fees $29.30
Cr Stripe clearing $29.30
Payout of $970.70 lands in your bank:
Dr Bank checking $970.70
Cr Stripe clearing $970.70返金と係争による引き出しも同じように、逆方向に記帳されます。入金のスイープがクリアされると、その入金の項目についてクリアリング勘定はゼロに収束します——これこそが、単なる簿記の慣習ではなく照合ツールにしている理由です。ゼロでない残りは、手数料、返金、または調整が未記録であることを意味します。
各入金をその内容に結びつけるには、Stripeの入金照合レポートを使用します。これは入金内のすべての請求、返金、手数料、調整を項目別に示し、総額から手数料を引き返金を引いたものが銀行預金と等しいことを検証します。これを月単位ではなく、入金ごとに行ってください。入金は絶えず月末をまたぎ、月次でのバッチ処理が「銀行がStripeと決して一致しない」という謎の源です。取引量が少ない場合は、クリアリング勘定を使った週次のリズムで、小さな不一致をまだ追跡しやすいうちに捕まえられます。
トゥルーアップ：スケジュールを壊す期中の変更
年間契約が12か月間じっとしていることはめったになく、すべての変更には前受スケジュールに対するトゥルーアップ仕訳が必要です。
- アップグレードとシート拡張 は残存前受残高に加算されます。残り6か月で年12,000ドルから18,000ドルにアップグレードした顧客は、未認識の残りに加えて、約3,000ドルの新規前受収益（月額500ドル×6か月）を追加します。
- ダウングレード はそれを縮小します。残り6か月でプランを縮小すると、その差額を前受収益から移します——多くの場合、現金返金ではなく将来の請求書へのクレジットとしてですが、お金が動かなくても仕訳は必要です。
- 日割り計算 がメカニズムです。Stripeは未使用時間のクレジットでサブスクリプション変更を処理し、そのクレジットが旧プランと新プランの間で移すべき前受収益の額を正確に教えてくれます。
- 前払い期間の返金を伴う解約 は前受収益を減らし、当月の収益は決して減らしません。12,000ドルプランの未使用6か月を返金することは、前受収益への6,000ドルの借方です——これを今月の収益に計上すると、何も悪いことをしていない月を過少表示することになります。
- 年間更新の支払い失敗 は逆方向に注意が必要です。現金回収がなければ新しい前受残高もないので、資金調達が止まった契約の収益をスケジュールが認識し続けてはなりません。
実践的なルール：Stripeでのサブスクリプション変更は、同じ月にスケジュール更新を伴わなければなりません。両者をずれるに任せるチームは、四半期末ごとに請求書PDFから何が起こったかを再構築するのに費やします。
すべてを隠すSaaS指標：ダッシュボードのMRRは収益ではない
ここに、この設定全体が隠している罠があります。StripeダッシュボードはMRRが美しく上昇するのを示します——年間プランは月額換算され、アップグレードは即座に拡張MRRを加え、チャートは右上がりに傾きます。創業者はごく自然に、その数字を「毎月稼ぐもの」と考え始めます。
そうではありません。MRRは正規化されたランレート指標です。何も変わらなければ、アクティブなサブスクリプションの月額価値です。認識収益は、発生主義会計の下で今月実際に稼いだものです。両者は絶えず乖離します——今月回収された年払い前払いは今月の収益にはほとんどならず、月中のアップグレードによる拡張MRRは半月分の稼ぎに過ぎず、ダッシュボードのどの数字も前受スケジュール、返金、トゥルーアップを知りません。
この乖離は、痛手を負うまで見えません。課税所得はMRRではなく認識収益に従うため、大きなBookingsの四半期は、ダッシュボードを見ていた創業者を驚かせる税額を生み出す可能性があります。そして買収者や貸し手はMRRではなくGAAP収益をデューデリジェンスします——実際には未認識の請求額であった「収益」のすべてのドルが、評価の会話から調整除去されます。
両方の数字を保ちつつ、一方にもう一方の仕事をさせてはなりません。有用な月次の健全性チェック：その月の認識収益に前受残高の変動を加えたものは、Billingsに戻って照合されるべきです。MRRが成長したと言い、その等式がそうでないと言うなら、等式を信頼してください。
Stripe SaaSの月次決算チェックリスト
毎月これを実行すれば、各部分は結びついたままです。
- 入金を銀行に結びつける。 入金照合データをエクスポートし、総額から手数料を引き返金を引いたものが各預金と等しいことを確認し、クリアリング勘定を通じてスイープを記帳します。
- 入金ごとにクリアリング勘定をゼロにする。 残った残高は未記録の手数料、返金、係争、または調整です——月末前に見つけてください。
- 前受スケジュールをロールする。 新規契約と更新を追加し、その月の認識仕訳を記帳し、期首残高＋請求額−認識収益＝期末残高を確認します。
- 期中の変更をトゥルーアップする。 Stripeのすべてのアップグレード、ダウングレード、日割り計算、解約、返金をスケジュール調整と突き合わせます。
- MRRを認識収益に照合する。 ダッシュボードのランレートと稼いだ収益のギャップを説明し、一文で説明できないものは調査します。
- 手数料と返金を別々にレビューする。 総収益、決済手数料、返金はそれぞれ独自の物語を語ります——それらを純額にすると3つすべてが隠れます。
一貫して行えば、これは月末をフォレンジックな発掘からルーチンに変えます。入金側は現金が完全であることを証明し、スケジュール側は収益が稼がれていることを証明します。
SaaS収益を投資家対応に保つ
年払い請求を拡大するにつれて、認識収益、前受残高、Stripe現金を毎月結びつけておくことが、会計士、税務当局、将来の買収者にとってあなたの数字を信頼できるものにします。Beancount.io はプレーンテキスト会計を提供し、財務データに対する完全な透明性とコントロールを実現します——ブラックボックスなし、ベンダーロックインなし。無料で始める と、開発者や財務のプロフェッショナルがなぜプレーンテキスト会計に切り替えているかをご覧ください。
