営業担当が受注報告をSlackに投稿する。経理担当はそれを見て、会計ソフトを開き、取引先情報を手入力し、請求書を作成する。入金があれば、CRMの商談ステータスを手動で更新し、Excelの管理表にも反映する――。この「同じ情報を複数のシステムに何度も入力する」二重入力問題は、多くの企業の経理業務に根深く存在しています。
CRMには受注に必要な情報がすべて揃っています。顧客名、金額、商品、受注日、担当者。これらのデータは、請求書の発行に必要な情報とほぼ同じです。にもかかわらず、CRMと会計ソフトが分断されているために、経理担当者は「営業が入力済みのデータ」を見ながら、会計ソフトに同じ内容を再入力しているのです。
本記事では、CRMと会計ソフト（freee・マネーフォワード）を連携させ、受注から請求・入金管理までを自動化する実践的な設計方法を解説します。HubSpotを中心としたCRMと、日本の主要クラウド会計ソフトとの接続パターンを、実際の設計・実装経験に基づいて具体的にお伝えします。
この記事は、CRM導入済み（または導入検討中）の経営者・経理責任者・IT担当者を対象に、会計連携の設計から実装までの実務ガイドとしてご活用いただけます。
CRMと会計ソフトが分断されている場合、受注のたびに以下のような作業が発生します。
この一連の作業には、1案件あたり数十分の工数がかかります。月に数十件の受注がある企業では、経理担当者の月間数時間〜十数時間がデータの転記作業に費やされている計算になります。CRMと会計ソフトを連携させることで、このステップ3〜6の大部分を自動化できます。
手入力によるデータ転記には、必ず誤入力のリスクが伴います。金額の桁間違い、取引先名の表記ゆれ、税率の設定ミスなど、ヒューマンエラーは避けられません。
特に深刻なのは、CRM上の受注データと会計上の売上データが一致しないという問題です。月次決算のたびに、営業が報告する受注額と経理が集計する売上額の差異を調べ、原因を突き止める突合作業が発生します。この作業は、データ量が増えるほど負担が大きくなります。
CRMと会計ソフトをシステムで連携すれば、同一のデータソースから請求書が生成されるため、データの不整合が構造的に発生しなくなります。
CRMには「今月の受注見込み（パイプライン）」が、会計ソフトには「入金済みの確定売上」があります。しかしこの2つのデータが分断されていると、経営層が「今月の着地見込みと入金実績を一覧で見たい」と思っても、それを手動で突合して提出するまでにタイムラグが生じます。
CRMと会計ソフトが連携していれば、受注から入金までのステータスがリアルタイムに把握でき、月末を待たずに経営の意思決定に必要な数字が揃う状態を構築できます。
CRMと会計ソフトの連携は、単に「データを送る」だけではなく、業務フロー全体を設計することが重要です。ここでは、受注から消込までの自動化フローの全体像を示します。
CRM × 会計連携で実現する一気通貫フローは、以下の4つのステップで構成されます。
| ステップ | トリガー | 処理内容 | データの流れ |
|---|---|---|---|
| Step 1：取引先同期 | CRMにコンタクト/会社が登録・更新されたとき | 会計ソフトの取引先マスタに自動登録・更新 | CRM → 会計ソフト |
| Step 2：請求書自動発行 | CRMの取引ステージが「受注」に移行したとき | 会計ソフトで請求書を自動生成 | CRM → 会計ソフト |
| Step 3：入金確認 | 会計ソフトで入金が記録されたとき | CRMの取引ステータスを「入金済み」に自動更新 | 会計ソフト → CRM |
| Step 4：消込・売上計上 | 入金と請求書の突合完了時 | 会計ソフトで消込処理・売上仕訳を確定 | 会計ソフト内で完結 |
ここで注目すべきは、データの流れが「CRM → 会計ソフト」の一方向ではなく、入金情報は「会計ソフト → CRM」の逆方向にも流れる点です。この双方向のデータフローを設計することで、営業担当者がCRM上で入金状況を確認できるようになり、「入金が遅延している顧客への対応」や「入金済み案件の次回提案」といった営業活動にも活用できます。
CRMと会計ソフト間で同期するデータ項目は、以下のように整理できます。
| データカテゴリ | CRM側の項目 | 会計ソフト側の項目 | 同期方向 |
|---|---|---|---|
| 取引先情報 | 会社名、住所、電話番号、担当者名 | 取引先名、住所、連絡先 | CRM → 会計 |
| 請求情報 | 取引金額、商品名、数量、税率 | 請求書の品目、金額、消費税 | CRM → 会計 |
| 入金ステータス | 取引ステージ（入金済み等） | 入金日、入金額、消込ステータス | 会計 → CRM |
| 請求書番号 | カスタムプロパティ（請求書番号） | 請求書番号 | 会計 → CRM |
CRMと会計ソフトの連携方法は、大きく3つのパターンに分類できます。企業の技術リソース、連携の複雑さ、予算に応じて最適なパターンを選択することが重要です。
概要：CRMプラットフォームのアプリマーケットプレイスで提供されている公式連携アプリを利用する方法です。HubSpotの場合、アプリマーケットプレイスにfreeeやマネーフォワードとの連携アプリが公開されていることがあり、インストールと初期設定だけで基本的なデータ同期を実現できます。
| 項目 | 特徴 |
|---|---|
| メリット | 導入が容易。コードを書く必要がない。公式サポートが受けられる場合がある |
| デメリット | 同期できるデータ項目やトリガー条件がアプリの仕様に制約される。細かいカスタマイズが難しい |
| 適する場面 | 基本的な取引先同期や請求書連携で十分な場合。まず連携を試してみたい段階 |
ネイティブ連携の注意点として、アプリの更新やサポート終了によって連携が影響を受ける可能性があります。導入前に、アプリの開発元の信頼性やアップデート頻度を確認しておくことが重要です。
概要：Zapier、Make（旧Integromat）などのiPaaSツールを使い、CRMと会計ソフト間のデータ連携をノーコード/ローコードで構築する方法です。
| 項目 | 特徴 |
|---|---|
| メリット | 柔軟なトリガー設定とデータマッピングが可能。複数のシステムをまたぐ連携も構築できる |
| デメリット | iPaaSツールの月額コストが発生。シナリオが増えると管理が煩雑になる |
| 適する場面 | ネイティブ連携では不足するカスタマイズが必要な場合。複数のトリガー条件や条件分岐を設けたい場合 |
iPaaS連携の設計では、以下の点を事前に検討します。
概要：HubSpotのOperations Hub（カスタムコードアクション）や、直接APIを呼び出すカスタム開発により、高度な連携ロジックを実装する方法です。
| 項目 | 特徴 |
|---|---|
| メリット | 完全なカスタマイズが可能。独自のビジネスロジック（税率計算、勘定科目の自動判定等）を組み込める |
| デメリット | 開発スキルが必要。API仕様の変更に追従するメンテナンスコストが発生する |
| 適する場面 | 複雑なビジネスロジックが必要な場合。大量データの同期が必要な場合。既存パターンでは対応できない要件がある場合 |
Operations Hubのカスタムコードアクションを使えば、HubSpotのワークフロー内でNode.jsコードを実行し、freeeやマネーフォワードのAPIを直接呼び出すことが可能です。たとえば、HubSpotの取引ステージが「受注」に変更されたタイミングで、カスタムコードアクションがfreeeのAPIを呼び出し、請求書を自動作成する、というフローを構築できます。
この方法のメリットは、外部ツール（Zapier等）への依存なく、HubSpotのワークフロー内で完結する連携を実現できる点です。ただし、APIの認証トークン管理やエラーハンドリング、レート制限への対応など、開発・運用面での考慮が必要です。
| 比較項目 | ネイティブ連携 | iPaaS連携 | API/カスタムコード連携 |
|---|---|---|---|
| 導入の手軽さ | 非常に高い | 高い | 低い |
| カスタマイズ性 | 低い | 中程度 | 非常に高い |
| 必要な技術スキル | 不要 | ノーコード/ローコード | プログラミングスキル |
| ランニングコスト | 低い（アプリ費用のみ） | 中程度（iPaaS月額） | 低い（Operations Hub費用） |
| メンテナンス負荷 | 低い | 中程度 | 高い（API変更への追従） |
| 推奨場面 | 基本的な同期で十分な場合 | 柔軟な条件設定が必要な場合 | 独自ロジックが不可欠な場合 |
実際の導入支援の現場では、まずネイティブ連携やiPaaS連携で基本的なフローを構築し、要件の高度化に応じてカスタムコード連携を追加する段階的アプローチが最も成功率が高くなっています。
ここからは、HubSpot × freeeの連携設計を、実際の実装経験に基づいて具体的に解説します。
freeeとの連携の起点となるのが、取引先マスタの同期です。HubSpotの会社オブジェクト（Company）をfreeeの取引先にマッピングします。
| HubSpot（会社プロパティ） | freee（取引先項目） | 備考 |
|---|---|---|
| 会社名（name） | 取引先名 | 表記ゆれに注意（正式名称で統一） |
| 住所（address） | 住所 | 郵便番号とセットで同期 |
| 電話番号（phone） | 電話番号 | フォーマットを統一する変換処理が必要な場合あり |
| カスタム：freee取引先ID | 取引先ID | 連携後にfreee側のIDをHubSpotに書き戻して紐づけ管理 |
設計のポイント：HubSpotの会社レコードにカスタムプロパティとして「freee取引先ID」を作成し、freee側で取引先が作成された際にそのIDを書き戻します。このIDの紐づけが、以降のすべての連携処理の基盤となります。取引先IDがHubSpot側に記録されていれば、請求書作成時にfreee上の正しい取引先を特定できます。
取引先の同期が完了した前提で、HubSpotの取引（Deal）データからfreeeの請求書を自動生成するフローを設計します。
トリガー設計：
freeeへ送信するデータ：
| freee請求書の項目 | HubSpotからの取得元 | 注意点 |
|---|---|---|
| 取引先 | 会社レコードのfreee取引先ID | 事前に取引先同期が完了している前提 |
| 品目・金額 | 取引の商品明細（Line Items） | 商品コードの対応付けが必要 |
| 請求日 | 取引の受注日（closedate） | 請求日 = 受注日とするか、別のロジックとするかを設計 |
| 支払期限 | カスタムプロパティ or 固定ルール | 「月末締め翌月末払い」等のロジックを実装 |
| 消費税 | 商品明細の税率設定 | freee側の税区分コードとの対応を設計 |
連携後の処理：freeeで請求書が作成されたら、発行された請求書番号をHubSpotの取引レコードにカスタムプロパティとして書き戻します。これにより、営業担当者がCRM上で「この案件の請求書番号」を確認できるようになります。
freee側で入金が記録され、請求書と入金の消込が完了したタイミングで、その情報をHubSpotに反映する逆方向のフローです。
この逆連携を実現するには、freee側のWebhook機能（ステータス変更時に外部URLへ通知）を利用するか、定期的にfreeeのAPIをポーリングして入金ステータスの変更を検知する方法があります。Webhook方式のほうがリアルタイム性は高いですが、実装の手軽さではポーリング方式（iPaaS経由）が現実的です。
連携処理では、さまざまな理由でエラーが発生する可能性があります。堅牢な連携を実現するためには、エラーハンドリングの設計が不可欠です。
| エラーの種類 | 原因例 | 対処方法 |
|---|---|---|
| 認証エラー（401/403） | APIトークンの期限切れ、権限不足 | 管理者への通知、トークンの再取得フローを用意 |
| レート制限エラー（429） | 短時間に大量のAPI呼び出し | リトライ間隔を設けた再実行（バックオフ） |
| データ不備エラー（400） | 必須項目の未入力、不正なデータ形式 | CRM側のバリデーション強化（必須プロパティの設定） |
| 重複エラー | 同一取引先や請求書が二重に作成される | IDの紐づけチェック（作成前にfreee取引先IDの存在を確認） |
エラー発生時に「処理が止まったこと」を即座に検知できる仕組みが最も重要です。Slackやメールへのアラート通知を設定し、エラー発生から対応までのタイムラグを最小化する設計にしましょう。また、エラーになった処理を後から再実行できるリトライの仕組みも併せて設計しておくことで、運用負荷を軽減できます。
マネーフォワードクラウド会計との連携も、基本的な設計思想はfreee連携と共通です。ただし、APIの仕様やデータ構造に違いがあるため、設計時に考慮すべきポイントを整理します。
| 比較項目 | freee | マネーフォワード |
|---|---|---|
| API公開範囲 | 会計・請求書・経費など幅広く公開 | 会計・請求書・経費等を個別サービスで提供 |
| 請求書機能 | freee会計と統合 | マネーフォワードクラウド請求書として独立 |
| HubSpotとの連携実績 | マーケットプレイスに連携アプリあり | iPaaSまたはAPI連携が中心 |
| 連携の推奨パターン | ネイティブ連携 or iPaaS | iPaaS or API/カスタムコード連携 |
マネーフォワードの場合、会計機能と請求書機能が別サービスとして提供されているため、連携の設計では以下の点に注意が必要です。
マネーフォワード連携では、クラウド請求書サービスを経由して会計データに接続する設計が実装しやすいパターンです。CRM（HubSpot）→ マネーフォワードクラウド請求書（請求書作成）→ マネーフォワードクラウド会計（仕訳連携）という流れで、請求書の作成をトリガーに会計側のデータが自動更新される設計を構築します。
CRMの受注データをトリガーに請求書が自動生成されるため、「受注したのに請求書を発行し忘れた」という事態が構造的に発生しなくなります。特に月末に受注が集中する企業では、発行漏れのリスクが高まるため、自動化の効果が顕著です。
会計ソフト側の入金情報がCRMに自動反映されることで、入金遅延の検知が迅速になります。入金期日を過ぎた案件をCRMのリストで自動抽出し、担当営業にタスクを自動割り当てる、といった督促フローも構築可能です。入金遅延の検知から督促アクションまでを仕組み化することで、回収率の向上と経理担当者の負荷軽減を同時に実現できます。
CRMの受注データと会計ソフトの売上・入金データが自動で同期されているため、月末の突合作業が不要になります。「CRMの受注一覧」と「会計帳簿の売上一覧」を手動で照合する工程が省略され、月次決算にかかる日数を短縮できます。
営業はCRM上で入金状況を確認でき、経理はCRMの受注情報を会計ソフト側で確認できます。「この案件、請求書は出しましたか？」「入金はありましたか？」といった部門間の確認連絡が不要になり、コミュニケーションコストが大幅に削減されます。
CRMのパイプラインデータ（受注見込み）と会計データ（確定売上・入金実績）が連動することで、経営ダッシュボードの精度が向上します。「受注済み・請求書発行済み・入金待ち・入金済み」の各ステータスをリアルタイムに可視化でき、キャッシュフローの予測精度を高めることが可能です。
CRM × 会計連携は正しく設計すれば大きな効果を生みますが、設計を誤ると逆に業務を混乱させる原因にもなります。実際の導入支援で見かける典型的な失敗パターンを共有します。
「まず連携を動かしてから考えよう」というアプローチは、最もよくある失敗です。CRM側の取引先名と会計ソフト側の取引先名の表記ルールが統一されていない状態で連携を開始すると、重複レコードが大量に発生します。連携の構築前に、データの命名規則・マスターの所在・IDの紐づけ方針を確定させることが最優先です。
取引先同期、請求書生成、入金反映、消込連携をすべて同時に構築しようとすると、どこでエラーが発生しているのか切り分けが困難になります。まずは取引先同期から始め、安定稼働を確認してから請求書連携に進む、という段階的なアプローチが鉄則です。
API連携は「必ず成功する」ものではありません。ネットワーク障害、API仕様の変更、データ不備など、さまざまな原因でエラーが発生します。エラーが発生しても検知できない状態で運用すると、「請求書が発行されていない案件」や「入金が反映されていない取引」が放置され、後から大量の手動修正が必要になります。
freeeやマネーフォワードには、テスト用の事業所（サンドボックス環境）を作成できる場合があります。本番の会計データに影響を与えないよう、必ずテスト環境で連携の動作確認を行ってから、本番環境に移行しましょう。特に請求書の自動発行は、誤って顧客に送付されるリスクがあるため、慎重なテストが不可欠です。
CRMと会計ソフトの両方で取引先情報を編集できる状態にしておくと、どちらのデータが正しいのかわからなくなります。取引先情報のマスターはCRM側、勘定科目のマスターは会計ソフト側、といったデータ種別ごとのマスター所在を明確に定義し、非マスター側での編集は連携で上書きされるルールを運用に組み込む必要があります。
CRMと会計ソフト（freee・マネーフォワード）の連携は、経理業務の自動化だけでなく、事業全体のデータ品質と意思決定スピードを向上させる基盤となります。本記事のポイントを整理します。
CRMと会計ソフトの連携は、「経理業務の効率化」にとどまらず、CRMを起点としたバックオフィス統合の核心部分です。受注データの流れを起点に、請求・入金・売上計上までがシステムでつながることで、営業と経理の分断が解消され、事業全体の可視化が実現します。
本記事で解説した設計パターンをベースに、自社の会計ソフトと業務フローに合った連携設計を構築してみてください。CRMを起点としたバックオフィス統合の全体像や、ERP連携の設計方法、見積から入金までのQuote-to-Cashプロセスの実装についても、関連記事で詳しく解説しています。
A. 一般的に、freeeのほうがAPIの公開範囲が広く、HubSpotとのネイティブ連携アプリも提供されているため、初期の連携構築はスムーズに進む傾向があります。一方、マネーフォワードは請求書サービスと会計サービスが分かれている分、それぞれのサービスに特化した連携が可能です。どちらを選ぶかは、自社がすでに利用している会計ソフトを基準に判断するのが現実的です。連携のために会計ソフトを変更する必要はありません。
A. Operations Hubがなくても連携は可能です。Zapier、Make等のiPaaSツールを使えば、HubSpotの標準機能とクラウド会計ソフトのAPIをノーコードで接続できます。Operations Hubのカスタムコードアクションは「HubSpotのワークフロー内で完結する高度な連携」が必要な場合に有効ですが、基本的な取引先同期や請求書連携であれば、iPaaS経由で十分に実現できます。
A. 連携の範囲と方法によりますが、取引先同期と請求書の自動生成を含む基本的な連携であれば、設計から稼働開始まで4〜8週間程度が目安です。iPaaS連携の場合は比較的短期間（2〜4週間）で構築可能ですが、カスタムコード連携やエラーハンドリングを含む堅牢な設計の場合は、6〜8週間程度を見込む必要があります。いずれの場合も、データ設計（マスターの統一、ID紐づけの方針決定）に十分な時間を確保することが重要です。
A. 可能です。ただし、過去データの一括移行（初期同期）と、日常業務のリアルタイム同期は別のプロセスとして設計する必要があります。過去データの移行では、CRM側と会計ソフト側の取引先の名寄せ（同一企業の特定と紐づけ）が最大の課題となります。この名寄せ作業を丁寧に行い、IDの紐づけを完了させてから、リアルタイム同期を開始する手順が推奨されます。
A. 影響します。インボイス制度対応では、CRMから会計ソフトに連携する請求書データに適格請求書の要件（登録番号、適用税率、税額の記載等）を含める設計が必要です。電子帳簿保存法への対応では、請求書データの保存要件を満たすために、会計ソフト側での電子保存機能を活用する設計が求められます。freee・マネーフォワードともにこれらの法制度に対応した機能を備えているため、連携設計時にデータ項目のマッピングを適切に行うことで対応可能です。