HubSpotのMRR管理は、取引の経常収益プロパティを使う方法と、請求レコードを作る方法があります。まず取引単位で傾向をつかみ、必要な分析に応じて月次データへ広げます。
「月次の売上を表計算シートに転記しているが、契約変更のたびに数字がずれる」
「MRRが増減した理由を、取引や顧客までたどりにくい」
「営業の契約情報と経理の請求データが別々で、照合作業に手間がかかる」
HubSpotのMRR可視化とは、取引に登録した経常収益の金額や種別、変更日などをもとに、月次収益の変化をレポートで確認する方法です。より細かな請求単位の分析が必要な場合は、請求レコードを取引や会社に関連付ける設計も選べます。
本記事は「AI × CRMで企業価値を上げる設計思想|経営者が知るべきAI CRM戦略」シリーズの一部です。
本記事はStartLinkの「AI活用完全ガイド」関連記事です。
この記事でわかること
HubSpotで月次収益を把握する方法と、契約情報から請求データまでをつなぐ考え方を整理します。
- 収益アナリティクスの基本 — 新規・既存・喪失した経常収益をどのように確認するかを説明します。
- 取引プロパティの設定 — レポートの前提になるデータと、手動で更新する範囲を解説します。
- 請求レコードを使う設計 — 商材別や月別に収益を追跡する場合の構成を紹介します。
- 自動生成と会計連携 — ワークフローやカスタムコードを使う流れと、運用時の確認点をまとめます。
- 段階的な導入判断 — まず取引単位で始め、分析要件に合わせて広げる方法を示します。
HubSpotのMRRレポートで把握できること
次の画像は画面の例です。

MRRのレポートでは、経常収益が増えた時期や減った時期を取引情報と結び付けて確認できます。月次の合計だけを見るのではなく、変化の背景を取引や会社までたどれる状態にすることが運用のポイントです。
新規・既存・喪失の経常収益を分ける
次の画像は画面の例です。

収益アナリティクスでは、新たに発生した経常収益、継続中の経常収益、解約などで失われた経常収益を区分して把握できます。これにより、合計額の増減だけでなく、どの収益変化が月次の数字に影響したかを確認しやすくなります。
ただし、レポートの数字だけで増減理由が明らかになるわけではありません。取引の担当者や会社、契約の変更内容と合わせて確認できるよう、各取引の情報を整えておきます。
月次収益の動きを取引へつなぐ
月次収益を経営判断に使うには、レポートから個別の取引へ戻れることが重要です。例えば、ある月に収益が減少していた場合、該当する取引の解約日や収益の変更理由を確認すれば、影響を受けた契約を特定できます。
スプレッドシートで合計だけを更新する運用では、数字の変化と顧客・契約の動きを後から結び付けにくくなります。取引をCRMの記録として管理し、レポートと同じデータにつなげることで、集計と確認の流れを一つにまとめられます。
収益レポートの前提を理解する
HubSpotの収益アナリティクスは、取引の経常収益プロパティに入力した値をもとに収益の変化を集計します。関連付けた商品や見積もりの金額から自動で計算する仕組みではなく、対象の取引でプロパティを更新する必要があります(出典:Track recurring revenue in HubSpot)。
そのため、取引金額や商品明細を登録しただけではレポートに必要な経常収益データがそろわない場合があります。まず現在使っている取引項目と経常収益プロパティを照合し、どの情報を誰が更新するか決めてから分析を始めます。
収益アナリティクスを使う基本の流れ
収益アナリティクスは、取引の経常収益情報を使って月次の全体像を把握する方法です。最初に項目と入力ルールを整え、次にレポートを確認し、数字の変化を個別取引へたどる流れを作ります。
取引の経常収益プロパティを準備する
次の画像は画面の例です。

設定項目は、取引タイプ、月額の経常収益金額、経常収益が発生しなくなる日付や理由です。新規契約、更新、解約などの事象ごとに、どの項目を更新するかを整理します。
HubSpotの公式資料では、経常収益の追跡に使うプロパティとして、経常収益額、取引タイプ、非アクティブ日、非アクティブ理由が案内されています。取引タイプと金額、または非アクティブ理由と日付は、それぞれ対になる情報として入力します(出典:Track recurring revenue in HubSpot)。
入力ルールを取引プロセスに組み込む
取引のステージが受注確定へ進むときに経常収益額と取引タイプを登録し、契約内容が変わったときには変更理由と日付も記録する、といったルールを決めます。担当者が覚えておく運用に頼らず、取引画面の必要項目やステージ移行時の入力ルールに組み込むと、引き継ぎ後も同じ手順で扱いやすくなります。
入力項目は、レポートに必要なものから絞って始めます。情報を増やしすぎると入力負荷が高まり、空欄や更新漏れが生じやすくなるためです。分析に使っていない項目があれば、利用目的を確認して整理します。
レポートから取引の変化を確認する
レポートで新規・既存・喪失の経常収益の推移を見たら、増減した月を選び、影響した取引を確認します。金額だけで終わらせず、契約変更や解約の情報を取引に残すことで、次の対応や社内共有につなげられます。
例えば解約による減少が見つかった場合、該当する会社や取引を開き、登録された日付や理由が実際の契約状況と合っているかを確認します。入力と実際の契約がずれていれば、集計ルールを見直してから次の月のレポートを使います。
取引プロパティで始める方法の範囲と限界
取引プロパティを使う方法は、MRR全体の増減を把握する出発点として取り入れやすい方法です。取引に必要な情報を登録すればレポートを利用できますが、請求明細や商材ごとの内訳まで一つの取引項目で表せるとは限りません。
取引単位の管理が向いている場面
契約ごとの月額収益と、新規・更新・解約などの変化を中心に把握したい場合は、取引の経常収益プロパティから始められます。データ構造を大きく変えずに、まず収益の全体像と入力漏れの傾向を確認できます。
この段階では、月次の総額を経営指標として見るだけでなく、数字の根拠になる取引を特定できるかを確かめます。担当者ごとに入力方法が異なる場合は、項目の定義や更新タイミングをそろえることから着手します。
細かな内訳を一つの項目に詰め込まない
複数の商材やサービスが一つの取引に含まれる場合、取引単位のMRRだけでは商材ごとの収益が見えにくくなります。従量課金や事業形態ごとの詳細な集計が必要になった場合も、取引プロパティだけでは分析要件に届かないことがあります。
そのときは、何を一件の請求データとして数えるのか、月次の収益をどの単位で持つのかを先に整理します。取引単位のレポートで足りているなら現状の方式を続け、商材別・月別の明細が必要なら請求レコードを作る方式を検討します。
段階的に方式を選ぶ
以下のように、必要な分析の粒度を基準に方法を選びます。
| 確認したいこと |
取引プロパティ |
請求レコード |
| 契約単位のMRR推移 |
適しています |
管理できます |
| 新規・継続・喪失の変化 |
適しています |
管理できます |
| 商材ごとの月次収益 |
項目設計によっては見えにくくなります |
商材項目を持たせて分析できます |
| 契約月ごとの請求履歴 |
取引項目だけでは表現しにくい場合があります |
月ごとのレコードで追跡できます |
| 導入時のデータ設計 |
取引項目から始められます |
オブジェクトや自動生成の設計が必要です |
最初から全ての明細を作り込む必要はありません。まず取引プロパティでレポートを運用し、判断に必要な内訳が不足した段階で請求レコードへ広げると、設計と運用の負担を抑えやすくなります。
カスタムオブジェクトで請求データを管理する
請求レコードを使う方法では、「請求」や「計上」を表すカスタムオブジェクトを作り、月ごとの金額を個別のレコードとして記録します。契約を表す取引と請求レコードを関連付けることで、契約情報と月次の収益明細を分けて扱えます。
月ごとの請求レコードを設計する
次の画像は画面の例です。

請求レコードには、対象月、金額、契約の状態、商材分類など、レポートや会計連携に使う項目を設計します。例えば契約期間中の各月を個別レコードにすれば、どの月にどの会社からいくらの請求が発生するかを追跡できます。
項目を決める際は、請求書の発行や会計処理で必要な情報と、MRR分析で必要な情報を分けて確認します。どちらにも使わない項目を増やすと更新負荷が高くなるため、利用目的を説明できる項目に絞って始めます。
取引・会社との関連付けを定める
請求データは、元となる取引や契約先の会社と関連付けて管理します。取引に対して請求レコードをひも付けると、契約単位の状況を確認できます。会社にも関連付けておけば、顧客ごとの請求履歴をたどる設計にできます。
HubSpotでは、カスタムオブジェクトのレコードを作成し、取引や会社など他のオブジェクトと関連付けて管理できます。ワークフローからカスタムオブジェクトのレコードを作成する場合は、ワークフロー対象のオブジェクトとの関連付けが必要です(出典:Create custom object records)。
商材別・契約別の収益を見る
次の画像は画面の例です。

請求レコードに商品項目やサービス分類を持たせると、商材ごとの月次収益を分けて分析できます。例えばコンサルティングとシステム開発のサービスラインがある場合、それぞれの月次収益の推移を別々に確認できます。
この方法では、取引の合計金額だけでは見えなかった内訳を分析に使えます。一方、商品分類の定義が担当者によって違うと集計が分散するため、分類の選択肢と判断基準を運用前にそろえます。
ワークフローとカスタムコードで請求レコードを作る
請求レコードを契約のたびに手作業で作ると、月の抜けや関連付けの間違いが起きやすくなります。取引のステージ変更を起点にワークフローを動かし、標準の作成アクションや必要に応じたカスタムコードで請求データを生成する方法があります。
受注確定を起点にする
次の画像は画面の例です。

取引が「検収」(受注確定)のステージに移動した時点を起点として、請求レコードを作成します。開始条件を決めるときは、見積もり段階や契約前の取引が誤って対象に入らないよう、実際の業務上の受注確定条件とステージ定義を合わせます。
ワークフローでは、対象取引が条件を満たしたときに請求レコードを作成し、元の取引との関連付けを設定します。作成後に取引側からレコードをたどれるかを確認できれば、次の月次集計に進めます。
複数月分を作成する処理を設計する
次の画像は画面の例です。

取引の受注確定をきっかけに、12ヶ月分の請求レコードを生成する構成です。例えば、11月21日にクローズした案件について、11月末から翌年10月までの月次レコードを作成する例です。
こうした繰り返し処理をカスタムコードで実装する場合は、開始月、終了月、請求日、対象金額、取引との関連付けを明示しておきます。標準のワークフローだけで必要な月次レコードを分割作成できるなら標準アクションを使い、日付計算や複数件の生成が要件に含まれる場合にカスタムコードを検討します。
生成結果を人が照合できるようにする
次の画像は画面の例です。

自動化を設定したら、最初の取引で生成されたレコード数や対象月、金額、関連付けを確認します。期待した月数と一致し、請求データが正しい取引・会社に関連付いていれば、対象範囲を広げます。ずれがあれば、開始条件や日付計算を修正してから運用します。
自動化は設定後の確認を不要にするものではありません。契約期間や請求条件が例外的な取引をどう扱うかを決め、例外に該当する場合は担当者が内容を確認してから生成結果を確定する流れにします。
会計システムとの連携で契約から請求へつなぐ
請求データをHubSpotで管理すると、受注した取引から月次の請求情報を作り、会計システム側の請求情報と照合する流れを設計できます。HubSpotを顧客・取引管理だけに使うのではなく、販売管理に必要な情報をつなぐ業務アプリケーションとして位置付けられます。
営業情報と経理情報をつなぐ
営業が管理する取引情報と、経理が扱う請求・会計データが別々の表に分かれていると、契約内容の確認や転記が必要になります。取引と請求レコードをCRM上で関連付ければ、契約の受注から月次収益までの根拠をたどりやすくなります。
HubSpotで作成した請求レコードを、freeeなどの会計ソフトの請求情報と突合します。会計側へどの情報を渡すか、どの段階で照合するかを定めると、営業と経理が同じ契約情報をもとに確認できます。
連携対象と照合方法を決める
次の画像は画面の例です。

連携前に、会社名や取引先、請求月、金額など、HubSpotと会計側で照合する項目を整理します。取引の受注内容と請求レコードが一致していても、会計側の請求先や発行状態が異なることがあるため、どちらのシステムを正として確認する項目かを決めます。
StartLinkの連携サービスには、Sync for Money ForwardとSync for freeeがあります。インストール先はSync for freee(HubSpotマーケットプレイス)とSync for Money Forward(同)です。連携の対象項目や運用手順は、利用する構成に合わせて確認します。
フロー全体の中でMRRを位置付ける
MRRは請求レコードだけの数字ではありません。コンタクトや会社から営業機会が生まれ、取引として契約が管理され、受注後に請求データが作られ、その結果を月次収益として分析する流れの中に置きます。
この一連の流れがつながると、収益の変化を顧客や契約の状況に結び付けて確認できます。まず受注確定から請求レコード作成までを整え、照合とレポートが回ることを確かめてから、自動化や分析対象を広げるのが現実的です。
MRR管理を運用に定着させる設計のポイント
次の画像は画面の例です。

MRR管理の精度は、レポートの種類だけでは決まりません。取引や請求の定義、入力担当、更新タイミングがそろっていることが必要です。人の記憶や個別の表計算に頼らず、次の担当者も同じ手順で回せる形にします。
収益の定義と更新タイミングをそろえる
月額の経常収益に何を含めるか、契約の変更をいつ反映するか、解約の情報をいつ更新するかを関係者間で定めます。定義が曖昧なままでは、同じ契約でも担当者によって登録額や変更月が変わり、月次比較の意味が薄れます。
特に更新・アップグレード・ダウングレード・解約は、取引タイプや変更日などの記録方法をそろえます。レポート上の増減と契約履歴が一致しない場合は、対象取引を確認し、定義か入力ルールのどちらを直すべきか判断します。
項目を絞り、入力を仕組みにする
利用目的が明確な項目だけを用意し、取引が必要なステージに進むときに入力する運用にします。営業担当者に毎月別の表を更新してもらう方法では、CRMの契約情報と月次集計がずれる可能性があります。
入力が抜けやすい項目は、ステージ移行時の必須項目やワークフローの通知など、システム側で気付ける仕組みにします。運用後は入力されていない項目と、実際の契約とのずれを確認し、必要な項目だけを調整します。
方式を切り替える判断基準を持つ
取引単位のレポートで必要な判断ができているなら、その方式を維持できます。商材別の月次推移、契約月ごとの請求履歴、会計データとの突合が必要になったときは、請求レコード方式に広げる候補になります。
ただし、請求レコードを作ると、項目・関連付け・自動生成・例外処理の設計が必要になります。必要な分析が不足していることを確認してから移行し、まず一つの取引でデータ作成からレポートまでを検証すると、運用の抜けを見つけやすくなります。
よくある質問
HubSpotでMRRを確認するにはどのプランが必要ですか?
収益アナリティクスの利用にはSales Hub ProfessionalまたはEnterpriseが必要です。HubSpotの製品仕様は更新されることがあるため、導入前に公式の収益アナリティクス案内でアカウントの利用条件を確認してください。カスタムオブジェクトを使う設計についても、契約中のサブスクリプションで利用可能かを合わせて確認します。
収益アナリティクスと請求レコードはどう使い分けますか?
契約単位の新規・既存・喪失収益を把握したい場合は、取引の経常収益プロパティから始められます。商材別や月別の請求履歴まで分析する場合は、請求レコードを作る方法が向いています。必要なレポートで判断できているかを基準に選びます。
取引に商品や見積もりを登録すればMRRも集計されますか?
公式資料では、収益アナリティクスは取引の経常収益プロパティに入力された値を使い、商品や見積もりの関連金額から自動計算しないと案内されています。取引タイプと経常収益額、または非アクティブ理由と日付など、必要なプロパティを更新してからレポートを確認します。
請求レコードの作成を自動化できますか?
取引の受注確定ステージへの移行を起点に、ワークフローとカスタムコードで月次レコードを生成できます。自動化する場合は、生成月・金額・関連付けを最初の取引で照合し、期待どおりなら対象を広げます。例外的な契約は、個別確認の流れも用意します。
MRR管理は最初から請求レコードで始めるべきですか?
最初から請求レコードを作る必要はありません。まず取引プロパティで月次の増減と入力ルールを整え、商材別や請求月別の明細が必要になった段階で拡張できます。小さく始めて、分析要件と運用負荷を確かめながら広げます。
まとめ
HubSpotのMRR可視化は、取引の経常収益プロパティで月次の変化をつかむ方法と、請求レコードで月ごとの明細を管理する方法に分けられます。取引単位で全体像を確認し、商材別分析や会計連携などの必要性が見えたら、カスタムオブジェクトやワークフローへ段階的に広げます。
まずは取引の経常収益プロパティと現在の入力ルールを照合するところから始めます。
- 新規・更新・解約時に記録する項目と担当者を整理します。
- 取引単位のレポートで、月次の増減と根拠となる取引を確認します。
- 不足する分析が明確になったら、請求レコードや会計連携の対象項目を設計します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい