id: V-19
title: 部門別損益管理の設計｜CRMデータで事業部ごとの収益性を可視化する方法
slug: crm-backoffice/department-pnl-crm-profitability-visualization
metaDescription: 部門別損益管理をCRM×会計データ連携で実現する方法を解説。CRM商談データとfreee会計データを事業部コードで統合し、部門ごとの売上・粗利・営業利益を自動で可視化する設計手法、間接費の按分ルール、Excel脱却の導入ステップまで紹介します。
keywords: 部門別損益管理, 部門別P/L, CRM, 収益性, 可視化
blogAuthorId: 166212808307
「全社の売上は伸びているのに、どの事業部が利益を出し、どの事業部が赤字なのかがわからない」「部門別の損益を見たいが、Excelの手作業で月次集計に3日かかっている」――事業部制をとる企業にとって、部門別損益管理（部門別P/L）は経営判断の基盤です。しかし、多くの企業では会計データと営業データが分断されているために、部門ごとの収益性をタイムリーに把握できていません。
この課題を解決するのが、CRM商談データとfreee等の会計データを統合し、部門別P/Lを自動で構築するアプローチです。CRMには「どの事業部が、どの案件で、いくら売り上げたか」という売上の発生源データがあり、会計ソフトには「どの勘定科目に、いくらの費用が計上されたか」という原価・販管費データがあります。この2つを事業部コードで紐づけることで、部門別の収益性をリアルタイムに可視化できます。
この記事では、CRMデータを活用した部門別損益管理の設計手法を、データ源泉のマッピングから導入ステップまで具体的に解説します。
事業部が2つ以上ある企業にとって、全社P/Lだけでは「どこに投資すべきか」「どこを立て直すべきか」の判断ができません。部門別P/Lを整備することで、以下の経営判断が可能になります。
多くの企業では、部門別P/Lをスプレッドシートで手動集計しています。しかし、この運用には構造的な限界があります。
| 課題 | 具体的な問題 | 影響 |
|---|---|---|
| 集計工数の肥大化 | 会計データの部門按分・売上の部門別仕分けを毎月手作業で行う | 月次決算の確定まで5〜10営業日かかる |
| データ鮮度の低下 | 月末締め後に手動集計するため、リアルタイムの部門別収益性がわからない | 問題の検知が1ヶ月以上遅れる |
| 属人化リスク | 部門按分のルールや計算式が特定の担当者のExcelに閉じている | 担当者の異動・退職でブラックボックス化する |
| ミスの混入 | 手入力・コピペ・関数参照ミスが発生する | 経営会議で誤った数値に基づく議論が行われる |
| バージョン管理の不在 | 複数のExcelファイルが乱立し、どれが最新版かわからなくなる | 部門間で異なる数値を参照してしまう |
Excel脱却の全体像については「CRM × 会計管理の設計思想｜freee・マネーフォワードとCRMを接続する前に整理すべきこと」もあわせてご参照ください。
部門別P/Lを正しく設計するには、各構成要素のデータがどこから取得できるかを明確にする必要があります。CRM商談データと会計データの役割を整理しましょう。
| P/L項目 | 内容 | データ源泉 |
|---|---|---|
| 売上高 | 事業部ごとの受注・売上金額 | CRM（取引オブジェクト） |
| 売上原価 | 外注費、仕入、直接人件費 | 会計ソフト（freee等）＋ 案件管理ツール |
| 売上総利益（粗利） | 売上高 - 売上原価 | CRM × 会計の統合値 |
| 販管費 | 人件費、広告費、地代家賃等 | 会計ソフト（freee等） |
| 営業利益 | 粗利 - 販管費 | 統合ダッシュボードで自動計算 |
CRMは「売上の発生源」を管理するデータ基盤です。部門別P/Lの売上サイドを構築するうえで、CRMが提供するデータは不可欠です。
| CRMデータ項目 | 部門別P/Lでの活用 | 設計ポイント |
|---|---|---|
| 取引の金額（Amount） | 部門別売上高の算出 | 取引に「事業部」カスタムプロパティを持たせる |
| 取引のパイプライン | 事業部の識別 | パイプラインを事業部単位で分けるか、プロパティで区別する |
| 取引のクローズ日 | 月次・四半期の期間集計 | 会計の計上基準（発生主義）と一致させる |
| 取引に紐づく商品明細 | 商品・サービス別の売上内訳 | 商品ライン別の粗利率分析に活用 |
| 取引の担当者 | 部門・チーム別の実績管理 | 組織階層とCRMのチーム設定を一致させる |
freee等の会計ソフトは「費用の発生」を管理するデータ基盤です。部門別P/Lのコストサイドを構築します。
| 会計データ項目 | 部門別P/Lでの活用 | 設計ポイント |
|---|---|---|
| 勘定科目別の仕訳 | 売上原価・販管費の算出 | freeeの「部門」タグを活用して仕訳を部門別に振り分ける |
| 部門タグ | 費用の部門按分 | 直接費はタグで直接紐づけ、間接費は按分ルールを定義する |
| 月次推移データ | 部門別の月次P/L推移 | API経由で月次の勘定科目残高を自動取得する |
| 取引先マスタ | 外注費の案件紐づけ | CRMの取引先IDと会計の取引先を対応させる |
CRM商談データとfreee会計データを統合して部門別P/Lを構築するには、以下の3層構造で設計します。
第1層：データ収集
CRMからは取引データ（売上サイド）、freeeからは仕訳データ（コストサイド）をそれぞれAPIで取得します。HubSpotのData Hubやワークフローを活用して、CRM側のデータを構造化しておくことが前提になります。
第2層：データ統合・紐づけ
売上データとコストデータを「事業部コード」をキーにして結合します。具体的には、CRM取引の「事業部」プロパティと、freee仕訳の「部門」タグを対応させます。
第3層：集計・可視化
統合したデータを部門別P/Lのフォーマットに集計し、ダッシュボードで可視化します。HubSpotのカスタムレポートや、外部BIツールとの連携で実現します。
データ統合の要となるのが「事業部コード」の設計です。CRMと会計ソフトの双方で一貫したコード体系を使うことで、データの自動紐づけが可能になります。
| 設計項目 | 推奨ルール | 設計例 |
|---|---|---|
| コード体系 | 英数字3〜5桁の一意コード | CONS（コンサルティング事業部）、DEV（開発事業部）、MKT（マーケティング事業部） |
| CRMでの実装 | 取引のカスタムプロパティ（ドロップダウン） | プロパティ名「department_code」、値はコード体系と一致させる |
| freeeでの実装 | 部門タグ | freeeの部門設定で同一コードを設定する |
| 按分ルール | 間接費の按分基準を定義 | 売上高比率・人員比率・面積比率のいずれかを事前に決定する |
部門別P/Lの精度を左右するのが、間接費（共通経費）の按分です。按分基準を曖昧にしたまま運用を始めると、部門間で不公平感が生じ、P/Lの信頼性が損なわれます。
| 費用項目 | 按分基準 | 理由 |
|---|---|---|
| 地代家賃 | 占有面積比率 | 部門が使用するオフィス面積に比例して配分するのが合理的 |
| 共通人件費（管理部門等） | 売上高比率 or 人員比率 | 売上高比率が最もシンプルで説明しやすい |
| 通信費・システム利用料 | 人員比率 | ライセンス数やアカウント数に比例するケースが多い |
| 広告宣伝費 | 直接配賦（部門別予算） | 各部門の広告予算として直接紐づけるのが正確 |
部門別P/Lの管理方法として、従来のExcel管理とCRM基盤での管理を比較します。
| 比較項目 | Excel管理 | CRM × 会計SaaS連携 |
|---|---|---|
| 集計工数 | 月次で3〜5営業日 | 自動集計（設定後はゼロ） |
| データ鮮度 | 月末締め後の手動更新 | リアルタイム（API連携） |
| 売上データの粒度 | 担当者のExcel入力に依存 | CRM商談データから自動取得（案件・商品・担当者別） |
| コストデータの紐づけ | 手動で部門按分 | freee部門タグで自動紐づけ |
| バージョン管理 | ファイル名に日付を付けて管理 | 一元管理（常に最新版のみ） |
| 属人化リスク | 高い（計算ロジックがExcelに閉じる） | 低い（設定がシステムに残る） |
| ドリルダウン分析 | 不可（別シートで再集計が必要） | 可能（ダッシュボードから案件単位まで掘り下げ可能） |
| 導入コスト | 低い（Excel既存） | 中程度（CRM設定 + iPaaS月額数千〜数万円） |
CRMと会計データの連携設計については「FP&Aを中小企業に導入する方法｜CRMと管理会計の接続で実現する「攻めの経理」」で詳しく解説しています。
部門別P/Lのダッシュボードは、「全社俯瞰」と「部門詳細」の2階層で設計します。経営会議で全社の部門間比較を確認したあと、各事業部長が自部門の詳細を掘り下げるという運用フローを想定します。
全社俯瞰ダッシュボード：
| レポート | 表示内容 | 活用場面 |
|---|---|---|
| 部門別 売上・粗利・営業利益の比較 | 棒グラフで部門ごとの収益構造を一覧 | 月次経営会議 |
| 部門別 粗利率の推移 | 折れ線グラフで各部門の粗利率トレンドを表示 | 収益性の改善・悪化トレンド把握 |
| 部門別 売上構成比 | 円グラフで全社売上に占める各部門の割合 | 事業ポートフォリオの確認 |
| 部門別 予実対比 | 予算と実績の乖離を部門ごとに可視化 | 未達部門の早期検知 |
部門詳細ダッシュボード：
| レポート | 表示内容 | 活用場面 |
|---|---|---|
| 月次P/L推移 | 当該部門の売上・原価・粗利・販管費・営業利益の月次推移 | 部門長の月次レビュー |
| 案件別売上・粗利 | CRM取引データから案件ごとの売上と粗利を表示 | 案件単位の収益性分析 |
| 費目別コスト内訳 | 売上原価・販管費の費目別構成を表示 | コスト削減の優先順位付け |
| パイプライン × 売上予測 | 進行中の商談から翌月以降の売上予測を表示 | フォーキャスト精度の向上 |
部門別P/Lの仕組みは、一度にすべてを構築するのではなく、スモールスタートで段階的に整備するのが成功の鍵です。自社に最適な設計を見つけるために、まずは1事業部で検証し、成功パターンを横展開するアプローチを推奨します。
この段階で、CRMの売上データを事業部別に分けて見られるようになります。月次の売上集計をExcelから移行する最初の一歩です。
Phase 2では、1事業部のP/Lがほぼ自動で生成できる状態を目指します。手動での微調整は残りますが、Excelでゼロから集計する工数と比較すれば大幅な削減になります。
予実管理との連携については「CRM × 予実管理の統合設計｜売上パイプラインから予算管理のExcel脱却まで」で詳しく解説しています。
部門別損益管理は、以下のフローで段階的に構築するのが現実的です。
大切なのは、最初から全事業部の完璧なP/Lを目指さないことです。まずは1事業部を対象にCRM売上データと会計データを突合し、部門P/Lのプロトタイプを作るところから始めてください。具体的な数値で部門の収益構造が見えた瞬間、「この仕組みを全社に広げたい」という推進力が自然と生まれます。Excel集計に毎月3〜5日かけている状態から、CRM基盤の自動化された部門別P/Lに移行することで、経営判断のスピードと精度が格段に向上します。
事業部制をとっている企業であれば、社員数30名程度から部門別P/Lの導入効果が出始めます。事業部が2つ以上あり、それぞれが異なる収益構造を持っている場合、全社P/Lだけでは経営判断に必要な粒度が不足します。ただし、事業部が1つしかない企業でも、プロジェクト別やサービスライン別にP/Lを管理するニーズがあれば、同じ設計手法を応用できます。
CRMの受注金額と会計上の売上計上額が一致しないのは、計上基準の違いが原因であるケースがほとんどです。CRMでは「受注時点」で金額が確定しますが、会計では「役務提供完了時」や「検収時」に計上します。この差異を解消するには、CRM取引に「計上月」プロパティを追加し、会計上の計上タイミングに合わせてデータを管理する設計が有効です。差異が生じる構造を理解したうえで、どちらのデータを「正」とするかのルールを定義してください。
freeeの部門タグを使っていなくても、部門別P/Lの構築は可能です。代替手段として、freeeの「取引先」や「メモタグ」を活用して費用を部門別に分類する方法があります。ただし、部門タグを使う方がfreeeの部門別損益レポート機能とも連動するため、中長期的にはタグ整備を推奨します。Phase 1ではCRM側の売上データだけで部門別の売上集計を先行し、並行してfreeeの部門タグ整備を進めるのが現実的なアプローチです。
管理会計としての部門別P/Lでは、按分精度80%を目安にするのが実務的です。按分精度を100%に近づけようとすると、ルール策定と運用の工数が膨大になり、仕組み全体が回らなくなります。重要なのは、按分基準を明文化し、全部門で同一ルールを適用することです。按分ルールの一貫性が担保されていれば、部門間の相対比較は十分に有効です。まずはシンプルな「売上高比率」で按分を始め、運用しながら精度を高めていくアプローチがスモールスタートの原則に合致します。
CRM × 会計SaaSの連携による自動化を導入することで、部門別P/Lの集計工数は従来の3〜5営業日から1営業日以内に短縮できるケースが多いです。売上データはCRMからリアルタイムに取得され、費用データはfreeeのAPI連携で自動集計されるため、手動でのデータ転記・按分計算・Excel集計の工程が不要になります。ただし、初回のPhase 1〜3の構築には2〜4ヶ月の期間が必要です。構築期間の投資が、その後毎月の集計工数を削減し続けるという長期的な視点で判断してください。