AWS Marketplaceの売上が伸びているのに、銀行フィードが依然として不可解に少ないように見えることがあります。これは必ずしも価格設定の問題ではありません。多くの場合、報告上の問題です。顧客への請求はある日に行われ、AWSがその請求書を後日回収し、手数料が差し引かれ、税金が別のシナリオで処理される可能性があり、その結果としての現金は後日の銀行明細書に到着します。
AWS Marketplaceを通じて販売するソフトウェア企業にとって、入金は複数のイベントの最終結果であり、販売そのものではありません。信頼性の高い簿記プロセスは、総額取引を保持し、マーケットプレイス手数料と税務処理を記録し、返金を追跡し、その後、純支払い額を銀行と調整します。これらのレイヤーが分離されれば、利益率、収益、売掛金、現金予測をはるかに信頼しやすくなります。
AWS Marketplaceの入金が収益と等しくない理由
最も一般的な間違いは、各銀行入金を売上収益として計上することです。この短縮法は4つの疑問を隠します：
- 顧客は実際に何を、どのオファーで購入したのか？
- AWSは掲載手数料としていくら差し引いたのか？
- 税はAWSが徴収したのか、徴収してあなたに渡したのか、それともあなたが計算して納付するのか？
- この特定の入金は、どの請求書、返金、クレジット、および前期の活動で構成されているのか？
AWS Marketplaceのレポートは、これらの疑問に答えるために必要な構成要素を提供します。回収・支払いダッシュボードは、総収益、総返金、掲載手数料、掲載手数料返金、セラー税負担分、AWS税負担分、セラー純収益、および支払い詳細を区別します。また、運用レポートを会計記録に結び付けるために使用できる請求書ID、オファーID、契約ID、取引参照、銀行トレースIDも提供します。
その結果、重要な会計原則が導き出されます。取引レベルで経済活動を記録し、入金を調整目標として使用します。現金はお金が動いた証拠です。しかし、なぜ動いたかを説明するには十分な証拠ではありません。
マーケットプレイスの流れのための勘定科目表を構築する
顧客ごとに個別の勘定科目は必要ありませんが、プラットフォームの活動を可視化するのに十分な構造が必要です。有用な出発点は次のとおりです：
収益と控除収益
- AWS Marketplace総収益
- AWS Marketplace返金およびクレジット
- 割引または契約譲歩（総額レポートの金額にまだ反映されていない場合）
SaaS契約期間にわたって収益を認識する場合、マーケットプレイスの請求イベントを収益認識スケジュールから分離してください。マーケットプレイスの請求日とサービス期間は、同じ会計日付ではない場合があります。
クリアリングおよび貸借対照表勘定
- AWS Marketplace売掛金または未払い回収金
- AWS Marketplace支払いクリアリング
- 顧客預り金または繰延収益（該当する場合）
- 返金未払金または返金クリアリング
- 売上税または付加価値税（VAT）未払金（税務プロセスで必要に応じて管轄区域ごとに分離）
費用および控除
- AWS Marketplace掲載手数料
- 掲載手数料に課されるVATまたはその他の税（該当する場合）
- リセラーを含むオファーのチャネルパートナーまたは卸売コスト
- 支払いと決済の間に発生する銀行手数料または為替差損益
正確な勘定科目名は、一貫性ほど重要ではありません。簿記システムは、「今月、マーケットプレイスの総収益をいくら生み出したか、いくらが未払いのままか、プラットフォームはいくら保持したか」という質問に、単一の純入金から答えを再構築することなく答えられるようにする必要があります。
マーケットプレイスの合計だけでなく、オファーレベルのディメンションを使用する
AWS Marketplaceには、パブリックオファー、プライベートオファー、エンタープライズ契約、SaaS契約、使用量ベースの製品、チャネルパートナープライベートオファーが含まれる場合があります。それらの価格設定、タイミング、手数料、税金、更新行動は異なる場合があります。
販売または仕訳インポートプロセスで、少なくとも次のディメンションを追跡します：
- 製品名と製品ID
- オファーIDとオファーの可視性
- 契約ID
- 顧客または支払者識別子
- 請求書IDと請求日
- 使用期間の開始日と終了日
- 通貨
- 記録上の販売者または仲介事業体（該当する場合）
オファーIDは、価格分析に特に役立ちます。1つのプライベートオファーに交渉済み割引や異なる支払いスケジュールが含まれている場合、それをパブリックリスティング収益と組み合わせると、健全なオファーが不採算に見えたり、実際に弱いオファーが隠れたりする可能性があります。
契約IDは、契約の継続性に役立ちます。アップグレード、更新、または修正により、既存の請求書が変更されていなくても、保留中の支払い条件が置き換えられる場合があります。つまり、現在の契約の変更が、帳簿の履歴を自動的に書き換えるわけではありません。
仕訳パターン：まず総額、後で現金
次の例では、フローを示すために単純な数値を使用します。パブリックSaaSオファーが期間中に$10,000の総請求を生み出し、該当する掲載手数料が3%であるとします。当面は税金、返金、為替変動の影響を無視します。
請求または収益認識段階で、次のように記録します：
借方 AWS Marketplace売掛金 10,000
貸方 AWS Marketplace収益 10,000掲載手数料が認識または決済から差し引かれるとき：
借方 AWS Marketplace掲載手数料費用 300
貸方 AWS Marketplace売掛金 300AWSが残高を回収して支払うとき：
借方 AWS Marketplace支払いクリアリング 9,700
貸方 AWS Marketplace売掛金 9,700銀行入金が発生したとき：
借方 事業用銀行口座 9,700
貸方 AWS Marketplace支払いクリアリング 9,700実際の帳簿では、仕訳のタイミングは収益認識方針、会計基準、法的エンティティ、税務処理によって異なります。パターンが重要なのは、手数料を可視化し続けるからです。$9,700の入金のみを収益として計上すると、総売上が過小評価され、掲載手数料が説明不能な収入減少の中に消えてしまいます。
AWSの掲載手数料スケジュールは、製品とオファータイプによって異なります。たとえば、AWSはSaaS、サーバー製品、データオファー、プライベートオファー、チャネルパートナープライベートオファー、プロフェッショナルサービスについて異なる標準料率を文書化しています。会計自動化に単一のパーセンテージをハードコードしないでください。報告された手数料額をインポートし、報告されたパーセンテージをチェックとして保持します。
税金を推測ではなく、識別すべきシナリオとして扱う
マーケットプレイスの税務処理は、購入者の税務住所、製品タイプ、販売者の所在地、マーケットプレイス促進者ルールによって異なります。請求イベントデータは、少なくとも3つの大まかなパターンを区別できます：
- AWSが税を徴収して納付する。これはAWS税負担分イベントとして表され、販売者に支払われる金額は増加しません。
- AWSが税を徴収し、それを販売者の決済に含め、販売者が納付する。これはセラー税負担分イベントとして表されます。
- AWSは税を計算または徴収せず、販売者が計算して納付する責任を負います。
これらのパターンは交換可能ではありません。税額が単に情報提供のみで、販売者の残高に影響を与えない場合は、売上や現金に追加しないでください。税があなたに支払われる場合は、収益ではなく未払税勘定に振り向けてください。AWSが徴収しなかった税について販売者が責任を負う場合は、自社の請求または税務エンジンを通じて負債を作成し、マーケットプレイスの入金の外で調整します。
税務証拠を取引と一緒に保持します。購入者の地域、製品、オファー、請求書、税負担タイプ、金額、申告管轄区域、またはそれらのフィールドを含むレポートへの参照を保存します。取引レベルのサポートがない税務サマリーは、防御が困難で、修正も困難です。
返金とクレジットを元のオファーに調整する
返金は単なるマイナスの銀行入金ではありません。総収益を取り消し、掲載手数料を部分的に取り消し、税額を減らし、将来の支払いを変更する可能性があります。AWSは、セラーワークフローの一部で返金を請求調整と呼び、キャンセルは必ずしもすでに発行された請求書をキャンセルするわけではありません。
すべての返金またはクレジットについて、以下を取得します：
- 元の請求書ID
- 請求期間
- 製品IDとオファーID
- 契約またはサブスクライバー参照
- 返金額と理由
- 掲載手数料と税負担分も取り消されたかどうか
- 調整が請求、回収、または支払われた日付
次に、元の取引に使用された同じ収益、手数料、税勘定に調整を適用します。すべての返金を一般的な「返金費用」勘定に計上すると、製品利益率が歪み、収益レポートがAWSの総額および純額フィールドと一致しなくなります。
契約キャンセルには特別な注意が必要です。キャンセルは契約ステータスを変更しますが、請求調整は請求書を変更するか、資金を返還します。両方必要な場合は、両方のアクションを追跡し、影響を受ける請求書明細にリンクします。
毎月の支払い調整を機械的にする
入金がおかしいように見えるときにだけレポートをダウンロードするのではなく、繰り返し可能なクロージングチェックリストを使用します。
1. 報告期間を固定する
クロージングが請求日、使用期間、回収日、支払い日のいずれに基づくかを選択します。これらは異なるビューです。ある月の支払いレポートには、以前に請求された請求書が含まれる場合があり、同じ月の収益レポートには、まだ回収されていない請求書が含まれる場合があります。
2. 詳細レポートをインポートする
請求書、オファー、契約、総収益、返金、手数料、税、通貨、支払いステータス、支払い日、銀行トレースフィールドを取り込みます。元のレポートファイルまたは不変のエクスポート参照を保持します。
3. 取引参照でグループ化する
取引参照IDまたは関連する請求イベント識別子を使用して、1つの取引ファミリーに属する請求書、手数料、税、返金、支払いの行を二重計上しないようにします。スプレッドシートのピボットまたは小さなスクリプト化されたインポートで、重複した明細をすばやく明らかにできます。
4. 未払い残高を未収売掛金に結び付ける
回収ダッシュボードは、回収済みおよび支払済みの資金と、未請求および未払いの請求書を区別します。未払い残高をAWS Marketplace売掛金と比較します。すべての遅延を銀行の問題として扱うのではなく、支払い条件、顧客、オファー、請求書の経過日数で古い残高を調査します。
5. 純支払いを銀行に一致させる
レポートの支払い額と銀行トレースIDを銀行入金に一致させます。金額が異なる場合は、プラグを転記する前に、ACHタイミング、通貨換算、支払い失敗、返金活動、手数料請求書、または残高調整を探します。
6. オファーごとに例外を確認する
異常に高い返金、長い回収時間、マイナスの純収益、予期しない税負担分、期待される契約条件と異なる掲載手数料率を持つオファーを探します。これらは簿記のクリーンアップだけでなく、運用上のシグナルです。
数値を信頼できないものにする一般的な間違い
入金を総収益として計上する
これにより手数料が隠され、収益から現金への調整が不可能になります。クリアリング勘定を使用し、総額から純額へのブリッジを計上します。
顧客請求日と現金日を混同する
これにより人為的な月次変動が生じ、売掛金が誤って表示される可能性があります。請求日、回収日、支払い日、サービス期間日を明確に区別します。
すべての税負担分フィールドを未払税として扱う
一部の税額はAWSによって徴収および納付され、残高に影響を与えません。取引タイプと管轄区域で分類します。
プライベートオファーと修正を無視する
プライベートオファーには、交渉済みの価格設定と支払いスケジュールがある場合があります。オファーと契約の識別子を保存して、更新や修正が間違った製品コホートに統合されないようにします。
一般的な返金勘定を使用する
該当する場合は、元の収益、手数料、税の構成要素を取り消します。返金は元の取引を説明する必要があり、単に別の場所で利益を減らすだけではありません。
銀行フィードを唯一の真実の源にする
銀行は決済を確認できますが、どの顧客、オファー、請求書、税シナリオ、掲載手数料が現金を生み出したかを教えてくれません。銀行をマーケットプレイスレポートに照合し、その逆ではありません。
調整を経営管理レポートに変える
仕訳が構造化されたら、製品とオファーごとに有用な運用指標を計算します：
- マーケットプレイス総請求額
- 掲載手数料と返金後の純収益
- オファー別返金率
- 請求から回収および支払いまでの平均日数
- 経過日数区分別の未払い売掛金
- 総収益に対するマーケットプレイス手数料率
- 売上に対する徴収税とAWSが納付した税
- 通貨と顧客セグメント別の現金換算
ダッシュボードはこれらの傾向を示し、基盤となるプレーンテキスト台帳は計算を監査可能に保ちます。Beancountを使用する場合、各取引を請求書、オファー、またはレポート識別子にリンクすると、後のレビューがはるかに高速になります。Favaなどの可視化レイヤーは、ソースレコードをブラックボックスにすることなく、残高とディメンションを探索するのに役立ちます。技術ユーザーには、ドキュメントがインポートと調整ワークフローを標準化するための自然な場所を提供します。
財務管理を簡素化する
すべての入金を総収益、手数料、税金、返金、オファーに遡ってトレースできる場合、AWS Marketplaceの管理は容易になります。Beancount.ioは、透明でバージョン管理され、AI対応のプレーンテキスト会計を提供し、販売チャネルが増えても財務データをレビュー可能に保ちます。