「見積書はExcelで作って、請求書は会計ソフトで発行して、入金確認は通帳を見て手動でチェックしている」「受注したはずの案件の請求漏れが発覚した」——こうした業務のつなぎ目で発生するミスやロスに悩んでいる企業は少なくありません。
Quote-to-Cash（QTC）とは、見積の作成から請求書の発行、入金確認・消込までを一連のプロセスとして設計・管理する考え方です。CRMを起点にこのプロセスを一気通貫で管理することで、業務の分断を解消し、売上の可視化と回収効率を飛躍的に高めることができます。
この記事では、Quote-to-Cashの全体設計から、CRM/HubSpotを活用した実装方法、そしてよくある失敗パターンまでを解説します。
Quote-to-Cash（QTC）とは、顧客への見積提示から、受注、請求書発行、入金確認・消込までの一連の収益プロセスを指す概念です。日本語では「見積から入金まで」と表現されることが多く、営業プロセスとバックオフィスプロセスの結節点に位置するフローです。
多くの企業では、このプロセスが複数のツールと部門にまたがって分断されています。営業がCRMで商談管理、経理がExcelで見積作成、会計ソフトで請求書発行、銀行のオンラインバンキングで入金確認——という具合に、それぞれが独立して動いているケースが一般的です。
問題1：請求漏れ・請求遅延
営業が受注した案件を経理に伝える手段がメールやチャットだけの場合、伝達漏れが発生します。特に月末に受注が集中する時期は、請求書の発行が翌月にずれ込むケースも珍しくありません。これは結構、現場で起きがちな問題です。
問題2：売上の可視化遅延
見積・受注・請求・入金のデータが別々のシステムに存在すると、「今月の売上はいくらか」「入金予定はいくらか」をリアルタイムに把握できません。月次の経営会議で前月のデータをようやく確認するという状態では、タイムリーな経営判断が困難です。
問題3：業務の属人化
見積の作成ルール、値引きの承認フロー、請求書の発行タイミングなど、暗黙のルールが担当者の頭の中にしかない場合、その人がいなくなった瞬間にプロセスが崩壊します。仕組みとしてシステムに落とし込んでおくことが重要です。
| 指標 | 改善効果の目安 |
|---|---|
| 請求書発行リードタイム | 5営業日 → 1営業日以内 |
| 請求漏れ率 | 3〜5% → 0.5%以下 |
| 入金消込の工数 | 月20時間 → 月5時間 |
| 月次売上の確定速度 | 翌月15日 → 翌月5日以内 |
| フォーキャスト精度 | ±20% → ±5%以内 |
QTCのプロセスは、以下の6フェーズで構成されます。
| フェーズ | 担当部門 | 主な業務 | システム |
|---|---|---|---|
| 1. 見積作成 | 営業 | 見積書の作成・提出 | CRM（見積機能） |
| 2. 見積承認 | 営業マネージャー | 値引き・条件の承認 | CRM（承認フロー） |
| 3. 受注処理 | 営業 / 営業事務 | 契約締結・受注登録 | CRM（取引ステージ更新） |
| 4. 請求書発行 | 経理 / 営業事務 | 請求書の作成・送付 | 会計ソフト / CRM |
| 5. 入金確認 | 経理 | 入金の確認・消込 | 会計ソフト / 銀行API |
| 6. 売上計上 | 経理 | 会計上の売上認識 | 会計ソフト |
ここでポイントになってくるのが、フェーズ3の「受注処理」とフェーズ4の「請求書発行」の間のデータ連携です。この接続が自動化されていないと、請求漏れの原因になります。
見積作成の設計では、以下の3つの要素を定義する必要があります。
例えばHubSpotの見積もり機能では、製品ライブラリから項目を選んで見積書を作成し、電子署名まで完結できます。ただし、承認機能があまり強くないという制約があるため、値引き承認のフローについてはワークフローで補完する設計が必要になってくるかなと思います。
取引のステージが「受注」に移行した時点で、以下のアクションを自動実行する設計が効果的です。
請求書の発行と入金管理は、CRMと会計ソフトの連携で設計するのが現実的です。CRMに請求機能を持たせる方法と、会計ソフト側にデータを連携する方法の2つのアプローチがあります。
アプローチA：CRM側で請求まで管理（HubSpot Commerce Hub活用）
HubSpotのCommerce Hub機能を使うと、見積から請求書の発行・決済まで一気通貫で管理できます。Stripeとの連携で決済まで完結するため、シンプルなBtoBサブスクリプションビジネスには適しています。
アプローチB：会計ソフトとの連携（freee / マネーフォワード）
多くの日本企業では、請求書の発行と入金管理は会計ソフトで行うのが一般的です。この場合、CRMの受注データを会計ソフトに連携する設計が必要です。iPaaS（Zapier、Make、Yoomなど）を介してCRMの受注情報→会計ソフトの請求書作成を自動化する方法が実務的です。
HubSpotでQuote-to-Cashを実装する場合、以下のような設計が考えられます。
パイプライン設計
見積作成 → 見積提出 → 見積承認 → 受注内示 → 契約締結 → 請求処理 → 入金完了各ステージの必須プロパティとして、見積金額、支払条件、請求予定日、入金予定日などを設定し、データの品質を担保します。
ワークフローによる自動化
カスタムオブジェクトの活用（サブスク/分割払い対応）
月額課金や分割払いの場合、1つの取引に対して複数の請求レコードが必要になります。この場合、カスタムオブジェクトで「請求」レコードを作成し、取引と関連付ける設計が有効です。例えば12ヶ月のサブスクリプション契約であれば、受注時にワークフロー（またはカスタムコード）で12件の請求レコードを自動生成する方法が取れます。
CRMと会計ソフトの連携で結構ミソになってくるのが、「どの時点で」「どのデータを」連携するかの定義です。
| 連携タイミング | 連携データ | 連携方向 |
|---|---|---|
| 受注確定時 | 取引先名、金額、支払条件 | CRM → 会計ソフト |
| 請求書発行時 | 請求番号、発行日、金額 | 会計ソフト → CRM |
| 入金確認時 | 入金日、入金額、消込状況 | 会計ソフト → CRM |
HubSpotとfreeeの連携では、Sync連携アプリを活用することで、受注→請求→入金のデータ連携を自動化できます。
ツールだけを導入しても、営業と経理の実際の業務フローが変わらなければ効果は出ません。導入前に両部門のプロセスを可視化し、「どこで引き継ぐのか」「どのデータを共有するのか」を合意しておくことが重要です。
見積パターンが数十種類、支払条件も多岐にわたるような企業が、すべてのパターンを一度に自動化しようとすると失敗します。まずは売上の80%を占める主要なパターンから自動化し、例外的なケースは手動対応を残す「スモールスタート」が推奨です。
振込名義と取引先名の表記ゆれ（例：「株式会社ABC」と「ABC」）があると、自動消込が正しく機能しません。完全自動化を目指すよりも、「候補のマッチング提示→人間が確認」というハイブリッドの運用が現実的です。
CRM上でQTCを完結させるには限界があります。特に日本のBtoB商習慣では、請求書の押印、インボイス制度対応、源泉徴収の計算など、会計ソフトでなければ対応しきれない部分が多いのが実情です。CRMは「フロントのプロセス管理」、会計ソフトは「バックのトランザクション処理」と割り切り、その間をiPaaSで接続する設計が日本企業にはフィットしやすいかなと思います。
Quote-to-Cashの全体フローを整理すると、以下のように段階的に構築していくアプローチが現実的です。
まずは「受注→請求漏れゼロ」を最初のゴールとして設定し、そこから段階的にプロセスを拡張していくのが良いかなと思います。CRMにデータが蓄積されるほど、キャッシュフローの予測精度が上がり、より正確な経営判断につながります。
関連記事もぜひご覧ください。
パイプライン設計と受注通知の自動化（Phase 1）は1〜2週間で実装できます。会計ソフトとのAPI連携やカスタムオブジェクトの構築を含めた全体像の完成には、2〜3ヶ月が目安です。スモールスタートで段階的に構築するのが推奨です。
HubSpotの見積もり機能は見積書の作成・送付・電子署名には対応していますが、日本のインボイス制度に完全準拠した請求書の発行や、入金消込の機能は備えていません。請求以降のプロセスはfreeeやマネーフォワードなどの会計ソフトとの連携が必要です。
サブスクリプションでは「1契約=複数回の請求」が発生するため、取引と請求の関係を1対多で設計する必要があります。HubSpotのカスタムオブジェクトで「請求」レコードを作成し、契約期間分の請求レコードを自動生成する設計が有効です。また、MRRの可視化にはHubSpotのMRR管理機能も活用できます。
Salesforceの「CPQ（Configure, Price, Quote）」は、見積の構成・価格設定・見積書作成を高度にカスタマイズできるアドオン製品です。HubSpotの見積機能はCPQほどの柔軟性はありませんが、標準的なBtoBの見積業務には十分対応でき、セットアップのハードルが低いのが特徴です。