ソフトウェア開発費の会計処理｜自社利用・受注制作・研究開発費をどう切り分けるか

結論：ソフトウェア開発費は「何のために作るか」で処理が変わる

ソフトウェア開発費の会計処理を考えるとき、最初に問うべきは金額でも開発手法でもなく「そのソフトウェアを何のために作るのか」という目的です。日本基準では、ソフトウェアの制作費を「受注制作のソフトウェア」「市場販売目的のソフトウェア」「自社利用のソフトウェア」の3つに区分し、区分ごとに異なる会計処理を適用します。受注制作は請負工事の会計処理に準じ、市場販売目的は「最初に製品化された製品マスター」の完成を境に費用処理と資産計上が切り替わり、自社利用は「将来の収益獲得又は費用削減が確実」と認められる場合に限り資産として計上します。この3区分の考え方の土台になっているのが、企業会計審議会が公表した「研究開発費等に係る会計基準」と、その実務上の具体的な取扱いを示す実務指針です。以下では、この3区分をそれぞれどう判断し、どこで研究開発費として費用処理し、どこから資産計上に切り替わるのかを、法人税法上の耐用年数や、クラウド（SaaS）利用料をめぐる近年の論点まで含めて整理していきます。支出が資産計上と費用処理のどちらになるかという、より広い意味での判断枠組みは修繕費・改良費を中心とした資本的支出の考え方とも共通するため、ソフトウェアに固有の論点に絞って解説する本記事とあわせて理解しておくと、支出全般の判断軸が一貫します。

ソフトウェアの3区分と会計処理の全体像

ソフトウェアの制作費をめぐる会計処理は、1998年3月に企業会計審議会が公表した「研究開発費等に係る会計基準」を出発点としています。この会計基準は、研究開発費について「発生時に全額を費用として処理しなければならない」という原則を定める一方、ソフトウェアの制作費については研究開発費とは別に、目的に応じた取扱いを定めています。具体的な適用にあたっての実務上の指針は、もともと日本公認会計士協会の会計制度委員会報告第12号「研究開発費及びソフトウェアの会計処理に関する実務指針」として公表され、その後の移管を経て、現在は企業会計基準委員会の移管指針第8号として存続しています。この実務指針が示す3区分と、それぞれの会計処理の骨格を整理すると次のとおりです。

ここで注意したいのは、SaaS企業が自社のプロダクトとして開発するソフトウェアの多くは「市場販売目的」ではなく「自社利用」に区分されるという点です。市場販売目的の区分は、顧客にソフトウェアの複製物（製品マスターのコピー）を販売するパッケージソフトを想定した区分であり、自社が保有し続けるソフトウェアをサービスとして提供するSaaS型のビジネスモデルでは、顧客はソフトウェアそのものを取得せず利用サービスを受けるだけであるため、開発したソフトウェア自体は自社が利用するソフトウェアという整理になります。この違いは、この記事の後半で扱うEBITDA分析にも直結する重要な前提です。

研究開発費とは何か——なぜ発生時に全額費用処理されるのか

「研究開発費等に係る会計基準」は、研究を「新しい知識の発見を目的とした計画的な調査及び探究」、開発を「新しい製品・サービス・生産方法についての計画若しくは設計又は既存の製品等を著しく改良するための計画若しくは設計として、研究の成果その他の知識を具体化すること」と定義しています。この定義に該当する活動から生じた費用は、金額の大小や社内での呼び方にかかわらず、発生した会計期間に全額を費用として処理しなければなりません。研究開発費とソフトウェアの資産計上の関係を理解するうえでの出発点になるのがこの原則です。

資産計上を認めない理由は明快です。研究開発活動は、それが将来の収益に結びつくかどうかが発生の時点では判然としません。開発が進み、実現の見込みが高まってきたとしても、完成や商業化が確実になったと言い切れる保証はなく、支出時点でその効果を資産として認識するのは会計上適当でないという考え方に立っています。この「将来の便益が確実かどうか」という物差しが、この後に見る市場販売目的・自社利用それぞれの資産計上の切り替えポイントを判断する際にも一貫して使われます。

受注制作のソフトウェア：請負工事の会計処理に準じる

顧客からの注文を受けて特定の仕様のソフトウェアを開発する受注制作の場合、制作費は請負工事の会計処理に準じて処理します。受注制作は、顧客との契約によって収益が確定しており、制作を行う企業にとっては研究開発のような「実現するかどうか分からない」不確実性が本質的には存在しないため、独立した会計処理の区分として整理されています。実務上は、進捗に応じて収益と原価を計上する方法や、完成・引渡し時点で一括して収益と原価を計上する方法があり、どちらを採用するかは契約の性質や進捗の合理的な見積り可能性によって判断されます。受注制作の収益認識そのものの詳細な会計処理（履行義務の識別や一時点認識・一定期間認識の判定）は、収益認識基準に関わる論点であり、本記事では取り上げているソフトウェアの3区分の中での位置づけに絞って解説しています。

市場販売目的のソフトウェア：「最初に製品化された製品マスター」の完成前後

市場販売目的のソフトウェアで実務上もっとも重要な判断ポイントは、「最初に製品化された製品マスター」がいつ完成したかという一点です。会計基準の注解には、最初に製品化された製品マスターの完成までの費用、および製品マスターや購入したソフトウェアに対する著しい改良に要した費用が研究開発費に該当すると明記されています。製品マスターとは、量産を前提とした複写可能な完成品の原本を指し、それ以前の段階、つまり企画・仕様検討・試作・要素技術の実証などは、まだ「販売できる製品」が存在しない不確実な段階であるため、研究開発費として発生時に費用処理します。

製品マスターが完成した後にかかる費用は、原則として無形固定資産として資産計上します。ただし、完成後の費用のすべてが自動的に資産計上されるわけではなく、単純なバグ取りや、製品の性能を維持するための機能維持は資産計上の対象になりますが、製品マスター自体に対する「著しい改良」に該当する費用は、完成後であっても研究開発費として費用処理に戻ります。つまり、製品マスターの完成という一つの時点を境に処理が単純に切り替わるのではなく、完成後も「著しい改良」に該当するかどうかという判断が続くという点が実務上見落とされやすいポイントです。

自社利用のソフトウェア：資産計上の判断基準と立証の考え方

自社利用のソフトウェアは、社内の基幹システムのように会社自身が業務で使うために制作するソフトウェアと、自社のサービスとして顧客に提供するプラットフォーム（SaaS型のプロダクトなど）の両方を含みます。この区分での資産計上の判断基準は一つで、「その利用により将来の収益獲得又は費用削減が確実であると認められる場合」に限り、ソフトウェアの制作費を資産として計上しなければならないというものです。逆に言えば、この確実性が認められない段階の費用は、研究開発費と同様に発生時の費用として処理します。

実務でこの判断基準を適用する際に難しいのは、「確実」であることをどう立証するかという点です。実務指針の考え方に沿うと、判断の根拠としては、ソフトウェアの制作予算が承認された社内稟議書や、原価を集計するための管理台帳といった、意思決定と原価集計の両方を裏付ける社内記録の有無が目安とされています。単に「将来役に立ちそうだ」という漠然とした期待だけでは資産計上の根拠として不十分であり、予算承認や原価管理の仕組みが実際に機能していることが前提になります。また、自社利用のソフトウェアであっても、新しい技術要素の実現可能性を検証するような研究開発的な性格の強い部分は、たとえ最終的に完成しても、その部分については研究開発費として費用処理する必要がある点にも注意が必要です。OPEX/CAPEX区分の考え方とあわせて理解しておくと、日々の開発関連支出をどちらに仕訳すべきかの整理がしやすくなります。

減価償却：耐用年数と償却方法

資産計上したソフトウェアは、無形固定資産として減価償却を行います。法人税法上の減価償却資産の耐用年数を定める省令では、ソフトウェアの法定耐用年数を「複写して販売するための原本又は研究開発用のもの」は3年、「その他のもの」は5年としています。自社利用のソフトウェアは通常この「その他のもの」に該当するため、5年で償却するのが一般的です。国税庁のタックスアンサーには、取得価額の考え方（購入の場合は購入代価に事業供用のための費用を加算、自社製作の場合は原材料費・労務費・経費を集計）もあわせて示されています。会計上の耐用年数は、税法上の法定耐用年数をそのまま使う実務が一般的ですが、実際の利用可能期間がそれより明らかに短いと見込まれる場合には、会計上の判断でより短い年数を採用することもあります。減価償却の方法や、Capexと減価償却の関係をより一般的な視点から理解したい場合は減価償却とCapexの実務｜「現金の出ない費用」を使いこなすを参照してください。また、減価償却費がPLとキャッシュフローにどう影響するかという基礎は、この記事とあわせて押さえておくと理解が深まります。なお、この耐用年数の定めは日本の法人税法に基づくものであり、会計上の償却年数（利用可能期間の見積り）とは別の概念である点、また日本基準とIFRSでは無形資産の会計処理にも違いがある点は日本基準とIFRSの実務差分｜分析で「効いてくる」違いだけを押さえるで扱っています。

クラウド（SaaS）利用料・カスタマイズ費用の会計処理の論点

ここまで見てきた3区分は、いずれも自社がソフトウェアという資産を保有することを前提にした整理です。一方、他社が提供するクラウドサービス（SaaS）を利用する側の企業では、話が変わります。ユーザー企業が支払うSaaSの月額・年額利用料は、ソフトウェアそのものを取得しているのではなく、ベンダーが保有するソフトウェアの利用サービスを受けている対価であるため、原則として発生に応じて費用処理します。この点は、自社利用のソフトウェアを自社で制作・保有する場合とは前提が異なることに注意が必要です。

実務上の論点になりやすいのは、SaaS導入時にかかる初期設定費用やカスタマイズ費用の扱いです。日本公認会計士協会が2022年6月に公表した会計制度委員会研究資料第7号「ソフトウェア制作費等に係る会計処理及び開示に関する研究資料～DX環境下におけるソフトウェア関連取引への対応～」では、こうしたクラウド関連取引の会計処理について、ソフトウェアそのものがオフバランス（ユーザー企業の資産にならない）である以上、支払時に一時の費用として処理すべきという考え方と、その費用が将来の便益をもたらす経済的資源に該当するのであれば資産性を検討する余地があるという考え方の両方があることが整理されています。実務では、初期設定・カスタマイズ費用を長期前払費用として計上し、契約期間にわたって償却するという処理も見られますが、明文の会計基準があるわけではなく、契約内容や費用の性質を個別に見て判断する必要がある領域です。SaaS企業自身の収益側の会計処理（Bookings・Billings・Revenueの違いや繰延収益の扱い）はSaaS企業の収益モデリング｜Bookings・Billings・Revenue・繰延収益のつながりを設例で組むで扱っているため、開発費側の本記事とあわせて読むと、SaaS企業のPLとBSの全体像がつながります。

数値設例：開発費の資産化率が営業利益とEBITDAに与える影響

以下は説明用の仮設例です。前節で見たとおり、SaaS企業が自社プロダクトのために投じる開発費の多くは「自社利用のソフトウェア」の区分に入り、資産計上するかどうかは「将来の収益獲得又は費用削減が確実」という基準に照らした会社ごとの判断に委ねられます。同じ開発活動でも、この判断基準の当てはめ方（どこまでを資産化の対象と見るか）によって、当期の営業利益とEBITDAの見え方は大きく変わります。SaaS財務モデルを分析する際には、この会計方針の違いを踏まえて数値を読む必要があります。

仮設のSaaS企業（A社）を想定します。売上高は年間5,000百万円、ソフトウェア開発費と減価償却費を除くその他の費用（原価・販管費）は年間3,800百万円、当期のソフトウェア開発費（人件費中心）は600百万円、過去に資産計上済みのソフトウェアに係る当期の償却費は資産化方針にかかわらず一律150百万円とします。この600百万円のうち何割を資産計上するかについて、「保守的方針」（資産化率20%）と「積極的方針」（資産化率60%）の2通りを比較します。

式：当期の費用処理額と営業利益
費用処理額＝開発費600百万円×（1−資産化率）
営業利益＝売上高5,000百万円−その他費用3,800百万円−費用処理額
EBITDA＝営業利益＋既存資産の償却費150百万円

同じ600百万円の開発活動、同じ売上高であるにもかかわらず、資産化率の違いだけで営業利益率は14.4%対19.2%、EBITDA率は17.4%対22.2%と、いずれも5ポイント近い差が生まれます。これは会社の実態が異なるからではなく、当期にどれだけの開発費をいったん資産として計上し、費用化を将来に繰り延べたかという会計方針の違いによるものです。ここで見落とされがちなのが、この差はEBITDAの段階でも解消しないという点です。当期に新たに資産計上した金額はまだ償却が始まっていないため、営業利益とEBITDAのどちらにも当期はプラスの効果として残ります。差が縮み始めるのは翌期以降、新たに資産計上した金額の減価償却が始まってからです。前節の耐用年数（5年・定額法）で計算すると、保守的方針の120百万円は年24百万円、積極的方針の360百万円は年72百万円の追加償却費が翌期以降に発生し、その差は年48百万円です。この追加償却費は営業利益を押し下げますが、EBITDAの計算では償却費として足し戻されるため、EBITDAへの影響はありません。つまり、開発費の資産化率の違いは、当期の営業利益・EBITDAの両方に効いたあと、翌期以降は営業利益にだけ効き続けるという時間差のある構造になっています。SaaS企業を分析する際、開発費の資産化率が他社と大きく異なる会社をEV/EBITDA倍率などで単純比較すると、この会計方針の差を実態の収益力の差と誤読するおそれがあるため、有価証券報告書の会計方針注記でどの程度の開発費を資産計上しているかを確認したうえで数値を読むことが欠かせません。EBITDAを分析目的で調整する際の一般的な考え方はEBITDAの正常化調整（Adjusted EBITDA）｜どこまで足し戻してよいかで扱っています。

よくある質問（FAQ）

Q. SaaS企業が自社開発するプロダクトは「市場販売目的」と「自社利用」のどちらに区分されますか。
A. 一般的には「自社利用のソフトウェア」に区分されます。市場販売目的の区分は、顧客にソフトウェアの複製物（製品マスターのコピー）を販売するパッケージソフトを想定しており、顧客が利用サービスを受けるだけでソフトウェア自体は自社が保有し続けるSaaS型のビジネスモデルとは前提が異なるためです。

Q. 自社利用ソフトウェアの資産計上は「開発を始めた時点」から可能ですか。
A. いいえ。開発を始めた時点ではなく、「将来の収益獲得又は費用削減が確実であると認められる」状況になった時点から資産計上の対象になります。それ以前の、実現するかどうかが不確実な段階の費用は研究開発費として費用処理します。

Q. クラウド（SaaS）の利用料は資産計上できますか。
A. ソフトウェアそのものを取得するのではなくサービスの提供を受けているため、利用料自体は原則として発生に応じて費用処理します。初期設定費用やカスタマイズ費用については資産性を検討する余地があるとする考え方もありますが、明文の会計基準があるわけではなく、契約内容に応じた個別の判断が必要です。

Q. ソフトウェアの耐用年数はすべて5年ですか。
A. いいえ。国税庁のタックスアンサーでは、複写して販売するための原本または研究開発用のものは3年、それ以外（自社利用のソフトウェアなど）は5年とされています。

まとめ

ソフトウェア開発費の会計処理は、「受注制作」「市場販売目的」「自社利用」という目的別の3区分を出発点に考える必要があります。受注制作は請負工事の会計処理に準じ、市場販売目的は「最初に製品化された製品マスター」の完成を境に研究開発費から資産計上へ切り替わり、完成後も著しい改良は研究開発費に戻ります。自社利用のソフトウェアは「将来の収益獲得又は費用削減が確実」という基準に照らして資産計上の可否を判断し、耐用年数は法人税法上原則5年です。SaaS企業の分析では、この資産化率の違いが同じ開発活動でも営業利益とEBITDAの見え方を大きく変えるため、有価証券報告書の会計方針注記を確認したうえで数値を比較する視点が欠かせません。

出典・参考（2026年8月確認）

• 企業会計審議会「研究開発費等に係る会計基準」（平成10年3月13日公表、平成11年4月1日以後開始事業年度から実施）（fsa.go.jp）
• 日本公認会計士協会「研究開発費及びソフトウェアの会計処理に関する実務指針について」（もとは会計制度委員会報告第12号、平成11年3月31日発行・平成23年3月29日改正、現在は企業会計基準委員会の移管指針第8号として存続）（jicpa.or.jp）
• 日本公認会計士協会 会計制度委員会研究資料第7号「ソフトウェア制作費等に係る会計処理及び開示に関する研究資料～DX環境下におけるソフトウェア関連取引への対応～」（2022年6月30日公表）（jicpa.or.jp）
• 国税庁 タックスアンサー No.5461「ソフトウエアの取得価額と耐用年数」（nta.go.jp）

※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための仮設例です。