IT企業・SaaS企業の販売管理設計｜サブスクリプション × 案件管理 × 会計連携の最適解

「月額課金の売上をExcelで集計しているが、MRRの正確な推移が追えない」「受託開発とSaaSの売上が混在し、プロジェクト別の採算が見えない」「サブスクリプションの請求処理が属人化して、解約や契約変更のたびに手作業が発生する」——IT企業やSaaS企業の経営層・DX推進担当から、こうした声を耳にすることが増えています。

IT企業・SaaS企業の販売管理とは、サブスクリプション収益（MRR：月次経常収益 / ARR：年次経常収益）の正確な把握、プロジェクト別の原価・利益管理、そして定期請求の自動化という3つの固有課題を統合的に設計・運用する業務基盤です。

製造業や卸売業を前提に設計された汎用的な販売管理の仕組みでは、これらの課題に対応しきれません。本記事では、IT/SaaS企業が直面する販売管理の構造的な課題を整理し、サブスクリプション × 案件管理 × 会計連携の観点から最適な設計アプローチを解説します。

この記事でわかること

• IT企業・SaaS企業の販売管理が一般的な販売管理と異なる3つのポイント
• MRR/ARRの定義と、正しく管理するためのデータ設計
• プロジェクト別原価管理の設計手法と収益可視化
• サブスクリプション請求の自動化に必要な業務フロー
• 収益認識基準（ASC 606 / IFRS 15）がSaaS企業に求める対応
• 会計システムとの連携設計のポイント

IT/SaaS企業の販売管理が「特殊」である理由

販売管理の基本的な定義と業務フローについては別記事で解説していますが、IT企業やSaaS企業の販売管理には、汎用的なフレームワークだけではカバーしきれない固有の構造があります。

一般的な販売管理との違い

この違いを無視して汎用的な販売管理システムを導入すると、「データは入っているのに経営判断に使えない」状態に陥ります。

課題1：MRR/ARR管理——サブスクリプション収益の正確な把握

MRRとARRの定義

IT/SaaS企業の収益管理で最も重要な指標がMRR（Monthly Recurring Revenue：毎月繰り返し発生するサブスクリプション収益の合計）とARR（Annual Recurring Revenue：年間ベースの経常収益規模を示す指標）です。

• MRR：毎月繰り返し発生するサブスクリプション収益の合計額
• ARR：MRR × 12。年間ベースの経常収益規模を示す指標

一見シンプルですが、正確にMRRを算出するには以下の分類が必要です。

MRR管理が破綻する典型パターン

多くのIT企業で、MRR管理は以下のような理由で正確性を欠いています。

パターン1：請求額 = MRRと見なしている

年額一括払いの顧客の請求月に12ヶ月分が計上され、MRRが大きく跳ね上がるケースです。MRRは「月次で按分（一定期間に均等割り）した経常収益」であり、請求タイミングとは切り離して管理する必要があります。

パターン2：契約変更の反映が遅れる

月の途中でプラン変更や解約が発生しても、翌月の請求処理まで反映されない場合、その期間のMRRは実態を反映していません。

パターン3：スポット売上が混在している

初期構築費、コンサルティング料、カスタマイズ費用などの非経常売上（一度限りの売上）がMRRに混入すると、経常収益の実態が見えなくなります。

正確なMRR管理のためのデータ設計

MRRを正しく管理するには、販売管理の仕組みの中に以下のデータ構造を持たせる必要があります。

• 契約マスタ：顧客ごとの契約内容（プラン・単価・契約期間・更新日）を一元管理
• 契約イベントログ：新規・変更・解約の発生日と内容を時系列で記録
• 収益分類フラグ：各売上が「経常収益」か「非経常収益」かを自動判定するルール

この設計があって初めて、New MRR / Expansion / Contraction / Churnの正確な内訳分析が可能になります。

課題2：プロジェクト別原価管理——「どの案件で利益が出ているか」の可視化

IT企業の原価構造の特殊性

製造業では原価の大部分が仕入原価（材料費）ですが、IT企業の原価は「人の稼働」が中心です。

• 社内エンジニアの工数（人件費の按分）
• 外注パートナーへの委託費
• クラウドインフラコスト（AWS、GCPなどの利用料）
• ライセンス費用（開発ツール、ミドルウェアなど）

これらは案件やプロジェクト単位で発生し、複数の案件に跨がることも珍しくありません。

プロジェクト別採算が見えないことの経営リスク

プロジェクト別の原価が把握できていない場合、以下のリスクが顕在化します。

• 赤字案件の放置：売上は立っているが、工数超過で利益がマイナスの案件に気づけない
• 見積精度の低下：過去案件の実績原価が蓄積されないため、新規案件の見積もりが勘と経験頼りになる
• リソース配分の最適化ができない：どの案件にどれだけのリソースを投入すべきか、データに基づく判断ができない

プロジェクト別原価管理の設計ポイント

プロジェクト別の採算を正確に把握するためのデータ設計には、3つの要素が必要です。

1. プロジェクトコードの統一管理

すべての売上・原価データにプロジェクトコード（案件を識別するための管理番号）を紐づけ、案件単位での集計を可能にします。営業が管理する案件コードと経理が使用する勘定科目の補助科目を一致させることが重要です。

2. 工数記録の仕組み化

エンジニアやコンサルタントの稼働時間を、プロジェクトコードごとに記録する仕組みが必要です。日報ベースの手入力は定着しにくいため、カレンダーやタスク管理ツールとの連動が現実的な選択肢になります。

3. 間接費の配賦ルール

オフィス賃料、管理部門の人件費、全社共通のインフラコストなど、直接プロジェクトに紐づかない間接費をどう配分するかのルールを定めます。完全な正確性よりも、一貫したルールで運用することが重要です。

見積から入金まで（Q2C）の設計の考え方を応用しつつ、IT企業特有の原価構造に合わせた設計を行うことが求められます。

課題3：サブスクリプション請求——定期請求の自動化と契約変更対応

サブスク請求の複雑さ

サブスクリプションビジネスの請求業務は、一見シンプルに見えて、実際には多くの変数を抱えています。

• 月額払い / 年額一括払い / 四半期払いの混在
• 契約開始日がバラバラ（月初開始とは限らない）
• 月途中でのプラン変更（日割り計算の必要性）
• 無料トライアルから有料への移行
• 解約・休止・再開の処理
• 従量課金要素の加算（API利用回数、ユーザー数など）

これらを毎月手作業で処理している企業では、顧客数の増加に比例して請求ミスと作業工数が増大していきます。

請求自動化に必要な業務フロー設計

サブスクリプション請求を自動化するには、以下のフローを一気通貫で設計する必要があります。

ステップ1：契約情報の構造化

顧客ごとの契約内容（プラン、単価、課金サイクル、契約開始日、次回更新日）をデータベースで管理します。Excelやメモアプリではなくシステム上の正規データとして持つことが前提です。

ステップ2：請求スケジュールの自動生成

契約情報に基づき、毎月の請求対象リストと請求金額を自動で算出します。年額契約の月次按分、日割り計算、従量課金の加算などのロジックをシステムに組み込みます。

ステップ3：請求書の自動発行と送付

請求データから請求書を自動生成し、顧客へ送付します。インボイス制度（2023年10月開始。適格請求書の発行・保存を義務付ける制度）に対応した適格請求書の形式を満たすこと、電子帳簿保存法への対応も考慮が必要です。

ステップ4：入金消込と督促管理

銀行口座への入金データと請求データを照合し、消込処理（入金の消し込み、つまり未回収の請求に対して入金を対応付ける作業）を行います。未入金の顧客に対するリマインドの自動送信も含めて設計します。

収益認識基準への対応——ASC 606 / IFRS 15がSaaS企業に求めること

なぜ収益認識が重要なのか

IT企業・SaaS企業の販売管理を設計する際に避けて通れないのが、収益認識基準への対応です。収益認識基準とは「いつ・いくらの売上を計上するか」を定めた会計ルールのことで、日本では2021年4月から「収益認識に関する会計基準」（国際会計基準のIFRS 15や米国基準のASC 606に準拠）が適用され、上場企業を中心に対応が求められています。

SaaS企業への影響が大きいのは、以下の点です。

履行義務の識別

契約の中に複数の「履行義務」（顧客に提供するサービスの単位。たとえば「ライセンス提供」と「導入支援」はそれぞれ別の履行義務）が含まれる場合、それぞれを分離して収益を認識する必要があります。

たとえば、SaaS契約に以下が含まれる場合を考えます。

• SaaSライセンス利用料（月額）
• 初期導入支援（一括）
• カスタマイズ開発（一括）
• テクニカルサポート（月額）

これらを一括で「売上」として計上するのではなく、履行義務ごとに取引価格を配分し、それぞれの充足パターン（一時点 or 一定期間）に応じて収益を認識する必要があります。

販売管理システムへの影響

収益認識基準に対応するためには、販売管理の仕組みの中に以下の機能が必要です。

• 契約書と履行義務のマッピング：契約に含まれるサービスを履行義務単位で分解・登録できること
• 取引価格の配分ロジック：独立販売価格（それぞれのサービスを単独で販売した場合の価格）に基づく按分計算が行えること
• 収益認識スケジュールの管理：履行義務ごとの収益認識タイミングを自動生成し、会計仕訳と連動させること

中小規模のSaaS企業であっても、上場準備や監査対応を見据えるなら、早期にこの設計を組み込んでおくことが重要です。

会計連携の設計——販売管理と会計システムをどうつなぐか

なぜ会計連携が重要なのか

販売管理で記録した売上・原価データは、最終的に会計システム上の仕訳として反映される必要があります。この連携が手動であれば、月次決算のたびに転記作業が発生し、ミスや遅延の原因になります。

IT企業・SaaS企業が会計連携で特に注意すべきポイントは以下の3つです。

ポイント1：売上の計上タイミング

サブスクリプション売上は「請求日」ではなく「サービス提供期間」に基づいて計上します。4月1日に年額120万円を請求した場合、4月の売上は10万円であり、残り110万円は前受金（まだサービスを提供していない期間の対価）として処理します。

この按分処理を販売管理側で自動計算し、会計システムに連携できる設計が理想です。

ポイント2：プロジェクト原価と部門別PL

プロジェクト別の原価を会計システムに連携する際、部門コードやプロジェクトコードをどのレベルで持たせるかを設計段階で決めておく必要があります。

販売管理側のプロジェクトコードと会計側の補助科目・部門コードのマッピングルール（対応関係の定義）を事前に設定することで、月次の部門別PL（損益計算書）やプロジェクト別損益の自動出力が可能になります。

ポイント3：消費税・インボイス対応

2023年10月開始のインボイス制度により、適格請求書（一定の記載事項を満たした請求書）の発行と保存が義務化されています。販売管理システムから発行する請求書がインボイス要件を満たしているか、また、受領した請求書のデータが仕入税額控除の要件を満たす形で会計に連携されるかを確認する必要があります。

会計連携の全体設計については、販売管理と会計連携の設計ガイドも参考にしてください。

IT/SaaS企業の販売管理設計：3ステップのアプローチ

ここまで解説した3つの課題を踏まえ、IT企業・SaaS企業が販売管理の仕組みを設計する際の実践的なアプローチを3ステップで整理します。

ステップ1：現状の業務フローを棚卸しする

まず、現在の販売管理に関わる業務フローを可視化します。以下の観点で整理するのが効果的です。

• 受注から入金までのプロセスに関与する人・ツール・データの流れ
• MRR/ARRの算出方法と、その正確性の自己評価
• プロジェクト別の原価把握の有無と粒度
• 請求業務にかかる工数と、ミスの発生頻度
• 会計システムへのデータ連携方法（手動 or 自動）

ステップ2：「あるべき姿」のデータモデルを設計する

業務フローの棚卸し結果をもとに、以下のデータモデルを設計します。

ステップ3：スモールスタートで段階的に実装する

すべてを一度にシステム化しようとすると、要件が膨張してプロジェクトが頓挫するリスクがあります。優先順位をつけて段階的に進めることが成功の鍵です。

Phase 1（1〜2ヶ月）：契約マスタの整備とMRR集計の仕組み化

Phase 2（2〜4ヶ月）：請求自動化とプロジェクト別原価記録の開始

Phase 3（4〜6ヶ月）：会計連携の自動化と収益認識対応

販売管理システムの選定にあたっては、自社に最適な販売管理システムの選び方や導入コストの比較も参考にしてください。

IT/SaaS企業が販売管理設計で陥りやすい3つの落とし穴

落とし穴1：汎用ERPをそのまま導入する

製造業・卸売業向けに設計されたERP（統合基幹業務システム）をカスタマイズなしで導入すると、サブスクリプションの契約管理や従量課金の処理に対応できず、結局Excelで補完する「二重管理」が発生します。

落とし穴2：サブスク管理と受託管理を完全に分離する

SaaS事業と受託開発事業を持つ企業が、それぞれに別の管理ツールを導入し、経営ダッシュボードで統合できない状態に陥るケースがあります。事業横断で顧客情報・売上・原価を統合できるデータ設計が必要です。

落とし穴3：ツール選定から入る

「どのツールを使うか」を最初に議論してしまうと、業務フローの設計が後回しになります。まずは業務プロセスとデータモデルを設計し、その要件を満たすツールを選定する順序が正しいアプローチです。

よくある質問（FAQ）

Q1. MRR管理は売上規模がどの程度から必要ですか？

サブスクリプション型の売上が存在する時点で、MRRの管理は開始すべきです。顧客数や金額の大小に関わらず、New / Expansion / Contraction / Churnの分類を早期に始めることで、事業の成長構造が可視化されます。上場準備に入ってから整備しようとすると、過去データの遡及対応に大きな工数がかかります。

Q2. 受託開発とSaaS事業が混在する場合、販売管理は分けるべきですか？

管理の仕組み自体は統合し、収益区分（経常/非経常）やプロジェクト分類で分離するのが望ましい設計です。顧客マスタや請求プロセスを共通化しつつ、レポーティング時に事業別のフィルタリングができる構造を目指してください。

Q3. 収益認識基準は中小企業にも適用されますか？

日本の会計基準では、上場企業には強制適用ですが、中小企業は従来の基準を選択適用できます。ただし、将来の上場準備、海外投資家への説明、大企業との取引要件などを見据えると、早期に収益認識基準を意識した管理体制を整えておくことには大きなメリットがあります。

Q4. 販売管理システムと会計システムの連携は、APIで行うのが一般的ですか？

API連携（システム同士がリアルタイムでデータをやり取りする仕組み）、CSV/Excelによるファイル連携、iPaaS（システム間をノーコードでつなぐ連携プラットフォーム）経由の連携など、方法は複数あります。リアルタイム性が必要な場合はAPI連携が望ましいですが、月次決算のタイミングで一括連携するだけで十分なケースも多いです。自社の業務サイクルと会計処理の頻度に合わせて選択してください。

Q5. 販売管理のシステム化に着手する際、最初に何をすべきですか？

最初にすべきは「現状の業務フローの可視化」です。どの部門の誰が、どんなデータを、どのツールで、どのタイミングで処理しているかを一覧化します。この棚卸しなしにツール選定やシステム設計に入ると、導入後に「使われないシステム」になるリスクが高まります。

まとめ

IT企業・SaaS企業の販売管理は、サブスクリプション収益の正確な把握（MRR/ARR管理）、プロジェクト別の原価・利益管理、そして定期請求の自動化という3つの固有課題を同時に解決する必要があります。

さらに、収益認識基準（ASC 606 / IFRS 15）への対応や、会計システムとのシームレスな連携も求められます。

重要なのは、ツール選定から入るのではなく、自社の業務フローを棚卸しし、データモデルを設計した上で、段階的にシステム化を進めることです。

販売管理の基本的な考え方については販売管理とは？業務フロー・システム化のメリット・選び方を基礎から解説を、業務フロー全体の設計についてはQ2C（見積から入金まで）の設計ガイドもあわせてご確認ください。