2026年7月1日、Envatoは静かにCodeCanyonとThemeForestでの販売の経済性を書き換えた。10年かけて「エクスクルーシブ」ステータスを築き上げ、1件あたり最大87.5%という手数料率を得ていた著者たちも、例外なく一律50%の収益シェアへと移行させられた。段階制もロイヤルティボーナスも独占契約の要件も、もはや存在しない。あなたがCodeCanyonやThemeForestで販売するWordPressプラグイン・テーマの開発者なら、1件あたりの手取りはすでに半分に減っているかもしれない。そして、もし帳簿がプラットフォームごと、手数料構造ごと、ライセンス種別ごとに収益を追跡していなかったなら、入金額が想定より少なくなるまでその変化に気づかなかった可能性が高い。
この変更の裏に隠れている本当の問題はこうだ。ほとんどの個人・小規模チームのWordPressプロダクトビジネスは、自分たちが実際にいくら稼いでいるかを正確には把握していない。把握しているのは、銀行口座に何が入ってきたかだけだ。この二つは同じ数字ではない。そしてその差——マーケットプレイス手数料、決済処理手数料、通貨換算、源泉徴収されたVAT、一時収入として計上された更新収益——こそが、記帳ミスが何年もかけて静かに積み重なっていく場所なのだ。
マルチチャネル入金の問題
ほとんどのWordPressプロダクトビジネスは、単一のチャネルだけで販売しているわけではない。典型的な構成は、次のような組み合わせになっていることが多い。
- セルフホスト型のストア — FreemiusやPaddleのような「みなし販売主(merchant of record)」プラットフォームを利用し、ライセンス管理、サブスクリプション、税金の徴収を任せる形態
- Envato Market(プラグイン向けのCodeCanyon、テーマ向けのThemeForest) — 入金される前にマーケットプレイス側が取り分を差し引くマーケットプレイス
- 直接決済 — Stripeや、Easy Digital DownloadsやWooCommerceに組み込んだ決済ゲートウェイを使い、自分自身がみなし販売主となる形態
これらのチャネルはそれぞれ異なるスケジュールで、異なる通貨構成で、異なる組み合わせの手数料を差し引いた後に入金される。Freemiusは収益シェアと売上税処理分を差し引いた純額を毎月送金するかもしれない。Envatoは手数料を差し引いた後にPayPalまたは銀行振込で支払うが、その正確な割合は、これまでの独占契約ティアではなく2026年7月の一律料金への変更によって決まる。Stripeによる直接決済ではカード決済の総額がそのまま入金され、決済処理手数料は数日後に別の費用項目として計上される。
もし記帳が「銀行口座に入ってきた数字をそのまま『売上収入』として記録する」だけになっているなら、総収益、マーケットプレイス手数料、決済処理手数料、税金の納付という4つの異なる会計イベントを一つの数字に混同していることになる。その数字からは、どのチャネルが実際に1件あたりいくら儲かっているのかはほとんど読み取れない。
解決策は複雑ではないが、規律は必要になる。各チャネルの補助元帳で、販売時点の総収益を計上し、マーケットプレイス手数料、決済処理手数料、源泉徴収された税金は別個の費用項目または収益控除項目として記録することだ。そうして初めて、「2026年7月の料率変更後もCodeCanyonへの出品は続ける価値があるか」といった問いに、勘ではなく実際の数字で答えられるようになる。
Envatoの変更が勘定科目表にとって重要な理由
2026年7月以前は、Envatoのエクスクルーシブ著者プログラムは累計収益に応じて手数料を段階的に設定していた。プラットフォームでの販売期間が長く、販売数量が多いほど手数料率は下がり、トップ著者では最低12.5%まで下がることもあった。つまり1件あたり最大87.5%を著者が受け取れる計算だ。他のプラットフォームにも出品できる非独占の販売者は、これより明らかに不利な条件だった。2026年7月1日をもって、この段階制はすべて撤廃された。販売履歴や独占契約の有無にかかわらず、すべての著者は一律50%の収益シェアを受け取ることになる。
記帳の観点から見れば、これは些末な注記ではない。もし「Envato Sales」という勘定科目が、過去の粗利計算の中に暗黙のうちに85%以上の取り分を前提として組み込んでいたなら、その前提は今後のすべての取引において誤りとなる。すぐに行うべきことが二つある。
- プラットフォーム別の収益レポートを2026年7月1日を境に分割する。 マーケットプレイスがまだ続ける価値があるかを評価する際に、変更前と変更後の月をまとめて平均してはいけない——ユニットエコノミクスはこの日を境に実際に変わったのだから。
- チャネル比較をやり直す。 Envatoの一律50%の手数料は、Freemiusの累進的な収益シェアモデル(通常は高い率から始まり、販売量が増えるにつれて下がっていく)や、「手数料」が約2.9%の決済処理手数料と顧客獲得コストだけで済む自前運用のStripe決済と比べると、まったく異なる数字になる。旧ティアの下ではEnvato独占にする意味があった製品も、もはや採算が合わなくなっているかもしれない。
みなし販売主 vs. 自前運用の決済:税金を誰が負うのか
ここはWordPressプロダクトの記帳の中でも、最も多くの人が不意を突かれる部分だ。なぜなら、この二つのモデルは帳簿上まったく異なる義務を生み出すからだ。
FreemiusやPaddleのような、みなし販売主(merchant of record、MoR)プラットフォームを通じて販売する場合、税務上の法的な販売者はそのプラットフォームになる。EU/UKのVAT、該当する場合のGST、経済的関連性(nexus)がある米国各州の売上税を計算・徴収・納付するのはプラットフォーム側だ。そのため、これらの販売については帳簿に売上税未払金の負債勘定を設ける必要はない——MoRがすでにその責任を引き受けているからだ。記録すべきなのは実際に受け取った純入金額であり、加えて、税務当局からある販売の課税方法について問われた場合に備えて、MoR自身の取引レポートを監査証跡として保管しておくべきだ。
直接販売する場合——自前のチェックアウトにStripeやPaddle-classicを組み込み、自分自身がみなし販売主となる場合——その責任はあなたにある。州ごとに異なる経済的関連性(nexus)の閾値を追跡し(多くの米国の州では、年間売上$100,000または取引件数200件のあたりで売上税の義務が発生するが、閾値は州によって異なる)、必要な州で登録し、徴収した税金を納付する責任を負う。つまり帳簿には、単なる収益項目ではなく、実際の売上税未払金の負債勘定が必要であり、各申告期間ごとに、徴収した金額と納付した金額を照合するプロセスも必要になる。
この二つのモデルを帳簿上で区別せずに混同してしまうのは、よくある、しかも高くつくミスだ。MoRプラットフォームがすでに処理した税負担を二重に計上してしまうか、あるいはさらに悪いことに、実際には自分が責任を負っているチャネルについて、MoRが税務義務を処理してくれていると思い込んでしまうかのどちらかになる。
ライセンス更新は一回限りの販売ではない
プラグインやテーマのライセンスは通常、年間(または買い切り)キーとして販売されており、更新料が入金された瞬間にその全額を収益として計上したくなるかもしれない。しかし標準的な収益認識の原則(米国のASC 606)の下では、そのライセンスが1年分のアップデートとサポートを付与するものである場合、それは正しくない。更新による収益は、更新期間の開始より前に認識してはならず、顧客が実際にサービスを受ける権利を持つ期間にわたって按分して計上すべきものだ。
具体的に言えば、顧客が年間$120のライセンスを更新した場合、課金された当日に$120の収益を計上してはいけない。まず$120を繰延収益(負債——1年分のアップデート・サポートを提供する義務がある)として記録し、その義務を実際に履行するにつれて毎月$10ずつ収益として認識していく。もし主に年間ライセンスを販売していて、入金額をそのまま収益として計上しているだけなら、月次の損益計算書は実態を誤解させるものになる——更新が集中する月には跳ね上がり、それ以外の月には過小評価される。そして、融資の申し込みや事業売却の交渉、あるいは単に事業が成長しているかどうかを正直に把握したいときに、その乱高下が本当のトレンドを覆い隠してしまう。
Freemius、Envato、直接決済を同時に併用して販売している場合、この問題はさらに重要になる。各チャネルの更新の仕組みは微妙に異なるからだ(たとえばEnvatoのライセンスは伝統的にサブスクリプション更新型よりも一回限りの購入型に近く、一方でFreemiusは継続課金を前提に設計されている)。繰延収益の追跡は、すべての販売に一律の前提を当てはめるのではなく、チャネルごとにこの違いを反映させる必要がある。
正気を保ちながら入金を照合する
これらすべてを結びつける実務上の週次・月次タスクが、入金照合(payout reconciliation)だ。各プラットフォームのダッシュボードが示す「稼いだ金額」と、実際に銀行口座に入金された金額を突き合わせ、その間にあるすべての項目を理解する作業になる。実践的なプロセスは次のようになる。
- 各チャネル(Freemius、Envato、Stripe)から取引レベルのレポートを取得する。 入金合計のサマリーだけに頼ってはいけない。総売上、手数料、源泉徴収税をそれぞれ別個の項目として把握する必要があり、一つの純額だけでは足りない。
- 総収益と各控除項目を台帳に個別に計上し、チャネルごとにタグ付けする。そうすることで、チャネルごとの正確な粗利レポートを作成できる。
- 純入金額を照合する。 その入金期間について、総収益から手数料と源泉徴収税を差し引いた合計額と突き合わせる。差異がある場合は、多くの場合、まだ記録していない返金、チャージバック、または通貨換算差額が原因だ。
- 更新収益と新規販売収益を、同一チャネル内であっても分けて追跡する。 そうすることで、実際の更新率——ライセンス型ソフトウェアビジネスにとって、おそらく最も優れた健全性指標——を把握できる。更新と新規販売を一つの「Envato Sales」勘定にまとめてしまうと、この指標は完全に見えなくなってしまう。
これを手作業でスプレッドシートに行うのは、月にごく少数の取引しかなければ何とかなる。しかし、通貨も手数料体系も税務上の扱いも異なる三つのチャネルを、入金サイクルごとに互いに照合しなければならなくなった瞬間、この方法はスケールしなくなる。
マルチチャネルの帳簿を監査可能な状態に保つ
Freemius、Envato、そしてStripeによる直接決済という複数のチャネルからの入金を同時にやりくりしているなら、プレーンテキスト会計は自然にフィットする。各チャネルの取引は、純入金額しか見せてくれないブラックボックスのダッシュボードの奥に埋もれるのではなく、タグ付けし、スクリプトで処理し、差分を取れるバージョン管理された記録として存在する。Beancount.ioは、その透明性をもたらしてくれる——総収益、マーケットプレイス手数料、繰延更新収益をどう分類するかを完全にコントロールでき、すべての販売に完全な監査証跡が残る。無料で始めて、すでにバージョン管理で考えている開発者たちが、なぜ帳簿もプレーンテキストに切り替えているのかを確かめてほしい。