あなたはメーター制API製品をリリースしました。顧客は500ドルのクレジットをチャージし、6週間かけてエンドポイントにアクセスしながら消費し、あなたは前払いを受け取ります。簡単ですよね？ ところが会計士がこう尋ねます。「実際に3月に計上した収益はいくらですか？」
もし「500ドルです、なぜならそれが銀行口座に入金された額だからです」と答えたなら、あなたには問題があります。しかも小さな問題ではありません。使用量ベースおよび従量課金の価格設定は、API製品、AIツール、インフラストラクチャ系スタートアップの標準になってきましたが、その収益を認識するための会計ルールは、請求モデルが柔軟になったからといって簡単になったわけではありません。これを誤ると、単に税金を誤って申告するだけでなく、自身のキャッシュランを誤読し、投資家を誤導し、後日痛みを伴う修正申告を招くことになります。
ここでは、これを実際に統制する原則と、最初から正しい数値を出すための帳簿の構築方法を説明します。
「現金受領」≠「収益獲得」
米国GAAPでは、収益認識はASC 606という5段階のフレームワークに従います。
- 顧客との契約を識別する
- 契約内の履行義務を識別する
- 取引価格を算定する
- 取引価格を履行義務に配分する
- 各履行義務が充足された時点（または期間にわたって）収益を認識する
定額年間サブスクリプションの場合、これは簡単です。請求書がいつ支払われたかにかかわらず、収益は12ヶ月にわたって均等に計上されます。使用量ベースの請求の場合、ステップ5が本当に厄介なポイントです。顧客がサービスを消費した時点で収益を認識し、支払いを受けた時点ではありません。
この一文が、使用量ベースの会計におけるほとんどすべての過誤の原因です。APIクレジットとして500ドルを前払いした顧客は、あなたに500ドルの収益を与えたのではありません。500ドルの現金と、負債を与えたのです。あなたは彼らにサービスを提供するか、お金を返す義務を負っています。彼らがコール、ストレージ、コンピュートを消費するにつれて、ようやくその負債を認識収益に振り替えることができるのです。
スタンバイ義務をシンプルに説明する
会計士は、使用量ベースモデルであなたが実際に販売しているものをスタンバイ義務と呼びます。あなたは単にAPIコールを処理することを約束しているのではありません。顧客が必要とするときにいつでも、必要な量だけ、オンデマンドで処理できるよう利用可能であることを約束しているのです。
これは、収益を概念的に異なる2つの要素に分割できる可能性があるため重要です。
- アクセス要素 — 単に利用可能であることの価値（契約期間にわたって均等に認識されることがある）
- 消費要素 — 実際の使用量単位あたりに提供される価値（使用が発生した時点で認識される）
純粋な従量課金制製品（基本料金なし、最低利用コミットメントなし）のほとんどは、これを消費要素のみに集約します。これは良いニュースです。会計処理がより簡単だからです。
変動対価：待ってから決められない理由
最終的な請求額は契約締結時に誰も予測できない使用量に依存するため、ASC 606は使用量ベースの料金を変動対価として扱います。理論上は、取引価格を事前に見積もる必要があり、以下のいずれかの方法を使用します。
- 期待値法 — 起こりうる結果の確率加重平均
- 最も可能性の高い金額法 — 最も確からしい単一の推測値
そして重要な点として、実際の使用量が判明した後で重大な戻し入れが発生しない範囲でのみ、見積もりを認識収益に含めることができます。この「制約」は、企業が楽観的な収益を早期に計上し、後でそれを取り消さなければならない事態を防ぐために存在します。これは、規制当局がソフトウェア監査で繰り返し指摘してきたパターンです。
リーンに運営する個人開発者にとって、毎月確率加重の使用量予測を構築するのは過剰です。幸いなことに、近道があります。
ほぼすべてのAPIビジネスが利用すべき実務便法
ASC 606には「請求権」実務便法があります。特定の期間に請求する権利のある金額が、その期間に提供した価値に直接対応する場合、見積もりのプロセスを省略し、使用が発生するにつれて、請求する権利のある金額で収益を認識することができます。
これは、純粋なコール単価、トークン単価、トランザクション単価の価格設定における標準的なパターンです。APIコールあたり0.001ドルで、数量割引や最低コミットメントがない場合、特定の日のコールに対して請求できる金額は、その日に提供された価値そのものです。見積もりは不要です。コールが発生するにつれて、収益を認識します。それだけです。
この便法が機能しなくなるのは、段階的または累積数量価格設定で、期間2の単価が期間1の顧客の使用量に依存する場合です（例：「最初の10万コールは0.002ドル、それを超える分は0.001ドル」）。この場合、単一期間の請求金額はその期間の価値にきれいに対応せず、適切な見積もりが必要になる可能性があります。価格設定に数量段階がある場合は、近道が適用できると仮定する前に、会計士と相談する価値があります。
具体的なウォークスルー
あなたのAPI製品に、20万コールを含む月額200ドルの基本料金があり、超過分は含まれるコールと同じ実効レートで1コールあたり0.001ドル請求されるとします。
- 基本料金 + 含まれる使用量：超過レートが含まれる実効レートと一致するため、基本料金と超過分を合わせた料金全体が、通常は請求実務便法の対象となります。20万の含まれるコールが消費されるにつれて200ドルを均等に認識し、超過コールが発生するたびに1コールあたり0.001ドルを認識します。
- 前払いクレジットパック：顧客が1月に1,000ドルのクレジットを購入します。借方：現金、貸方：繰延収益 1,000ドル。2月に0.002ドル/コールでクレジットを消費するにつれて、借方：繰延収益、貸方：認識収益をコールごとに計上します。月末時点で300ドルのクレジットが未使用の場合、300ドルは貸借対照表上、負債として残ります。3月の見通しがどんなに良くても、これは収益ではありません。
- 月末の未請求使用量：請求サイクルが1日から1日までですが、顧客の12月の使用量は1月2日まで請求されません。このギャップには仕訳が必要です。借方：未請求債権（資産）、貸方：収益。これは12月に行われたがまだ請求されていないコールの価値です。実際に請求書が発行された時点で、未請求債権から標準的な売掛金に振り替えます。収益はすでに計上済みです。
現金主義の税金と発生主義の帳簿
ここで、多くの個人創業者が混乱します。税務申告と収益認識は同じ基準で行う必要はなく、多くの場合そうすべきではありません。大多数の小規模事業者は、ASC 606が収益が「獲得」された時期について何と言おうと、現金主義で税金を申告できます。収入は受領時に課税され、費用は支払時に控除されます。APIクレジットを販売する個人事業主LLCは、内部の帳簿では認識収益が700ドルで300ドルが繰延収益に計上されている場合でも、1,000ドルの前払い金が銀行口座に入金された年に、それに対する税金を合法的に支払うことができます。
罠は、これら2つの見方を互換性があるとみなし、1つの数値セットしか保持しないことです。現金主義の合計のみを追跡している場合、潜在的な買収者、投資家、または融資者がデューデリジェンスでGAAP基準の収益を尋ねたとき、防御可能な答えを持っていません。そしてその時には、何ヶ月分もの使用履歴を再構築するには遅すぎます。最初から両方のビューを元帳に保持してください。税理士に渡すキャッシュフローと、繰延収益と未請求債権を明示的に追跡する発生主義ビューです。そうすれば、どちらの質問にも、締め切りに追われたスプレッドシートではなく、同じ信頼できる情報源から答えられます。
実際に痛手となる過ち
これを経験したチームと話をすると、失敗はいくつかの繰り返しパターンに集中しています。
- メータリングのずれ。使用量追跡パイプラインが、実際に請求するコール数に対して過少または過大カウントしている場合、収益元帳と請求システムは静かに乖離します。そして、調整が行われるまで誰も気づきません。ブートストラップチームの場合、それは「なぜ数値が合わないのかと会計士が尋ねる時」かもしれません。
- 日割り計算ロジックのないサイクル途中のプラン変更。顧客が30日サイクルの15日目にティアをアップグレードします。システムがその期間の使用量と価格を正しく分割しない場合、その月のその顧客の収益を過大または過小に認識することになります。
- 請求ロジックと収益認識ロジックの未分離。「請求した金額」を「獲得した金額」として扱うのは魅力的です。定額サブスクリプションの場合、これらの数値はすぐに収束します。使用量ベースの価格設定の場合、特に前払いクレジットや年間最低利用量がある場合、これらは頻繁に一致しません。
- 紛争とクレジットを後回しにすること。顧客が超過料金に異議を唱え、クレジットを発行する場合、そのクレジットは請求システムだけでなく、収益元帳にも反映される必要があります。そうしないと、既に取り消した期間の収益を過大計上することになります。
初日から帳簿に組み込む
小規模なうちは、これらのためにエンタープライズ会計ソフトウェアは必要ありません。必要なのは、使用量イベントを単なる請求インプットではなく、実際の会計上の証跡として扱うことです。
- 使用量イベントの監査可能なログ（タイムスタンプ、数量、適用レート）を請求システムとは別に保持します。期間ごとの収益を再構築し、監査や資金調達の際に数値を防御するために必要です。
- 繰延収益と未請求債権を暗黙の仮定ではなく、明示的な元帳勘定として追跡します。顧客が前払いし、すべてを使い切っていない場合、その残高は、営業以外誰も見ない請求ダッシュボードに埋もれさせるのではなく、帳簿上で可視化される必要があります。
- 請求システムと収益元帳を定期的（最低でも月次）に調整し、メータリングのずれを四半期単位ではなく週単位で発見できるようにします。
これはまさに、プレーンテキストでバージョン管理された会計が得意とする構造です。勘定科目表がブラックボックスのSaaSダッシュボードではなく、Gitで追跡された元帳に存在する場合、「3月1日時点の繰延収益を見せて」や「この顧客のサインアップ以来のすべての使用量ベース収益エントリを見せて」は、実際に読めるファイルへの単なるクエリであり、請求ベンダーへのサポートチケットではありません。
使用量ベースの収益を正直に保つ
使用量ベースの価格設定は、顧客にとって真に優れており、成長にもしばしば有効です。しかし、製品を出荷したい創業者に、現実の会計上の複雑さを押し付けます。Beancount.ioは、プレーンテキストの複式簿記会計を提供し、繰延収益、未請求債権、使用量ベースの認識を、誰か他のSaaSの中に隠すのではなく、透明で監査可能にします。無料で始める そして、メータリングパイプラインと同じくらい正確な帳簿を維持しましょう。