価格と契約
AWS Billing Transferとは?Marketplaceの購入請求・販売手数料・売上への影響
公開日:
この記事の要点
Billing Transfer(請求転送)は、AWS Organizationsの管理アカウントが、自組織の外のアカウントに一括請求の管理と支払いを任せる仕組みです。請求を渡す側がBill-Source(請求元)アカウント、受ける側がBill-Transfer(請求転送)アカウントです。購入者としてのAWS Marketplaceの請求書はBill-Transfer側へ移りますが、販売者としての掲載手数料は自社への直接請求が続き、売上と送金は影響を受けません。発注番号と税務プロファイルの扱いも、購入側と販売側で分かれます。
請求の管理を外部の企業に任せているSaaS企業の経理担当は、AWS Marketplaceの請求書が自社に届かなくなったとき、次の疑問を抱きます。自社が売っている製品の手数料と売上は、どこに届くのでしょうか。顧客の支払先を確認したい営業担当にとっても、顧客が請求を外部に任せている場合に、購入の請求書がどこへ向かうのかは、商談の進め方に関わります。
AWSのBilling Transfer(請求転送)では、購入者としてのAWS Marketplaceの請求書はBill-Transfer(請求転送)アカウントへ移ります。(購入者向けFAQ)いっぽう、販売者としての掲載手数料は自社への直接請求が続き、売上と送金は影響を受けません。(販売者向けFAQ)自社が購入者でもあり販売者でもあるなら、一つの会社に二つの請求の流れが並ぶことになります。
本記事の内容は、2026年10月28日に確認したAWSの公式ドキュメントにもとづきます。仕様は変わることがあるため、判断の前には各出典で最新の内容を確認してください。
Bill-SourceとBill-Transferの役割
Billing Transferは、管理アカウントが、自組織の外のアカウントを指定して、一括請求の管理と支払いを任せる仕組みです。(AWS Billing and Cost Management:請求管理の外部アカウントへの転送)外部のアカウントがBill-Transfer(請求転送)アカウントで、一括請求を渡す管理アカウントがBill-Source(請求元)アカウントです。
| 用語 | 役割 |
|---|---|
| Bill-Source(請求元)アカウント | 一括請求を生成する管理アカウント。請求の管理と支払いを外部に任せる側 |
| Bill-Transfer(請求転送)アカウント | Bill-Sourceアカウントの一括請求を管理して支払う、外部の管理アカウント。AWS Billing Conductorで、Bill-Sourceアカウントに見せる価格を管理する |
| 請求転送の招待 | Bill-Transferアカウントが送る、自分をBill-Transferアカウントに指定してほしいという依頼 |
(出典:AWS Billing and Cost Management:請求管理の外部アカウントへの転送)
成立までの流れは、招待から始まります。
- Bill-Transferアカウントが、Bill-Sourceアカウントに招待を送ります。招待を送れるのはBill-Transfer側だけで、管理アカウントどうしでしかやり取りできません。
- 招待には、請求を引き受ける開始日と、Bill-Sourceアカウントに見せる価格の設定を入れます。価格の設定は、AWS Billing Conductorの基本価格か、既存のカスタム価格から選びます。
- Bill-Sourceアカウントにメールで通知が届き、受諾すると、開始日からBill-Transferアカウントが請求の管理と支払いを担います。
- 開始日は月の初日の00:00:00 UTCです。受諾は、開始日の24時間前(UTC)までに済ませる必要があります。
- どちらのアカウントも、いつでも転送を撤回できます。撤回した場合の終了日は、当月または翌月の末日の23:59:59 UTCです。
(出典:AWS Billing and Cost Management:請求管理の外部アカウントへの転送)
開始日より前に発生した料金は、Bill-Sourceアカウントが引き続き支払います。開始日以降の料金について、Bill-SourceアカウントにはAWSの請求書が届かなくなり、請求額(AWSが付けた価格)のデータも見られなくなります。代わりに、Bill-Transferアカウントが付けた価格の費用が、AWS Billing Conductorを通じて表示されます。(AWS Billing and Cost Management:請求管理の外部アカウントへの転送)
AWS Organizationsの一括請求との違い
AWS Organizationsの一括請求は、複数のAWSアカウントの料金を一つにまとめる仕組みです。(AWS Billing and Cost Management:請求管理の外部アカウントへの転送)Billing Transferは、その一括請求を、組織の外のアカウントに管理させ、支払わせる仕組みです。
| 観点 | AWS Organizationsの一括請求 | Billing Transfer |
|---|---|---|
| 請求を管理して支払う側 | 組織の管理アカウント(転送の開始前は、Bill-Sourceアカウント自身) | 組織の外のBill-Transferアカウント |
| 組織の管理 | 管理アカウントが担う | 受諾した管理アカウントが、引き続き自組織の管理全般を担う |
| 請求元が見る金額 | AWSが付けた価格 | Bill-Transferアカウントが、AWS Billing Conductorで設定した価格 |
| 割引階層、Reserved Instances、Savings Plans | 組織の単位で計算される | 変わらない。それぞれのAWS Organizationsの単位で計算される |
(出典:AWS Billing and Cost Management:請求管理の外部アカウントへの転送)
つまり、Billing Transferは、組織の作りや権限を変える仕組みではありません。変わるのは、請求書の宛先、支払う主体、請求元に見える価格です。
すべての請求代行がBilling Transferとは限らない
「請求代行」という言葉が指す内容は、契約ごとに違います。AWSのBilling Transferは、管理アカウントどうしが招待と受諾によって成立させる、AWSの機能です。請求代行の契約があっても、AWSで請求転送を受諾していなければ、本記事の説明は当てはまりません。
自社がBilling Transferの対象かどうかは、契約書と、受諾した請求転送の発効日で確かめます。購入者向けの公式FAQによると、発効日は、AWS Billing and Cost Managementコンソールで確認できます。(購入者向けFAQ)
購入請求・販売手数料・売上送金の比較
自社がBill-Sourceアカウントで、購入者でもあり販売者でもある場合に、何がBill-Transfer側へ移り、何が移らないかを並べます。
| 対象 | Bill-Transfer側へ移るか | 届き先 | 出典 |
|---|---|---|---|
| 購入者としてのAWS Marketplaceの請求書 | 移る | Bill-Transferアカウント。支払いもその保有者が行う | 購入者向けFAQ |
| AWSサービスの利用料の請求書 | 移る | Bill-Transferアカウント | 販売者向けFAQ |
| 購入の確認と、購入に関する通知 | 移る | Bill-Transferアカウント | 購入者向けFAQ |
| 販売者としての掲載手数料と、販売に関する請求 | 移らない | 自社に直接請求される | 販売者向けFAQ |
| AWS Marketplaceの売上と送金 | 影響を受けない | 従来どおり | 販売者向けFAQ |
| 販売に関する税務書類 | 移らない | 自社の管理アカウントだけ | 販売者向けFAQ |
| 販売者レポートと財務情報 | 変わらない | 従来どおり自社が確認する | 販売者向けFAQ |
| 販売手数料、差し引かれた税、送金額の可視性 | Bill-Transfer側には見えない | 自社だけ | 販売者向けFAQ |
販売者向けの公式FAQは、販売活動はBilling Transferの状態から完全に分かれており、分離は自動で行われるため、特別な操作は要らないと説明しています。(販売者向けFAQ)同じFAQは、販売者としての売上や顧客の情報は、チャネルパートナーに既定では見えないとも書いています。
購入請求と販売手数料は、同じ相手に届かない
質問に直接答えると、購入請求と販売手数料は、同じ相手に届きません。購入者としてのAWS Marketplaceの請求書はBill-Transferアカウントに届き、支払いもBill-Transferアカウントの保有者が行います。(購入者向けFAQ)販売者としての掲載手数料は、Billing Transferを使っていても、自社に直接請求されます。(販売者向けFAQ)
販売手数料が、請求書の形で届くのか、売上の送金額から差し引かれる形で現れるのかは、公式FAQの記載だけでは判別できません。Billing Transferを使っていても手数料がBill-Transfer側へ移らない点は、FAQが明記しています。手数料の率はAWS Marketplaceの手数料はいくら?で、受取口座と通貨の設定はAWS Marketplaceの売上受取設定で整理しています。
Billing TransferでAWS Marketplaceの売上は移るか
売上は、移りません。販売者向けの公式FAQは、売上と送金はBilling Transferの影響を受けないとしています。(販売者向けFAQ)売上と入金の確認先と照合の手順は、AWS Marketplaceの売上、利用量レポートにあります。
顧客がBilling Transferを使っているとき
営業担当が確認したいのは、顧客がAWS Marketplaceで購入するとき、請求書がどこに向かうかです。購入者向けの公式FAQによると、顧客がBill-Sourceアカウントなら、顧客のAWS Marketplaceの請求書はBill-Transferアカウントに移り、支払いもBill-Transferアカウントの保有者が行います。(購入者向けFAQ)開始日以降は、顧客の組織でAWS Marketplaceの請求書を直接受け取らなくなります。
商談の中では、次の点を顧客に確認します。
- 顧客の組織がBilling Transferを使っているか、使っているなら開始日はいつか
- 請求書を受け取り、支払うのはどの企業か
- 発注番号を求められるか、求められるなら誰が入力するか
- 税の扱いを、顧客と請求書の受取先のどちらが確認するか
契約は、Private Offer(プライベートオファー)を承諾した購入者との間に結ばれます。(AWS MarketplaceのPrivate Offerとは?)公式のFAQとガイドには、Billing Transferによって契約の当事者が変わるという記載はありません。また、購入者側のBilling Transferが販売者への送金に与える影響も、これらのページには記載がありません。契約の当事者や送金に関わる確認が必要なときは、AWSに問い合わせてください。
Billing TransferとCPPOの違い
Channel Partner Private Offer(CPPO)は、独立系ソフトウェアベンダー(ISV)が販売権限を発行したチャネルパートナーが、購入者にPrivate Offerを出す再販の仕組みです。(Channel Partner Private Offerの作成)名前の響きは近くても、Billing Transferとは別の仕組みです。
| 観点 | Billing Transfer | Channel Partner Private Offer(CPPO) |
|---|---|---|
| 何の仕組みか | AWSの請求の仕組み。管理アカウントどうしで、一括請求の管理と支払いを移す | AWS Marketplaceの再販の仕組み。チャネルパートナーが、購入者一社に個別のオファーを出す |
| 成立させる操作 | Bill-Transferアカウントが招待を送り、Bill-Sourceアカウントが受諾する | ISVが販売権限を作り、チャネルパートナーが承諾して、購入者向けのCPPOを作る。購入者が承諾する |
| 決まるもの | 請求書の宛先、支払う主体、請求元に見える価格 | 購入者への販売価格(卸の原価への上乗せ)と、販売者(seller of record)がチャネルパートナーであること |
| 対象の範囲 | 請求元アカウントの一括請求全体。AWS Marketplaceの購入も含む | オファーごと |
| 手数料への影響 | 公式ドキュメントに、販売手数料の率が変わるという記載はない | 通常の料率に0.5ポイントが加算される |
(出典:AWS Billing and Cost Management:請求管理の外部アカウントへの転送、購入者向けFAQ、Channel Partner Private Offerの作成。CPPOの手数料の加算は、AWS MarketplaceのCPPOとは?に整理しています)
代理店との取引にBilling Transferが入っていても、CPPOが成立しているとは限りません。その逆も同じです。一方の設定がもう一方を自動的に設定するとは、Billing Transferの公式ページにも、CPPOの公式ドキュメントにも書かれていません。両方を併用した場合の請求書の流れは、公式ドキュメントに記載がないため、代理店と自社のどちらが確認するかを決めたうえで、AWSの案内を確かめてください。
発注番号、税務プロファイル、通知、問い合わせ先の確認
購入側と販売側で扱いが分かれる項目を、自社が請求元アカウントの場合で整理します。
| 項目 | 購入者として | 販売者として |
|---|---|---|
| 発注番号(PO番号) | 購入時に入力した番号が、Bill-Transferアカウントに送られる最終請求書に載る | 公式FAQに記載なし |
| 税務プロファイル | Bill-Transfer側(FAQ上はチャネルパートナー)の税務プロファイルで税を計算する | 常に自社のAWSアカウントの税務プロファイルを使う。自社が税務上の販売者(seller of record)のまま |
| 免税 | Bill-Transfer側の税務プロファイルに適用する | 公式FAQに記載なし |
| 通知と書類 | 購入の確認や通知は、Bill-Transferアカウントに届く | 税務書類は、自社の管理アカウントだけに届く |
| 問い合わせ先 | 請求の質問はBill-Transfer側、製品の技術的な問題は販売者、プラットフォームの問題はAWS Support | 販売者アカウントの管理は従来どおり |
発注番号(PO番号)
購入者向けの公式FAQによると、チェックアウトで入力した発注番号は、Bill-Transferアカウントに送られる最終請求書に載ります。(購入者向けFAQ)Bill-Transfer側が、Service Control Policies(サービスコントロールポリシー)を適用して、購入者の発注番号を自社の請求書に載せないようにすることもできます。発注番号の要件は、購入する前にBill-Transfer側と調整するのが望ましいと、FAQは案内しています。発注番号そのものの登録方法と、組織での必須化は、AWS MarketplaceのPurchase Orderとは?で扱います。
発注番号を請求書に載せたい購入者と、載せたくないBill-Transfer側とで、希望が食い違うことがあり得ます。購入を始める前に、どちらの運用にするかを決めておきます。
税務プロファイル:AWS上の扱いと、自社の会計判断は別
購入側では、Bill-Transferアカウント側の税務プロファイルで税が計算されます。免税が必要なら、その税務プロファイルに適用します。直接購入した場合と比べて、適用される税率が変わり得るとも、FAQは説明しています。(購入者向けFAQ)なお、購入者向けのFAQは、AWS Solution ProviderやDistributorとの請求転送の関係を前提に書かれています。それ以外の事業者がBill-Transferアカウントの場合に、同じ説明が当てはまるかは、記載がありません。
販売側では、常に自社のAWSアカウントの税務プロファイルが使われ、自社の管理アカウントの所在地で税が計算されます。Billing Transferを使っていても、自社が税務上の販売者であることは変わりません。販売に関する税務書類は、自社の管理アカウントだけに届きます。販売用の税務情報は、Billing Transferとは独立して、最新に保つ必要があります。(販売者向けFAQ)
ここまでが、AWS上の扱いに関する公式の説明です。自社の仕入れや売上の会計処理、税務申告への影響は、公式FAQの範囲に入っていません。最終的には、税理士など税務の担当者に確認を取ってください。
通知、問い合わせ先、更新と解約
購入の確認と通知は、Bill-Transferアカウントに届きます。そのため、購入者の担当者が通知を直接受け取れない場合に備えて、通知を誰が受け取り、誰に転送するかも、購入の前に取り決めておきます。(購入者向けFAQ)
問い合わせ先は、問題の種類で分かれます。請求に関する質問は、まずBill-Transfer側に連絡します。製品そのものの技術的な問題は販売者に、プラットフォームの問題はAWS Supportに連絡します。請求の異議も、請求書を受け取るBill-Transfer側と進め、必要に応じてBill-Transfer側がAWSと調整します。
更新と解約は、購入者の側に管理権限があっても、請求の変更がBill-Transfer側に影響します。FAQは、更新や解約の進め方を、Bill-Transfer側と事前に決めておくよう案内しています。(購入者向けFAQ)返金や解約の仕組みそのものは、AWS Marketplaceの解約、返金対応で扱っています。
開始前に確認する、請求データとレポートへの影響
Bill-Sourceアカウントとして請求転送を受諾すると、AWSの請求に関するデータの扱いも変わります。AWS Billing and Cost Managementの公式ページは、次の影響を挙げています。(AWS Billing and Cost Management:請求管理の外部アカウントへの転送)
- 転送の開始後、AWS Cost and Usage Reportのファイルは利用できなくなります。既存の設定は無効になり、
Unhealthyと表示されます。開始前にデータを保存し、開始後に設定をやり直すよう勧められています。 - AWS Cost Anomaly Detectionは、Bill-Sourceアカウントでは使えません。既存と新規のどちらのモニターも、アラートを生成しません。
- Bill-Sourceアカウントは、AWSが付けた価格の請求データを見られなくなり、Bill-Transferアカウントが付けた価格の費用だけを見られます。
- 費用の確認では、Bill-Transfer側が設定していなければ、サポートプランの料金、AWSクレジット、無料利用枠が、費用の表示に含まれないことがあります。
これらは、購入者としての請求データに関する影響です。販売者向けの公式FAQは、販売者レポートと財務情報は従来どおり確認できるとしています。(販売者向けFAQ)購入者のAWS Cost and Usage Reportと、販売者の売上レポートの違い、数字が合わないときの照合手順は、AWS Marketplaceの売上、利用量レポートに戻してご確認ください。
自社と顧客の購入・支払・契約・テナント情報を分けて管理する
請求関係の変更は、請求の宛先と支払う主体を変えるものです。購入者向けの公式FAQは、Billing Transferが影響するのは請求の関係だけで、アカウントへのアクセスや権限、リソース管理、セキュリティ設定、管理機能は引き続き購入者が持つと説明しています。(購入者向けFAQ)公式のFAQとガイドに、契約名義、ライセンス、SaaSのテナントが、請求の転送に伴って移るという記載はありません。そのため、請求関係の変更を、契約名義やライセンスやテナントの移転として扱わないようにします。
AWSアカウントそのものをリセラーが発行する形では、明細に載るアカウントの保有者がリセラーになるという課題を、私たちは運用で確認しています。(AWS Marketplaceの契約をSaaSテナントに紐付けるには?)Billing Transferでは、Bill-Sourceアカウントは顧客自身の管理アカウントのままで、組織の管理も顧客に残ります。この二つは、別の構成です。
自社と顧客の情報は、次の四つに分けて持つと、混同を避けられます。これは公式の仕様ではなく、本記事の設計案です。
| 情報 | 指すもの | Billing Transferの影響 |
|---|---|---|
| 購入 | 購入の操作をしたAWSアカウント | 購入者向けFAQでは、Procurement insightsダッシュボードの費用分析は、Bill-Sourceアカウントの識別子を使う |
| 支払 | 請求書を受け取り、支払う企業 | Bill-Transferアカウントの保有者に変わる |
| 契約 | 承諾したオファーと、その契約のID | 公式のFAQとガイドには、変わるという記載がない |
| テナント | 自社SaaSの中での顧客の単位 | AWSは関与しない。自社のデータとして保持する |
(出典:購入者向けFAQ。テナントの行は、AWS Marketplaceの契約をSaaSテナントに紐付けるには?の説明にもとづきます)
架空の例です。顧客のA社が、AWSの請求をB社に任せているとします。AWS Marketplaceの請求書は、B社に届きます。いっぽう、SaaSを実際に使うのはA社で、自社のテナントもA社のものです。請求や支払いの連絡をA社に送り、利用開始の案内をB社に送ってしまうと、請求先の企業とSaaSを使う企業を取り違えることになります。
顧客のデータには、次の項目を別々に持つことをお勧めします。
- 購入したAWSアカウントのID
- 請求書を受け取る企業の名称と連絡先
- Billing Transferの有無と、発効日
- 発注番号の運用(誰が入力し、誰が受け取るか)
- 契約のIDと、ライセンスを表すLicenseArn
- 自社SaaSのテナントのID
- 税務の確認を担当する人
なお、SaaSが受け取る購入者のAWSアカウントIDが、Billing Transferを使う購入者でどの値になるかは、公式のFAQとガイドに記載がありません。自社の連携を公開する前に、検証用の取引で、受け取る値を確かめておきます。契約とテナントの紐付けの設計は、AWS Marketplaceの契約をSaaSテナントに紐付けるには?に整理しています。
次に取る行動
- 請求代行の契約書と、AWS Billing and Cost Managementで、請求転送を受諾しているかと、その発効日を確認します。
- 自社を、購入者の立場と販売者の立場に分けて整理します。購入請求はBill-Transfer側へ移り、手数料と売上は従来どおり自社に残ります。
- 発注番号の要件と、通知の受け取り方を、購入の前にBill-Transfer側と調整します。
- 税務プロファイルの違いが、自社の会計処理と税務申告に与える影響を、税理士など税務の担当者に確認します。
- 請求転送を受諾する前に、AWS Cost and Usage Reportなどの請求データを保存します。
- 顧客データに、購入、支払、契約、テナントを別々の項目として持ちます。
- 検証用の取引で、SaaSが受け取る購入者の情報を確かめます。
Deshimaで扱える範囲
購入後の利用申請フォームと、購入者と契約の情報の同期を自社で作らずに済ませたい場合は、AWS Marketplaceへの掲載を支援するDeshimaが選択肢になります。Deshimaは、購入者と契約の情報の取得と同期、利用申請フォーム、Amazon EventBridgeへのイベント発行を担います。自社SaaSでは、そのイベントを既存のユーザーやテナントに結び付け、契約に応じた機能、数量、利用可否を反映する処理を実装します。具体的な分担は、導入する構成に応じてご確認ください。
本記事で扱ったBilling Transferの招待と受諾は、管理アカウントの側で行う操作で、Deshimaでは設定の代行を行いません。請求書を受け取る企業を、Deshimaの契約情報の中でどう扱うかは、個別にご相談ください。契約とテナントの紐付けは、AWS Marketplaceの契約をSaaSテナントに紐付けるには?で整理しています。
2026年10月28日時点のDeshimaの対応範囲は、SaaS Contract(SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル)型のみです。従量課金(メータリング)とChannel Partner Private Offer(CPPO)は対象外で、Concurrent Agreementsには対応済みです。Deshimaの利用料は、初期費用と月額費用がどちらも0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案しています。対応範囲はトップページのFAQに、料金の考え方は料金のセクションに記載しています。Deshimaは更新が多いため、最新の機能と対応範囲は、無料のアカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。