SaaSの創業者が3月に36万ドルの3年契約を締結したとします。営業部門は36万ドルの受注（ブッキング）を祝います。財務部門は1年目の12万ドルを請求（ビリング）し、4月にそれを回収します。会計部門は3月の損益計算書で1万ドルの収益（レベニュー）を認識します。年末、CEOは36万ドル、12万ドル、10万ドルという3つの数字を眺め、なぜこれらが一致しないのか、投資家向け資料にはどの数字を載せるべきか、そして何かが間違っているのではないかと頭を悩ませることになります。
結論から言えば、どれも間違いではありません。これらは、同じ契約をそのライフサイクルの異なる3つの時点で測定した数値です。財務チームの役割は、どれか一つの数字を優先することではありません。これら3つを密接に連携させ、それらが照合可能であることを証明し、前受収益の残高を解消していくことで、損益計算書、貸借対照表、そしてARRスケジュールが毎月同じストーリーを語るようにすることです。
これはASC第606号に基づくサブスクリプション会計の運用の核心であり、ほとんどのSaaS財務機能がその真価を発揮するか、あるいは18ヶ月後の資金調達時のデューデリジェンスで露呈するようなエラーを静かに蓄積させてしまうかの分かれ道となります。
3つの数値とその違いの理由
すべてのサブスクリプション契約は、時間の経過とともに3つの経済的事象を発生させます。
- 受注（ブッキング） — 顧客が署名した瞬間。これは、契約期間全体を通じて支払うことを約束した「契約総額（TCV）」です。受注は営業のスコアボードに記載されるものであり、損益計算書には載りません。
- 請求（ビリング） — 請求書を発行した瞬間。数年間の契約であれば、毎年1回の年間請求、12回の月次請求、あるいはTCV全額の巨大な一括前払い請求が発生する可能性があります。請求はキャッシュの回収と売掛金を動かします。
- 認識された収益（レベニュー） — 期間中に「実際に提供された」サービスのGAAP（一般に公正妥当と認められた会計原則）に基づく測定値。ASC第606号の下では、契約がいつ締結されたか、あるいはいつ現金が入金されたかに関係なく、収益は定額（または履行義務が充足されるにつれて）認識されます。
これら3つの数値が特定の月に一致することは、ほぼありません。これは不具合ではなく、発生主義会計の設計によるものです。必要なのは、お金があるバケツから次のバケツへとどのように移動するかを示す信頼できる方法と、何も漏れがないことを証明する照合プロセスです。
具体的な計算例
先ほどの36万ドルの3年契約をもう一度考えてみましょう。価格は月額1万ドルで、1年分を前払いで請求するとします。
- 受注: 3月（契約締結月）に36万ドルを記録。
- 請求: 最初の12ヶ月分として4月に12万ドルを請求し、翌年の4月にさらに12万ドル、3年目にさらに12万ドルを請求。
- 認識された収益: 契約のサービス開始日から36ヶ月間、毎月1万ドルを計上。
13ヶ月目までに、36万ドルを受注し、12万ドルを請求し、13万ドルの収益を認識しており、前受収益（最初の年間前払分はすべて収益化済み）はゼロになります。2回目の請求書が発行される直前には、「契約資産」の領域に入ります。つまり、まだ請求していない収益を認識している状態です。2回目の請求により、その契約資産は売掛金に振り替わり、サイクルが繰り返されます。
これは、スタートアップがSaaSビジネスを現金主義の元帳で運営しようとしたときに、まさに見落とされがちなニュアンスです。
1ページでわかる5段階モデル
ASC第606号（数年前に旧来の業界固有のルールの寄せ集めに取って代わった基準）は、収益認識をすべての契約に適用すべき5つのステップに集約しています。
- 顧客との契約を識別する。 契約は書面、口頭、または黙示でも構いませんが、双方が承認しており、権利と支払条件が明確で、経済的実態があり、回収可能性が高い必要があります。
- 契約における履行義務を識別する。 「履行義務」とは「別個の」約束を指します。標準的なSaaSサブスクリプションの場合、義務は通常、サブスクリプション期間を通じてプラットフォームへの継続的なアクセスを提供することという、単一のものです。
- 取引価格を算定する。 これは、受け取ると見込まれる対価です。固定料金に加えて、使用料の上限超過、リベート、ボリュームディスカウントなどの変動要因の予測（過大評価しないための制約付き）を含みます。
- 取引価格を契約内の履行義務に配分する。 契約に複数の履行義務（サブスクリプション ＋ 導入支援 ＋ プレミアムサポート）がある場合、それぞれの独立販売価格に基づいて総額を配分します。
- 収益を認識する。 各義務が充足されるにつれて認識します。継続的なサブスクリプションサービスの場合、それは期間にわたる定額での認識となります。一時点での成果物（オンボーディング、特定の専門サービス）については、提供された瞬間に認識します。
基準自体はシンプルに聞こえます。複雑さは、各ステップにおける判断、特にステップ2（何をもって「別個」とするか？）とステップ3（どの程度の変動対価が認識するには不確実すぎるか？）の中に存在します。これらの判断は、契約が新鮮なうちに文書化しておきましょう。半年後には、なぜ導入費用を別の義務として扱ったのか誰も覚えておらず、監査人に尋ねられることになるからです。
前受収益ウォーターフォール
前受収益ウォーターフォール（繰延収益ウォーターフォール）は、SaaS会計のオペレーショナル・エンジンです。これは、請求済みだが未稼得の収益がいつ収益として認識されるかを、契約ごとに正確に示すスケジュールです。正しく運用されれば、「貸借対照表の前受収益残高」、「損益計算書の収益認識額」、そして「契約に基づいた確度の高い将来の収益予測」という3つの成果物を同時に生成します。
ロールフォワードの仕組み
最も単純な形では、ウォーターフォールは毎月次の等式に従います。
期首前受収益 + 新規発生前受収益 − 収益認識額 = 期末前受収益
例を見てみましょう。あるSaaS企業が、4月の開始時点で貸借対照表に50万ドルの前受収益を計上しているとします。4月中に、新規の年間購読と更新で18万ドルを請求しました。また、過去に請求済みの契約（および4月の新規請求のうち4月のサービス提供分）から、4月中に9万ドルの収益を認識しました。期末残高は次のようになります。
$500,000 + $180,000 − $90,000 = $590,000
もし補助簿が総勘定元帳の期末残高と1ドル単位で一致しない場合、何かが漏れています。通常は、契約の変更、ウォーターフォールを経由しない返金、あるいは元の前受残高を解消せずに収益に直接適用されたクレジットメモなどが原因です。
流動・固定の区分
GAAP（一般に公正妥当と認められる会計原則）の下では、前受収益は負債であり、負債は流動（12ヶ月以内に決済されるもの）または固定（それ以降に決済されるもの）に分類されます。年払いの1年契約の場合、前受残高の全額が流動負債となります。年払いの3年契約の場合、各請求書は12ヶ月以内に収益認識されるため、その都度全額が流動負債として発生します。しかし、3年契約で36万ドルを一括請求した場合は、12万ドルを流動負債（サービス1〜12ヶ月分）、24万ドルを固定負債（13〜36ヶ月分）に分割します。
投資家や貸し手はこの区分に注目します。固定の前受収益は、実質的に翌年以降の契約済み将来収益のスナップショットであり、流動の前受収益だけでは見えないビジネスの持続性を読み取るための有用な指標となります。
ウォーターフォールが予測するもの
完全なウォーターフォールは、契約ごと・月ごとのグリッドを作成し、受注した金額がいつ認識されるかを示します。その行を合計すれば、次のような予測が得られます。「第4四半期に認識予定の収益のうち、すでに契約済み（したがって非常に確度が高い）のものはいくらか、そして、まだ獲得していない新規受注に依存しているものはいくらか」。サブスクリプションビジネスにおいて、これは財務部門が作成する最も有用な計画ツールです。新規受注は未来を動かし、ウォーターフォールは近い将来のどれだけがすでに確定しているかを正確に教えてくれます。
受注 → 請求 → 収益 → 現金のブリッジ
ウォーターフォールが稼働すれば、受注から回収までのフロー全体を繋げることができます。
新規受注 (TCV signed)
↓
請求済 (Billings) ──→ 売掛金
↓ ↓
前受収益 ←─────── 回収済現金
↓
売上高 (損益計算書)毎期、これらの各矢印が数値を生成します。新規受注は営業レポートに、請求額は売掛金の年齢調べ（エイジング）に、現金回収はキャッシュフロー計算書に、前受収益は負債のロールフォワードとして、そして収益認識額は損益計算書に表示されます。もしこれら5つの数値が整合していなければ（つまり、「今四半期にXドル受注した」から「今四半期にYドル収益認識した」までの過程を、貸借対照表の動きを通じてステークホルダーに説明できなければ）、そのストーリーには欠陥があり、誰かに指摘される前に見つけ出す必要があります。
優れた財務決算は、その期間の受注、請求、収益認識、期首・期末の前受収益、期首・期末の売掛金、および回収済み現金をまとめ、それらの間の算術的な繋がりを読者に明示した1ページのブリッジ・スケジュールで締めくくられます。このページを作成できなければ、それは本当の意味でのSaaS決算ではなく、単に現金の動きを報告しているに過ぎません。
ARRブリッジとウォーターフォールとの整合性
ARR（年間経常収益）は管理上の指標であり、GAAP上の指標ではありません。これはサブスクリプション契約のランレート価値を近似したものです。ある一時点において、契約の変更がないとしたら、今後12ヶ月のサブスクリプション収益はどうなるかを示すものです。
ARRは毎期、4つのチャネルを通じて変動します。
- 新規ARR: 純新規顧客から。
- エクスパンションARR: 既存顧客のアップグレード、シートの追加、使用量ティアの引き上げから。
- コントラクションARR: ダウングレードまたは一部解約から。
- チャーンARR: 全解約から。
期首ARR + 新規 + エクスパンション − コントラクション − チャーン = 期末ARR
ここで、緻密な財務組織とそうでない組織を分けるクロスチェックがあります。ARRの変動の方向性と規模が、前受収益ウォーターフォールの動きと一致していなければなりません。もしARRが20%急増したのに、新規の前受収益の発生が横ばいであれば、新しい契約が後払いになっている（その場合は売掛金が膨らんでいるはずです）か、あるいは営業担当が請求システムに登録されていない案件を報告しているかのどちらかです。ARRスケジュールと前受収益ウォーターフォールの間のブリッジは、SaaS財務における銀行勘定調整のようなものです。そのように厳格に扱うべきです。
ほとんどのモデルを崩壊させる5つのエッジケース
標準的なSaaSサブ元帳は、変更のないクリーンな年間サブスクリプションの前払いという簡単なケースしか扱えません。エラーの多くは難しいケースに潜んでいます。初日からこれらを想定して構築しましょう。
1. 期中サービス開始
4月18日に署名され、サービス開始日が4月22日の契約の場合、4月には1ヶ月分のMRRの30分の9を認識すべきであり、丸1ヶ月分ではありません。サブ元帳が月単位で切り捨てを行う場合、契約1件につき数百ドルの誤差が生じます。数千件の契約になれば、累積誤差は6桁（数十万ドル）に達します。
2. 契約変更
3年契約の2年目の途中で、顧客が20シート追加したとします。ASC 606には特定のルールがあります。その変更が、独立した販売価格を反映した価格で「独立した」財またはサービスを追加する場合、それは「別個の契約」として扱われます。そうでない場合は、残りの取引価格を残りの履行義務に再配分する必要があります。ほとんどのサブ元帳は単純な「別個の契約」パスは適切に処理しますが、後者のケースでは密かに破綻します。自社のシステムをテストしてください。
3. 複数要素契約
30,000ドルの年間プラットフォーム・サブスクリプションと、一回限りの6,000ドルの導入費用がセットになっている場合、導入が独立していれば、それは2つの履行義務となります。36,000ドルの取引価格を、独立販売価格に基づいて2つに配分し（値引きがある場合は請求書の品目価格とは異なる可能性があります）、導入部分は提供時点で、サブスクリプション部分は期間に応じて定額で認識します。両方を1つのバケツに詰め込んで均等に認識すると、第1四半期の収益を過小評価し、その後の収益を過大評価することになります。
4. 変動対価
従量課金、パフォーマンスボーナス、返金権、段階的割引はすべて変動対価です。ASC 606では、変動額を「見積もり」、取引価格に含めることが求められています。ただし、収益の重大な戻入れが発生しない可能性が高い金額に限定するという制約があります。見積もりの妥当性を証明するのはあなたの責任です。方法論を文書化し、各期に見積もりを再評価してください。
5. 解約と返金
年間前払い契約の7ヶ月目に顧客が解約したとします。規約が返金不可である場合、残りの5ヶ月分も認識し続けます。回収済みの現金は自社のものであり、サービス提供は終了していますが、履行義務はすでに顧客に移転しているためです（これは文書化に値する判断です）。日割り計算で返金を行う場合は、残りの前受収益を取り消し、顧客に返金します。ウォーターフォール（収益認識スケジュール）はこの違いを把握している必要があります。サブ元帳がすべての解約を返金として処理すると、収益は恒常的に過小評価されます。
実践的なセットアップの推奨事項
SaaSの財務機能をこれら3つの数値と同期させるための、譲れないポイントがいくつかあります。
- 1つのサブ元帳、1つの真実のソース。 1つのシステム（請求プラットフォーム、専用の収益認識ツール、または小規模な会社であれば厳格に管理されたスプレッドシート）を選び、その出力を正式なものとして扱います。毎月、総勘定元帳（GL）と1ドル単位で照合します。
- サービス開始日は神聖なもの。 ウォーターフォールはサービス開始時に始まります。契約締結時や顧客の支払い時ではありません。契約作成時にサービス開始日を取得し、誤った編集から保護します。
- すべてを契約IDに紐付ける。 すべての請求書、支払い、前受収益仕訳、収益仕訳には契約識別子を付与する必要があります。不一致が生じたとき、単一の契約でフィルタリングしてそのライフサイクルを追跡できる必要があります。
- ウォーターフォールをスナップショットではなくデータとして保存する。 契約条件からオンデマンドで再生成されるウォーターフォールはツールです。スプレッドシートに貼り付けられ、その場で編集されたウォーターフォールは、将来の財務諸表再作成を待っているようなものです。
- 毎月GLと照合する。 全契約のサブ元帳上の前受収益の合計は、総勘定元帳の前受収益残高と一致しなければなりません。差異があれば、月次決算を締める前に調査して解決します。この規律が、監査時に大きな見返りとなります。
初日からの正確な記帳が、これらすべてを可能にします。取引、請求書、契約条件が発生の都度きれいにキャプチャされていれば、決算は機械的な作業になります。そうでなければ、毎月の決算は考古学的な発掘作業に変わります。
監査以外でこれが重要な理由
創業者は時々、ARRが100万ドルの段階でこれほどの複雑さが本当に必要なのかと尋ねます。正直な答えは、技術的には後回しにできますが、実際にはすべきではありません。理由は3つあります。
- 次のラウンドのデューデリジェンスは過去に遡る。 シリーズBの投資家は、過去2〜3年間のASC 606準拠の財務諸表を求めます。タームシートの前日に現金主義から発生主義に切り替えようとすると、時間のプレッシャーの中で2年分のウォーターフォールを再作成することになります。それこそが、間違いが混入するタイミングです。
- 間違った数値で経営を行うことになる。 サブスクリプションビジネスにおいて、現金の入金に基づいて価格設定、採用、バーンレートの意思決定を行う創業者は、目隠しをして飛行しているようなものです。ウォーターフォールこそが、先月が本当の成長月だったのか、単なる請求サイクルの産物だったのかを教えてくれるものです。
- 規律こそが参入障壁（モート）である。 ARR、前受収益、認識収益をクリーンに報告するサブスクリプションビジネスは、それができないビジネスとはデータルームでの見え方が全く異なります。買い手や投資家は、透明性に対して明確なプレミアムを支払います。
5段階モデル、前受収益ウォーターフォール、そして受注・請求・収益の照合は、官僚的なオーバーヘッドではありません。これらは自社のビジネスを可視化するための計器です。早期に設定し、毎月運用し、その効果を積み上げてください。
サブスクリプション帳簿を初日から監査対応可能な状態に保つ
SaaSやサブスクリプションビジネスの成否は、収益数値の信頼性にかかっています。投資家、監査人、貸し手は皆、同じものを求めています。それは、契約締結から収益認識までの一貫した流れと、すべての段階で照合された繰延残高です。Beancount.ioは、プレーンテキストによるバージョン管理された会計機能を提供し、創業者や財務チームにあらゆる取引と契約の完全な透明性をもたらします。ブラックボックスもベンダーロックインもなく、grep可能な完全な監査証跡が手に入ります。無料で開始して、デューデリジェンスを緊急事態から単なる形式的な手続きへと変えるような収益記録を構築しましょう。