業種

SaaS・サブスクの「会計PLとMRRが噛み合わない」を直す

SaaS・サブスクで会計の数字とMRR・チャーンがつながらない原因を、開発人件費の資産/費用区分・顧客獲得費（CAC）の期間対応・収益認識の3点から解説。国内企業のクラウド利用率は80.6%（総務省）。プロダクト別・コホート別に採算を見える化する方法を具体化。

Updated: 2026-06-27
Data: 総務省令和6年版情報通信白書／通信利用動向調査ベース
Verified: 2026-06-27

この記事の目次

SaaS・サブスクで「会計PLとMRRが噛み合わない」理由
採算を見るための指標と会計論点
見るべき採算単位とKPI
開発費・獲得費・収益認識の論点
SaaS・ツールだけでは届かない理由
AI管理会計ビルダーでの解き方
よくある質問
関連リンク
出典

この記事の要点AI / AEO 最適化

Q1SaaS・サブスクで採算が噛み合わなくなる主因は、会計PL（発生主義の損益）とSaaS指標（MRR・チャーン・LTV/CAC）が別管理で、開発費と顧客獲得費がいつの売上に対応するのかが整理されていないこと。先行投資が大きいモデルのため、費用と収益の期間対応を設計しないと「儲かっているのか」が判断できない。
Q2国内企業のクラウドサービス利用率は80.6%（総務省・令和6年版情報通信白書）で、SaaS／サブスクは事業基盤として定着した。市場が広がるほどプロダクトやプランが増え、開発費・サーバー費・獲得費をプロダクト別に分けて見ないと、どのプロダクトが採算に乗っているか分からなくなる。
Q3見るべき採算単位はプロダクト別・コホート別で、KPIはMRR/ARR・チャーン率・ユニットエコノミクス（LTV÷CAC）・CAC回収期間。ユニットエコノミクスは1顧客あたりの採算で、3以上・回収期間12カ月以内が健全の目安とされる。会計の粗利率とつないで初めて意思決定に使える。
Q4直し方は、採算単位をプロダクト×コホートに固定し、開発人件費の資産/費用区分と獲得費の期間対応を会計と業務指標の両面で整えること。多くのSaaSツールは予実やMRRは見えても会計と分断しているため、まず業務棚卸しで費用の対応関係を設計する。

SaaS・サブスクで「会計PLとMRRが噛み合わない」理由

SaaS・サブスクの会社で「会計の利益とMRRやチャーンの数字がつながらない」「経営会議で会計の話とSaaS指標の話が噛み合わない」という状態は、構造的に起きやすいものです。理由は、会計PL（発生主義の損益）とSaaS指標（MRR・チャーン・LTV/CAC）が、見ている時間軸も集計の単位も違うことにあります。

SaaSは先行投資型のモデルです。顧客を獲得した時点では、開発費や営業・マーケティングの費用を回収できておらず、顧客に継続利用してもらって初めて利益が積み上がります。ところが会計PLは当期に発生した費用と収益を計上するため、獲得を増やすほど当期費用がかさみ、利益が圧迫されて見えます。一方でMRRやLTV/CACは将来を含めた顧客軸の指標で、両者を別々に見ていると「会計は赤字だが事業は健全」あるいはその逆が判断できません。

だからSaaSの採算管理は、開発費と顧客獲得費が、いつの・どのプロダクトの売上に対応するのかを整理し、会計とSaaS指標を同じ基盤でつなぐところから始まります。これは指標ダッシュボードを入れるだけでは終わらず、費用の対応関係（期間対応）の設計が前提になります。

総務省の令和6年版情報通信白書によると、クラウドサービスを一部でも利用している企業の割合は80.6%に達し、SaaS・サブスクは事業基盤として定着しました。市場が広がるほど、1社が扱うプロダクトやプランは増えます。複数プロダクトの開発費・サーバー費・獲得費をひとまとめにした全社PLでは、どのプロダクトが採算に乗っているかが見えなくなるため、プロダクト別に費用を分けて見る必要が高まります。

出典総務省「令和6年版情報通信白書」／「令和6年通信利用動向調査」（企業のクラウド利用動向）

採算を見るための指標と会計論点

SaaSの採算を考えるとき、MRRなどの事業指標と、開発費・獲得費の会計上の扱いを並べてみると、論点が具体的になります。下表はSaaSの採算判断に使う代表指標と会計論点の整理です。自社の値や方針を入れて確認する出発点として使ってください。

SaaS・サブスクの採算を見るための指標と会計論点

出典：クラウド利用率は総務省「令和6年版情報通信白書」／通信利用動向調査。ユニットエコノミクスの目安は一般的なSaaS経営指標の水準。開発費・獲得費の会計上の扱いは研究開発費及びソフトウェアの会計処理に関する実務指針および日本公認会計士協会研究資料第7号に基づく一般的な整理。自社値は自社の会計・契約データから記入。

SaaS・サブスクの採算を見るための指標と会計論点
指標	自社値	業界平均	出典
企業のクラウドサービス利用率	—	80.6%（一部でも利用している企業）	総務省令和6年版情報通信白書／通信利用動向調査
ユニットエコノミクス（LTV÷CAC）の健全目安	—	3以上	一般的なSaaS経営指標の水準
CAC回収期間の目安	—	12カ月以内	一般的なSaaS経営指標の水準
開発人件費の会計上の扱い	—	将来収益が確実な段階から資産計上・償却／それ以前は費用処理	研究開発費及びソフトウェアの会計処理に関する実務指針
顧客獲得費（CAC）の会計上の扱い	—	発生時に費用処理（採算判断はコホートで回収を確認）	実務指針・SaaS経営指標の一般的整理

この表で見てほしいのは、事業指標（ユニットエコノミクス）と会計処理（開発費・獲得費）を別々に放置しないという点です。ユニットエコノミクス（LTV÷CAC）は3以上、CACの回収は12カ月以内が健全の目安とされますが、これは事業側の指標です。一方で会計側では、開発人件費は将来収益が確実な段階から資産計上して償却され、それ以前は費用処理されます。顧客獲得費は発生時に費用処理されます。事業指標で「この顧客は回収できている」と分かっても、会計のPLには償却費や当期の獲得費が乗るため、両者を対応づけて見ないと利益の実態がつかめません。

見るべき採算単位とKPI

SaaS・サブスクで採算を見える化するときの基本単位は、プロダクト別、そしてコホート別（顧客を獲得時期ごとの群で見る単位）です。全社のMRRだけでは、どのプロダクト・どの顧客群が利益を生んでいるかが見えません。

採算単位	何を見るか	使いどころ
プロダクト別	プロダクトごとの売上（MRR/ARR）・直接費・開発費・粗利	注力プロダクトと撤退候補の判断
コホート別（獲得時期別）	獲得月ごとの顧客のCAC回収・継続利益	獲得効率と定着の評価、投資判断
プラン・契約形態別	月額／年間一括の収益認識、解約	価格設計・契約条件の見直し
チャネル別（獲得経路別）	経路別のCACとLTV	マーケ投資の配分

KPIとしては、MRR/ARR（月次・年次の経常収益）、チャーン率（解約率）、ユニットエコノミクス（LTV÷CAC＝1顧客あたりの採算）、CAC回収期間が中心になります。いずれも会計の粗利率・費用とつないで初めて意思決定に使えます。事業指標だけでも会計だけでも、片方では採算の全体像は出ません。

開発費・獲得費・収益認識の論点

SaaSの採算を組み立てるとき、避けて通れない3つの会計論点があります。

1. 開発人件費の資産/費用区分。自社利用ソフトウェアは、将来の収益獲得または費用削減が確実と認められる場合に無形固定資産として計上し、確実でない場合や不明な場合は費用処理します（実務指針）。実務では、製品として収益を生むことが確実になった段階から資産計上を始め、研究・企画段階は費用処理することが多くなります。資産計上した分は耐用年数にわたって償却され、毎期の費用として乗ります。どの段階から資産計上するかを会計方針として明確にしておくことが、プロダクト別原価の前提になります。

2. 顧客獲得費（CAC）の期間対応。広告・営業・初期導入支援などの獲得費は、会計上は発生時に費用処理されますが、SaaSの採算ではその顧客が将来生む利益で回収できるかを見る必要があります。会計の費用計上と、事業としての投資回収（コホート別のCAC回収）を対応づけて見ることで、「獲得を増やして当期は赤字だが、既存顧客は利益を生み続けている」という構造を分けて示せます（1顧客あたりの採算の考え方は限界利益とはも参照）。

3. 収益認識・前受の繰延。サブスクの売上は、サービスを提供する期間にわたって収益を認識します。年間一括や前払いで受け取った金額は、受け取った時点では前受として負債で扱い、期間の経過に応じて売上へ振り替えます（収益認識に関する会計基準）。前受を一度に売上計上すると、見かけの売上と実際に確定する収益がずれます。月額・年額・複数年契約が混在するほど、契約形態ごとに収益認識のルールをそろえることが重要になります。

ユニットエコノミクス（1顧客あたりの採算＝LTV÷CAC）は、SaaSの採算判断の土台になる概念です。獲得にいくらまで使えるか、どのプロダクト・どのチャネルを伸ばすかは、すべて「その顧客群が将来どれだけ利益を生み、獲得費を何カ月で回収するか」で決まります。一般にユニットエコノミクスは3以上、CAC回収は12カ月以内が健全の目安とされます。会計のPLだけを見て獲得を絞ると、本来は回収できる優良なコホートまで止めてしまうことがあります。事業指標と会計を対応づけて見ることが、伸ばす判断と抑える判断を分ける鍵です。

出典日本公認会計士協会会計制度委員会研究資料第7号（ソフトウェア制作費等／DX環境下）

SaaS・ツールだけでは届かない理由

「予実管理ツールやSaaSダッシュボード、BIを入れれば解決する」と考えがちですが、ツール導入だけでプロダクト別・コホート別の採算が見えるようになるとは限りません。多くのSaaS系ツールは、MRRやチャーン、予実は見えても、会計の発生主義損益（開発費の償却・獲得費・サーバー原価）とは分断しているのが一般的です。

プロダクト別・コホート別の採算を出すには、開発人件費の資産/費用区分や獲得費の対応関係を会計側と突き合わせ、プロダクトログ（利用データ）と会計を1つの基盤でつなぐ設計が必要で、これは事業構造によって会社ごとに作り込みが要ります。自社の採算単位と費用の対応ルールを先に決めないままツールを入れると、テンプレートに業務を合わせることになり、出てくる数字が実態とずれます。順序は「まず業務棚卸しで費用の対応関係と採算単位を設計する→その構造を崩さずにツール運用へ乗せる」です。

AI管理会計ビルダーでの解き方

AI管理会計ビルダーは、この「採算単位の設計→開発費・獲得費の対応関係の整理→会計とSaaS指標の接続→運用」という前工程を、AIで圧縮して支援します。まず業務を棚卸しして、プロダクト・コホートのどの単位で採算を見るかを会社固有に設計し、プロダクトの利用ログと会計（開発費の償却・獲得費・サーバー原価・MRR）を1つのデータ基盤で接続して、プロダクト別・コホート別の採算を出せる仕組みを構築します。ツールのテンプレートに会社を合わせるのではなく、会社のプロダクト構造に合わせて管理会計をつくる。だから、会計とSaaS指標が分断した状態からでも、プロダクト別・コホート別の見える化を始められます。

まずは自社のSaaSが「どのプロダクト・どのコホートで採算に乗っているか」を可視化することから。無料診断で、会計とMRRをつなぐ起点になる費用対応の論点を洗い出せます。

無料診断をはじめる AI管理会計ビルダーとは

よくある質問

なぜSaaSは会計の利益とMRRなどの指標が噛み合わないのですか？

会計PLは発生主義で当期の費用と収益を計上する一方、SaaS指標（MRR・チャーン・LTV/CAC）は顧客や契約を軸に将来を含めて見るため、見ている時間軸と単位が違うからです。SaaSは顧客を獲得した時点では開発費や営業・マーケティング費の先行投資を回収できず、継続利用で初めて利益が出ます。この先行投資（開発費・獲得費）が、いつの売上に対応するのかを整理しないと、会計上は赤字に見えても事業としては健全、あるいはその逆という状態が起き、経営会議で数字が噛み合いません。両者を同じデータ基盤でつなぐことが出発点です。

プロダクト別・コホート別の採算を出すには、まず何から始めればよいですか？

採算を見る単位を「プロダクト×コホート（獲得時期ごとの顧客群）」に固定することから始めます。次に、開発人件費・サーバー費・カスタマーサクセス費・獲得費（広告・営業）を、どのプロダクトのどの顧客群に対応するかで割り当てます。コホート別に見ると、獲得月ごとの顧客が何カ月でCAC（獲得費）を回収し、その後どれだけ利益を生んでいるかが追えます。最初から精緻にせず、まずプロダクト別の売上・直接費・獲得費の3つを分けるところから始め、徐々にコホートの粒度を上げると続けやすくなります。

SaaSの開発費は資産計上すべきですか、費用処理すべきですか？

自社利用ソフトウェアの会計処理では、将来の収益獲得または費用削減が確実と認められる場合に無形固定資産として計上し、確実と認められない場合や不明な場合は費用処理するとされています（研究開発費及びソフトウェアの会計処理に関する実務指針）。実務では、製品として収益を生むことが確実になった段階から資産計上を始め、それ以前の研究・企画段階は費用処理することが多くなります。資産計上した分は耐用年数にわたって償却され、毎期の費用として乗ります。SaaSのようにクラウドで継続提供する取引については、日本公認会計士協会も研究資料で論点を整理しており、自社の開発フェーズと資産/費用の区分を会計方針として明確にしておくことが、プロダクト別採算の前提になります。

顧客獲得費（CAC）はどう扱えば採算が正しく見えますか？

顧客獲得費（CAC＝広告・営業・初期導入支援などの獲得コスト）は、会計上は発生時に費用処理されますが、SaaSの採算判断では「その顧客が将来生む利益で回収できるか」を見ることが重要です。1顧客あたりの生涯価値（LTV）を獲得費（CAC）で割ったユニットエコノミクスや、CACを何カ月で回収できるか（回収期間）を、コホート別に把握します。会計のPL上は獲得を増やすほど当期費用がかさんで利益が圧迫されますが、コホートで見れば既存顧客は利益を生み続けている、という構造を分けて示せます。会計の費用と事業の投資回収を、別々ではなく対応づけて見るのがポイントです。

SaaS向けの予実管理ツールを入れれば、プロダクト別の採算は見えるようになりますか？

ツールは有効ですが、それだけでは解決しないことが多いです。多くのSaaS系ツールはMRRやチャーン、予実は見えても、会計の発生主義損益（開発費の償却・獲得費・サーバー原価）とは分断していることが一般的です。プロダクト別・コホート別の採算を出すには、開発人件費の資産/費用区分や獲得費の対応関係を会計側と突き合わせる設計が必要で、これは事業構造によって会社ごとに作り込みが要ります。自社の採算単位（プロダクト×コホート）と費用の対応ルールを先に決めないと、ツールから出る数字が実態とずれます。まず業務棚卸しで土台を固めてから運用に乗せる順序が有効です。

出典

参照元