会社の短い歴史の中で最大の契約を締結したばかりです。年間コミット12万ドル、さらに含まれる許容量を超えるAPI呼び出し1回につき0.10ドル。請求システムはすでにメーターを回しており、明らかな会計処理は「使ったときに収益を認識する」ことのように思えます。その直感は、この契約のちょうど半分については正しく、もう半分については年次調整を監査人に突きつけるほどには間違っています。
従量課金制の価格設定は、今や珍しい例外ではなく、SaaS企業の標準的な課金方法です。2025年には59%以上のSaaS企業が従量課金制の仕組みを導入しており、2年前の約40%から増加しています。そうした契約のほとんどは純粋な従量課金ではありません。割引を買うための確定ベースラインと、その上にメーター制の超過分が乗るハイブリッドです。ASC 606の下では、その一つの署名が、正反対のタイミングルールを持つ二つの収益ストリームに分かれます。ベースラインは固定対価であり、顧客がAPI呼び出しを1回しかしなくても契約期間にわたって配分されます。超過分は変動対価であり、メーターを待ちます。本ガイドでは、それを実装する仕訳とともに、その理由を説明します。
一つの契約、二つの収益処理
まず構造から始めましょう。それ以外はすべてそこから導かれるからです。確定ベースラインと超過分の契約には、三つの可動部分があります。
- 確定最低額。 顧客は何があっても年間12万ドルを支払います。その代わりにプラットフォームへのアクセスと、含まれる許容量（たとえば月100万API呼び出し）を、実効レートで定価を大きく下回る価格で受け取ります。
- 超過分のメーター。 許容量を超える利用は、通常は月末締めで超過レートで請求されます。この例では1回あたり0.10ドルです。
- 一つの署名、一つの期間。 通常は12か月で、サービスは年間を通じて少しずつ提供されるにもかかわらず、前払いまたは四半期ごとに請求されることがよくあります。
ASC 606はこの契約を5つのステップのモデル（契約の識別、履行義務の識別、取引価格の決定、配分、履行義務の充足に応じた収益認識）にかけ、二分割の判断を下します。確定した12万ドルは、12か月にわたって継続的に提供されるサービスの固定取引価格であり、時の経過にわたって認識され、通常は月1万ドルの定額按分となります。超過分は変動対価です。その金額は将来の利用に依存するため、利用が発生したときに認識され、あるいは意図的に高い基準である制約をクリアできる場合にのみ、事前に見積もられます。同じ顧客、同じ請求書、二つの時計です。
実際の結果はすぐに現れます。顧客が40万回しか呼び出さない低調な月でも、ベースライン収益の全額1万ドルを認識します。顧客は1年間のアクセスを購入し、1月分の12分の1が提供されたからです。150万回の呼び出しとなる急増月には、1万ドルに加えて超過分50万回×0.10ドル、すなわち5万ドルの利用収益を認識します。ベースラインは利用に応じて下がることはなく、超過分は何も起きなかった月に平準化されることもありません。
ベースラインが定額按分される理由
ベースラインの会計ロジックは、物語のより穏やかな半分です。あなたの履行義務は「100万API呼び出し」ではなく、顧客に月全体を通じてサービスを提供できるよう待機していることであり、ASC 606が時の経過にわたって充足されるとみなす、日次または月次の区分された一連のサービス期間です。進捗の適切な尺度は経過時間であり、最も忠実でシンプルなパターンは定額按分、つまり毎月コミット額の12分の1です。
大手の従量課金ベンダーはすべて、この半分について同じ結論に至ります。Datadogの10-Kでは、按分して配分される確定した契約金額について、プラットフォームが利用可能になった時点からサブスクリプション期間にわたって均等に収益を認識すると述べています。月次最低額で取引ベースの銀行向けソフトウェアを販売するAlkamiは、さらに明快に述べています。最低取引手数料は定額ベースで認識され、最低額を超える取引の手数料はその取引が処理された月に認識されます。最低額は時の経過に対応し、超過分はメーターに対応します。
知っておく価値のある有名な異論が一つあります。監査人が言及するからです。Snowflakeは、複数年の容量コミットの下でも、顧客がコンピュート、ストレージ、転送を消費するにつれて収益を認識します。価値が移転するのは時間ではなく消費だという主張です。この立場は目立つ形で開示され、会社固有の事実をもって擁護されています。そのメモを書いて監査で擁護する用意がない限り、ベースラインは定額按分してください。それは監査人が初期段階のSaaS企業に期待する処理であり、逸脱には肩をすくめるのではなく、書面による立場が必要です。
超過分がメーターを待つ理由
超過分は変動対価であり、ASC 606は変動対価を疑いの目で扱います。不確実性が解消したときに重要な戻し入れが生じないことが確実である（probable）範囲でのみ、取引価格に含めることができます。これが制約です。すでに発生しメーターで測定された利用については不確実性が残らないため、利用月に超過分収益を認識すれば常に基準を満たします。だからこそ「使ったときに認識する」がほとんどのSaaS企業が選ぶデフォルトであり、監査人が最も異議を唱えにくい方法なのです。
もう一つの選択肢は、年間の超過分総額を事前に見積もり、ベースラインとともに定額で認識することです。New Relicはまさにこれを行っています。過去のデータと将来を見据えた要因からコミットを超える利用を予測し、得られる権利と見込まれる額に見積もりを制約し、その金額を期間にわたって認識します。これは準拠しており、より滑らかな収益を生みますが、何を要求するかに注目してください。信憑性をもって予測するのに十分な履歴、文書化された見積方法、制約の分析、そして実績がずれたときの修正プロセスが必要です。測定データが6か月分しかなく、利用が四半期ごとに倍増する大口顧客が1社しかいないスタートアップには、そのファイルはまだ存在しません。履歴が推定する権利を得るまでは、超過分は発生時に認識してください。
基準のもう一つの部分が、このシンプルなアプローチを静かに支えています。あなたのサブスクリプションは区分された月次サービス期間の連続であるため、特定の月に関連する利用料は、変動対価の配分の例外の下で、その月に完全に配分できます。平たく言えば、1月を正しく記帳するのに年間を予測する必要はありません。1月のメーターの読み取りは1月に属する、それだけです。
最後のタイミングの罠は、請求と認識を混同することです。1月に12万ドルのコミットを前払いで請求した場合でも、1月の収益は1万ドルのままです。残りの11万ドルは繰延収益に残ります。逆に、1月に提供されたが2月の請求処理まで請求されない超過分の利用も、依然として1月の収益です。月末には未請求収益または未収収益として計上します。現金と請求書は請求イベントです。時の経過とメーターは収益イベントです。決算チェックリストはこの二つを切り離しておく必要があります。
実際の数字で見る仕訳
これが帳簿上の取引例です。Acmeは1月5日に契約します。年間コミット12万ドル、月100万回の呼び出しを含み、超過分は1回0.10ドル。1月の利用は1,021,000回で、許容量を21,000回、すなわち2,100ドル超過しました。2月は80万回と静かで、超過分はまったくありません。
2026-01-05 * "Invoice Acme annual platform commit"
Assets:Receivable:Acme 120000.00 USD
Liabilities:Deferred-Revenue:Acme -120000.00 USD
2026-01-31 * "January: release 1/12 of commit"
Liabilities:Deferred-Revenue:Acme 10000.00 USD
Income:Subscription-Revenue -10000.00 USD
2026-01-31 * "January overage: 21000 calls over allowance at 0.10"
Assets:Receivable:Acme 2100.00 USD
Income:Usage-Revenue -2100.00 USD
2026-02-28 * "February: release 1/12 of commit, usage under allowance"
Liabilities:Deferred-Revenue:Acme 10000.00 USD
Income:Subscription-Revenue -10000.00 USD台帳が語る物語を読み取ってください。1月は12万ドルの請求のうち12,100ドルを認識し、11万ドルの差額は繰延収益、すなわちまだ提供していないサービスに対する負債であり、利益ではありません。2月は利用が5分の1に落ちても、定額の1万ドルを認識します。ベースラインは呼び出しではなくアクセスに対して支払われるからです。そして超過分の仕訳は、メーターが許容量を超えた月にのみ存在します。あなたの収益勘定がまさにこの形（一定のベースラインと急増する利用）を示していなければ、上流のどこかが誤って配線されています。
別々の収益勘定に注意してください。サブスクリプションのベースラインと利用収益を分けるのは見た目だけの問題ではありません。純収益維持率、利用付帯率、コミット・カバレッジを、スプレッドシートではなく総勘定元帳から報告できるようにするために必要なのです。契約初日から両方の勘定を設定し、最初の監査のときに設定するのではありません。
監査人による調整を招く四つの誤り
署名時にコミット額を収益として計上する。 12万ドルの請求書は売上のように感じられ、営業チームは1月に成約したと言うでしょう。しかしあなたが提供したのは12か月のサービスのうち1か月分です。1月の1万ドルを超えるすべては繰延収益です。コミット全額を前払いで計上する企業は、1か月を誤って表示するだけでなく、将来の11か月分の収益を借り、それを恥ずかしい修正再表示として返済することになるのです。
むらのある超過分を静かな月に分散させる。 急増月の5万ドルの超過分を周辺の四半期に平均化すると、きれいに見えますが、総額を事前に見積もり、制約の分析を文書化し、修正するのでなければ誤りです。そのファイルがなければ、各月のメーターの読み取りはその月に残ります。監査人は認識した利用収益を期間ごとにメーターで測定した利用と比較してこれを検証します。むらのあるメーターに対して平準化された数字は、この検証に最も早く失敗する方法です。
請求カレンダーに認識を左右させる。 年間前払い請求は、チームを請求日で認識させる誘惑になります。四半期ごとの修正請求は、超過分を請求時にのみ認識させる誘惑になります。どちらの方向もルールを破ります。ベースラインはサービスのカレンダーに従い、超過分は利用のカレンダーに従い、どちらも請求のカレンダーには従いません。測定済みだが未請求の利用に対する月末の未収計上は、若い財務チームのほとんどが欠いている仕訳です。メーターが確定するよう、月末から数日後に決算を締めてください。
未使用のコミットを忘れる。 Acmeが年間の総許容量を200万回下回って年を終え、契約が使い切り制（use-it-or-lose-it）である場合、その不足分は12月のボーナス収益には自動的にはなりません。未使用の前払い額（失効）は、規律ある方針の下でのみ認識されます。権利が行使されるにつれて利用に比例して、または行使の可能性がわずかになる時点で認識します。12月より前に方針を書き、一貫して適用し、開示してください。監査中に失効を発見することは、無限定意見が遅れる原因になります。
コミット・プラス・超過分の月末決算チェックリスト
上記のルールを繰り返し可能な決算に変えましょう。毎月、この順序で行います。
- メーターのエクスポートを取得し、レーティングエンジンと突き合わせる。 顧客別のレーティング済み利用は、請求システムの請求書入力と呼び出し単位で一致するはずです。何かを計上する前に差異を調査してください。メーターの停止は収益の完全性の問題であり、ITチケットではありません。
- ベースラインをリリースする。 有効な各コミットの12分の1を繰延収益からサブスクリプション収益に振り替えます。期首残高に新規請求を加え、リリースを差し引いて期末残高になる繰延収益のウォーターフォールは、監査人が最初に求める統制です。繰延収益勘定に絞り込んだFavaでレビューすれば、形の誤りがすぐに浮かび上がります。
- メーターから超過分を計上し、未請求の末尾を未収計上する。 請求済みの超過分は売掛金を借方に計上し、最後の請求処理後に測定された利用は未収収益を借方に計上します。どちらも利用月に利用収益を貸方に計上します。
- 見積もりを修正する。 超過分を定額で見積もる場合は、年初来の認識額と年初来のメーター測定額を比較し、修正額を計上します。発生時に認識する場合、このステップは5分の妥当性チェックに過ぎません。スタートアップがここから始めるべきもう一つの理由です。
- コミット・カバレッジをレビューする。 各顧客について、累積利用価値と累積リリース済みベースラインを比較します。コミットを大きく超えて消費する顧客は拡大の会話の対象です。大きく下回る顧客は更新リスクであり、将来の失効の仕訳の可能性があります。いずれにせよ、財務は営業より先に気づくべきです。
今月のメーターのエクスポートから始めましょう。台帳が認識したものと突き合わせ、ベースラインと利用に分け、二つの時計が独立して動いていることを確認してください。そうであれば、あなたのコミット・プラス・超過分の会計処理は、同規模のほとんどの企業よりすでに進んでおり、次の監査は短くなるでしょう。
