ソフトウェア開発費の資産計上：新規事業の会計処理の考え方

新規事業でシステムやアプリを開発するとき、その開発費を「その期の費用」として処理するか、「ソフトウェアという資産」として計上し複数年に分けて費用化するかで、事業の損益の見え方は大きく変わります。判断の出発点になるのは、そのソフトウェアが自社で利用するためのものか、外部に販売するためのものか、そして支出がどの段階のものかという二つの問いです。

結論を先に言うと、新規事業の担当者が押さえるべきなのは細かい会計処理の手順ではなく、「資産計上できるかどうかは事業の確からしさと支出の性質で決まる」「資産計上すると単年度の赤字は小さく見えるが、将来の費用と減損のリスクを抱える」という二点です。そして、どちらで処理するかは開発に着手する前に経理部門や税理士と相談しておく必要があります。後から整理しようとすると、根拠となる資料が残っておらず判断できないことが多いからです。

この記事は、新規事業の企画担当者、事業責任者、スタートアップの経営者で、開発費が事業計画や損益にどう影響するのかを理解したい方に向けて書いています。会計処理の基本的な考え方、判断の手順、事業計画への影響、よくある失敗を順に整理します。具体的な会計処理や税務の判断は、必ず公認会計士・税理士など専門家に確認してください。

ソフトウェア開発費の資産計上とは何か

資産計上とは、支出した金額をその期の費用にせず、貸借対照表に資産として載せ、利用期間にわたって少しずつ費用（減価償却費）にしていく処理です。ソフトウェアは目に見えない資産ですが、会計上は無形固定資産として扱われます。用語の基本はソフトウェアの資産計上の解説ページでも整理しています。

なぜこの区別が必要かというと、ソフトウェアは一度作れば複数年にわたって事業に貢献するからです。その期にすべて費用にすると、開発した年だけ大きな赤字が出て、以降の年は利益が過大に見えます。資産として計上し利用期間に配分すれば、費用と収益の対応関係が実態に近づきます。

一方で、資産計上は「将来その支出が収益や費用削減につながる」という前提に立った処理です。前提が崩れれば、資産の価値を切り下げる処理（減損や除却）が必要になります。新規事業は前提が崩れやすいため、ここが既存事業のシステム投資と大きく違う点です。

減価償却と減損の基本

資産計上したソフトウェアは、利用できる期間にわたって毎期少しずつ費用に振り替えます。これが減価償却です。会計上は利用可能期間を見積もって償却し、税務上は用途ごとに耐用年数が定められているため、両者の期間が異なる場合は調整が必要になります。

減損は、資産から将来得られる収益が帳簿上の価値を下回ると見込まれるときに、その差額を損失として計上する処理です。サービスの利用が想定を大きく下回った、事業の方針転換で使わなくなった、といった場面が典型です。使わなくなったソフトウェアを廃棄する場合は除却として、残っている帳簿価額を一度に損失にします。新規事業では、ピボットによってそれまでの開発資産の多くが使われなくなることがあるため、資産計上した金額が大きいほど、この一度の損失も大きくなります。

自社利用と販売目的で処理の考え方が分かれる

日本の会計基準では、ソフトウェアは取得や制作の目的によって大きく分類され、目的ごとに処理の考え方が異なります。新規事業でよく出てくる分類を整理すると次のようになります。

ここで多くの人が戸惑うのが、自社で運営するSaaSやWebサービスの扱いです。ソフトウェアそのものを販売するのではなく、ソフトウェアを使ってサービスを提供し利用料を受け取る形なので、一般的には自社利用のソフトウェアとして扱われます。そして自社利用の場合、資産計上の条件は「将来の収益獲得または費用削減が確実であること」です。

新規事業は、まさにこの「確実かどうか」が分からない段階から始まります。そのため、事業の初期段階での開発費は資産計上の要件を満たさず、費用として処理されることが少なくありません。逆に、需要が確認され、契約や利用の実績が積み上がった段階での機能開発は、資産計上の対象になり得ます。どの時点で何をもって「確実」と判断するかは、会社の方針と根拠資料によって決まるため、専門家との相談が欠かせません。

なお、外部の開発会社に作ってもらう場合も、社内で開発する場合も、考え方の軸は同じです。違いが出るのは、どの支出がソフトウェアの取得や制作にかかったものかを示す証拠の残り方です。外部発注なら見積書・契約書・請求書が証拠になりますが、社内開発では工数記録が唯一の手がかりになることが多く、記録がなければ判断のしようがありません。また、クラウドサービスの利用料のように、ソフトウェアを所有せず使うだけの支出は、通常は利用した期の費用として扱われます。

開発の段階ごとに支出の性質を見る

同じプロジェクトの中でも、支出の性質は段階によって変わります。開発費をひとまとめにせず、段階ごとに分けて考えると判断しやすくなります。

構想・調査の段階

市場調査、顧客へのヒアリング、事業計画の作成、要件の検討などです。この段階の支出はソフトウェアそのものの制作ではないため、通常は費用として処理されます。

技術検証・試作の段階

新しい技術が使えるかを確かめるPoCや、仕様を固めるための試作です。研究開発の性質が強く、費用として処理されることが一般的です。MVPのように顧客の反応を確かめる目的の開発も、事業の確実性がまだ低い段階では費用処理になることが多いでしょう。

本格開発の段階

需要が確認され、サービスとして提供するための開発を進める段階です。自社利用のソフトウェアとして資産計上の要件を満たすかどうかが検討の中心になります。

運用・改善の段階

リリース後の保守、不具合の修正、小さな改善は、通常は発生した期の費用です。一方、機能を大きく追加して価値を高めるような開発は、資産計上の対象として検討されることがあります。どこまでが保守でどこからが機能追加かは、社内で基準を決めておく必要があります。

資産計上が事業計画と投資判断に与える影響

資産計上か費用処理かは、事業の実態（現金の出入り）を変えるものではありません。開発会社に支払う現金の額とタイミングは同じです。変わるのは損益計算書の見え方で、それが社内の評価や判断に影響します。

新規事業でよくあるのが、初年度の赤字を小さく見せるために資産計上を前提にした計画を作り、事業がうまくいかずに撤退する際、残った資産を一度に損失として計上することになる、というパターンです。撤退の判断そのものが、この一度の損失を嫌って先延ばしになることもあります。

だからこそ、新規事業の投資判断は損益ではなく現金の出入り（キャッシュフロー）で行い、会計処理はその結果の見せ方として別に扱うのが基本です。開発費と回収の見方はシステム開発を伴う新規事業の投資判断で詳しく解説しています。事業計画の収益モデルの組み方はSaaS事業計画の収益モデルの作り方も参考にしてください。

開発費の処理を決めるまでの手順

開発費の処理は、プロジェクトが始まってから慌てて決めるものではありません。次の順序で、着手前に方針を固めておきます。

1. ソフトウェアの目的を整理する。 自社で運営するサービスか、販売するソフトウェアか、社内業務用か、受託として作るものかを明確にします。複数の目的が混ざる場合は、その旨も書き出します。
2. 開発の段階を区切る。 構想、技術検証、MVP、本格開発、運用改善のように段階を分け、それぞれの開始と終了の目安を決めます。
3. 経理部門・税理士に相談する。 目的と段階の整理を持って、どの段階の支出をどう処理する方針かを相談します。会社としての会計方針がすでにある場合は、それに沿っているかを確認します。
4. 見積もりと発注を段階ごとに分ける。 開発会社の見積もりや請求が一括だと、後から段階ごとに切り分けるのが難しくなります。可能な範囲で段階ごとに見積もり・契約・請求を分けます。
5. 根拠資料を残す。 事業の確実性を示す資料（顧客の契約、利用状況、収益の見込みなど）や、開発内容が保守か機能追加かを判断した記録を残します。
6. 事業計画に反映する。 損益計画とキャッシュフロー計画の両方に、処理方針に沿った数字を入れます。減価償却の期間や、撤退時の損失の可能性も書き込みます。
7. 定期的に見直す。 事業の状況が変われば、資産の価値も変わります。少なくとも決算の前には、資産計上したソフトウェアが今後も使われる見込みかを確認します。

経理・税理士に相談するときに持っていく資料

相談の場で「詳しいことが分からないので判断できない」と言われないよう、次の資料をそろえておくと話が早く進みます。

• 事業の概要と収益モデル。 誰に何をいくらで提供するのか、売上はどう立つのかを一枚にまとめたもの。
• 開発の段階と範囲の一覧。 段階ごとに作る機能、期間、外部への支払い見込み、社内の関与人数を並べた表。
• 開発会社の見積書と契約書の案。 段階ごとに分かれているか、保守と開発が分かれているかを確認してもらいます。
• 事業の確実性を示す材料。 顧客のヒアリング記録、試験利用の結果、受注や申込みの状況など、現時点で手元にあるもの。
• 撤退や方針転換の条件。 どんな状況になったら事業をやめるのか、または方向を変えるのか。資産計上した場合の損失の見積もりに使います。

これらは会計処理のためだけでなく、経営層への説明や開発会社との交渉にもそのまま使えます。会計の相談を、事業計画の解像度を上げる機会として使うと無駄がありません。

具体的な場面の例：社内ベンチャーが会員制サービスを立ち上げる場合

架空の一般例で考えます。ある中堅企業の新規事業チームが、既存顧客向けの会員制Webサービスを立ち上げることになりました。最初の半年でMVPを作って顧客の反応を確かめ、手応えがあれば本格開発に進む計画です。

チームの当初の事業計画では、開発費の全額を資産計上し、利用期間で償却する前提になっていました。初年度の赤字を小さく見せられるため、社内の承認が通りやすいという考えです。しかし、計画を経理部門に共有したところ、「MVPの段階ではまだ収益の確実性を示す根拠がなく、資産計上は難しい可能性が高い」と指摘を受けました。

そこでチームは計画を見直し、MVPまでの開発費は費用として処理する前提で初年度の損益を作り直しました。あわせて、本格開発に進む判断の条件として「一定数の有料契約が成立していること」を定め、その条件を満たした段階の開発については、経理部門・監査法人と相談のうえで資産計上を検討する方針にしました。開発会社への発注も、MVPと本格開発で契約を分けています。

結果として初年度の赤字は大きく見えますが、経営層にはキャッシュフローの見通しと段階ごとの判断条件を合わせて説明したため、承認は得られました。何より、MVPの結果が思わしくなく撤退することになっても、資産の除却による追加の損失を心配する必要がなくなりました。

この例から分かるのは、会計処理の方針を決める作業が、そのまま「本格開発に進む条件は何か」という事業の判断基準を決める作業になっているということです。資産計上できるかどうかを考えると、事業の確実性を何で示すのかを言葉にせざるを得なくなります。その問いに答えられないうちは、まだ本格開発に大きな資金を投じる段階ではない、と読み替えることもできます。

よくある失敗とその避け方

ソフトウェア開発費の扱いで、新規事業がつまずきやすい点をまとめます。

• 資産計上を前提に事業計画を作り、承認後に処理が認められない。 計画の段階で経理部門に確認し、費用処理になった場合の損益も並べておきます。
• 開発会社からの請求が一括で、段階の切り分けができない。 見積もり・契約・請求を段階ごとに分けるよう、発注の時点で開発会社と取り決めます。
• 保守と機能追加の区別があいまいなまま処理している。 社内で判断の基準を文書にし、案件ごとに判断の記録を残します。
• 撤退時の除却損を嫌って撤退判断が遅れる。 撤退の判断は会計上の損失ではなく、今後の現金の出入りで行うことを、事業開始時に経営層と合意しておきます。
• 社内の人件費の扱いを忘れる。 外部への支払いだけでなく、社内のエンジニアやプロダクト担当者が開発に関わった時間の扱いも論点になります。資産計上の対象にするなら、誰がどの開発にどれだけの時間を使ったかを後から示せなければなりません。プロジェクトの途中から記録を始めても過去の分は再現できないため、着手と同時に工数の記録方法を決めます。
• 税務と会計を同じものだと考える。 会計上の処理と税務上の扱いは必ずしも一致しません。法人税の計算での扱いは税理士に確認します。

着手前に確認したいチェックリスト

• 開発するソフトウェアの目的（自社利用・販売・社内業務・受託）が整理されている
• 開発の段階と、それぞれの開始・終了の目安が決まっている
• 経理部門または税理士・会計士に処理方針を相談した
• 見積もり・契約・請求を段階ごとに分けられる発注になっている
• 事業の確実性を示す根拠資料を残す方法が決まっている
• 保守と機能追加を区別する社内基準がある
• 社内人件費の工数を記録する方法が決まっている
• 損益計画とキャッシュフロー計画の両方を作っている
• 撤退時の損失の可能性を事業計画に書き込んでいる

よくある質問

Q. MVPの開発費は資産計上できますか？

一概には言えませんが、MVPは顧客の反応を確かめるための開発であり、その時点では将来の収益の確実性を示す根拠が乏しいことが多いため、費用として処理されるケースが少なくありません。会社の会計方針や事業の状況によって判断が変わるため、経理部門や会計士に確認してください。

Q. 資産計上したほうが会社にとって得なのですか？

現金の出入りは変わらないため、損得の問題ではありません。資産計上すると開発した年の損益は良く見えますが、翌年以降に減価償却費がかかり、事業が不調になれば減損や除却で一度に損失が出ることがあります。事業の実態に合った処理を選ぶことが大切です。

Q. SaaSの開発費は販売目的のソフトウェアになりますか？

自社でSaaSを運営し利用料を受け取る形であれば、一般的には自社利用のソフトウェアとして扱われます。ソフトウェアそのものをライセンス販売する場合とは考え方が異なります。提供形態が複合的な場合は専門家に相談してください。

Q. 会計基準が変わることはありますか？

会計基準や税制は見直されることがあります。ソフトウェアや無形資産の扱いについても議論が続いているため、計画を立てる時点で最新の基準を専門家や公的な情報源で確認してください。

Otsumuに相談できること

開発費の会計処理そのものは、経理部門と会計士・税理士が判断する領域です。社内に経理の体制があり、事業の目的と開発の段階が明確になっているなら、まずは社内で相談を進めるのが最短の道です。外部のコンサルタントに頼む必要はありません。

ただ、実際に相談の場で困るのは、会計の知識よりも「この開発はどの段階なのか」「事業の確実性を何で示すのか」「どこまでをMVPとして作り、どこから本格開発とするのか」といった事業側の整理が追いついていないことです。事業計画と開発計画がつながっていない状態では、経理部門も判断の材料を持てません。

Otsumuは、自らも事業を手がける実践者として、新規事業開発コンサルティングで事業の仮説と検証の段階を整理し、段階ごとの開発範囲と判断条件を決めるお手伝いをしています。検証段階の開発が必要になれば、新規事業の爆速MVPシステム開発で、目的から逆算して必要な機能に絞った開発を短期間で進めることもできます。顧客の需要を確かめる段階であれば、顧客検証 Sprint（98万円〜・税別、4週間）のように、開発に入る前の検証から始める方法もあります。

事業計画と開発の段階の切り方に迷っている段階でも構いません。30分の無料相談で、現在の計画を一緒に確認します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01