App Store Connect は先月の売上が3,108と表示します。合計して6,580、Googleから$2,210。誰もあなたから盗んでいません。消えたドルにはすべて名前があります：VAT、手数料、返金、源泉徴収、通貨換算、そして最終的な所得税です。問題は差額そのものではなく、ほとんどのインディーデベロッパーがそれを説明できる台帳を持っていないため、本当に重要な3つの質問に答えられないことです：価格設定は正しいか？正しい手数料率に登録しているか？キャッシュフロー予測は現実的か？
このガイドでは、表示価格から手取りまでの完全なウォーターフォールを解説し、ペイアウトがレポートと一致しない理由を説明し、一度設定すれば毎月約30分で完了する照合ルーチンを提供します。
3つの数字、3つの異なる答え
すべてのアプリビジネスには3つの売上数字があり、これらを混同することが混乱の始まりです：
- 総売上 — 顧客が支払った金額で、分析ダッシュボードに表示されます。これは虚飾の数字です。ストアが徴収する税金を含み、通常は後に調整される見積もりです。
- デベロッパー収益（Developer proceeds） — ストアがあなたの収益として示す金額で、月次財務レポート（Apple）および収益レポート（Google）に表示されます。これは手数料、ストアが徴収・納付する税金、返金、チャージバックを差し引いた金額です。会計の基盤はこの数字に置くべきです。
- ペイアウト — 銀行入金です。収益から源泉徴収税を差し引き、通貨換算を調整し、最低支払い額基準とストアの支払いカレンダーの影響を受けます。
帳簿に銀行入金だけを記録すると、売上は静かに過小評価され、1か月以上ずれます。総売上を記録すると、売上は30〜50%過大評価され、実際に受け取る金額とは一致しません。アプリストアの簿記の技術は、これら3つの数字を結びつけ、毎月報告された収益と受け取った現金の差がゼロになるようにすることです。
表示価格から手取りまでのウォーターフォール
VAT 20%の国で販売された€9.99のサブスクリプションを標準の30%手数料で考えます。実際に起こることを正直に示します：
| ステップ | 計算 | 残額 | 表示価格に対する割合 |
|---|---|---|---|
| 表示価格 | — | €9.99 | 100% |
| ストアが徴収・納付するVAT | €9.99 ÷ 6 | €8.33 | 83% |
| ストア手数料（標準率） | 30% × €8.33 | €5.83 | 58% |
| 返金・チャージバック（3%と仮定） | 3% × €5.83 | €5.65 | 57% |
| 実効税率30%の所得税 | 30% × €5.65 | €3.96 | 40% |
表示価格の約60%はあなたの懐に入りません。デジタル商品に課税しない米国の州での販売はより高い基準から始まり、低減手数料率のデベロッパーは大幅に多く保持できます（同じVAT地域での15%手数料販売は、返金前で€7.08 — 表示価格の約71%）。正確な割合は販売構成に依存しますが、構造的な教訓はどこでも同じです：総売上はあなたのお金ではありません。ストアのお金がダッシュボードを通過しているだけです。
これらは隠されていません。AppleとGoogleのプログラム利用規約はすべての控除を明記しています。インディービジネスに欠けているのは追跡です — ウォーターフォールの各層を毎月の驚きではなく記録され監査可能な事実にする場所です。
実際に支払っている手数料率
この分野で最も高くつく簿記関連の間違いは、誤った手数料率にいることです。両ストアとも小規模デベロッパーには手数料を半減しており、登録はどこでも自動ではありません：
AppleのApp Store Small Business Program は、有料アプリ、アプリ内課金、サブスクリプションの手数料を30%から15%に引き下げます。資格は収益（proceeds） — Appleの手数料や特定の税金・調整を差し引いた売上で、総売上ではありません — で測定され、前暦年にあなたのアカウントおよびすべての関連デベロッパーアカウント（あなたが所有、管理、またはあなたを所有・管理するすべてのアカウント）で100万以下であることが条件です。デベロッパーがつまずく2つの詳細：
- 年度途中で$100万を超えた場合、標準の30%率が将来の販売に適用されます — すでに15%で行われた販売は遡及されず、収益が基準を下回った翌年に再資格を得られます。
- 手数料率の変更は、登録が承認された会計月の終了から15日後に有効になるため、登録が遅れると毎週実質的なコストが発生します。
Google Playの低減ティア は、各暦年の最初の$100万に15%を適用し、それを超える収益に30%がかかります — Play Consoleで関連アカウントをグループ化し、条件に同意して登録します。知っておくべき構造的な違い：Googleでは、すべての自動更新サブスクリプションはプログラム登録に関係なく初日から15%のサービス手数料が適用されます。Appleの標準率では、加入者は最初の12か月は30%で、2年目から15%になります — これは低減プログラムを卒業した後にのみ重要になる、継続率の静かな論拠です。
$100万未満でAppleのプログラムに登録していない場合、それを修正することは今年で最もROIの高い10分間かもしれません：登録フローはApp Store Connectの「契約、税金、および銀行」にあります。
入金がレポートと一致しない理由
正しい手数料率でも、収益とペイアウトはすべて機械的な理由で乖離します — そしてそれぞれが帳簿に1行必要です：
支払いカレンダーは月次ではありません。 Appleは各会計月の終了から45日以内に支払いますが、その会計月は暦月と一致しません — 会計月が12月27日に終了し、支払いが1月29日に届くこともあります。実際には約33日の差があります。Googleは翌月の15日に支払います（15日が週末の場合、次の営業日にずれます）。発生主義会計の場合、12月の売上は1月または2月中旬の現金になり、帳簿には両者を橋渡しするペイアウト清算勘定が必要です。
最低支払い額基準により小額のペイアウトが遅れます。 Appleは、銀行所在国と通貨によって異なる最低支払い額を超えた場合のみ支払います。売上が低い月は入金がなく、残高が翌月に繰り越されます — 追跡していなければ$30が消えたように見えます。
返金・チャージバックは収益から差し引かれます。 ストアは取引全体を回収し、返金率は製品や地域によって静かに変動します。正しく計上すれば、これは返金がレポートに反映された月の反対売上（contra-revenue）であり、入金からの謎の控除ではありません。
税金は2つの異なる経路を流れます。 VATおよび多くの売上税では、ストアが税務上の merchant of record として機能します — 例えばEUでは、GoogleがVATを請求・徴収・納付するため、収益は税抜き基準で計算され、それらの国でVAT申告をする必要は通常ありません。別途、米国外のデベロッパーは米国源泉の金額に対して米国の源泉徴収の対象となり、App Store Connect（またはPlay Consoleの同等物）でW-8BENまたはW-8BEN-Eを提出していない場合、30%の一律税率が適用されることがあります。租税条約率 — またはペイアウトがストアの国際エンティティから送金されるという事実 — により0%に減らせる場合があります。いずれにせよ、源泉徴収は報告された収益と入金の差として現れ、通常は税額控除として回収可能です — 記録していれば。
通貨換算は実際のコストです。 ストアは銀行契約の通貨でペイアウトし、その過程で地域ごとの収益を換算します。FXスプレッドは請求書のない費用であり、それを見る唯一の方法は、通貨ごとの報告された収益と入金を比較することです。
ほとんどのインディーが間違える会計上の質問
売上項目には総売上と純収益のどちらを表示すべきですか？圧倒的多数のインディーデベロッパーにとって、答えは**純額（net）です。米国GAAP（ASC 606）およびIFRS 15に適用される収益認識フレームワークでは、テストはあなたが販売の本人（principal）であるか — 顧客への移転前に商品やサービスを管理しているか — またはストアが販売を行った時点で履行義務が満たされる代理人（agent)**であるかです。ストアが merchant of record で、税金を徴収し、支払い経路を設定し、返金処理を負担し、取引ごとの純額を支払う場合、ストアが本人であり、あなたの売上は収益（proceeds）です。総売上を計上して手数料を費用として表示すると、売上が膨らみ、計算するマージン率が歪み、誰かが見た場合に税金を誤って表示します。
2つ目の誤りはタイミングです：銀行入金をその月の売上として計上すること。入金は前月（または前会計月）の収益を精算します。正しいパターンは：
- 売上が発生した時点で収益を見越し計上し、実際の数値が出ていない場合はストアの見積もりを使用。
- 月次財務レポートが届いたら実際の数値に調整し、見積もりと実際の差を計上（ほぼ常に差があります — 通貨、返金、遅延調整が原因）。
- ペイアウトが届いたら売掛金を精算し、残差は源泉徴収、FX、または最低額の繰り越しに分類 — それぞれ独立した勘定科目。
最後の項目が重要です：すべての残差に名前の付いた勘定科目があれば、ゼロ以外の差は見逃せず、説明に数分しかかかりません。
30分で完了する毎月の照合ワークフロー
- 実際の数値をダウンロード。 App Store Connectから月次財務レポート（全地域をカバーし、決済日を含む詳細版）を取得。Play Consoleから収益レポートを取得。これら — 分析ダッシュボードではなく — がソース文書です。
- 地域・通貨別に収益を記録。 ストアごとに1つの売上行を作成し、地域と通貨を下で追跡。ここが監査証跡です：「なぜ3月にEU収益が12%減ったのか」と聞かれた日に、VAT、手数料、返金を分けて表示できるように。
- 見積もりと実際の差を計上。 ダッシュボードの予測とレポートの差：通常は返金、通貨、一括ペイアウト調整。
- 返金・チャージバックを反対売上として計上 レポート月に計上し、時間の経過とともに率を監視 — 返金率の上昇は会計の衣を着たプロダクトシグナルです。
- ペイアウトを売掛金と照合。 入金が届いたらレポートと照合。源泉徴収は税債権勘定へ（多くの場合控除可能）；FX差額は通貨費用へ；最低額を下回る少額入金は清算勘定に翌月まで残す。
- 手数料率を四半期ごとに確認。 App Store ConnectでSmall Business Program登録、Play Consoleでティアを確認 — 特に収益が$100万に近づいている場合、両ストアとも将来の販売で率が変更されます。卒業を事前にモデル化：閾値を超えると、年度途中でマージン構造全体が再価格設定される可能性があります。
6つのステップ、月1回の1セッション。報酬はきれいな帳簿だけではありません — 価格決定、手数料率登録、キャッシュ予測がすべて虚飾の数字ではなく収益で動き始めることです。
ウォーターフォール全体をプレーンテキストで追跡
これはまさにプレーンテキスト会計が力を発揮する多層照合の種類です。beancount台帳は、ウォーターフォールの各層に独自の勘定科目を提供します — income:appstore:ios、income:playstore:android、expenses:refunds、assets:receivable:payouts:apple、assets:tax-withheld — したがって、月次仕訳自体が説明であり、すべての数字が何年後でも再導出できるダウンロード済みレポートに結びつきます。台帳がテキストであるため、ストアレポートをバージョン管理の隣に置き、照合はスプレッドシートの考古学プロジェクトではなくdiffになります。銀行明細とストアデータのインポートメカニズムが必要な場合は、ドキュメントでインポートパイプラインを詳しく解説しています。
財務管理をシンプルに
アプリストアの収益は、ほとんどのデベロッパーが直面する中で最もあなたに対して照合される収入です：手数料、税金、返金、支払いカレンダーがすべてお金が届く前に控除されます。そのウォーターフォールを反映した帳簿 — 単一の「アプリ収入」行ではなく — を維持することが、混乱するペイアウトを透明で監査可能なシステムに変えます。Beancount.ioは、透明性があり、バージョン管理され、AI対応のプレーンテキスト会計を提供し、すべてのストアレポート、調整、入金を追跡可能に保ちます。無料で始めて、手取りをコードと同じくらい読みやすくしましょう。