SaaSのMRR、粉飾できることを知っているか
M&Aの現場で「ARR ◯億円・チャーン月1%・NRR 120%」というSaaSのIMを開いた瞬間、買い手の頭に最初によぎるべきは「美しすぎる」という違和感です。IMに仕込まれた粉飾15パターンで扱ったメディア系IMの粉飾15パターンと、SaaSのIM粉飾は構造が根本的に異なります。SaaSは継続課金（リカーリング）であるがゆえに、定義をひとつズラすだけで数字が桁単位で動く設計になっており、その定義の境界を仲介業者・売り手・買い手の3者ともが共有していないという、極めて危うい前提の上にIMが書かれているからです。
SaaSの譲渡対価は、買い手側で「Multiple of ARR」（ARRの何倍で買うか）として算定されることが圧倒的多数派です。ARRが10倍評価のマーケットに置かれていれば、IM上のARRが1億円ズレるだけで譲渡額は10億円ズレます。定義の曖昧な「ARR」という3文字が、増幅器のように譲渡額を歪める── これがSaaS買収の構造的な怖さです。本記事では、技術者目線で剥がせる10の粉飾パターンを、Bookings/Billings/Recognized Revenueの差、Logo Churn vs Revenue Churn、年契約前受金、CAC恣意性、PMF錯覚といった切り口で分解していきます。
1. なぜSaaSのIMは「ARR」で盛られるのか ── 年換算マジックと仲介ビジネスのインセンティブ
1-1. 「Multiple of ARR」の増幅構造 ── 1億のARR水増しが10億の譲渡額差に化ける
SaaSの譲渡対価は「ARR ✕ マルチプル」として算定されるのがほぼ定石で、SMB向けで2〜4倍、エンタープライズ向けで8〜15倍、グロース投資家が群がるカテゴリでは20倍超のマルチプルが普通に観測されます。最も危ういのは、IM上のARRが1億円水増しされた状態で取引が進行した場合、買い手はマルチプル分（仮に10倍なら10億円）の対価を実体のない数字に対して支払う、という事実です。SaaSのARR水増しはその瞬間からマルチプル倍に増幅されて譲渡額に乗ります。これがSaaSのIM粉飾を、買い手側で最も警戒すべきテーマに押し上げる根本理由です。
1-2. 「ARR」定義が3者で揃っていない ── サイレントな定義スイッチの罠
SaaSのIMで本当に厄介なのは、「ARR」という言葉の定義が、仲介業者・売り手・買い手の3者で揃っていない事実です。売り手は「直近月のMRR×12」、仲介業者は「直近12ヶ月のRevenue合計」、買い手は「期末時点で1年以上の有効契約が乗ったContracted ARR」を期待しているかもしれません。特に頻発するのが、表紙に「単月MRR×12」のARR（直近月の好調が反映された大きい値）が記載され、本文の解説には「契約ベースARR」と書かれるサイレントな定義スイッチです。買い手は表紙のARRで稟議を起案し、契約直前のDDで本文側の定義を見つけて初めて、自分が見ていた数字と仲介・売り手が指していた数字が違うことに気付く構図です。
1-3. ARR検証はDDの最終局面で発覚する ── LOI後に気付いても引き返せない構造
SaaSの場合、ARR・MRR・NRR・Churnの再集計には、Stripe・Chargebee・Recurly・自社課金システム・SFDC・プロダクトログを横断したデータ抽出が必要で、最終DDの段階で着手してもまともな再集計には2〜4週間を要します。「数字が違う」と気付いた時には独占交渉期間の終盤に差し掛かっており、引き返せばDD費用が丸ごと損失、価格を下げれば「LOI後の値下げ要求は信義則違反」と争われるリスクを抱えます。IM段階で数字の出所と定義の境界を1ページ目で剥がし切る能力が、買い手にとって最大の費用対効果を持つ投資です。
2. ARR/MRRの盛り ──「契約」「請求」「認識収益」の3者を混同させる粉飾①〜③
2-1. 【粉飾パターン①】Bookings（受注）をそのままARRとして表記する
SaaSの財務指標には3つのレイヤがあります。Bookings（受注額：契約上のコミット金額）、Billings（請求額）、Recognized Revenue（認識収益：会計上の発生主義で計上）です。粉飾①の典型は、年契約Bookings（例：3年契約・総額3,600万円）を、その契約締結月に「ARR：1,200万円増」として丸ごと計上するケースです。Bookingsベースの数字は最も大きく最も早く立ち上がって見えるため、IMで好まれる粉飾の入口です。
2-2. 【粉飾パターン②】BillingsとRecognized Revenueの差を埋めずに「年商」と称する手口
年契約一括請求のSaaSでは、契約締結月に1年分のBillingsが立ちますが、Recognized Revenueは12ヶ月かけて按分計上されます。この差を意識せずIMを書けば、契約集中月のBillingsだけが膨らみ、その月のARRが本来の月次認識収益の何倍にも見える資料が出来上がります。買い手は「IMに記載のARRが、Bookingsベースか・Billingsベースか・Recognized Revenueベースか、明示してください」と最初の質問状で文書として確認するのが正しい初手です。これを明示できない・遅らせる売り手のIMは、その時点で構造的疑義を抱えていると判断するのが妥当です。
2-3. 【粉飾パターン③】無料トライアル・フリーミアムを「Active Account」に混入させる水増し
粉飾③は、無料トライアル中・フリーミアム・有料化前PoCのアカウントを有料アクティブアカウントと混在させてActive Account数を盛り、それを根拠にARRや成長率を語る手口です。買い手側はActive Accountの定義を厳密に問い直し、「過去◯ヶ月で実際に有料課金が発生したアカウント数（Paying Active Account）」と「無料・トライアル含めた登録アカウント数」を別カラムで開示してくださいと要求すべきです。両者の比率が判明した瞬間、IMの「成長グラフ」の意味は大きく変わります。
2-4. ARR Bridge表（期首→New→Expansion→Contraction→Churn→期末）の作成義務
粉飾①〜③を一気に剥がす最強の道具がARR Bridge表です。「期首ARR」を起点に、期中の「New ARR（新規）」「Expansion ARR（既存からのアップセル）」「Contraction ARR（既存のダウングレード）」「Churned ARR（解約）」を加減算し、「期末ARR」へ着地する増減内訳を月次で示す表です。買い手側は過去24ヶ月分のARR Bridgeを月次で開示請求すべきです。これを作成できない売り手は、社内でARRの増減内訳を管理していないと自白しているに等しく、IM記載のARR数値そのものの信頼性に重大な疑義が生じます。
3. チャーンの盛り ──Logo・Revenue・Net・Grossの定義をすり替える粉飾④〜⑤
3-1. 【粉飾パターン④】Logo Churnだけ表示し、Revenue Churnを隠す手口
Churn率には、Logo Churn（解約社数÷期首社数）と、Revenue Churn（解約金額÷期首ARR）の2種類があります。粉飾④は、IMにLogo Churnだけを「月次0.8%・年換算9.2%」と記載し、Revenue Churnを意図的に省略する手口です。隠れているのは「解約しているのは大型顧客ばかりで、社数ベースでは少なくても金額ベースでは大幅にARRが減っている」という不都合な事実です。エンタープライズSaaSで上位10社が売上の60%を占める構造であれば、たった1社の解約で月次Revenue Churnが10%を超える事態すら起こり得ます。
3-2. 【粉飾パターン⑤】Net Churn（Expansion相殺後）でGross Churn（解約のみ）を見えなくする
粉飾⑤は、Gross Churn（解約・ダウングレードによる純減のみ）と、Net Churn（GrossからExpansion ARRを差し引いた値）を意図的に混同させ、Net ChurnがマイナスとなるNegative Net Churn（実質純増）を強調する手口です。極端な例で、Gross Churnが月次5%（年換算で半分の顧客が解約）でも、残った大口顧客のExpansionが月次6%発生していればNegative Net Churnは成立します。表面上のNRRは優秀でも、実態は「多くの顧客が短期離脱し、残る少数の大口顧客への依存度が増している」買収後に脆弱な収益構造です。Gross ChurnとNet Churnを必ず別の数字として並べて開示請求すべきです。
3-3. コホート別Retention Curveを開示請求する ──「平均」ではなく「分布」で剥がす
Churnの本当の姿は、平均ではなくコホート別Retention Curveに表れます。契約締結月をコホートに分解し、契約からの経過月数ごとの残存率を曲線で示したものです。健全なSaaSは経過月数とともに緩やかに低下し24〜36ヶ月後にもフロアに着地しますが、PMFが取れていない・初期オンボーディングに失敗しているSaaSでは、契約3〜6ヶ月地点でカーブが崩れ落ち、12ヶ月後には半分以下に減衰します。Retention Curveを開示できないSaaSは、社内でコホート分析を行っていない（=継続課金ビジネスとしての基本動作ができていない）と自白しているに等しく、買い手側はこの開示の有無を技術DDの最初の踏み絵として扱うべきです。
4. NRRの盛り ──「Net Revenue Retention 120%」が嘘になる粉飾⑥
4-1. 【粉飾パターン⑥】NRR分母から「期中解約済み顧客」をこっそり除外する集計境界の罠
NRRの計算式は概ね「（期末ARR − 期中New ARR）÷ 期首ARR × 100%」です。粉飾⑥は、この分母（期首ARR）から、期中に解約した顧客のARRをこっそり除外する手口です。期首ARR 10億円のうち期中に2億円分が解約した場合、本来の分母は10億円のままですが、「分母を期末まで残った顧客の期首ARRに絞る」と分母は8億円に減り、同じ実態でもNRRは125%まで膨らみます。買い手は「NRRの分母は、期首時点の全有効契約ARRですか、期末まで残存した顧客のみのARRですか」を必ず確認し、計算式を売り手側に明文化させるべきです。
4-2. 単発のアップセル1件で20pt押し上がる脆弱性と、NRR/GRRをペアで開示請求する理由
SaaSの規模が小さい段階では、NRRはたった1件の大型アップセル契約で大きくブレます。期首ARR 5,000万円のSaaSで期中に1社が500万円分のアップセルを契約した場合、それだけでNRRに+10pt以上の押し上げが発生します。IM上の「直近期NRR：123%」が、実態として「平時のNRRは110%だが、たまたま期中に大口アップセルが1件入って跳ねた値」だったケースは現場感として非常に多いため、過去8四半期分のNRRを四半期別に開示させ、跳ね値・凹み値を均した実勢NRRを買い手側で算出し直すべきです。
NRRと対になる重要指標がGRR（Gross Revenue Retention）で、Expansionを含めず「既存顧客の解約・ダウングレードによる純減」だけを反映したRetention率です。優れたエンタープライズSaaSではGRR 95%以上、SMB向けでは80〜90%が標準です。NRRが120%でもGRRが75%しかないSaaSは、解約純減を少数の大口顧客アップセルで強引に押し戻している脆弱な構造で、買収後にアップセルの伸びが止まれば一気にNRRがマイナスに転じます。
5. 前受金・収益認識の盛り ──年契約一括請求を粉飾する⑦
5-1. 【粉飾パターン⑦】年契約一括前受金（Deferred Revenue）を「単月の好調」として混入
年契約一括前受のSaaSで、年額1,200万円の契約を一括請求した場合、契約締結月に1,200万円のキャッシュインが発生しますが、会計上はDeferred Revenue（前受収益）として負債計上され、12ヶ月かけてRecognized Revenueに振り替えられます。粉飾⑦は、IMで「直近月売上：1,500万円（前年同月比3倍）」という記載で、契約締結月のキャッシュインを単月売上として混入させ、その月の好調をハイライトする手口です。発生主義から明確に逸脱した表記であり、買い手側はキャッシュベースと発生主義ベースの数字を別物として開示請求すべきです。
5-2. キャッシュベースP/Lと発生主義P/Lの乖離パターンが、契約獲得モメンタムを露呈する
年契約一括前受のSaaSでは、キャッシュベースP/Lと発生主義P/Lの間に極めて大きな乖離が生まれます。事業初期で年契約を大量獲得した期はキャッシュベースが大幅黒字に見えますが、Deferred Revenueの按分計上は翌期以降にずれ込むため発生主義P/Lはキャッシュより遥かに低い数字になります。逆に、契約獲得が止まった期はDeferred Revenueの取り崩しでRecognized Revenueは継続するが、新規キャッシュインが止まり、キャッシュベースは急減します。過去24ヶ月のキャッシュベース損益と発生主義損益を別表で開示させ、両者の乖離パターンからSaaSの契約獲得モメンタムの実態を読み取るべきです。
5-3. Stripe・Chargebee・Recurlyの課金台帳との突合で剥がす実務手順
これらの粉飾を一気に剥がす実務手順が、課金SaaSの管理画面とIM記載のMRR/ARRを直接突合することです。Stripe管理画面には月次のSubscription収益・New/Active/Canceled数・MRR推移がシステム的な生データとして記録されており、売り手側で操作する余地が極めて少ない客観値です。仲介業者経由で課金SaaSの閲覧権限を一時付与してもらい、IM記載のMRRと管理画面上のMRRを月次で並べて突合すべきです。10%以上の乖離は明確な疑義として書面で出典を確認します。これを開示できない売り手は、課金管理がスプレッドシートベースで行われている可能性が高く、それ自体がSaaSとしての運用品質に重大な疑義を生じさせます。
6. CAC・LTVの盛り ──ユニットエコノミクス幻想を作る粉飾⑧⑨
6-1. 【粉飾パターン⑧】CAC計算からマーケ人件費・代理店マージンを除外する手口
CAC（Customer Acquisition Cost）の分子には、本来、広告費だけでなくマーケ人件費・コンテンツ制作費・SDR/BDR人件費・フィールドセールス人件費・CRM/MAツール運用費・代理店マージンまで全てを含めるべきです。粉飾⑧は、CAC分子から人件費・ツール費・代理店マージンを除外し、純粋な広告費だけで計算する手口で、CACは実態の30〜60%程度の小さい値で表記されます。買い手は「CAC算出のレシピ（分子に含める費目の一覧）と費目別内訳金額」をIM段階で文書化させるべきです。
6-2. 【粉飾パターン⑨】LTV算出で「平均顧客寿命」をChurn率の逆数として楽観計上する
LTVの算出式は概ね「ARPA ÷ 月次Churn率 × 粗利率」で、「1 ÷ 月次Churn率」が平均顧客寿命として扱われます。粉飾⑨は、月次Churn率1%という「平時の最も低い月の数字」を採用し、平均顧客寿命を100ヶ月（8.3年）と計上する手口です。実際にはSaaSの平均顧客寿命は3〜5年に着地することが多く、100ヶ月という見積もりは極めて楽観的です。さらに「LTV/CAC ≥ 3.0」が健全とされる業界フレームを逆手に、CACを実態の半分に抑えLTVを2倍に楽観計上すれば、LTV/CACは実態の4倍に膨らみます。実勢「LTV/CAC=1.5」でもIM上は「6.0」と表記される仕掛けです。
6-3. CAC Payback Periodで18ヶ月超は警戒 ──回収期間の方が比率より読みやすい
LTV/CAC比率は分子分母ともに変動が大きいため、代替として有用なのがCAC Payback Period（CAC回収期間）です。「CAC ÷ ARPA × 粗利率」で算出し、新規顧客1社獲得費用を粗利で何ヶ月で回収できるかを示します。SMB向けは12〜18ヶ月、エンタープライズ向けでも24ヶ月以内が健全水準です。Payback Periodが30ヶ月を超えるSaaSは、契約獲得直後のキャッシュフローが極端に悪化する構造であり、買収後の成長投資余力を圧迫します。買い手はIM記載値を実勢CACで再計算し、18ヶ月超なら警戒、24ヶ月超なら譲渡対価の値下げ根拠として明確に位置付けるべきです。
7. PMF錯覚の盛り ── 自家製エンゲージメント指標で作る粉飾⑩
7-1. 【粉飾パターン⑩】DAU/MAU・Active Account・NPSを独自定義で都合よく算出する
粉飾⑩は、PMF（Product Market Fit）を語るためのKPIを売り手側で都合よく自家定義する手口です。例えば「DAU」を「過去30日のうち1日でもログインしたアカウント」と定義すれば、ほぼ使われていないアカウントも含まれDAU/MAU比率は見かけ上高くなります。本来のDAUは「特定日における能動的なプロダクト利用」を測る指標で、ログインのみでは不十分です。買い手は「DAU・MAUの定義（測定対象イベント）」と「主要機能の利用率（ログイン以外の能動的アクション）」を必ず開示請求すべきです。
7-2. プロダクトログ×契約データ突合で「ゴーストアカウント」を炙り出す
SaaSの本当のリスクは、IMに「Active Account：500社」と記載されている中に、3ヶ月以上ログインしていない、または主要機能を一度も使っていない「ゴーストアカウント」が大量に紛れ込んでいるケースです。これらは契約上は有効でARRに乗っていますが、実態は解約予備軍であり、契約更新タイミングで一気に解約される可能性が高い顧客群です。買い手はプロダクトログから「過去30日のログイン回数・主要機能の利用回数・最終ログイン日」を契約データと突合した形で開示するよう要求すべきです。Active Account 500社のうちログインゼロが100社あるなら、その20%は譲渡後のARR目減りリスクの定量根拠になります。さらにPMFが取れているかの真の指標は解約理由ログとサポート問い合わせカテゴリ分布に表れ、「期待した効果が出ない」「機能が足りない」が上位に来ているSaaSはPMFが本質的に取れていない可能性が高いと判断できます。
8. SaaS技術者DDが30分で剥がし切るチェックフロー
8-1. 第1ステップ：Stripe・Chargebee管理画面とIMの単月MRRを直接突合する
SaaSのIMが手元に届いたら、まず最初の30分で実施すべきチェックフローを示します。第1ステップは、IM記載の単月MRR・直近期ARRと、課金SaaSの管理画面上の数字を月次で突合することです。1〜2%の誤差は集計タイミングの違いで発生し得ますが、10%以上の乖離は明確な疑義として記録し、根拠データを書面で開示請求します。複数の管理画面を全て見せられる売り手は、それだけで信頼度が大きく上がります。
8-2. 第2ステップ：プロダクトログから「請求対象なのに非アクティブ」な顧客を抽出する
第2ステップは、プロダクトログを開示してもらい、契約データと突合して「請求対象だが非アクティブ」な顧客を抽出することです。過去30日でログインゼロかつ主要機能利用ゼロのアカウントを契約金額順にリストアップします。SMB向けで20〜30%、エンタープライズで10〜15%程度のゴースト率が観測されることが多く、それらの解約タイミングを次回更新月で予測すれば、買収後12〜24ヶ月の実勢ARR推移が見えてきます。
8-3. 第3ステップ：契約書サンプル10社分の解約条項・返金条項・自動更新条項を実測する
第3ステップは、契約書サンプル（最低10社分、できれば直近1年で締結された契約と3〜5年継続している大口契約の両方）を開示請求し、解約条項・返金条項・自動更新条項・最低契約期間・支払いサイトを実測することです。自動更新が標準で組み込まれ、解約予告期間が3ヶ月以上、未経過月の返金条項が排除されているSaaSは、ARRの安定性が構造的に高いと評価できます。逆に、月単位での解約自由・全額返金条項・自動更新オプトイン式といった条項が並ぶSaaSは、契約上のARRが実勢ARRから容易に剥落する脆弱性を抱えています。
8-4. 第4ステップ：直近24ヶ月のARR Bridge表を売り手に強制作成させ、整合性を検証する
第4ステップは、第2章で述べたARR Bridge表を売り手側に月次で強制作成させることです。ARR Bridgeを月次で並べれば、IM上の「ARR成長率：年率150%」という1行が、実態として「New ARRが月次で減衰しており、Expansion ARRで全体ARRを維持している」という構造に変わるケースが頻発します。SaaS買収のIMは、ARR Bridgeの整合性検証を経て初めて、買い手の稟議資料として使える状態になる── これが本章の結論です。
9. SaaSのIMから絶対に読み取れない「真の継続課金力」── 数字に出ない無形資産
9-1. プロダクトロードマップの実装速度・技術的負債の蓄積度はIMに書かれない
SaaSの長期的な継続課金力は、プロダクトの進化速度に強く依存します。新機能リリースのリードタイム、UI/UXのモダナイゼーション、レガシーコードの蓄積度── これらはIMには書かれません。買い手は、過去24ヶ月のリリースノート、開発チーム構成、コードベースの行数推移、主要モジュールの最終リファクタリング日、技術スタックの世代をヒアリングすべきです。技術的負債を抱えたSaaSは、買収後の機能改善コストが想定の2〜3倍に膨らみ、その間にARRが流出する展開が現実に起きます。
9-2. CSM属人化・契約書外の口頭合意・創業者個人の人脈で繋がる主要顧客
SaaSのNRR維持にはCSMの働きが決定的に重要ですが、IMには「CSM体制：◯名」とだけ書かれ、実態が「特定の1〜2名のCSMが社内の暗黙知だけで主要顧客との関係を維持している」属人化された構造であれば、そのCSMが離職した瞬間にNRRが崩壊します。さらにエンタープライズSaaSでは、契約書には書かれていない「口頭合意」（来期からのディスカウント約束、特定機能の追加開発約束、SLAの実質的な引き上げ約束等）が創業者・営業責任者の頭の中にしかないケースがあります。創業期からの主要顧客は創業者個人の人脈で繋ぎ止められていることも多く、譲渡後に関係性が冷却し次回更新で解約に至る展開が現実に起きます。上位10〜20社との契約書外合意事項を書面で全件棚卸ししてくださいと明示的に開示請求し、創業者の譲渡後の関与期間（コンサルティング契約等）を譲渡条件として組み込むべきです。
10. それでもSaaSのIMは盛られ続ける ── 数字とプロダクトの両方がわかる伴走者が必要になる理由
ここまで、SaaSのIM粉飾10パターンと、技術者目線でのDDチェックフローを分解してきました。これだけ準備を尽くしても、それでもなお、SaaSのIMは構造的に盛られ続けます。仲介業者の報酬体系が「成約価格×料率」である以上、IMが買い手寄りの中立文書に変わることはなく、本シリーズ第17回で論じた構造はSaaS領域でも全く同じです。
4度の事業譲渡を経験し、自社で売り手・買い手の両側を歩いてきた立場として申し上げます。SaaSのIMという文書は、それ単体では事業価値の30〜40%しか表現できません。残りの60〜70%は、IMの外側で、ARR Bridgeとプロダクトログの両方を皮膚感覚で読み解ける人間が、現場に踏み込んで取りに行くしかない領域です。仲介業者は「IMを作って買い手候補を集める」までが業務範囲、会計士はBookings/Billings/Recognized Revenueの粉飾構造には踏み込まず、弁護士は契約書外の口頭合意やCSMの属人化までは検証しません。SaaS固有の粉飾を剥がし、現実の継続課金力を再構成する作業は、ARR Bridgeを書ける数字脳とプロダクトログを読めるエンジニア脳の両方を持った第三者にしかできない領域です。
SaaSの買収を検討する立場でも、売却を検討する立場でも、本記事の10パターンを1つずつ手元のIMに当てはめて確認するところから始めていただければ、最終契約直前のDDで「ARRが違う」と気付いて破談・大幅減額に追い込まれる地獄を未然に防ぐ、最初の防壁になります。SaaSのIMを鵜呑みにしないリテラシーと、数字の背後にプロダクトの実態を読み解こうとする姿勢── これがSaaS M&Aの世界で身を守るための、最低限の作法です。
