Revenue Hubとは？HubSpotの見積・請求・収益管理を解説

Revenue Hubの核心は、取引情報と見積・請求・決済をつなぎ、商談後の収益プロセスを見える形にすることです。まず自社の商取引の流れを整理し、必要な機能から組み立てます。

「営業の取引情報を、請求書を作るたびに別の表へ転記している」

「継続契約の更新日や次の対応が、担当者ごとのメモに分散している」

「見積の内容と実際の請求内容を、複数のツールを見比べて確認している」——

Revenue Hubとは、HubSpotのCRM上で商品情報、取引、見積、請求、決済、継続課金などをつなぎ、収益に関わる業務を管理する機能群です。導入時は、営業から請求までの記録先と担当者を確認し、HubSpotで扱う範囲を決めます。機能を選ぶ前に「どの記録を見れば次の担当者が処理を始められるか」を確かめると、優先して整える業務が見えてきます。

この記事でわかること

営業と請求の情報が分かれている担当者や、継続契約の更新・収益指標を整理したい担当者に向けて、Revenue Hubの機能を業務に当てはめる順序を解説します。商品情報の整備から見積、請求、更新対応まで、自社で管理する記録と外部サービスに任せる処理を判断できます。各機能の設定可否は、契約プランやアカウントの構成を確認してください。

• Revenue Hubの役割 — 顧客、取引、見積、請求、決済の記録をどの段階で結び付けるかを説明します。
• 商品カタログと見積の設計 — 共通の商品情報と個別の価格条件を分け、提示内容を取引と照合する方法を紹介します。
• 請求と継続課金の考え方 — 請求書の作成、支払いの確認、会計処理を分けて担当を決めます。
• MRR・ARRを確認するための準備 — 契約変更を記録し、集計対象と反映時点をそろえる手順を解説します。
• 導入時の注意点 — 最初に整える業務の選び方と、自動化へ進む前の確認事項をまとめます。

まず自社の業務に近い課題を選び、該当する節の「次へ進む条件」を現状の記録と照らし合わせてください。

Revenue Hubの役割は取引から収益管理までをつなぐことです

Revenue Hubは、営業データと商取引に関する情報をCRMの中で関連付けるための機能群です。商品、取引、見積、請求、支払いの情報が分かれている場合、最初に確認するのは機能の一覧ではなく、担当者が次の処理に必要な情報をどこから取得しているかです。実際に使った見積と請求の記録をたどり、作成者、更新者、照合先を確認します。

コンタクトから請求までを同じ顧客情報に結び付けます

商談の前には、問い合わせをしたコンタクトと所属する会社の情報があります。営業が取引を作成した後、その取引に販売内容の明細を関連付けて見積を作り、受注後に請求や決済の処理へ進みます。

記録先を決める際は、顧客とのやりとりはコンタクトや会社、営業進捗は取引、販売内容は商品と明細、請求と支払いはそれぞれの記録、という形で役割を分けます。次に、見積の宛先、取引先、請求先が異なるケースを確認します。同じ顧客を指していても担当者や請求先が異なるなら、どの記録を請求担当者が参照するかを明示します。担当者が取引を開いて提示内容と請求先を確認できれば、見積手順の整備へ進めます。確認できない場合は、関連付けと入力担当を先に直します。

商品カタログを見積や請求の共通情報にします

商品ライブラリには、担当者が販売内容を選ぶ際の基準となる情報を整理します。まず現在の見積で繰り返し使う名称と価格条件を確認し、共通の情報と案件ごとに変わる条件を分けます。標準の内容を変更した際に、作成済みの見積を誰が確認するかも決めておくと、提示内容と後続の請求内容を照合しやすくなります。（出典：HubSpotで商品を作成、管理する）

次の画面は、HubSpotが公開している決済リンクの製品ページです。顧客に支払い方法を案内する場面を検討する際は、この画面だけで運用を決めず、請求先、支払い状態の確認担当、会計側へ渡す情報を併せて整理してください。

決済リンクの利用条件は、利用中のアカウントで確認してください。

収益情報は営業後の業務や経営判断にもつながります

受注した金額だけを見ても、請求済みか、入金されたか、継続契約がいつ更新されるかは把握できません。営業の取引、顧客に発行した請求書、支払いの確認結果、契約の更新情報を、別々の状態として追えるようにします。

ここで確認すべき分かれ目は、営業担当者が知りたい状態と、請求・会計担当者が確定させる状態です。受注時点で営業の対応を終える運用なら、請求担当者へ渡す条件を定めます。入金後も顧客対応が続く運用なら、確認結果を営業側がどこで見るかも決めます。CRMに情報を集めるだけで会計処理まで自動的に完了するわけではないため、請求書の発行、決済の受付、入金確認、会計上の消込を混同しないことが重要です。

導入の起点は手作業の流れとデータの受け渡しを整理することです

表計算シートや手動メールで商品、見積、請求、更新日を管理している場合は、実際の案件をたどり、情報が担当者間で渡る場面を洗い出します。転記元と転記先のどちらを更新する運用なのかを確かめてから記録先を決めます。現状の手順を残したまま一部だけを自動化すると、二重入力が続く場合があります。

現状の台帳と更新担当を一覧にします

最初に、商品マスタ、見積書、契約一覧、請求書、入金記録がどこにあるかを確認します。各情報について、作成者、更新するタイミング、参照する部門を記録します。複数の台帳に同じ情報がある場合は、値が食い違ったときにどちらを確認するかまで決めます。

棚卸し後は、担当者が同じ案件について商品名、提示価格、請求額、更新日を追えるか確認します。追えない項目は、記録先だけでなく、いつ誰が入力するかを決めてから移行対象にします。日々の業務で参照する情報の記録先が定まれば、次に受け渡しの順序を設計できます。

受注前後のプロセスを一つの流れとして設計します

処理の順番は、コンタクト・会社の登録、取引の作成、商品明細の設定、見積の提示、契約や受注の記録、請求、支払い確認、継続契約の更新という形で整理できます。実際の業務に存在しない段階を追加する必要はありません。各段階で誰が記録を確認し、どの状態なら次の担当者に渡せるかを決めます。

表の各段階に当てはめたとき、情報が欠けたまま次の担当者へ渡っている箇所があれば、そこで作業を止める条件と差し戻し先を決めます。例えば、見積の提示内容と取引明細が一致しない場合は、請求処理へ進む前に営業担当者が確認します。

自動化する条件は業務ルールから決めます

取引のステージが受注に変わったら請求担当者へ通知する場合、通知を受けた担当者が何を確認し、情報が不足していたら誰に戻すかまで決めます。請求書のドラフト作成や送付を検討する際は、請求先、明細、支払条件がそろった案件と、個別確認が必要な案件を分けます。

入力項目は、請求や更新対応に実際に使うものから選びます。必要項目を担当者が同じ意味で入力でき、受け取った担当者が追加の聞き取りなしに処理を始められるなら、自動化の条件を検討できます。記入場所や判断が担当者ごとに異なるなら、先に入力ルールを直します。個人の記憶や手作業で補っている部分を、誰が担当しても同じ順序で処理できるルールに置き換えることが設計の要点です。

商品カタログと見積は価格情報の管理方法をそろえて設計します

商品ライブラリは、販売する商品やサービスをHubSpot内で参照するための情報源です。取引と見積で扱う内容を照合できるよう、共通の商品情報と案件固有の条件を分けて管理します。商品名や価格が変わる場合は、変更後の見積だけに適用するのか、進行中の案件も見直すのかを社内で決めます。

商品情報は運用に必要な項目から登録します

商品名、説明、価格、課金の単位など、見積や請求に使う項目を選びます。月額サービスと初期作業費を別の明細として扱うか、まとめて提示するかは、顧客への説明、請求内容、社内で確認したい売上の内訳を比較して決めます。

登録前には、現在の見積で同じ名称が異なる意味に使われていないかを確認します。内容が異なるなら名称や説明を分け、条件だけが異なるなら個別条件の記録方法を決めます。担当者が商品を選んだ理由を見積の確認者が判断できる状態になってから、登録範囲を広げます。商品ライブラリと明細の扱いは、利用する画面でも確認してください。（出典：HubSpotで商品を作成、管理する）

見積内容を取引と照合します

見積は、取引の金額だけでなく、顧客に提示した商品や価格条件を確認する記録でもあります。作成時には顧客、取引、明細、数量、適用条件を照合し、提示後に内容が変わった場合の更新担当を決めます。取引の金額だけが更新され、提示した明細が古いままにならないよう、請求へ渡す前に最終的な提示内容を確認します。

見積機能の表示や操作に必要な条件は、利用中のアカウントで確認します。機能が表示されない場合は、見積の手順を作り込む前に契約内容と利用者の権限を確認してください。条件を確認する際は、公式の操作案内も参照できます。（出典：HubSpotで見積を作成して送信する）

価格の例外を記録できるようにします

通常価格と異なる値引きや個別条件を扱う場合、承認が必要になる条件、承認者、承認結果の記録先を決めます。判断の順序は、商品ライブラリの標準価格と見積価格の差を確認し、差が生じた理由と適用条件を記録し、承認後の内容を顧客への提示に使う形にします。

社内規程で求める確認をHubSpot内で扱えるかは、利用中の設定と照らし合わせます。必要な判断を扱えるなら取引と見積の流れに組み込み、別の承認手順を使うなら承認結果を取引から確認できる方法を決めます。承認結果を確認できない案件は、見積の送付や請求への引き継ぎを保留する運用が必要です。

請求と決済はHubSpotと外部サービスの担当範囲を分けます

請求書の作成と、実際の支払い処理は別の業務です。HubSpotで請求情報を扱う範囲と、決済サービスや会計側で確認する範囲を分けます。方式を比較するときは、顧客に提示する支払い方法だけでなく、支払い後の状態を誰が確認し、訂正や返金が起きたときにどの記録を更新するかを確認します。

請求書を作る入口と支払い方法を整理します

請求書の用途を一回限りの支払いと継続的な請求に分け、見積や契約から引き継ぐ内容を確認します。請求先、明細、請求額、支払条件のうち、取引から確認できるものと請求担当者が補うものを決めてください。HubSpotで請求書を作成する際の操作は公式の案内で確認できます。（出典：HubSpotで購入者向け請求書を作成する）

外部で支払いを受け取る運用なら、入金確認の結果を誰がどの記録へ反映するかを決めます。請求書を作れた段階を完了とせず、顧客への提示と支払い確認まで担当を追える状態にしてから運用を始めます。

決済連携では状態の受け渡しを明確にします

Stripeなど外部決済サービスを利用するときは、顧客や取引を識別する情報、請求額、支払い状態をどちらのシステムで確認するかを整理します。連携を検討する前に、通常の支払いに加えて、支払いが確認できない場合、金額が変わった場合、返金する場合の記録先を比較します。

「決済が完了した」という情報だけで会計処理も完了したと扱わないようにします。決済状態を確認する担当者、入金を確認する担当者、会計上の消込を行う担当者を明確にし、それぞれが参照する記録を決めます。状態が食い違ったときは、請求書と決済側の記録を照合し、原因が分かるまで次の処理を保留します。照合と修正の担当が決まれば、状態の受け渡し方法を具体化できます。

自動処理の前に例外対応を決めます

受注後に請求書を作る場合、受注ステージだけを条件にすると、請求先や商品明細が未入力でも処理が進む可能性があります。対象の取引、開始条件、必要項目、作成後の確認担当を定め、情報が不足した場合の差し戻し先も決めます。

決済連携が利用できることと、すべての業務が自動で完了することは同じではありません。利用する支払い方法と会計フローに合うことを確認できれば連携を検討し、合わない処理が残るなら、その処理を担当するシステムと確認手順を明示します。通常の支払いだけでなく訂正や返金の経路も担当者が説明できる状態が、自動処理へ進む条件です。

サブスクリプションとMRR・ARRは契約情報の品質が土台です

サブスクリプション型の収益を分析するには、請求額だけでなく契約期間、更新日、プラン変更、解約の記録を整理します。MRRは月次の継続収益、ARRは年次換算した継続収益を把握するための指標です。同じ名称の指標を比較する前に、対象とする契約と変更を反映する時点をそろえます。

継続課金の条件を契約単位で記録します

顧客、契約対象の商品、開始日、更新日、請求頻度、金額を関連付けます。プラン変更や一時停止、解約が発生したときは、現在の状態を更新するだけでなく、変更前の条件と変更が適用される時点を確認できるようにします。請求額が変わった理由を契約の変更と結び付けられなければ、収益の増減を正しく説明できません。

管理方法を選ぶ際は、契約ごとに必要な項目と変更履歴を先に書き出します。HubSpot標準のサブスクリプション機能で必要な情報を扱えるならその運用を検討し、独自の契約条件や変更履歴を別の記録で管理する必要があるなら、既存のデータ設計と比較します。どちらを選んでも、担当者が現在の契約条件と次の更新対応を確認できることを判断基準にします。

更新対応は日付とタスクを結び付けます

更新日を記録する際は、顧客へ連絡する前に確認する契約条件、担当者が判断する内容、連絡後の結果を残す場所まで決めます。更新日だけが記録され、次の行動が決まっていない契約は、担当者の確認対象として扱います。

更新対象の契約を担当者が確認し、利用状況や契約内容を整理してから顧客へ連絡する流れにします。連絡の結果、継続・変更・終了のいずれに進むかが決まったら、契約情報と必要な請求処理を更新します。通知は、受け取った人の判断と次の行動が明確な条件から設定します。

指標は定義と集計範囲をそろえて読みます

MRRやARRをレポート化する前に、継続契約として集計する売上、割引や一時費用の扱い、解約やプラン変更の反映時点を定義します。顧客単位と契約単位のどちらで集計するかもそろえます。

集計前には、契約一覧から継続、変更、解約の各状態を確認し、定義どおりに分類できるか試します。分類できない契約があれば、数字を比較する前に不足している情報と更新担当を特定します。商品や顧客の分類、契約変更の記録がそろい、指標の増減を個別の契約までたどれる状態になってから、レポートを定期的な判断に使います。

段階的な導入は日々の業務で使う範囲から始めます

導入時は、現在の手作業で重複や確認漏れが起きている業務を選び、その業務の記録先と担当者を整えます。次の範囲へ進むかは、機能を設定したかどうかではなく、担当者が記録を使って次の処理を進められるかで判断します。

最初に整える業務を選びます

見積作成で商品情報の転記が多い場合は、商品ライブラリと取引の明細を確認します。請求状況の把握が難しい場合は、請求書や支払い状態の記録先を決めます。更新日が担当者の個人管理にある場合は、契約情報とタスクの管理を優先します。

選んだ業務について、作業の開始から次の担当者への受け渡しまでを実際の案件で追います。必要な情報を探すために別の台帳や個人のメモを確認しているなら、その情報の記録先を先に整えます。受け渡しが同じ手順でできるようになれば、表の「次の段階」を検討します。

運用が定着してから自動化を追加します

担当者が商品、取引、請求の情報を同じルールで入力し、後続の担当者が内容を確認できる状態を作ります。その後、受注通知や更新タスクの作成など、開始条件と確認担当が明確な処理を選びます。

自動処理の確認には、通常の案件に加え、必須情報が欠けた案件や条件が変更された案件を使います。意図した案件だけで処理が進み、進めてはいけない案件は担当者の確認に戻るかを確かめます。処理後の記録を担当者が確認でき、例外時の修正先も分かるなら実運用へ進めます。想定外の処理が起きた場合は、開始条件と入力ルールを見直します。

他のシステムとの境界を保ちます

HubSpotを顧客・取引・見積の中心にする場合も、請求や支払いのどこまでを扱うかは業務ごとに決めます。連携先を増やす前に、顧客を識別する情報、金額、支払い状態について、どちらが更新元で、食い違いが起きたら誰が確認するかを定めます。

企業様によって最適な形は異なります。見積から請求までの記録をHubSpotで確認したい場合は、必要な機能と現在の業務を照合します。複雑な会計処理や既存システムとの連携が必要な場合は、HubSpotで持つ顧客・取引情報と、他のシステムで確定させる情報の境界を決めます。どちらの設計でも、担当者が顧客への提示内容から請求・支払いの確認先までたどれることを、運用開始の条件にします。

よくある質問

Revenue Hubとは何ですか？

HubSpotのCRM上で、商品、取引、見積、請求、決済などの収益業務を扱う機能群です。導入前に自社の業務を見積、請求、支払い、契約更新に分け、それぞれの記録先と担当者を確認します。必要な機能を絞った後、利用中の契約やアカウントで使えるかを確かめます。

HubSpotの商品ライブラリは何に使いますか？

販売する商品やサービスの共通情報を整理するために使います。まず繰り返し使う名称や価格条件と、案件ごとに変わる条件を分けます。見積の確認者が明細の内容と個別条件を判断できる状態にしてから、登録する商品を広げてください。

HubSpot上で請求から入金確認まで管理できますか？

扱える範囲は、利用中の設定と支払い方法を確認して判断します。請求書の作成、支払い状態の確認、会計上の消込を別の段階として整理し、それぞれの担当者と記録先を決めてください。支払いの訂正や返金が起きた場合も同じ手順で照合できるかが、運用方法を選ぶ分かれ目です。

MRRやARRを正しく見るには何を整えればよいですか？

継続収益に含める契約、金額、請求頻度、契約期間、解約やプラン変更の記録をそろえます。次に、一時費用や割引の扱いと、変更を集計へ反映する時点を決めます。個別の契約から指標の増減を説明できない場合は、レポートの比較より先に記録方法を見直します。

最初に取り組む業務はどう選べばよいですか？

転記や確認漏れが起きている業務を選び、実際の案件で情報の受け渡しを追います。見積で商品情報がそろわないなら商品と取引明細、請求状況が分からないなら請求書と支払い記録、更新対応が共有されないなら契約情報とタスクを整えます。次の担当者が必要な情報を確認できるようになってから、自動化やレポートへ進みます。

まとめ

Revenue Hubを活用するには、顧客情報、取引、見積、請求、支払い、契約更新の記録先と担当者を順に確認します。商品カタログでは共通情報と個別条件を分け、見積から請求へ渡す内容を照合します。継続収益の分析では、契約変更の記録とMRR・ARRの定義をそろえてから指標を比較します。

まずは、表計算シートや手作業で管理している業務を選び、次の順序で確認してください。

1. 商品、見積、請求、契約更新の情報がどこにあり、誰が更新しているかを書き出します。
2. HubSpotで管理する情報と外部システムで確定させる処理を分け、食い違った場合の確認担当を決めます。
3. 対象業務の商品情報や取引項目を整え、次の担当者が同じ記録を使って処理を始められるか確かめます。
4. 通常の案件と例外のある案件を確認し、受け渡しと差し戻しができてから自動化やレポートへ進みます。

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。

あわせて読みたい

商品・取引の管理から継続契約や決済の設計へ進む際は、次の記事も参照してください。HubSpot全体の役割を確認したい場合、契約更新や収益指標を詳しく整理したい場合、決済連携の運用を検討したい場合に、それぞれ必要な内容を選べます。

• HubSpot完全ガイド — HubSpotの全体像と各Hubの役割
• HubSpot AI・Breezeガイド — HubSpotのAI機能を活用する考え方
• HubSpotでサブスクリプション売上を管理する方法｜MRR追跡・更新通知・解約防止の設計 — 契約更新と継続収益の管理方法
• HubSpotの収益管理レポート｜ARR・MRR・チャーンレート・LTVダッシュボードの構築 — 収益指標をレポートで確認する方法
• HubSpot × Stripe決済連携ガイド｜サブスク課金からWebhook設定まで完全解説 — 決済連携の設計と運用