請求ダッシュボードは、先月の月次経常収益（MRR）が12パーセント成長したと言っている。総勘定元帳は、収益がほとんど動いていないと言っている。銀行口座は、まったく別の話をしている。この3つの数字は同時に正しいこともあり得る — そして、なぜそれらが食い違うのかを正確に説明できなければ、どれもあなたのビジネスを運営するのに十分な信頼性を持たない。
サブスクリプションプラットフォームが報告する数字と帳簿が示す数字の間のこのギャップこそ、収益の誤表示が繁殖する場所だ。期中のアップグレード、ダウングレード、日割り計算、解約、返金のたびに、そのギャップは少しずつ広がっていく。本ガイドでは、そのギャップを埋める方法を示す。各サブスクリプション変更がどのように元帳に反映されるべきか、チャーンがどのように勘定科目を流れていくか、そしてスプレッドシートの海に溺れることなく毎月請求と帳簿を照合する方法だ。
なぜ請求レポートと帳簿が食い違うのか
混乱は、似た響きだが異なるものを測定する3つの数字から始まる。
- 請求額（Billings） とは、この期間に顧客に請求または課金した金額であり、年間プランの12か月分を初日に回収した場合も含む。
- 収益（Revenue） とは、サービスを提供することでこの期間に実際に稼いだ金額 — 通常は各サブスクリプションの1か月分の切片だ。
- 現金（Cash） とは、決済手数料、返金、失敗した課金、入金タイミングを差し引いた後に銀行口座に着地した金額だ。
3月15日に年間プラン1,200ドルを前払いした顧客は、3月の請求額1,200ドル、第1四半期の収益約560ドル（月100ドルとして、3月の半分に4月と5月を加えたもの）、そしてカード手数料後の現金約1,164ドルを生み出す。全額1,200ドルを3月の収益として計上すれば、その月を2倍以上過大表示し、次の11か月を過小表示することになる。
これを正しく保つための保有勘定が繰延収益であり、負債である。提供前に回収するとき、現金を借方に、繰延収益を貸方に記録する。サービスを提供するにつれて毎月、繰延収益を借方に、サブスクリプション収益を貸方に記録する。すべてのサブスクリプション変更 — アップグレード、ダウングレード、解約 — は最終的にこのスケジュールへの調整であり、照合とは、そのスケジュールが依然として現実と結びついていることの毎月の証明である。
手計算でやり直せるべき日割り計算の算術
請求プラットフォームは日割り計算を自動で行うが、日割り計算の紛争は請求と元帳の不一致の最も一般的な原因の一つであるため、それを検証できる程度には算術を理解しておく必要がある。標準的な方法は時間ベースだ。古いプランの未使用部分をクレジットし、新しいプランの残り部分を課金する。
期中のアップグレード。 月50ドルプランの顧客が、30日サイクルのうち残り12日の時点で月120ドルプランにアップグレードする。未使用の古いプランのクレジットは12/30 × 50ドル = 20ドル。残りの新しいプランの課金は12/30 × 120ドル = 48ドル。正味の請求書は28ドルだ。一部のプラットフォームは28ドルを即座に請求し、他は次回の請求書に加算する。いずれにせよ、元帳は古いプランの繰延収益が20ドル減り、新しい48ドルの債務スケジュールが生じたことを反映しなければならない — 単に28ドルの即時収益としてではない。
期中のダウングレード。 同じ顧客が残り12日の時点で120ドルから50ドルへ移行する。算術は鏡写しだ。48ドルのクレジットに対して20ドルの課金で、28ドルのクレジット残高が残る。ほとんどのプラットフォームはそのクレジットを現金で返金するのではなく将来の請求書に充当する。そのクレジットは、消費されるまで顧客クレジット負債（または勘定科目表によってはマイナスの繰延収益）として帳簿に載る。照合が請求書と収益を比較するだけなら、未消費のクレジットは静かに蓄積し、負債残高はプラットフォームのクレジットレポートから乖離していく。
シート数と数量の変更 も同じように機能し、追加または削除されたシート数を掛け合わせる。請求間隔が異なるプラン変更 — 期中の月次から年次へ — は日割り計算と期間変更を組み合わせるもので、ここが自動スケジュールが最も頻繁に失敗する場所だ。プラットフォームは月次スケジュールを閉じて年次スケジュールを開くが、会計システムの収益認識スケジュールは、連携がそれを更新しない限り古いプランを償却し続ける。
ASC 606 の下で各変更が元帳にどう反映されるか
あなたのビジネスが米国 GAAP に従う場合、サブスクリプション変更は ASC 606 の下での契約変更であり、基準は3つの結果を持つ決定木を与える。
- 独立した契約。 変更が独立した財またはサービスを独立販売価格で追加する場合 — 顧客が定価で真に独立した追加モジュールを加える場合 — それをまったく新しい契約として会計処理する。元の収益スケジュールは手つかずのままだ。
- 将来への再配分。 これがプランのアップグレードとダウングレードの一般的なケースだ。残りの履行義務はすでに提供したものとは別個だが、価格設定は独立販売価格としての要件を満たさない。古い契約を終了したものとして扱い、未認識残高を新しい対価と結合し、残りのサービス期間にわたって再配分する。すでに認識した収益は決して修正されない。
- 累積的な一括調整（キャッチアップ）。 単純なサブスクリプションでは稀だが、変更が以前のものと別個でないサービスを対象とする場合に関連する — 例えば、実効的に単価が遡って変わる使用量ベースの構成要素など。ここでは、変更後の条件が最初から適用されていたかのように再計算し、一時的な調整を計上する。
ほとんどの小規模サブスクリプションビジネスにとって、実務的な要点は専門用語よりも単純だ。アップグレードとダウングレードは将来を調整するものであり、過去を調整するものではない。 顧客が前払い四半期の途中でアップグレードするとき、未稼得残高を新しいプランのスケジュールに移し、残りの日数にわたってより高い料率を認識する。すでに認識した収益にさかのぼって書き換えはしない。顧客がプランを変更するたびに、閉じた月に日付のある収益調整が帳簿に現れるなら、あなたのプロセスは将来に向けて再配分するのではなく履歴を修正しているのだ — そして前月比の傾向は虚構である。
もう一つのニュアンス。即時ではなく更新時に発効するダウングレード は、当期の仕訳をまったく生じさせない。スケジュールは次のサイクルで変わる。ダウングレードを発効日ではなくクリック日に計上するシステムは、当期の収益を過小表示し、クレジット負債を過大表示する。
チャーン会計：解約、返金、クレジット、貸倒れ
チャーンは同時に指標のイベントであり会計のイベントであり、両者は照合しなければならない。サブスクリプションが終了するとき、顧客が後に残す各残高を順に確認しよう。
返金を伴わない解約。 顧客は支払った期間を終えて去る。解約日に将来の請求書を止める以外の仕訳はない。残りの繰延収益は、支払った期間の残りを提供するにつれて認識され続ける。避けるべき誤りは、繰延残高を早まって償却することであり、これは負債と将来の収益の両方を過小表示する。
比例返金を伴う解約。 未稼得部分を返金する。繰延収益を借方に（または返金額がすでに認識されていた範囲では収益を借方に）、現金を貸方に記録する。返金する60ドルのうち40ドルがまだ繰延で20ドルが前月に認識されていたなら、仕訳は繰延収益40ドルを借方に、収益調整または返金勘定20ドルを借方に、現金60ドルを貸方に記録する。全額60ドルを当月の収益に充当すると、過去のサービスに関する決定のために当月を歪める。
返金対クレジット。 返金は現金を返す。クレジットは顧客の資金を将来の請求書に充当される負債として保持する。それらは異なる現金への影響を持つ異なる勘定であり、チャーンレポートはそれらを区別すべきだ。決して使われないクレジットで解約顧客に「返金」しているビジネスは、実効的な維持率を過大表示し、幻の負債を抱えている。
失敗した支払いと非自発的チャーン。 カード拒否は初日のチャーンではない — 未回収の売掛金だ。他の売掛金と同様にエイジングする。督促の再試行を通じて、当座、30日、60日、90日と。回収が放棄されたときに初めて貸倒損失（または、収益が認識されたかどうかとポリシーに応じて収益の取り消し）となる。ここでは2つの誤りが一般的だ。督促期間を通じて回収が確実であるかのように収益を認識し、収益と売掛金の両方を膨らませること。そして、何か月も後に売掛金として一切示すことなく収益に対して残高を償却し、財務諸表から真の非自発的チャーン率を隠すこと。
チャージバック は独自の追跡に値する。チャージバックはすでに受け取った現金を反転させ、通常は手数料を加える。手数料は銀行手数料またはチャージバック費用勘定に計上する — 決して収益と相殺しない — そうすれば紛争が実際にいくらかかっているかが見える。
毎月の照合チェックリスト
月に一度、すべての請求数字を元帳の数字に結びつけよう。ルーティンが一旦できれば作業全体は1時間足らずで終わり、各ステップは異なる失敗モードを捉える。
- 繰延収益をロールフォワードする。 期首残高＋新規請求額－認識済み収益－発行済みの返金とクレジットは、期末残高に等しくなるはずだ。次にその期末残高を請求プラットフォームの未稼得残高または繰延収益レポートと比較する。差異はスケジュールの破綻だ — 通常、連携が取りこぼした期中の変更である。
- 認識済み収益をウォーターフォールに結びつける。 収益認識スケジュール（顧客別またはコホート別）は、元帳のサブスクリプション収益に合計が一致するはずだ。認識済み金額が、提供したサービス日数に実効料率を掛けたものと一致しない顧客を調査する。
- 請求額を発行済み請求書に照合する。 その月にプラットフォームで作成された請求書の合計は、繰延収益ロールフォワードの請求額側と一致するはずだ。ここでのギャップは通常、プラットフォーム外で作成された請求書 — 手動請求書、サイド契約書でまとめられた年間契約 — がスケジュールに入らなかったことを意味する。
- 現金を入金に照合する。 決済代行の入金は銀行預金と結びつくはずであり、総課金額から手数料と返金を差し引いたものは入金と結びつくはずだ。入金預金はそれ自体では販売記録と一致しない。各預金は手数料控除後の多数の顧客を束ねているからだ。預金対収益ではなく、総額対純額で照合する。
- 顧客クレジットを照合する。 プラットフォームの未処理クレジットレポートは、元帳の顧客クレジット負債と等しくなるはずだ。1年を超える古いクレジットにはポリシーが必要だ。充当、返金、またはあなたの州の未請求財産法に従った国庫帰属。
- MRR の変動を認識済み収益の変動と比較する。 MRR は請求指標であり収益ではないが、大きな乖離 — MRR が急上昇する一方で認識済み収益が横ばい — は、月末を閉じる前に調査する価値のあるスケジュール破綻を示す。
毎月の照合項目を、反復するものであっても文書化しよう。一度書面で説明した一時的な差異は、次に3回現れても謎ではなくなる。
サブスクリプション帳簿を静かに汚染する誤り
- 年間前払いを前倒しで認識する。 最も一般的な単一の誤り。12か月分の現金は1か月分の収益と11か月分の負債である。
- 日割り計算を即時収益として計上する。 28ドルの正味アップグレード請求書は、ほとんどがスケジュールの再配分であり、稼得部分はわずかで、請求日に28ドルを稼いだのではない。
- 返金を新規売上と相殺する。 返金を発生月のマイナス請求として記録すると、真の売上と真の返金率の両方を隠す。対収益勘定を使って、総売上、返金、純収益をすべて可視化しよう。
- 日割り請求書の売上税を忘れる。 期中の請求書も依然として請求書だ。プラットフォームが正味の日割り額に対して税を計算するのに、元帳が請求書を税抜きで計上すると、負債勘定は毎月乖離する。
- 督促期間の収益を蓄積させる。 決して回収されない請求書で認識された収益は成長を膨らませ、後に不意の償却として現れる。ポリシーを設定し — 例えば、延滞60日後に認識を停止する — 一貫して適用しよう。
- 小さなクレジット残高を無視する。 3ドルのクレジットを持つ顧客1,000人は、3,000ドルの負債の誤表示であり、誰かがアカウントを監査する次の機会に顧客エクスペリエンスの問題となる。
経常収益を照合し続けよう
サブスクリプション会計は英雄的行為よりもシステムに報いる。経常収益の帳簿がきれいなビジネスは、最も賢い会計士を抱えるものではない — 毎月同じ照合チェックリストを実行し、日割り計算のロジックを一か所に保ち、すべてのプラン変更を一回限りの調整ではなくスケジュールのイベントとして扱うビジネスだ。
きれいな帳簿は複利的にも効く。繰延収益ロールフォワードが毎月結びつけば、収益の数字は、臆することなく価格設定の基準にし、借入の裏付けにし、投資家に報告できるものになる。サブスクリプション元帳を透明で、バージョン管理され、行ごとに監査しやすいものにしたいなら、Beancount.io はプレーンテキスト会計を提供し、すべての仕訳 — すべての日割り計算とチャーン調整を含む — を読みやすく追跡可能に保つ。無料で始める そして来月の決算を自信を持って照合しよう。
