今日Chromeウェブストアの開発者ダッシュボードを開くと、あるものが欠けていることに気づくはずだ。「決済」タブである。Googleは2021年に拡張機能向けの自社アプリ内決済システムを廃止し、それ以来復活していない。2026年にChrome拡張機能で課金したいなら、請求、サブスクリプション、返金、税金の徴収、そして——ほとんど誰も計画していない部分——実際に販売したものと銀行口座に入金された金額を突き合わせる作業まで、すべて自分でやらなければならない。
この最後の部分こそが、価格設定よりもはるかに多くのインディー開発者をつまずかせる。Stripe、Paddle、あるいはExtensionPayのようなラッパーを通じて3つか4つの拡張機能を運営している一人開発者は、どの製品にもきれいに対応しない入金、Chromeウェブストアの審査遅延の後に何の前触れもなく発生する返金の急増、そして販売ダッシュボードが示すべき金額と決して一致しない銀行残高に行き着く。これはあなたのビジネスの不具合ではない。かつてGoogleがあなたの代わりに運営していた決済スタックを、自分でつなぎ合わせた結果として当然起こることなのだ。
ここでは、それに耐えうる帳簿管理の構築方法を解説する。
なぜGoogleは決済事業から撤退したのか
Chrome Web Store Paymentsは2010年代初頭に開始された。当時、ソロ開発者がブラウザ拡張機能で課金するための優れた選択肢はほとんどなかった。2021年までにStripe、Braintree、そして「Merchant of Record」サービスの波が十分に成熟し、Googleは自前のチェックアウト、ライセンスキー、入金システムを運営する必要がないと判断した。GoogleはChrome Web Store Paymentsを廃止し、すべての有料拡張機能に無料化するかサードパーティの決済代行業者へ切り替えるかの選択を迫った。
開発者にとっての実際的な結果はこうだ。拡張機能が稼ぐすべてのドルは、今や自分自身が組み立てた決済スタックを通過し、そのスタックが生み出すすべての消込問題は自分で解決しなければならない。もはや単一の「Chrome Web Store入金レポート」というものは存在しない。あるのは決済代行業者が提供するもの、Chromeウェブストア自体の掲載アナリティクスが示すもの、そして銀行明細書であり、これら3つが一目で一致することはめったにない。
決済代行業者かMerchant of Recordか——拡張機能ごとに選ぶ
消込作業を始める前に、取引において自分が法的にどちら側に立っているのかを把握しておく必要がある。それによって帳簿に何が計上されるかが変わってくるからだ。
決済代行業者(Stripeを直接使うか、ExtensionPayのようなその上に構築されたラッパーを使う場合)は、あなたを販売者にする。あなたが代金を回収し、税務上のMerchant of Recordはあなた自身であり、顧客が住むあらゆる法域における売上税・VAT義務を把握する責任もあなたにある。手数料は低め——Stripeの基本料金は1回の課金につき2.9% + $0.30で、ExtensionPayのようなラッパーは通常さらに独自の取り分を上乗せする——が、コンプライアンス負担はあなたが負うことになる。
Merchant of Record(Paddle、Lemon Squeezy、Fungiesなど)は、あなたの代わりに法的な販売者となる。彼らがVATやGSTを回収し、デジタル商品に対してそれを義務付けている140以上の国で申告を行い、チャージバックに対応し、純収益をあなたに支払う。収益の約3%ではなく4〜8%を手放すことになるが、帳簿管理と税務申告作業のカテゴリーがまるごと消える。トレードオフの全体像と、切り替えがいつ元を取れるかの計算方法については、Merchant of Recordガイドを参照してほしい。
月収が数千ドル以下のほとんどのソロ拡張機能開発者にとって、MoRが請求する追加の3〜5%は、十数カ国で手作業によるVAT登録を行う必要をなくすための安い保険だ。複数の拡張機能で実質的な継続収益を運営するようになったら、もう一度比較してみるとよい——取引量が増えるにつれて計算は変わってくる。
どちらを選ぶにせよ、それを書き留めておくこと。帳簿には「この拡張機能の法的な販売者は誰か」という問いに対する明確な答えが必要だ。それによって、売上税負債がそもそも貸借対照表に現れるかどうかが決まるからだ。
消込問題は構造的なものであり、ミスではない
開発者が意表を突かれる部分がここにある。決済代行業者を正しく設定していても、受け取る入金額がその期間に発生した収益と一致することはほとんどない。1対1の対応関係を崩す要因は3つある。
- 入金のバッチ処理。 Stripeやほとんどのマーチャント・オブ・レコードはローリングスケジュールで入金を行う(多くの場合、課金から2〜7日後、週次のこともある)。そのため、月の5日に届く入金には、前月の最後の数日分の売上が含まれていることがある。入金を銀行口座に着金した日に収益として計上すると、毎月確実に誤った期間に収益を帰属させてしまうことになる。
- 複数の拡張機能を1つの決済代行業者アカウントで扱う場合。 同じStripeやPaddleのアカウントで複数の拡張機能を運営している場合——1つの主力製品ではなく、いくつもの小さなツールを出している開発者にはよくあるケースだ——入金はそれらすべてをまとめた一括の金額になる。拡張機能ごとのタグ付け(Stripeのメタデータフィールドや、拡張機能ごとに分けたProduct/Price)がなければ、どの拡張機能が実際に収益を生んでいるのか分からず、どれにメンテナンスの時間を割く価値があるのかも判断できなくなる。
- 手数料、返金、通貨換算は、数字を目にする前にすでに差し引かれている。 入金額は、決済手数料、その期間に発生した返金、そして海外で販売している場合は通貨換算後の、すでに純額になった金額だ。入金額を総収益として計上すると、トップラインを過大に見せてしまい、実際の利益率を隠してしまう。
解決策は、少なくとも月次で行う三者間照合である。
- 決済代行業者の売上レポート——手数料と返金が差し引かれる前の総取引額。アカウントが対応していれば製品/拡張機能ごとの明細付き。
- 決済代行業者の入金レポート——実際に銀行に振り込まれた純額。手数料と返金は個別の項目として分けて記載される。
- 銀行明細書——実際に着金が確定した入金。
この3つすべてを突き合わせる。売上レポートは、あなたが稼いだ金額(顧客がサービス期間分を支払った時点で認識される収益)を教えてくれる。入金レポートは、費用や収益控除として計上すべき手数料の目減りと返金の動きを教えてくれる。銀行明細書は、実際に現金が届いたことを確認してくれる。3つのうちどれか2つが一致しない場合、それは何か調査が必要だという合図だ——入金の失敗、係争中のチャージバック、あるいは予想していなかった決済代行業者の手数料などである。
Chrome特有のリスク: 審査遅延と削除
どんな決済スタックにも通常の返金活動はある。Chrome拡張機能にはさらに、独立した項目として追跡する価値のある障害モードがもう一つある。Chromeウェブストアの審査遅延とポリシー違反による削除だ。
Googleの審査チームが公開済みの拡張機能をポリシー違反としてフラグ付けすると、即座の削除(中〜重度の違反の場合)か、軽微な違反を修正するためのおよそ7〜30日間の警告期間のいずれかが科される。どちらの場合も、ユーザーは実際に料金を支払っている拡張機能へのアクセスを失い、それが返金リクエスト、チャージバック、サポートチケットの予測可能な急増を引き起こす——開発者たちは、直接的な返金に加えて、まさにこのパターンによって月間サブスクリプション収益の二桁パーセントを失ったと報告している。
次の2つの帳簿管理の習慣によって、これは予想外の出来事ではなく管理可能なものになる。
- 返金とチャージバックを原因別にタグ付けする。 顧客が拡張機能を気に入らなかったための返金は、事業運営上の通常のコストだ。拡張機能が1週間削除されたことによる返金は、それとは別の、追跡可能な事業リスクである。これらを分けておく(メモ欄やサブアカウントだけでも構わない)ことで、1年を通じて、収益のボラティリティのうちどれだけがプラットフォームリスクによるもので、どれだけがプロダクトマーケットフィットによるものかを把握できるようになる。
- 審査中の案件や未解決のポリシー警告は、開示に値するイベントとして扱う。 主要顧客の解約リスクにフラグを立てるのと同じ発想だ。値上げ、人材の雇用、融資の検討などのために数字を計算しているなら、現在30日間のコンプライアンス警告下にある拡張機能は「安定した継続収益」ではない——審査を通過するまではリスクありとしてモデル化すべきだ。
収益は入金時ではなく、稼いだ時点で認識する
サブスクリプション型と買い切り型の拡張機能では扱いが異なり、この2つを混同することが、このニッチ分野で最もよくある会計上のミスだ。
- 月次または年次のサブスクリプション: 課金が発生した時点で一度に計上するのではなく、顧客が支払っている期間にわたって均等に収益を認識する。前払いの年間プランは前受収益負債を生む——代金は受け取ったが、12カ月分のサービスのうち11カ月分はまだ提供していないため、販売月に収益となるのは1/12のみで、残りは月ごとに貸借対照表から取り崩されていく。
- 買い切りの永年ライセンス(ユーザーがブラウザツールの継続課金を警戒するため、拡張機能に特に人気の価格モデル): これでもなお、無期限にアップデートとサポートを提供する義務を表しているため、初日に現金の100%を収益として認識すると、その月の実際の稼得収入を過大に見せてしまう。より妥当なアプローチは、一度にすべてを計上するのではなく、妥当な推定サービス期間(多くの事業者は12〜36カ月を目安として使う)にわたって永年ライセンスの収益を認識することだ。
- 継続的な義務のない一回限りの購入: 提供時に全額を認識する——これが単純なケースだ。
MRR(月次経常収益)は成長を測る有用な指標だが、帳簿上の認識済み収益とは同じ数字ではない。MRRはアクティブなサブスクリプションのランレートを示すものであり、あなたの元帳は繰延処理後にその期間で実際に稼いだ金額を反映すべきである。
複数の拡張機能に耐えうる元帳構造
プレーンテキストの複式簿記システムで帳簿をつけているなら、「1回の入金、複数の拡張機能」問題の解決策は、最初から製品ごとに収益を分ける勘定科目体系と、入金レポートがすでに差し引いている控除項目のための明示的な勘定科目を用意することだ。
2026-07-05 * "Stripe payout - batch #4471"
Assets:Bank:Checking 842.17 USD
Income:Extensions:FocusTimer -510.00 USD
Income:Extensions:TabArchiver -390.00 USD
Expenses:PaymentProcessing:StripeFees 41.83 USD
Expenses:Refunds:FocusTimer 16.00 USDこうすることで、各入金は、どの製品が実際に利益を生んでいるのか何も教えてくれない不透明な「Stripe入金」という1行の代わりに、銀行への入金を拡張機能ごとの収益・手数料・返金という個別の記帳と突き合わせる1つの取引になる。ファイルがプレーンテキストであるため、拡張機能ごと、月ごと、あるいは返金の原因ごとにgrepしたりクエリを実行したりできる。これはまさに、一括の入金レポートでは得られない可視性だ。
月次チェックリスト
- その月の決済代行業者の売上レポートを取得する(可能であれば製品ごとの明細付きで総額を)。
- 入金レポートを取得し、手数料・返金・チャージバックをそれぞれ個別の項目に分ける。
- 入金額を銀行明細書と突き合わせて確認する。
- サブスクリプションと永年ライセンスの収益は、受領時ではなく認識スケジュールに沿って計上する。
- Chromeウェブストアの審査遅延や削除に関連する返金は、通常の解約とは別にタグ付けする。
- MoRを使わず決済代行業者を直接利用して海外販売している場合は、いずれかの国での累計売上がVAT/GST登録の閾値を超えていないか確認する。
拡張機能ビジネスの帳簿も、コードと同じくらいクリーンに保とう
バージョン管理なしで拡張機能をリリースすることはないはずだ。あなたの財務も同じ規律に値する——特に、入金が複数の製品や決済代行業者にまたがって分割されるようになったらなおさらだ。Beancount.ioは、プレーンテキストでバージョン管理された会計を提供し、拡張機能ごとの収益タグ付け、前受収益の追跡、そして銀行明細書との入金消込を、あなたがコードベースに注ぐのと同じ精度で行えるようにする。無料で始めることで、開発者たちが自分の作るものすべてと同じやり方で帳簿を管理している理由を実感してほしい。