2022年にSaaS創業者に今月の収益はいくら計上するか尋ねると、その答えはスプレッドシートの数式でした。シート数に価格を乗じ、契約残存日数で日割り計算するというものです。今日、AIネイティブの創業者に同じ質問をすると、正直な答えは「顧客がモデルをどれだけ利用したかによる」となります。顧客が機能を本番環境に投入すると、トークン消費量は1週間で倍増する可能性があり、実験を一時停止すると横ばいになることもあります。予測の基準となるシート数はありません。
サブスクリプションから消費量ベースへのこの移行は、単なる料金設定の決定ではありません。これは会計上の問題であり、2018年以来SaaSを規定してきたのと同じ収益認識基準であるASC 606に直接関係しますが、はるかに予測困難な入力に適用されることになります。これを誤ると、端数処理の誤差では済みません。デューデリジェンス中に会計年度の遡及修正が必要となり、最も余裕のない時にそのような事態に直面することになります。
トークンベースの料金設定が従来の戦略を破綻させる理由
従来のSaaS収益認識は比較的寛容です。顧客が年間プランに12,000ドルを支払うと、毎月1,000ドルを認識し、最大の判断は契約変更によって再配分が必要かどうかです。対価は固定されています。履行義務、つまり時間の経過とともにソフトウェアへのアクセスを提供するという義務は単純明快です。監査人はこれと同じような契約を何千件も見てきました。
AIと利用量ベースの料金設定は、この固定部分を取り除きます。顧客は処理されたトークン、行われたAPIコール、完了した推論実行、または消費された計算秒数に対して支払います。この対価は設計上変動的であり、ASC 606にはまさにこの問題に特化したセクション、すなわちASC 606-10-32-11から32-13における「変動対価」に関するガイダンスがあります。核心的な課題は哲学的ではなく、実務的です。つまり、決算を締め切る時点では顧客が最終的にいくら支払うことになるのか正確には分からない期間に、どれだけの収益を認識すればよいのか、ということです。
初期段階のAI企業にとっては、これは簡単になる前にさらに難しくなります。成熟したSaaSビジネスは、長年の利用履歴に依拠して消費量を自信を持って推定できます。トークンベースの料金モデルを8か月前にリリースした企業には、そのような比較対象がありません。顧客がパイロット運用から本番環境へ移行するにつれて利用量は大きく変動する可能性があり、前四半期のパターンが今四半期のパターンについてほとんど語らないこともあります。
すべてを決定する2つの契約形態
利用量ベースの収益を1ドルでも正しく認識する前に、実際にどちらの形態に属しているのかを知る必要があります。なぜなら、それらは異なる方法で会計処理されるからです。
純粋な消費量ベース、最低コミットメントなし。 顧客はクレジットのプールを購入するか、消費されたユニットごとに支払うことに同意し、下限はありません。もしその取り決めが単純なサービス（顧客が独自に利用する知的財産権をライセンス供与するのではなく、ホスト型モデルへのアクセスを提供している場合）であれば、一般的にASC 606-10-55-65にある狭義の「知的財産権の利用ベースのロイヤルティ」例外は適用できません。これは特許のロイヤルティのようなライセンス契約向けに作られたものであり、ホスト型API向けではありません。代わりに、変動対価は期待値法または最尤アプローチを用いて推定され、不確実性が解消されたときに「重大な戻入れ」が発生する可能性が高い金額を認識しないという制約が課されます。
コミットされた最低額と超過分。 顧客は、例えば月に2,000ドルの利用量をコミットし、それを超えた場合は追加で支払います。ここでは、下限は固定対価のように機能し、顧客が価値を受け取るにつれて体系的な基準で認識されます。一方、最低額を超える部分は、同じ推定および制約ルールに従う変動対価となります。このハイブリッドはAIの料金設定で頻繁に見られます。基本プラットフォーム料金に加えて、従量制の推論が上乗せされる形です。
どの形態に属しているかを知ることは、仕訳、注記、そして監査人があなたの見積もりについてどれだけ懸念すべきかに影響します。
ほとんどのAI企業が実際に利用する実務上の便法
ここで朗報です。ASC 606には、まさにこの状況のために組み込まれた近道があり、ほとんどの整然と構築された利用量ベースの契約はそれに該当します。
「請求権」の実務上の便法（ASC 606-10-55-18）により、契約総対価の見積もりを完全に省略できます。もし各期間に請求する金額が、その期間に顧客が受け取った価値に直接対応する場合（例えば、1,000トークンあたり0.002ドルを請求し、顧客が400万トークンを利用したため8ドルを請求する場合）、その8ドルは稼得した期間に収益として単純に認識できます。予測も、制約分析も、各決算時での再見積もりも不要です。
注意点は「直接対応する」という文言にあります。もし料金設定に、利用量が増加すると単価が下がる階層がある場合や、利用が発生した期間にきれいに対応しないバンドル割引がある場合、この便法は適用できなくなります。請求額がその期間の価値を表さなくなり、完全な変動対価の見積もりに戻る必要があります。便法が契約台帳全体に一律に適用されると仮定する前に、このテストを特に念頭に置いて料金体系を見直してください。
ほとんどの消費量ベースのAI契約は、ASC 606-10-25-14に基づくシリーズ処理にも該当します。これは、各APIコールをそれ自体のミクロな履行義務として会計処理するのではなく、利用の全流れを時間の経過とともに充足される単一の履行義務として扱うものです。これにより、請求便法が管理上実用的になります。何千もの個別の義務を追跡するのではなく、変動する価格タグを持つ一つの継続的なサービスを追跡するだけで済むのです。
前払いクレジット：繰延収益と未使用残高の問題
多くのAIプラットフォームでは前払いクレジットパックを販売しています。例えば、500ドル分のトークンを前払いで購入し、数ヶ月かけて消費していくといったものです。この仕組みは、キャッシュフローを改善し、コミットメントを確保できるため人気がありますが、創業者が日常的に見落としがちな2つの会計上の義務が生じます。
未使用残高における繰延収益。 前払いパックの現金が手元に入った時点では、その全額がまだ収益ではありません。これは負債であり、顧客に対してサービスを提供するか、払い戻しを行う義務があります。収益は、トークンが実際に消費された分だけ、繰延収益の項目から損益計算書に計上されます。前払い金として受け取った日に全額500ドルを計上してしまう創業者は、収益を過大に計上しており、後でそれを修正する必要が生じます。これは通常、最悪のタイミング、つまり資金調達のデューデリジェンスの際、監査人がスケジュールを再構築し、すでに投資家に提示済みの期間から差額を差し引くという形で発生します。
使用されなかったクレジットの未使用残高（ブレイクエイジ）。 顧客の中にはクレジットパックを購入しても、有効期限が切れるまでにすべてを使い切らない場合があります。この未使用残高（ブレイクエイジ）は、クレジットの有効期限が切れた日に認識される単なる「フリーマネー」ではありません。ASC 606（顧客との契約から生じる収益）によれば、過去の利用パターンから未使用残高発生率を見積もり、その見積もられた未使用残高を、実際の利用と並行して、収益に対するわずかな増加分として比例的に認識することが求められます。期限切れを待って一度に全額を計上するべきではありません。まだ利用履歴がない場合（新しいクレジットプログラムではよくあること）は、慎重なアプローチとして、利用履歴が蓄積されるまで待つこととし、それまでの間は期限切れ時にのみ未使用残高を認識し、数期のデータが得られた後に方針を見直すのが良いでしょう。
変動対価の制約が実際に重要になる場面
変動対価に関する「制約」は、ある四半期に大口顧客の利用量が4倍に急増し、その後元に戻ったという経験をするまでは抽象的に聞こえるかもしれません。ASC 606は、重要な修正が後で必要になる可能性が高い場合に限り、変動対価を収益の見積もりに含めるよう求めています。実際には、次のことを意味します。
- 新しい価格モデルの初年度： 慎重な姿勢を取ります。約定された最低限度額と実績を自信を持って認識し、請求済み/実績利用量を超える予測については、比較可能な契約がないため、非常に懐疑的な見方で扱います。
- 利用履歴が蓄積されるにつれて： 制約を緩めることができます。なぜなら、この顧客の利用量は6ヶ月連続でXとYの間で変動している、というような、より厳密な見積もりのための正当な根拠が得られるからです。
- 各決算時： 再見積もりを行います。変動対価は「一度設定したら忘れる」という数字ではなく、新しい情報が入るたびに各報告期間で見直され、累積遡及調整は現在の期間に反映されます。
何百、何千もの契約にわたってこれを管理する財務チームにとって、運用の解決策は、決算後ではなく決算前に請求システムと収益認識元帳を連携させることです。そうすることで、利用データが手動の監査証跡を毎月末に必要とすることなく、自動的に照合されるようになります。
小規模であってもこれが重要な理由
もしあなたがトークン課金の顧客を数社抱える二人組のAIツールスタートアップであれば、これらすべてを「シリーズAを調達するときに対処すること」と捉えたくなる誘惑に駆られるかもしれません。しかし、それは現実的なリスクです。収益認識の誤りは、SaaSの資金調達デューデリジェンスで最も一般的な指摘事項の一つであり、利用量ベースの価格設定は、監査人が文書化を求める判断の数を増やします。例えば、どの契約で請求の便宜が用いられているのか、どのような未使用残高発生率を仮定し、その理由は何なのか、顧客の利用量が急増した四半期にどのように対処したのかなどです。
小規模な段階であっても、初日から仕組みを正しく構築することは、後で締め切りに追われて18ヶ月分の収益履歴を再構築する手間を省くことになります。また、社内で価格設定や採用の意思決定に使う数字が、あるべきでない場所に置かれている未認識の繰延収益によって水増しされることなく、実際に正確なものとなることを意味します。
帳簿を価格モデルと同じくらい明確に保つ
利用量ベースおよびトークン課金は、固定月額サブスクリプションよりも会計処理がはるかに複雑ですが、その複雑さは監査可能です。ただ、契約構造、制約の根拠、未使用残高に関する仮定を、後付けするのではなく、進行に合わせて文書化するだけです。Beancount.ioのプレーンテキスト会計は、その文書化の記録を明示的にします。すべての収益認識仕訳、繰延収益残高、未使用残高調整がバージョン管理されたテキストに残るため、あなた（またはあなたの監査人）は、ブラックボックス化した請求プラットフォームに埋もれることなく、行ごとに追跡することができます。無料で始めることで、あなたの帳簿を、その上に構築する価格モデルと同じくらい透明に保ちましょう。