freee Mikatus M&A事例｜会計SaaS統合の公開情報分析

freee Mikatus M&A事例の要点

freee Mikatus M&A事例の中心は、税理士向けのクラウド税務・会計・給与システムA-SaaSを提供するMikatusを、freeeが現金対価の簡易株式交換で完全子会社化したことです。freeeは2022年5月9日、合意書の締結を決議したと公表しました。後日の公式発表では、2022年6月30日に完全子会社化したと説明されています。

2022年8月24日には、freeeを存続会社、Mikatusを消滅会社とする吸収合併が公表されました。予定された効力発生日は同年9月30日です。2024年のfreee公式発表は、同日に吸収合併したことを過去の事実として記載しているため、法人統合が実施されたことを確認できます。

一方で、法人を一つにした時点でA-SaaSを直ちに終了させたわけではありません。吸収合併の発表では、合併に伴うA-SaaSのサービス・サポート内容に変更はないと案内されました。その後、freeeは2024年10月7日、A-SaaS税務・会計システムを2026年6月30日をもってfreee申告・freee会計へ、A-SaaS給与システムを2027年6月30日をもってfreee人事労務へ移行する方針を公表しました。

公式情報は、買収時の目的として、MikatusがA-SaaSで培ったクラウドサービスのノウハウ、会計事務所におけるシェア拡大、顧問先のスモールビジネスへのfreeeサービス浸透を挙げています。したがって本件は、単なる機能の追加というより、会計事務所を介した顧客接点と、税務・会計・給与を一気通貫で扱う実務知識を取り込む戦略として読むことができます。

参照：freee「Mikatus株式会社、freeeグループジョインのお知らせ」、freee「Mikatus株式会社、吸収合併のお知らせ」、freee「A-SaaSのfreee各種プロダクトへの移行に関するお知らせ」

freee Mikatus M&A事例を時系列で整理

freee Mikatus M&A事例は、2022年の一点だけを見ると重要な背景を見落とします。freeeとA-SaaSは、買収より前の2015年に仕訳データ連携を発表していました。APIやデータ連携で接点を持った後、資本関係へ進み、法人を統合し、さらに複数年をかけて製品移行へ進む流れです。

2026年6月30日と2027年6月30日は、2024年の公式発表に記載された移行時期です。本稿は、個々の顧客環境がその日付までにどのような状態になったかを外部から断定しません。公式ヘルプにはA-SaaSからfreee会計へ仕訳データを移す手順が掲載されていますが、それは移行実務の存在を示す資料であり、全顧客の移行完了を示す資料ではないからです。

この時系列は、SaaSのPMIにおいて「株式取得日」「法人統合日」「製品統合日」を同じ日にしなくてよいことを示します。顧客に日常利用される基幹システムほど、一時的な二重運用、データ変換、教育、問い合わせ体制、税制改正対応を含む準備期間が必要です。買い手にとっては統合速度が目的ではなく、顧客価値を毀損せずに将来の共通基盤へ到達することが目的です。

参照：freee「A-SaaSとクラウド会計ソフトfreeeがデータ連携を開始」、freeeヘルプ「A-SaaSから仕訳データを移行する」

freeeとMikatus、A-SaaSは何を持っていたのか

freee Mikatus M&A事例を理解するには、売上や利益だけでなく、両社が誰のどの業務を支えていたかを見る必要があります。freeeは統合型クラウドERPを中核に、スモールビジネスのバックオフィスを支えるサービス群を開発・提供してきました。Mikatusは会計事務所とその顧問先を対象に、A-SaaSというクラウド税務・会計・給与システムを提供していました。

2022年5月のfreee公式発表によると、A-SaaSは会計・給与・税務が一気通貫になったクラウドサービスで、2010年の提供開始から全国1,000以上の会計事務所で利用されていました。ここで重要なのは、会計事務所が単なるソフト利用者ではなく、多数の顧問先企業にサービスを届けるハブであることです。会計事務所向けの顧客関係を獲得することは、その先にいるスモールビジネスとの接点を広げる可能性を持ちます。

顧客数の数字は定義をそろえて読む

2015年の連携発表は、当時のA-SaaSについて1,700件超の事務所が契約・利用していると記載し、2022年の買収発表は全国1,000以上の会計事務所で利用されていると記載しています。数字だけを並べると減少したように見えますが、対象時点、集計単位、契約と実利用の定義が同じかは公表資料から確認できません。したがって、本稿ではこの差を解約やシェア低下の証拠とは扱いません。

この注意点はSaaS DDの基本です。「ユーザー数」「契約社数」「課金顧客数」「稼働顧客数」「アカウント数」「顧問先数」は別の指標です。譲渡企業は定義と集計ロジックを明示し、買い手は同じ母集団・同じ時点で比較できるよう再集計する必要があります。数字の見栄えより、継続的に再現できる管理指標であることが重要です。

会計SaaSは二者間サービスではない

一般的なBtoB SaaSでは、提供会社と契約企業の二者関係が中心です。会計事務所向けサービスでは、提供会社、会計事務所、事務所職員、顧問先、場合によっては給与担当者や経営者が同じデータを異なる権限で扱います。製品価値は機能数だけでなく、役割別の権限、承認、仕訳のレビュー、申告への接続、顧問先とのコミュニケーションに埋め込まれています。

そのため企業価値を説明するときは、ソフトウェアのコードだけでなく、顧客導入手順、税目ごとの業務知識、問い合わせ分類、教育コンテンツ、制度改正対応、会計事務所との関係、顧問先へ展開する仕組みを含めるべきです。これらは買収後のクロスセルや継続率を左右する無形資産であり、PMIの作業量にも直結します。

freee Mikatus M&A事例の戦略目的を四つに分解する

freee Mikatus M&A事例について、freeeの公式発表は、A-SaaSのノウハウを取り込むこと、会計事務所におけるシェアを広げること、顧問先へのfreeeサービス浸透を加速すること、より多くのスモールビジネスを支える体制を整えることを目的として示しています。ここから先は公開情報を踏まえた当センターの分析です。

1．顧客チャネルの拡張

会計事務所は、顧問先の会計・税務データへ継続的に接し、業務改善の相談を受ける立場です。買い手が会計事務所との接点を広げれば、単一プロダクトの販売だけでなく、会計、人事労務、申告など複数領域を提案する入口が増えます。ただし、顧客基盤は自動的に移転する資産ではありません。担当者との信頼、製品への習熟、価格、サポート品質、移行負担が維持されて初めて価値が残ります。

2．税務ドメイン知識の取り込み

税務プロダクトは、制度改正への追随、帳票、電子申告、例外処理、複数年度データ、会計事務所のレビュー手順など、一般的な業務アプリより強い専門知識を要します。Mikatusの価値をコードや顧客契約だけで見ると、開発・サポート組織に蓄積した判断基準を見落とします。どの問い合わせが制度解釈を要し、どこまで製品仕様で吸収し、どこから専門家確認へつなぐかという運用知識も承継対象です。

3．統合型プロダクトの範囲拡大

A-SaaSは税務・会計・給与を扱い、freeeも統合型クラウドERPを志向していました。両社の組み合わせは、プロダクト範囲を広げる一方、重複領域も生みます。重複は直ちに悪いものではありません。既存顧客を守りながら移行先の機能を整えるため、一時的に複数製品を維持する選択肢があります。問題は、二重の開発・運用コストをいつまで許容し、どの顧客価値を共通基盤へ残すかです。

4．顧問先データの連続性

2015年の公式発表では、freeeで作成した仕訳データをA-SaaSへ取り込み、税務申告へつなぐ連携が説明されていました。買収以前から業務上の接続点があったことは、両製品の利用シーンを理解する材料になります。もっとも、過去にデータ連携があったことと、完全な製品統合が容易であることは別です。データ項目、勘定科目、補助科目、部門、税区分、開始残高、添付証憑、権限、監査ログなど、移行対象は仕訳以外にも広がります。

戦略適合性を評価するときは「同じ市場だから相性がよい」で終わらせず、顧客、プロダクト、データ、販売、サポート、人材の六つに分けます。そして各シナジーについて、誰が責任者か、いつ効果が出るか、移行コストはいくらか、既存顧客へどの不利益があり得るかを計画に落とします。シナジーは評価資料の数字ではなく、実行項目へ変換されて初めて価値になります。

現金対価の簡易株式交換をどう理解するか

freee Mikatus M&A事例では、freeeを株式交換完全親会社、Mikatusを株式交換完全子会社とする株式交換が採用されました。一般的な株式交換では親会社株式を対価とする場合がありますが、本件の適時開示は、Mikatusの普通株式1株につき22,415円の金銭を交付する予定としています。予定総額は2,075,247,945円でした。

適時開示では、freeeがMikatusの第三者割当増資約4.5億円も引き受ける予定とされ、本株式交換対価と第三者割当引受額の合計は約25億円と説明されています。株主へ支払う対価と、子会社へ投入する資金は性質が異なるため、「買収価格は25億円」と一語でまとめるより、株式交換対価約20.75億円と増資引受約4.5億円を分けて理解する方が正確です。

なぜ金銭対価だったのか

公式資料は、Mikatusの一般株主へ合理的な価格で確実な換価機会を提供できること、freee株式を交付した場合の株価変動影響を避けられること、freeeの既存株主に希薄化が生じないことを理由として挙げています。これは金銭対価の説明であり、すべての非上場SaaSに同じ選択が最適という意味ではありません。

譲渡企業にとって現金対価は価値を確定しやすい一方、買い手グループの将来成長を株式で共有する余地は小さくなります。買い手にとっては希薄化を避けられますが、手元資金と資金調達への負担が生じます。さらに役員・主要社員の継続を目的に、株式交換とは別にリテンション、業績連動報酬、雇用条件を設計することがあります。これらの個別条件は、本件の公開資料から全容を確認できません。

完全子会社化を先に置く意味

100％支配を実現すると、少数株主との調整を残さず、組織再編や製品投資の意思決定を進めやすくなります。本件は完全子会社化後に吸収合併へ進んでいます。資本関係を先に確定し、次に法人を統合する流れは、クロージングと合併準備を分離できる点で理解しやすい構造です。

ただし、会社法上のスキーム、税務、株主ごとの課税、ストックオプションの処理、契約上のチェンジ・オブ・コントロール条項は個別に確認する必要があります。本稿は本件開示の読み方を説明するもので、類似スキームの採用を推奨するものではありません。

参照：freee適時開示「現金対価の簡易株式交換によるMikatus株式会社の完全子会社化」

freee Mikatus M&A事例で公表された評価額と算定手法

freee Mikatus M&A事例は、非上場SaaSの価値評価に関する具体的な開示がある点でも参考になります。freee側が選任した独立算定機関AIPは、Mikatusが非上場企業であることを踏まえ、将来キャッシュフローを反映するDCF法を用い、株式価値を2,398百万円から3,008百万円と算定しました。

Mikatus側が選任した独立第三者算定機関investment hubは、類似公開企業比較法で2,268百万円から3,069百万円、DCF法で2,373百万円から3,080百万円と算定したことが開示されています。株式交換対価と第三者割当引受額の合計約25億円は、それらの範囲内であると説明されました。

赤字純資産でも将来収益力が評価対象になる

適時開示に記載されたMikatus単体の2022年1月期は、売上高741百万円、営業利益87百万円、経常利益84百万円、当期純利益83百万円でした。一方、同時点の純資産はマイナス207百万円と記載されています。時価純資産だけでは、継続課金、顧客基盤、ソフトウェア、税務ドメイン知識、将来のシナジーを十分に捉えられない可能性があります。

だからといって、SaaSなら純資産を無視してよいわけではありません。負債、前受金、未払費用、開発投資、偶発債務、資金繰りは取引後の必要資金へ直結します。本件でも第三者割当増資約4.5億円が別途予定されていました。企業価値、株式価値、譲渡企業への対価、クロージング後の運転資金や追加投資を分けて検討することが重要です。

DCFの前提にはシナジー期待が含まれていた

freee側算定の前提となった財務予測には、freeeグループ参入に伴うシナジーによる売上増加とオペレーション効率化を踏まえ、2024年1月期および2025年1月期にそれぞれ前年度比3割以上の増益を見込む年度が含まれていたと開示されています。これは予測であり、実績を示すものではありません。

譲渡企業目線では、単独継続価値と買い手固有シナジーを分け、どの部分を価格へ反映できるかが交渉論点になります。買い手目線では、シナジーを先払いし過ぎると、統合遅延や顧客離脱のリスクを自ら負うことになります。DCFのセルを埋めるだけでなく、顧客移行率、クロスセル率、開発統合、人員維持、サポート増員など、予測を実現する運用仮説を検証する必要があります。

類似公開企業比較法の使い方

類似公開企業比較法は、上場する類似企業の売上、利益、時価総額等を参照して価値レンジを考える手法です。しかし会計SaaSでは、成長率、粗利率、解約率、顧客単価、顧客獲得効率、税務領域の製品成熟度が異なります。対象会社と比較会社の違いを調整せず、単一の倍率を売上へ掛けるだけでは説明力が弱くなります。

本件の開示は、Mikatus側算定機関が類似公開企業比較法とDCF法を併用したことを示しています。複数手法のレンジが近接していても、それが唯一の正解価格を意味するわけではありません。最終対価は、算定結果、財務・資産状況、将来見通し、入札、交渉、取引確実性を総合して決まります。

企業価値評価の基礎をさらに知りたい方は、当センターのIT M&Aガイドもご覧ください。

入札プロセスと公正性確保から学べること

freee Mikatus M&A事例の適時開示によれば、Mikatusは2021年10月上旬から4社の候補先へ打診する入札プロセスを実施しました。その結果、取引スキーム、株主への分配対価、社内承認の迅速性、取引のスピードと確実性等を総合し、freeeが最も優れた候補者だと判断したと説明されています。

この記載は、最高価格だけが買い手選定基準ではないことを示します。SaaSの売却では、資金力、データ移行能力、顧客サポート、製品方針、従業員の受け入れ、意思決定速度、独占交渉後の実行可能性が同時に問われます。高い意向価格でも、DD後に条件が大きく変わる、承認に時間がかかる、移行計画が曖昧であるなら、総合評価は下がり得ます。

双方が独立した算定機関・法律事務所を選任

公式開示では、freee側はAIPを算定機関・ファイナンシャルアドバイザーとして、アンダーソン・毛利・友常法律事務所外国法共同事業をリーガルアドバイザーとして選任しました。Mikatus側はinvestment hubを第三者算定機関、TMI総合法律事務所をリーガルアドバイザーとして選任したとされています。

また、Mikatus側算定機関の報酬は固定報酬で成功報酬を採用していないこと、Mikatus側法律事務所の報酬は時間報酬で成功報酬を採用していないことも開示されています。これらは、本件で公正性と利益相反への配慮を説明する材料です。

中小IT企業でも応用できる考え方

すべての案件で複数の算定書や同じ体制が必要とは限りません。しかし、誰が価格を算定したか、成功報酬が判断へどう影響し得るか、候補先比較の基準が何か、利害関係者が意思決定へどう関与したかは、規模を問わず整理すべきです。取締役会議事録、比較表、条件変更の履歴、専門家助言を残すことで、後から意思決定の合理性を説明しやすくなります。

freee Mikatus M&A事例に見る三段階統合

freee Mikatus M&A事例は、統合を「資本」「法人」「製品」の三層に分けて見ると理解しやすくなります。2022年6月の完全子会社化で資本を統合し、同年9月の吸収合併で法人を統合し、A-SaaSは継続提供した後、2024年に将来の製品移行方針を公表しました。

資本統合日を統合初日と呼ぶことがありますが、顧客から見た統合初日は別です。ブランド表示が変わる日、請求元が変わる日、利用規約が変わる日、ログイン方法が変わる日、データ移行日がそれぞれ異なる場合があります。プロジェクト管理では、法務上の日付だけでなく、顧客体験上のマイルストーンを定義する必要があります。

法人統合しても製品を残す合理性

合併によりバックオフィスや意思決定を一本化しつつ、顧客向け製品は一定期間維持すれば、移行先の不足機能を補う時間を確保できます。会計SaaSは、単純な画面差ではなく、申告書、税区分、部門管理、顧問先切り替え、過年度参照、給与連携など業務設計の差があります。機能一覧の一致率だけで移行可能と判断できません。

一方、長期の二重運用には、インフラ、セキュリティ、制度改正、品質保証、問い合わせ教育の重複コストが伴います。いつまで維持するかを決めずに延長すると、技術負債と顧客不安が増えます。期限を先に固定するだけでも危険であり、機能準備、移行ツール、顧客セグメント、繁忙期、サポート能力を統合ゲートとして管理することが必要です。

顧客継続を最優先するSaaS PMI

freee Mikatus M&A事例で注目したいのは、吸収合併の発表時にA-SaaSのサービス・サポート内容に変更はないと明記した点です。法人が消滅するニュースは、顧客に「製品もすぐなくなるのではないか」という不安を与えます。継続方針を同時に示すことは、問い合わせと解約懸念を抑える基本的なコミュニケーションです。

顧客が最初に知りたい五つのこと

• 今までどおりログインし、日常業務を続けられるか
• 契約相手、請求先、支払方法、利用料金は変わるか
• 保存済みデータ、添付証憑、過年度情報は維持されるか
• 問い合わせ窓口、担当者、対応時間は変わるか
• 将来の製品方針が決まった場合、いつ、どのように案内されるか

これらを一度に確約できない場合は、決定済み事項、検討中事項、次回案内時期を分けて説明します。「変更ありません」だけでは、何が変更対象に含まれるか曖昧です。サービス、サポート、料金、規約、データ保存、機能開発を項目別に示すと誤解を減らせます。

顧客を一括りにしない

会計事務所には、顧問先数、職員数、利用税目、記帳代行比率、顧問先自身の入力比率、給与利用、独自運用が異なる顧客が存在します。移行負担はアカウント数だけでは測れません。多数の顧問先を一つの手順で管理している事務所ほど、マスター差異や職員教育の影響が大きくなる場合があります。

移行計画では、利用機能、データ量、カスタム設定、繁忙期、サポート必要度で顧客を分けます。先行移行顧客からエラーと質問を集め、手順と変換ロジックを直した後に対象を広げます。重要顧客だけを優遇するのではなく、複雑性の高い顧客へ適切な人員を割り当てる考え方です。

解約率だけでなく信頼の先行指標を見る

解約は結果指標です。その前に、問い合わせ増加、ログイン頻度低下、データ出力、契約更新の保留、説明会欠席、ネガティブな自由記述などが表れます。PMIチームはCS、営業、サポート、プロダクトの情報をまとめ、顧客不安を早期に把握する必要があります。会計SaaSでは一社の解約が複数顧問先へ波及し得るため、会計事務所単位と顧問先単位を分けて観察します。

freee Mikatus M&A事例から考える製品統合

freee Mikatus M&A事例では、2024年の公式発表により、A-SaaS税務・会計システムと給与システムで異なる移行時期が示されました。税務・会計は2026年6月30日、給与は2027年6月30日とされ、領域ごとにロードマップが分かれています。これは、製品を一枚の計画で扱わず、機能・顧客・制度対応の準備に応じて移行単位を分ける考え方と整合します。

製品比較は画面機能の丸付けでは足りない

統合前に、機能を「ある・ない」で比較するだけでは不十分です。同名機能でも、入力単位、権限、締め処理、修正履歴、出力形式、顧問先横断操作が異なります。業務シナリオを起点に、開始から完了まで誰が何をするかを比較する必要があります。

残す機能と捨てる機能の基準

旧製品の全機能を新製品へ複製すると、統合に時間がかかり、複雑性も引き継ぎます。反対に、利用頻度だけで機能を削ると、少数の大口顧客や特定税目に不可欠な処理を失う場合があります。利用社数、利用回数、売上寄与、法令上の必要性、代替手順、サポート負荷、戦略適合性を組み合わせて判断します。

移行先で提供しない機能は、単に廃止と通知するのではなく、代替手順、データの保存・閲覧方法、外部サービスとの連携、契約条件を示します。顧客が自社の影響を判断できる粒度が必要です。製品ロードマップは開発部門だけでなく、法務、セキュリティ、CS、営業、会計・税務の専門担当を含めて決めます。

技術統合より業務統合を先に定義する

コードベースを一本化するか、APIで接続するか、データウェアハウスを共通化するかは手段です。先に定義すべきは、どの顧客体験を実現するかです。顧問先が入力した情報を会計事務所が確認し、税務申告へつなぎ、給与や人事労務も必要に応じて連携するという一連の業務を、どの製品構成で支えるかを明確にします。

会計SaaS統合で最も慎重さを要するデータ移行

freee Mikatus M&A事例に関連して、freee公式ヘルプはA-SaaSから仕訳データを出力し、freee会計へ取り込む手順を公開しています。これは移行の具体的な一側面です。ただし、会計SaaSの移行対象は仕訳CSVだけではありません。移行範囲を決め、移行しない情報の保存方法も設計する必要があります。

移行台帳を作る

最初に、データ種別ごとに「移す」「参照用に保持する」「法令・契約上の期間だけ保管する」「顧客へエクスポートする」を決めます。所有者、保存場所、件数、期間、機密区分、変換ルール、検証方法も台帳へ記載します。

• 事業所、会計期間、勘定科目、補助科目、部門、取引先の各マスター
• 仕訳、開始残高、未決済、消込、固定資産、予算、税区分
• 請求書、領収書等の証憑ファイルと仕訳へのひも付け
• 申告書、届出、電子申告結果、過年度データ
• 従業員、給与、勤怠、年末調整、社会保険関連情報
• ユーザー、ロール、事務所職員と顧問先の権限関係
• 操作ログ、承認履歴、コメント、タスク、問い合わせ履歴
• 銀行・カード連携、APIトークン、外部連携設定

正しさを三段階で検証する

第一に件数・合計値を比較します。仕訳件数、借方貸方合計、残高、ファイル数を旧新で突合します。第二にサンプルを目視し、摘要、税区分、部門、証憑リンク等の意味が保持されているか確認します。第三に実際の業務を通し、月次締め、決算、申告、給与計算等が完了できるか受入テストを行います。

件数が一致しても、意味が違えば移行成功とはいえません。たとえば旧システムの補助科目を新システムの取引先へ変換した場合、帳票や検索の使い方が変わります。変換前後の対応表と、利用者向け説明を残す必要があります。

ロールバックと証跡

本番切替の前に、移行に失敗した場合の戻し方を決めます。旧環境へ入力を再開する条件、新環境で入力された差分の扱い、再移行の所要時間、責任者を定義します。移行ツールのバージョン、実行日時、対象、エラー、再処理、承認者を記録すれば、後日の問い合わせと監査へ対応しやすくなります。

権限はデータより先に設計する

会計事務所では、一人の職員が複数顧問先へアクセスする一方、顧問先の利用者は自社だけを閲覧します。権限変換を誤ると、他社情報の誤閲覧という重大事故につながります。データ投入後に権限を考えるのではなく、ロール設計、最小権限、招待手順、退職者無効化、多要素認証を先にテストします。

移行ファイル自体も機密情報です。生成、転送、一時保管、削除の手順を決め、担当者個人の端末や共有リンクへ放置しないよう管理します。当センターの情報管理方針は情報セキュリティ方針でご確認いただけます。

freee Mikatus M&A事例に見るサポートPMI

freee Mikatus M&A事例のような会計SaaS統合では、サポートは統合後の付帯業務ではなく、顧客価値を守る中核機能です。A-SaaSの吸収合併発表でサービス・サポート内容の継続が示され、2024年の移行発表には会計事務所・freee認定アドバイザー向け問い合わせ先が用意されました。顧客の不安を受け止める窓口を明示することは、移行コミュニケーションの基本です。

問い合わせ量を事前に予測する

発表直後、契約変更、データ準備、テスト移行、本番移行、申告期、旧サービス終了前には問い合わせが増えます。通常期の平均件数だけで要員計画を作ると、応答遅延がさらに不安を増幅します。顧客セグメント別の対象数、説明会参加率、移行失敗率、再問い合わせ率を仮定し、ピーク時の席数と専門担当を準備します。

旧製品と新製品の知識を橋渡しする

旧製品の担当者は顧客の運用を知り、新製品の担当者は移行先の設定を知っています。どちらか一方だけでは解決できません。一定期間は共同対応チームを置き、質問を「旧側の出力」「変換」「新側の設定」「制度・業務」「契約」に分類します。回答をナレッジ化し、製品改善へ戻す仕組みが必要です。

会計事務所向けと顧問先向けを分ける

会計事務所は多数の顧問先を管理するため、説明会、移行ダッシュボード、一括処理、職員教育が重要です。顧問先は日常入力、銀行連携、請求、給与等の自社業務への影響を知りたいと考えます。同じFAQを配るだけでは、どちらにも十分な情報になりません。役割別に案内を分け、会計事務所が顧問先へ説明するための素材も用意します。

サポートKPIは応答時間だけでなく、初回解決率、再問い合わせ率、移行完了率、未解決の滞留日数、顧客満足、重大インシデントを見ます。短く回答してチケットを閉じても、顧客が業務を再開できなければ解決ではありません。

人材・組織・ドメイン知識をどう承継するか

freee Mikatus M&A事例の公式開示では、Mikatusの2022年1月31日時点の従業員数は83人と記載されています。ただし、誰がどの領域を担当し、統合後にどのような配置となったかは公開資料だけでは分かりません。ここでは会計SaaS一般の承継論点として整理します。

キーパーソンを役職名だけで決めない

創業者やCTOだけでなく、税務仕様を判断できる担当者、制度改正の影響範囲を知るエンジニア、データ変換を理解する担当者、主要会計事務所との信頼を持つCS、障害時の復旧を知るSREがキーパーソンになり得ます。組織図に名前が出ない実務担当者へ知識が集中している場合があります。

DDでは、重要業務ごとに主担当、副担当、手順書、繁忙期、外部委託先を確認します。PMIでは、残ってほしい人へ一律の慰留面談をするだけでなく、役割、意思決定権、評価制度、開発方針、働き方、処遇を具体的に示します。

暗黙知を三種類に分ける

• 製品知識：仕様の理由、例外処理、互換性、既知の制約、顧客別設定
• 業務知識：税務・会計・給与の年間サイクル、法令改正、レビュー、申告期対応
• 関係知識：主要顧客、パートナー、外部ベンダー、問い合わせ時の背景

文書化だけで暗黙知が完全に移るわけではありません。共同で障害対応や制度改正リリースを経験し、判断の過程を新チームへ移します。録画、設計判断記録、問い合わせ事例、ペア作業を組み合わせます。

文化統合は標語ではなく仕事の仕方

開発優先順位の決め方、品質基準、顧客要望の扱い、障害報告、承認階層、リリース頻度が異なると、同じミッションを掲げても摩擦が起きます。どちらかを即座に正解とせず、顧客価値とリスクに照らして残す運用を選びます。会計SaaSでは、スピードと正確性の両方が必要であり、制度期限がある領域と改善実験ができる領域を分けることが有効です。

freee Mikatus M&A事例から設計する統合KPI

freee Mikatus M&A事例の公表資料は買収目的を示していますが、個別の統合KPIや実績をすべて開示しているわけではありません。以下は、会計SaaS買収で目的を実行へ落とすための一般的な指標設計です。

移行完了の定義を厳密にする

アカウント作成だけを完了とすると、数字は早く増えます。しかし顧客が月次業務を完了できず旧環境へ戻っているなら、実質的な移行ではありません。「データ突合済み」「主要ワークフロー完了」「顧客承認」「旧環境への新規入力停止」など複数条件で完了を定義します。

シナジーとディスシナジーを同じ表で見る

クロスセル売上や開発共通化だけを追うと、解約、値引き、サポート増員、二重インフラ、移行ツール開発が見えなくなります。シナジー総額から実現コストと顧客毀損を差し引いてネット効果を管理します。評価時に置いた仮説と、実績の差を四半期ごとに説明できる状態が望まれます。

経営KPIと現場KPIを接続する

経営会議ではARRや統合費用を見ても、現場が今週直すべき移行エラーは分かりません。現場指標を原因別に集約し、どの問題が継続率やコストへ影響するかを結びます。たとえば勘定科目変換エラーが特定顧客群へ集中しているなら、変換ルール修正、対象顧客への案内、サポート増員を一つの改善計画にします。

IT・SaaSの譲渡企業が学べること

freee Mikatus M&A事例から譲渡企業が学べる第一の点は、事業価値を売上だけで説明しないことです。Mikatusについて公式資料が示したのは、A-SaaSの利用会計事務所、税務・会計・給与の一気通貫性、クラウドサービスのノウハウ、顧問先への接点です。買い手の戦略と接続する資産を言語化することが、候補先選定と価格説明の土台になります。

売却準備で作るべき価値マップ

• 顧客：課金顧客、実利用、顧客セグメント、継続率、集中度、更新月
• 収益：MRR・ARR、従量収益、導入費、サポート費、値引き、前受
• 製品：主要機能、差別化、ロードマップ、利用頻度、代替困難性
• 技術：コード、クラウド、デプロイ、監視、バックアップ、技術負債
• データ：権利、保存、移行性、品質、個人情報、顧客との役割分担
• 人材：ドメイン専門家、開発、SRE、CS、営業、引継ぎ可能性
• チャネル：紹介者、パートナー、会計事務所、API連携、コミュニティ
• 契約：利用規約、個別契約、知財、委託、承継条項、解約条件

買い手ごとにシナジーは異なる

同じ会社でも、会計プロダクトを持つ買い手、金融機関、水平SaaS、海外事業者では価値の見方が違います。顧客重複がクロスセル機会になる場合もあれば、カニバリゼーションになる場合もあります。候補先リストは企業規模だけでなく、どの資産をどう活用できるかで分類します。

競争プロセスは価格以外も比較する

本件開示では、対価だけでなく取引スキーム、承認速度、確実性が候補先選定で考慮されました。譲渡企業は意向表明書を、価格、対価形態、資金証明、DD範囲、独占期間、表明保証、役員・社員、製品方針、ブランド、クロージング条件で比較します。曖昧な高値より、実行条件が明確な提案が有利な場合があります。

移行負担も条件交渉へ入れる

旧製品を終了する場合、誰が移行ツールを作り、顧客へ説明し、サポート費用を負担するかが企業価値を左右します。譲渡企業の経営者や主要社員が長期間残る必要があるなら、期間、役割、意思決定権、報酬を先に話し合います。「協力する」という一文だけでは、繁忙期の負担や責任範囲が不明です。

IT企業の売却を検討し始めた段階では、当センターの支援方針とIT M&Aの基礎もあわせてご確認ください。

買い手が学べること

freee Mikatus M&A事例から買い手が学べる第一の点は、顧客基盤の取得と顧客価値の維持は同義ではないことです。契約上は100％子会社化できても、顧客が使い続けるか、主要人材が残るか、データを安全に移せるかはPMIの成果に依存します。

投資仮説を一文で終わらせない

「顧客基盤を活用してクロスセルする」という仮説は出発点にすぎません。対象顧客の何割が買い手製品の対象か、既に利用していないか、販売権限はあるか、同意が必要か、営業担当は誰か、移行前後のタイミングはどうかを検証します。顧客が移行対応で疲弊している時期に追加販売を急ぐと、信頼を損なう可能性があります。

買収対価と追加投資を分ける

本件開示は、株式交換対価と第三者割当増資を分けています。買い手の投資判断でも、譲渡企業の株主へ支払う金額だけでなく、運転資金、製品移行、インフラ、セキュリティ、リテンション、サポート増員を含む総投資額を見ます。評価上のシナジーが大きくても、実現コストを引いたリターンが低ければ条件を見直す必要があります。

統合初日前に顧客メッセージを準備する

発表時に、変更点、変更しない点、問い合わせ先、今後の案内時期を示します。営業やサポートが異なる説明をしないよう、社内FAQ、承認済み回答、エスカレーションを用意します。未決定事項を無理に断定せず、決定プロセスと次回更新日を明示する方が信頼を守れます。

統合しない選択肢も比較する

ブランド、製品、法人を残す方が顧客価値を守れる場合があります。吸収合併や製品一本化を既定路線とせず、独立運営、販売連携、共通基盤化、段階移行を比較します。統合の便益が、解約リスク、開発費、移行負担を上回るかを定期的に再評価します。

freee Mikatus M&A事例を踏まえた会計SaaS DDチェックリスト

freee Mikatus M&A事例の公開情報からすべてのDD項目は分かりません。以下は、本件から着想を得た一般的な会計SaaS向けチェックリストです。実際の確認範囲は事業、規模、スキームに応じて専門家と設計してください。

事業・収益

• MRR・ARRの定義、対象契約、為替・従量課金・一時売上の扱いは一貫しているか
• 新規、アップセル、ダウンセル、解約を同一顧客コホートで追えるか
• 会計事務所契約と顧問先利用を別に集計できるか
• 上位顧客、チャネル、特定税目、特定担当者への依存はどの程度か
• 価格改定、無料アカウント、値引き、返金、前受収益の条件は何か
• サポート、導入、データ化等の付帯業務は採算が取れているか

製品・技術

• 税務、会計、給与の製品別ロードマップと廃止予定機能は何か
• ソースコード、外部ライブラリ、OSS、委託成果物の権利は整理されているか
• クラウドアカウント、リポジトリ、CI/CD、監視、バックアップの権限は会社管理か
• 重大障害、データ復旧、性能問題、セキュリティ脆弱性の履歴はあるか
• 制度改正の要件化、実装、レビュー、リリースは誰が担うか
• 旧アーキテクチャを維持する費用と、移行に必要な開発量はどの程度か

データ・セキュリティ

• 顧客データの管理主体、利用目的、外部委託、越境、保存期間は明確か
• 会計事務所と顧問先の権限分離がテストされているか
• 監査ログ、多要素認証、特権ID、退職者IDの統制はあるか
• エクスポート可能なデータと、移行できないデータは何か
• バックアップからの復旧目標と復旧テストの結果は確認できるか
• インシデント通知、顧客説明、再発防止の手順はあるか

顧客・サポート

• 問い合わせ理由、初回解決率、滞留、繁忙期ピークを把握しているか
• 主要顧客との個別約束や非標準運用は文書化されているか
• 会計事務所向け研修、資格、コミュニティ、担当制度はどう運営されるか
• 製品統合を公表した場合の解約感応度を試算しているか
• 移行支援に必要な一社当たり工数と対象社数を見積もったか
• 旧新双方を理解するサポート要員を確保できるか

法務・人事・ガバナンス

• 利用規約、個別契約、再委託、契約承継、価格変更、終了通知の条件は何か
• 株式取得や合併で顧客・取引先の同意や通知が必要か
• 発明、著作物、データ、商標、ドメインの名義は会社へ集約されているか
• 重要人材、退職予定、競業、兼業、外部委託への依存はあるか
• ストックオプションや種類株式の処理をどう設計するか
• 取締役会の意思決定、公正性、利益相反への対応を説明できるか

チェックリストは資料回収のためではなく、統合計画と価格条件へつなげるために使います。見つかったリスクごとに、クロージング前の是正、価格調整、表明保証、補償、特別補償、移行計画、撤退条件のどれで対応するかを決めます。

会計SaaS統合計画の作り方

freee Mikatus M&A事例は長い時間軸で進んだため、PMIを100日で完了させる案件としてではなく、100日で長期統合を制御できる状態を作る案件として捉えると実務的です。以下は一般化した計画例であり、本件で実際に採用された計画を示すものではありません。

クロージング前

• 統合責任者、領域責任者、意思決定会議、重大事項のエスカレーションを決める
• 顧客向け発表文、社内FAQ、問い合わせ窓口、変更点一覧を準備する
• 契約、請求、口座、個人情報、クラウド権限、従業員手続の統合初日対応を確認する
• 重要人材と移行要員の役割・処遇・引継ぎ期間を合意する
• シナジー、統合費用、顧客離脱の基準値を凍結する

統合初日から30日

• サービス継続、障害監視、顧客問い合わせを最優先する
• 契約・請求・サポートの混乱を日次で確認する
• 製品、顧客、データ、人材、技術の詳細台帳を統合チームで検証する
• 公表前提とDD前提の差を洗い出し、投資仮説を更新する
• 顧客・従業員の声を経営会議へ直接上げる

31日から100日

• 顧客セグメント別の製品方針と移行難易度を決める
• 旧新機能差、データ変換、権限、サポート能力を評価する
• 先行移行の候補、テスト環境、成功条件、ロールバックを設計する
• 重複費用と必要投資を再見積もりし、製品ロードマップへ反映する
• 顧客へ次の案内時期を示し、未決事項を管理する

100日以降

• 先行顧客で移行ツールと手順を改善する
• 繁忙期を避けたウェーブ計画で対象を広げる
• 旧製品終了の条件を、日付だけでなく品質ゲートで管理する
• 移行完了後も過年度参照、問い合わせ、法定保存への対応を続ける
• 評価時のシナジーと実績差を取締役会でレビューする

統合事務局が工程表を更新するだけでは不十分です。製品、CS、セキュリティ、会計・税務専門、法務、財務、人事が同じ顧客影響表を見て判断する必要があります。遅延を隠すより、どのゲートが未達で、顧客へどの影響があり、追加投資で何が改善するかを透明にします。

会計SaaS M&Aで避けたい失敗

freee Mikatus M&A事例そのものの失敗を論じる章ではありません。公開情報から確認できない事実を推測せず、同種案件で一般に注意すべき失敗パターンを整理します。

顧客基盤を名簿として扱う

契約件数を引き継げば売上も残ると考え、利用実態と関係性を確認しない失敗です。会計事務所が製品を選ぶ理由、顧問先への展開方法、担当者の信頼を理解しなければ、クロスセルどころか既存契約を守れません。

製品終了日を先に宣言し、移行条件を後から考える

期限は意思決定を促しますが、データ突合、機能差、繁忙期、サポート能力が未検証のままでは顧客へリスクを転嫁します。日付とともに品質ゲート、例外顧客、参照環境、再移行手順を決めます。

技術チームだけで移行する

データが技術的に取り込めても、税務・会計上の意味、顧問先の権限、申告作業が再現できるとは限りません。専門業務担当、会計事務所、CSが受入テストへ参加する必要があります。

シナジーを売上だけで測る

クロスセル増加だけを報告し、値引き、解約、サポート増、二重インフラ、移行開発を別予算に置くと、買収全体の採算を誤ります。ネット効果とキャッシュの時期を一つのモデルで管理します。

人員削減を統合成果とみなす

重複業務の整理は必要ですが、旧製品を知る人を早期に失うと移行が止まります。必要な知識移転を定義し、完了条件を確認してから体制を変えます。

freee Mikatus M&A事例から考える統合の意思決定ゲート

freee Mikatus M&A事例のように、資本統合、法人統合、製品移行が異なる時間軸で進む案件では、長い工程表だけではプロジェクトを制御できません。次の段階へ進んでよいかを、顧客、品質、データ、人員、契約の条件で判定する「意思決定ゲート」が必要です。

期限を守ることは重要ですが、期限そのものが統合目的ではありません。会計事務所や顧問先が継続して業務を行え、データの正確性と機密性が守られ、買収時に想定した価値へ近づくことが目的です。予定日が到来しても重大な未解決事項が残るなら、対象を分ける、機能を補う、参照環境を延長するなどの選択肢を比較します。

戻せる判断と戻しにくい判断を分ける

案内文の表現、説明会の順序、先行移行の対象範囲は、結果を見ながら修正しやすい判断です。一方、旧製品への新規受付停止、顧客データの削除、主要クラウド環境の停止、契約の一括変更は、実行後に元へ戻すことが難しい判断です。後者ほど独立したレビューと経営承認を厚くします。

重大度を先に定義する

全体の完了率が高くても、顧客間の権限分離に一件の重大な欠陥があれば、展開を止めるべき場合があります。反対に、表示上の軽微な差異だけで全体を止める必要がない場合もあります。重大度を「顧客データの機密性」「会計・税務・給与の正確性」「法令期限」「業務継続」「利便性」に分け、停止条件を事前に定義します。

判定は統合責任者の感覚だけに委ねません。重大度別の未解決不具合、残高突合の結果、権限テスト、顧客の受入確認、サポートの滞留件数を同じシートへまとめます。例外を認める場合は、理由、期限、責任者、顧客への説明方法を記録します。

追加投資と延期を同じ土俵で比較する

遅延には二重運用費用が生じますが、無理な移行には解約、障害、再作業、信用低下の費用が生じます。経営会議では「予定より何日遅れるか」だけでなく、追加開発、支援要員、旧環境維持、顧客補償の可能性を含めて比較します。短期費用を避けるために、長期の顧客価値を損なわないことが重要です。

公表事項と社内仮説を分ける

顧客へ公表した内容は、社内の作業仮説とは重みが異なります。公表済みの期限や方針を見直す場合は、変更理由、顧客への影響、代替策、問い合わせ先を明示します。一方、社内のシナジー仮説は実績に応じて柔軟に更新し、当初計画へ固執しません。事実、約束、予測を分けることで、説明の一貫性を保てます。

会計・税務・給与の年間カレンダーをPMIへ組み込む

freee Mikatus M&A事例から会計SaaS統合を学ぶ際は、開発ロードマップだけでなく、利用者の年間業務を確認する必要があります。顧問先ごとに決算月が異なり、会計事務所には申告、年末調整、法定調書、給与、社会保険などの繁忙期があります。技術的に切替可能でも、利用者が確認や研修に時間を割けない時期があります。

顧客業務の重要日を把握する

会計事務所ごとに、顧問先の決算月分布、給与支給日、申告業務の集中、職員研修が可能な時期を確認します。全顧客を同じ日に切り替えるのではなく、利用機能、データ量、繁忙期、支援必要度で移行単位を作ります。

先行顧客は、協力意欲だけで選ぶと検証範囲が偏ります。税務・会計・給与の代表的な利用パターンを含みつつ、問題が生じても旧環境へ戻せる規模を選びます。先行結果から変換ルール、説明資料、問い合わせ分類を更新してから対象を広げます。

切替停止時間を業務から逆算する

切替では、旧環境への入力停止、データ出力、変換、取込、突合、利用者承認までの時間を見積もります。週末に実行すれば安全とは限りません。週明けに月次処理が集中する場合、問い合わせと再処理へ対応できる要員が必要です。

給与領域は支給日を越せないため、会計・税務とは別の移行計画が合理的なことがあります。人事マスター、勤怠、手当控除、年末調整など、確認対象も異なります。製品名で一括りにせず、失敗時の影響と復旧可能時間で移行単位を決めます。

過年度参照を旧製品終了後も設計する

会計データは移行後の入力だけに使うものではありません。比較、修正、税務調査、監査、顧客問い合わせのため、過年度情報へアクセスする必要があります。すべてを新製品の編集可能データへ変換するのか、帳票やファイルで保存するのか、旧環境を参照専用で残すのかを決めます。

参照専用環境にも、認証、脆弱性対応、バックアップ、退職者権限の削除、問い合わせ対応が必要です。「読み取り専用だから運用費がかからない」とは限りません。保存期間、責任者、終了条件を評価時点から見積もります。

制度改正と統合作業の競合を避ける

税務・給与製品には、制度改正に応じた期限付きの開発があります。統合開発へ人員を寄せすぎると、既存製品の制度対応や品質が遅れる可能性があります。制度対応、セキュリティ対応、顧客移行、新機能を一つの開発ポートフォリオで管理します。

特定担当者だけが制度要件を判断できる場合、その人の時間が統合全体の制約になります。判断記録、テストケース、レビュー観点を共有し、複数人が確認できる体制を作ります。長期PMIを担当者の善意や残業へ依存させないことが、サービス継続に直結します。

顧客が業務を再開して初めて完了とする

システム側でデータ投入が終わっても、顧客がログインし、権限と残高を確認し、主要業務を一巡するまでは移行途中です。完了条件を「アカウント作成」だけにせず、「顧客承認」「主要処理の完了」「旧環境への新規入力停止」まで含めます。

無回答顧客を自動的に完了扱いすると、後から未移行が発覚します。休眠顧客、廃業予定の顧客、連絡が取れない顧客にも、データ返却、保存、契約終了の手続が必要です。例外顧客を最後まで可視化することが、旧環境を安全に終了する条件になります。

地域の会計事務所・IT企業の視点で読む

freee Mikatus M&A事例は全国規模のSaaS統合ですが、地域IT企業の売却にも応用できる示唆があります。地域の業務システム会社は、製品機能だけでなく、顧客企業の運用を知る担当者、現地対応、地場の会計事務所や金融機関との関係、長年の保守履歴に価値があります。

地域の信用を検証可能な情報へ変える

「地域で信頼されている」という説明だけでは、買い手は価値を評価しにくくなります。契約継続年数、保守更新率、紹介経由の受注、顧客業種、上位顧客への依存、現地対応件数、担当者別の関係へ分解します。同時に、数値に表れない顧客固有の運用や意思決定者との関係を、引継ぎ台帳へ記録します。

顧客数が多くても代表者一人だけが関係を持つなら、承継リスクがあります。営業、サポート、開発が顧客情報を共有し、代表者以外も定例会や問い合わせ対応へ参加することで、会社として引き継げる関係へ変えられます。

全国基盤と地域運用を接続する

全国展開する買い手の製品へ統合する場合も、地域顧客が求める訪問、初期設定、教育、個別帳票を急に消すと価値が下がります。共通化する領域と地域チームが残す領域を分けます。製品基盤は統合し、顧客窓口や導入支援は地域で維持するなど、複数の統合モデルを比較します。

地域対応を残す場合は、属人的な善意としてではなく、サービス範囲、料金、対応時間、必要人員を定義します。買い手の標準サービスと地域独自サービスを区別すれば、統合後の採算と顧客期待を管理しやすくなります。

社名・拠点・雇用を条件として整理する

譲渡企業の経営者が地域で守りたいものは、価格だけではありません。社名、拠点、社員の雇用、地元協力会社、既存顧客への対応、代表者の引継ぎ期間を優先順位で整理します。永久保証が難しい事項でも、一定期間の方針、変更時の協議、顧客説明の責任を基本合意や統合計画へ落とせます。

情報管理と地域の評判を両立する

地域では経営者、顧客、社員、取引先の距離が近く、売却検討の情報が早期に広がると事業へ影響する場合があります。初期段階は社名や顧客名を伏せ、顧客構成、契約年数、業種、収益性を匿名化して候補先へ伝えます。

NDAを締結した後も、一度に全情報を出す必要はありません。候補先の関心、条件、資金、統合方針を確認しながら、顧客名、契約、ソースコード、個人情報の順に開示範囲を広げます。業界理解と情報管理を両立することが、譲渡企業、顧客、社員の信頼を守ります。

公開情報から分かること、分からないこと

freee Mikatus M&A事例を正しく扱うには、事実、会社側の目的説明、本稿の分析を分ける必要があります。公式開示で確認できるのは、スキーム、予定・実施日、対価、算定レンジ、過去の財務情報、買収目的、吸収合併、製品移行方針等です。

公開情報から確認できる主な事実

• 2022年5月9日に完全子会社化に関する合意書締結を決議したこと
• 現金対価の簡易株式交換で、1株22,415円、予定総額2,075,247,945円とされたこと
• 約4.5億円の第三者割当増資引受を別に予定していたこと
• 複数の算定機関がDCF法または類似公開企業比較法を用いたこと
• 2022年6月30日に完全子会社化し、同年9月30日に吸収合併したこと
• A-SaaSのサービスを合併後も継続提供したこと
• 2024年に税務・会計、給与の段階的な製品移行方針を発表したこと

公開情報だけでは断定できない主な事項

• 顧客別の契約条件、解約率、ARR、顧客単価、粗利率
• 買収後の個別シナジー実績と統合費用
• 従業員の定着、配置、リテンション条件
• ソースコード、インフラ、セキュリティDDの具体的結果
• 各顧客の移行状況、移行エラー、問い合わせ件数
• 2026年6月30日以降の全顧客についての移行完了状態
• のれん、無形資産、取得原価配分の詳細な判断経緯

公開情報事例の記事で重要なのは、空白をもっともらしい物語で埋めないことです。たとえば後年の製品移行発表から、買収当初から同じ日程が決まっていたとは言えません。吸収合併時の「サービス・サポート内容に変更なし」と、後年の移行方針は時点が異なります。各発表時点で確認できる事実として扱います。

freee Mikatus M&A事例の公式資料を読む順番

freee Mikatus M&A事例を自分で検証したい方は、短いプレスリリースだけでなく、適時開示PDFまで確認してください。プレスリリースは目的と顧客向けメッセージを理解しやすく、適時開示は対価、算定、公正性、財務情報を詳しく確認できます。

1. 2022年5月9日のグループジョイン発表で目的と顧客価値を把握する。
2. 完全子会社化の適時開示PDFでスキーム、対価、算定、公正性、財務を確認する。
3. 2022年8月24日の吸収合併発表で法人統合とサービス継続を確認する。
4. 2024年10月7日の製品移行発表で後年のロードマップを確認する。
5. 公式移行ヘルプで顧客が実際に行う作業の一部を確認する。
6. 2015年のデータ連携発表で買収前からの製品接点を確認する。

資料ごとに公表日を記録し、後日の情報で過去の判断を上書きしないことが大切です。予定と実績も区別します。後日の公式資料が「実施した」と明記している場合は実績として扱えますが、予定日だけの資料から完了を断定しません。

freee Mikatus M&A事例に関するよくある質問

Q1．freeeはいつMikatusを完全子会社化しましたか。

freee Mikatus M&A事例について、freeeは2022年5月9日に現金対価の簡易株式交換による完全子会社化を公表し、後日の公式発表で2022年6月30日に完全子会社化したと説明しています。合意発表日と効力発生日を分けて理解してください。

Q2．買収対価はいくらでしたか。

適時開示では、Mikatus普通株式1株につき22,415円、株式交換対価の予定総額2,075,247,945円とされています。これとは別に、freeeが約4.5億円の第三者割当増資を引き受ける予定とされ、両者の合計は約25億円と説明されました。株主への対価と会社への資金投入は分けて表現するのが正確です。

Q3．なぜ株式ではなく現金を対価にしたのですか。

公式開示は、Mikatusの一般株主へ合理的な価格で確実な換価機会を提供すること、freee株価の変動影響を避けること、freee既存株主の希薄化を生じさせないことを理由として挙げています。個別株主の税務上の有利不利までは本稿で判断しません。

Q4．Mikatusはどのような会社でしたか。

Mikatusは、会計事務所と顧問先向けのクラウド税務・会計・給与システムA-SaaSを提供していました。適時開示では2009年6月設立、税理士向けおよび中小企業向けクラウドサービスの企画・開発・販売を事業内容として記載しています。

Q5．A-SaaSは買収直後に終了しましたか。

終了していません。2022年8月の吸収合併発表は、合併に伴うA-SaaSのサービス・サポート内容に変更はないと説明しました。2024年に、税務・会計と給与を異なる時期にfreee各種プロダクトへ移す方針が公表されています。

Q6．A-SaaSの移行先と公表時期は何ですか。

freeeの2024年10月7日発表では、A-SaaS税務・会計システムを2026年6月30日をもってfreee申告・freee会計へ、A-SaaS給与システムを2027年6月30日をもってfreee人事労務へ移行するとしています。本稿は全顧客の個別移行完了を断定しません。

Q7．freeeとA-SaaSは買収前から関係がありましたか。

2015年4月、freeeはA-SaaSとの仕訳データ連携を発表しています。freeeで作成した仕訳データをA-SaaSへ取り込み、税務申告へつなぐ利用場面が説明されました。資本関係や取引関係について、2022年の適時開示は当時「該当なし」としています。過去の製品連携と、直前時点の会社間取引の開示は区別して読む必要があります。

Q8．企業価値はどの方法で算定されましたか。

freee側算定機関はDCF法を使用しました。Mikatus側算定機関は類似公開企業比較法とDCF法を使用しています。それぞれのレンジは本文の評価章に記載したとおりです。算定レンジは価格保証ではなく、交渉と意思決定の参考情報です。

Q9．Mikatusの買収前業績はどうでしたか。

適時開示に記載されたMikatus単体の2022年1月期は、売上高741百万円、営業利益87百万円、経常利益84百万円、当期純利益83百万円、純資産マイナス207百万円、総資産161百万円です。単年度の数字だけで価値や健全性を判断せず、継続収益、資金需要、顧客、将来計画をあわせて確認します。

Q10．候補先はfreee一社だけでしたか。

公式開示によれば、Mikatusは2021年10月上旬から4社の候補先に打診する入札プロセスを実施しました。対価だけでなく、取引スキーム、承認プロセスの迅速性、取引のスピードと確実性等を総合的に考慮したと説明されています。

Q11．吸収合併したのはいつですか。

freeeは2022年8月24日に吸収合併を決議し、効力発生日を2022年9月30日予定として公表しました。2024年の公式移行発表は、2022年9月30日にfreeeがMikatusを吸収合併したと記載しています。

Q12．この事例は成功事例と断定できますか。

本稿は「成功」「失敗」を断定しません。公開情報から、完全子会社化、吸収合併、製品移行方針は確認できますが、顧客継続率、シナジー実績、統合費用、人材定着等の全情報は確認できないためです。公開情報分析では、評価語より検証可能な事実を優先します。

Q13．会計SaaSの買い手が最初に確認すべきことは何ですか。

顧客と顧問先の関係、課金単位、継続率、製品別収益、制度改正対応、データと権限、主要人材、サポート繁忙期を確認します。コードレビューだけでは、税務・会計業務を安全に承継できるか判断できません。

Q14．譲渡企業はいつから移行資料を準備すべきですか。

売却を決めた後ではなく、日常運営の段階から準備するのが理想です。データ辞書、権限表、顧客別設定、障害履歴、リリース手順、制度改正の判断記録が整っていれば、DDとPMIの不確実性を下げられます。

Q15．SaaSの法人統合と製品統合は同日に行うべきですか。

必ずしも同日である必要はありません。本件では資本統合、法人統合、後年の製品移行が別の時間軸でした。最適な速度は、契約、顧客影響、技術、データ、サポート、制度期限によって異なります。

Q16．記事の情報は個別案件の価格交渉にそのまま使えますか。

使えません。公表された金額や倍率を他社へ機械的に当てはめることはできません。顧客構成、成長率、収益性、技術、資金需要、競争状況、買い手シナジーが異なります。個別評価は資料を確認して専門家と行ってください。

まとめ｜会計SaaSのM&Aは顧客業務を移すところまで設計する

freee Mikatus M&A事例は、現金対価の簡易株式交換による完全子会社化、吸収合併、A-SaaSの継続提供、後年のfreee各種プロダクトへの段階的移行という複数の段階で構成されています。公式資料からは、税理士向けの顧客基盤、クラウド税務・会計・給与のノウハウ、顧問先への接点が戦略上重視されたことを読み取れます。

また、価格は一つの倍率で決まったのではなく、DCF法、類似公開企業比較法、財務・資産状況、将来見通し、入札、取引確実性を踏まえて協議されました。買収対価と会社への追加資金も区別されています。譲渡企業は価値の源泉と移行可能性を示し、買い手はシナジー実現費用と顧客離脱リスクまで含めて投資判断する必要があります。

最も大きな示唆は、SaaSのクロージングは顧客にとっての統合完了ではないことです。契約主体が変わっても、製品、データ、権限、サポート、業務カレンダーは残ります。特に会計SaaSでは、月次、決算、申告、給与の正確性を守りながら、顧客ごとに移行する長期計画が必要です。

IT企業・SaaS事業の売却を考えているものの、顧客へ知られずに企業価値、候補先、製品継続、社員、データ移行を整理したい方は、譲渡企業向けの初期相談をご利用ください。社名を開示する前の段階から、守りたい条件と承継上の論点を整理します。

当センターの役割や情報管理についてはIT M&A総合センターとは、M&A全体の流れについてはIT M&Aガイドをご覧ください。