App Store ConnectやGoogle Play Consoleを開くと、まるで自分の収益のように見える数字が表示されます。先月は1万ドルと出ていました。銀行口座に入金されたのは7,000ドルです。どちらの数字も間違いではありませんが、損益計算書に「収益」として載せるのはそのうちの1つだけです。この判断を誤ると、粗利率が歪み、成長率が誤って表示され、貸し手や投資家に誤った事業実態を伝えることになりかねません。
これが本人対代理人の問題です。米国GAAPのASC 606収益認識基準の下では、これは単なる任意の書類作業ではなく、1万ドルの収益と3,000ドルの売上原価を報告するのか、それとも7,000ドルの収益だけを報告して他に何も言わないのかを決定するルールです。AppleのApp StoreやGoogle Play Storeを通じて販売するインディー開発者にとって、その答えはたいてい人を驚かせます。
すべてのアプリ開発者がいつか直面する質問
きっかけはほぼいつも同じです。創業者がピッチデッキを作成したり、中小企業向け融資を申し込んだり、単に「今四半期に実際にどれだけ稼いだのか」を知りたいと思ったときに、銀行口座に入金された金額をそのまま「売上」として記録していたことに気づくのです。その金額はAppleまたはGoogleの手数料が差し引かれた後、つまりプラットフォームの取り分がすでに差し引かれた数字です。
問題は、収益からプラットフォーム手数料を差し引くことがスタイル上の選択ではないことです。ASC 606にはこの状況に特化したテストがあり、その鍵となるのは1つの質問です：顧客に渡る前に、販売されるものに対する管理権を誰が持っているか？
ASC 606の管理テストをわかりやすく説明
ASC 606の5段階の収益モデルでは、契約内の履行義務を特定し、誰がそれを果たしているかを判断する必要があります。マーケットプレイスやプラットフォーム（Apple、Google、Etsy、DoorDash、Uberなど）があなたとエンドカスタマーの間にある場合、会計基準ではこれを本人対代理人の評価と呼び、PwCの収益ガイドは、アプリストアの売上がまさにこの注意深い検討を必要とする取引の典型例であると指摘しています。
- 本人：あなたが商品やサービスを顧客に移転する前に管理している。顧客が支払った全額（総額）を収益として認識し、プラットフォームの手数料は売上原価（費用）となり、収益の減額ではありません。
- 代理人：プラットフォームが提供物を管理しており、あなたは他者に代わって販売を手配しているだけです。あなたが保持する純額のみを手数料として認識します。
DeloitteとPwCのフレームワークによると、どちらに該当するかを決定する3つの指標は次のとおりです。
- 履行責任 — アプリが動作しない、サブスクリプションが提供されない、または顧客から苦情があった場合、誰が責任を負うか？ 通常、それはAppleではなく、あなた（開発者）です。
- 移転前のリスク — 「在庫」（アプリ、コンテンツ、サブスクリプション層）が売れなかったり、顧客を満足させなかったりするリスクを誰が負うか？ これも通常、あなたです。
- 価格設定の裁量権 — 顧客が実際に支払う価格を誰が決めるか？ あなたがアプリの価格帯を選びます。プラットフォームが取引ごとに交渉することはありません。
ほとんどのインディー開発者は、製品体験を管理し、サポートやアップデートに関する顧客関係を所有し、自ら価格を設定するため、テストの本人側に該当します。つまり、正しい会計処理は、顧客が支払った総額を収益として記録し、AppleやGoogleの取り分を売上原価項目として扱い、目に見えない削減としては扱わないことです。
削減額の内訳
自分が本人であることを知っていても、実際に何が差し引かれているのかを知らなければ意味がありません。プラットフォームの手数料体系はここ数年で大きく変化しており、ほとんどの開発者は時代遅れの前提に基づいて予算を立てています。
| プラットフォーム | 標準手数料率 | 割引料率 | 対象者 |
|---|---|---|---|
| Apple App Store | 30% | 15%（App Store小規模事業者プログラム） | 年間App Store収益が100万ドル以下の開発者 |
| Apple サブスクリプション | 30%（1年目） | 15%（2年目以降） | 初回12か月を過ぎたすべてのサブスクリプション |
| Google Play | 30% | 年間最初の100万ドルの売上に対して15% | すべての開発者（自動的に段階適用） |
| Google Play サブスクリプション | 一律15% | — | すべてのサブスクリプション収益 |
| Apple EU（デジタル市場法条件） | 約17% + コアテクノロジーフィー | 合計で最大約20% | EUの代替ビジネス条件を選択した開発者 |
さらに、ほとんどの人が割り当てるのを忘れがちな年間固定費もあります。Appleの年間99ドルの開発者プログラム料金、Googleの25ドルの一回限りの登録料です。少額ですが、これらも勘定科目表のどこかに属します。通常は一般運営費であり、売上原価ではありません。
正しい記録方法：具体例
顧客がAppleを通じて9.99ドルのアプリ内サブスクリプションを購入し、あなたが標準の30%料率の場合を考えます。Appleは顧客から9.99ドルを徴収し、3.00ドルを保持し、最終的に6.99ドルをあなたの銀行口座に入金します。この6.99ドルを「収益」として記録すると、トップラインが30%過小評価されます。これは、直接販売する競合との成長率を比較したり、貸し手に粗利率を説明したりする際に重大な影響を及ぼします。
正しい仕訳は、全額の売上を認識し、その後手数料を別途費用として計上します。
2026-07-18 * "Apple" "iOSサブスクリプション — 総額売上"
Assets:Receivable:AppStore 9.99 USD
Income:AppSales -9.99 USD
2026-07-18 * "Apple" "30% App Store手数料"
Expenses:CostOfRevenue:PlatformFees 3.00 USD
Assets:Receivable:AppStore -3.00 USD
2026-07-20 * "Apple" "入金受取"
Assets:Checking 6.99 USD
Assets:Receivable:AppStore -6.99 USD入金が完了すると売掛金勘定はゼロになりますが、損益計算書には9.99ドルの収益と3.00ドルの売上原価が表示され、この販売の粗利率は70%となります（謎の30%減少ではありません）。これはまさに、プレーンテキストでバージョン管理された台帳が得意とする取引の種類です。総額売上、プラットフォーム手数料、入金が3つの別々の監査可能なイベントとして記録され、1つにぼやけた銀行入金ではありません。
ダッシュボードの数字だけでは不十分な理由
ルールを知っても、手作業で適用するのは思っているより難しいです。標準のApp Store ConnectやPlay Consoleのレポートは、ASC 606が本来要求する加入者レベルや取引レベルの詳細（売上、払い戻し、通貨換算）を集計した合計のみを表示し、実際の販売から数日から数週間後にまとまった金額として到着することがよくあります。このギャップこそ、増え続けるサブスクリプションアプリのビジネスが、月次サマリーPDFから逆算するのではなく、プラットフォームAPIやRevenueCatのようなツールを使用して取引ごとの詳細を再構築する理由です。
このステップを省略すると、実際のコストが発生します。広く引用されている例では、ある開発者がダッシュボードで月に3,400ドルと表示されていたのに対し、手数料、税金、その他のプラットフォーム控除後、実際に使えるのは1,294ドルだけでした。つまり、「収益」と思っていた数字と事業が実際に保持した数字の間には60%以上のギャップがあったのです。ダッシュボードの数字に基づいて採用や支出の判断をしている開発者は、決して現実ではなかった数字に対して予算を立てていることになります。
帳簿を歪めるよくある間違い
- 純額入金のみを収益として記録すること。 これが最も一般的な誤りであり、この記事のテーマです。収益と売上原価の両方を過小評価し、粗利率の全体像を意味のないものにしてしまいます。
- 払い戻しとチャージバックを無視すること。 AppleとGoogleはどちらも顧客の払い戻しをあなたに代わって処理し、元の販売から数週間後に行われることもあります。取引ごとに照合しないと、払い戻された収益が帳簿上に無期限に残る可能性があります。
- Appleの99ドルの開発者料金やGoogleの25ドルの登録料を売上原価に混ぜること。 これらは固定の運営費であり、取引レベルの手数料ではありません。別の費用区分に属します。
- EUの別個の手数料スケジュールを忘れること。 ユーザーベースの一部がEUにあり、Appleの代替条件を選択した場合、その収益は事業の他の部分とは異なる手数料体系となるため、専用の勘定科目が必要です。
ビジネスの拡大に伴い財務を整理する
ストアに1つのアプリがある個人開発者でも、少数のサブスクリプション製品を扱う小さなスタジオでも、総額か純額かの判断を誤ると、毎月その影響が積み重なります。資金調達や融資申請の時点で、過小評価された収益ラインを説明するのは困難です。Beancount.ioは、まさにこの種の複数ステップ取引（総額売上、プラットフォーム手数料、入金を3つの別々の監査可能なエントリとして記録し、1つにぼやけた銀行入金にしない）に適した、プレーンテキストでバージョン管理された台帳を開発者に提供します。無料で始めましょう。すでにコードで思考する開発者が、同じように機能する会計を好む理由がわかります。