メインコンテンツへスキップ
Beancount.io Logo

ホワイトラベルSaaSリセラーの記帳術:本人か代理人かによる収益認識の違い

公開日 最終更新 約1分Mike ThriftMike Thrift
ホワイトラベルSaaSリセラーの記帳術:本人か代理人かによる収益認識の違い

Zendeskの調査は身も蓋もないほど率直だ。顧客の半数は、たった一度の悪いサポート体験で離れていくという。もしあなたが自社ブランドを掲げて他社のSaaS製品を再販しているなら、この統計は二重の意味で不安材料になる——サポート体験の責任を負うのはあなただが、その裏側にあるソフトウェアをコントロールしているのはあなたではないからだ。この「責任を負う範囲」と「実際にコントロールできる範囲」のずれこそが、記帳をつまずかせる元凶でもある。

ホワイトラベルSaaSの再販は、代理店やインディー開発者、特定業界に強みを持つ創業者が、ゼロから製品を作ることなく継続収益を積み上げる最速の手段のひとつになっている。他社が育て上げた成熟したソフトウェアを自社ブランドに衣替えし、あたかも自社製品であるかのように顧客へ販売する。ビジネスモデルとしては本当に優れている。しかしその裏にある会計処理は、通常のサブスクリプション事業よりも静かに複雑だ。なぜなら、あなたの銀行口座に振り込まれる1ドルすべてが、あなたが稼いだ1ドルとは限らないからである。

ホワイトラベルSaaSモデルの実際の仕組み

ホワイトラベル契約では、ソフトウェア提供元が(通常は非独占的かつ譲渡不可の)ライセンスを付与し、あなたが自社ブランドの下でそのプラットフォームを販売・展開できるようにする。あなたが担うのは販売、顧客対応、そして多くの場合は一次サポートだ。一方で提供元はインフラ、コード、そして稼働率保証(こうした契約では99.9%が一般的なSLAの基準値)を担う。

契約の組み方次第で、経済条件はかなり変わってくる。

  • 収益シェア型リセラーは、回収した金額の一部——おおむね20〜50%の範囲——をプラットフォームに支払う。割合は取扱量や、あなたがどれだけ付加価値のあるサポートを提供するかによって変わる。
  • 卸売り・固定コスト型リセラーは、エンドカスタマーへの請求額にかかわらず、アカウントあたりまたは席数あたりの定額コストを支払い、差額をすべて自分の取り分とする。ここでの利益率は分野によって40〜80%にもなり得る。自分で自由に上乗せ価格を設定できるからだ。
  • 紹介・アフィリエイト型の分配は、一定の割合を支払う仕組みで、最初の12か月は50%、それ以降は顧客が存続する限り20%といった小さめの継続的な取り分になることもある。

これらはいずれも絶対のルールではなく、契約ごとに交渉で決まる。しかし、どの契約形態にサインするかによって、収益をどう計上すべきかが決まり、これこそがリセラー会計の多くがつまずくポイントである。

本当に問われるべき会計上の問い:あなたは本人か、代理人か

これはホワイトラベルSaaS会計における最も重大な判断であり、ASC 606の「本人 vs. 代理人」ガイダンスによって規定される。この問いは哲学的なものではない——あなたのトップライン収益として計上される金額そのものを左右するのだ。

あなたが本人(プリンシパル)であるのは、サービスが顧客に届く前の段階でそれをコントロールしている場合だ。判断材料には、顧客への約束を果たす主たる責任を負っているか、顧客が支払う価格を決める裁量を持っているか、何らかの形で提供・履行リスクを負っているか、などが含まれる。これに該当するなら、顧客が支払う総額を収益として計上し、プラットフォームの取り分は売上原価または直接費用として計上する。

あなたが代理人(エージェント)であるのは、実質的には他社がサービスを提供する手配をしているに過ぎない場合だ——背後の提供元がソフトウェアをコントロールし、重要な取引条件を定め、あなたは顧客を連れてきたことに対する手数料や報酬を得ているにすぎない。これに該当するなら、計上すべき収益は純手数料のみだ。あなたを経由して流れる総額は、あなたが認識すべき収益ではない。

ここを取り違えると、財務諸表がうそをつくことになる。実際には代理人であるにもかかわらず総収益を計上すると、トップラインが水増しされ、利益率が薄く不可解に見えてしまう。逆に実際には本人であるにもかかわらず純額を計上すると、実際に行っているビジネスの規模を過小評価することになる——これは資金調達、融資の申し込み、あるいは会社の売却を検討する際に大きな意味を持つ。買い手や貸し手が見るのは収益であって、総取引量ではないからだ。

しかもこの判定は契約単位ではなく、履行義務単位で行う必要がある。もしホワイトラベル契約が、提供元がコントロールするコアソフトウェアと、あなたが実際に提供する導入支援やサポートサービスを一つにまとめている場合、取引を分割する必要が出てくるかもしれない——ソフトウェア部分は純額計上、自分が実質的にコントロールする部分は総額計上、という具合だ。

数字が乱れる場所:入金、手数料、チャージバック

総額か純額かという問いに決着をつけたとしても、リセラー事業の日々の記帳には構造的な問題がつきまとう。あなたの銀行口座に振り込まれる金額は、あなたが稼いだ収益の金額とは決して一致しない、ということだ。

ホワイトラベルのプラットフォームパートナーからの典型的な入金には、口座に届く前にいくつもの控除が組み込まれている。

  • プラットフォームの収益シェアまたは卸売コスト
  • 決済処理手数料
  • エンドカスタマーへの返金
  • チャージバック(売上を取り消すうえ、多くの場合は決済処理業者から独自のペナルティ手数料も課される)

もし単純に「受け取った現金」を収益として計上してしまうと、トップラインも利益率も体系的に誤って表示されることになり、しかもプラットフォームパートナーが報告してくる数字と自分の帳簿が一致しなくなる。解決策は、各要素を個別に記録することだ。総請求収益、プラットフォームの手数料または収益シェアをコスト項目として、返金とチャージバックを収益控除項目または専用の費用カテゴリとして、そして純額の残りだけを実際の銀行入金として計上する。これは通常の中小企業が管理すべき勘定科目数よりも多いが、それこそが損益計算書を現実と一致させる唯一の方法であり、チャージバック率が静かに利益率を蝕んでいることに気づくための唯一の手段でもある。

まさにここでこそ、プレーンテキストでバージョン管理された記帳が真価を発揮する。ホワイトラベルリセラーの月次締め作業では、1件の入金額を4〜5個の内訳——総売上、プラットフォーム手数料、返金、チャージバック、そして自分の純取り分——と突き合わせて照合する必要がある。Beancount.ioを使えば、この構造をそのまま元帳の中に、各要素ごとの明示的な勘定科目としてモデル化できる。そのため入金の食い違いは、スプレッドシートの数式の奥に埋もれた謎の差異ではなく、実際に読める形の差分として表面化する。

会計処理を左右する契約条項

ホワイトラベル契約にサインする前に、弁護士だけでなく記帳担当者にも内容を読んでもらうべきだ。いくつかの条項は、取引をどう計上すべきかに直接影響する。

  • 支払条件と請求スケジュール — 支払頻度、通貨、どちらか一方が支払いを遅延した場合にどうなるか。
  • ライセンス許諾の文言 — その契約は、あなたを再販者、サブライセンシー、あるいは代理人として位置づけているか。裁判所や監査人は取引の実質を見るが、契約書自体の文言は最初の判断材料になる。
  • サポートとSLAの責任分担 — 一次サポートの責任を誰が負うかは、ASC 606における「履行の主たる責任」テストに影響する。
  • 契約期間と解約条件 — ホワイトラベル契約の多くは1〜3年で、解約予告期間は30〜90日というのが一般的だ。この期日を把握しておくこと。繰延セットアップ費用や年間前払金の会計処理に影響する。
  • 知的財産権の帰属 — 提供元がIPの全権利を保持するのがほとんどの場合だ。これは収益認識よりも、資本化した開発コストの会計処理に関係する(一般的に、自分が所有しないソフトウェアは資産計上できない)。

シンプルな月次照合ルーティン

どの収益認識方針を採るにせよ、以下のステップを毎月の習慣として組み込んでおこう。

  1. その期間のプラットフォームパートナーの入金レポートと、自社の販売ログを取り出す。
  2. 総請求収益が、自分が発行した請求書またはプラットフォームが自社に代わって課金した金額と一致するか確認する。
  3. プラットフォームの手数料・収益シェア、返金、チャージバックを、それぞれ別個の項目として個別に記録する。
  4. 純額の残りが、実際の銀行入金額と一致するか確認する。
  5. チャージバック率がじわじわ上昇していないか注意を払う——これは多くの場合、プラットフォームパートナーが把握しておくべきサポートや履行上の問題の早期シグナルだ。

この照合作業を怠ると、確定申告の時期になって銀行明細と一致しない収益額に驚かされたり、さらに悪ければ、丸1会計年度にわたって本人・代理人の判定を誤っていたことが発覚したりする羽目になる。

リセラーの帳簿は初日から明瞭に保つ

ホワイトラベルSaaSの再販が強力なビジネスモデルである理由は、まさにソフトウェアが他社の問題だからだ——しかし収益認識、チャージバックの追跡、入金の照合はすべて完全に自分自身の責任である。Beancount.ioはリセラーに、プレーンテキストでバージョン管理された会計環境を提供する。あらゆる手数料、返金、収益シェア控除が、銀行明細から逆算しなければならないブラックボックスではなく、それぞれ明示的な仕訳として記録される。無料で始める——そして、実際に稼いでいる利益率と同じくらい透明な帳簿を保とう。

この記事を共有

約16分

Micro-SaaSとAPIの簿記:従量課金制、決済代行会社の照合、そして粗利率70%でも本物の帳簿が必要な理由

粗利率70%超のMicro-SaaS・APIビジネスにも発生主義会計は必要です。サブスクリプションと超過従量課金のハイブリッド請求、StripeやMerchan…

saas
bookkeeping
約8分

ニュースレタースポンサーシップの収益認識:検証済みCPC支払いが広告掲載当日に計上されない理由

beehiivのようなニュースレターCPC広告ネットワークは配信から約96時間後にクリックを検証し、翌月20日に支払いを行う——この3つの異なる日付が、多くの個…

revenue-recognition
accrual-accounting
約13分

Stripeペイアウトを調整しながら、本当の収益を見失わない方法

Stripeは手数料を差し引き、返金を保留し、純額で入金するため、銀行への入金額が売上と一致することはありません。総売上を計上し、手数料を別に費用化し、ペイアウ…

reconciliation
payments
約10分

Chrome拡張機能開発者の帳簿管理: Googleがアプリ内決済を廃止した後の入金消込

Googleは2021年にChrome Web Store…

reconciliation
saas
約14分

駐車場とバレーパーキングの簿記:5つの収益源の照合と30日間のクライアント資金フロート

駐車場運営者の勘定科目表と締め処理—時間貸し、月極許可証、法人、バレー、イベント収益の分離方法、月極許可証を繰延収益として計上する方法、税込み料金から駐車税を逆…

bookkeeping
revenue-recognition