ソフトウェア事業者にとって、開発費の処理は決算書と納税額に直接影響する重要論点です。しかし、ソフトウェア開発費の処理は【受注制作・市場販売目的・自社利用】という3つの区分で扱いが大きく異なり、しかも会計基準と税務上の取扱いに微妙な差異があるため、判断を誤ると税務調査での指摘につながりかねません。
本記事では、ソフトウェア開発費の3区分とそれぞれの処理方法を、実務上の具体例を交えて整理してまいります。
ソフトウェア開発費の3つの区分
ソフトウェア開発費の会計処理は、「研究開発費等に係る会計基準」および日本公認会計士協会の実務指針において、制作目的別に3つに区分されています。それぞれ将来の収益との対応関係が異なるため、処理方法も変わります。
区分①|受注制作のソフトウェア
特定のユーザーから依頼を受けて開発し、納品するソフトウェアです。SIerやシステム開発会社が顧客の要望に沿って構築する業務システムなどが該当します。
| 項目 | 処理方法 |
|---|---|
| 制作中の費用の集計先 | 仕掛品(棚卸資産) |
| 売上計上 | 完成基準または進行基準(現在は収益認識基準のステップに従って判定) |
| 無形固定資産への計上 | 制作者側では計上しない |
【受注制作の場合、ソフトウェアそのものは納品によって顧客側に移転する】ため、制作者側で無形固定資産として計上することはありません。発生した費用は仕掛品として集計し、納品時に売上原価として計上します。
区分②|市場販売目的のソフトウェア
不特定多数のユーザーへの販売を目的として開発するソフトウェアです。パッケージソフトとして販売する会計ソフト・販売管理ソフトなどが該当します。
会計上の処理は以下のとおりです(研究開発費等に係る会計基準・実務指針)。
| 開発フェーズ | 会計処理 |
|---|---|
| 研究開発フェーズ(最初に製品化された製品マスター完成前) | 研究開発費として費用処理 |
| 製品マスター完成後の制作費 | 無形固定資産(ソフトウェア)として資産計上 |
| 機能維持・バグ取り等の支出 | 費用処理 |
| 著しい改良に該当しない機能追加 | 資本的支出としてソフトウェアに加算 |
| 著しい改良に要した費用 | 研究開発費として費用処理 |
判定の境目となるのが【最初に製品化された製品マスターの完成時点】です。具体的には、「製品性を判断できる程度のプロトタイプの完成」、または「販売するための重要な機能の完成と重要な不具合の解消」が判定基準とされています。
なお、市場販売目的のソフトウェアについても【会計と税務で処理が異なる場面】があります。詳細は後述の差異セクションで整理します。
区分③|自社利用のソフトウェア
自社で利用する目的で開発・購入するソフトウェアです。社内業務効率化のためのシステムが該当します。SaaS事業のクラウド基盤として提供するソフトウェアも、自社利用目的に該当することが多いものの、サービスの設計や事業実態によっては市場販売目的とみなされる場合もあるため、自社の状況に即して判定が必要です(後述)。
| 状況 | 会計処理 |
|---|---|
| 将来の収益獲得・費用削減が確実 | 無形固定資産として資産計上 |
| 将来の収益獲得・費用削減が不明 | 会計上は費用処理/税務上は原則として資産計上 |
| 将来の収益獲得・費用削減にならないことが明らか | 費用処理(研究開発費) |
【「不明」な場合に会計と税務で処理が分かれる】点が、この区分の最大の論点です。詳しくは後述します。
SaaS事業の会計区分は会社により分かれる
SaaS事業のソフトウェア開発費は、会社の業態・サービス設計により、自社利用目的・市場販売目的・受注制作との複合のいずれにも該当し得ます。日本公認会計士協会のIT委員会研究報告等でも、SaaS事業者の会計処理は実務上分かれているのが実態として示されています。
| 該当しやすい分類 | 該当条件の傾向 |
|---|---|
| 自社利用目的 | クラウド基盤を自社で運営し、サービス利用料を得る一般的なSaaS |
| 市場販売目的 | パッケージソフトに近い形でユーザーに製品を提供するSaaS |
| 受注制作との複合 | エンタープライズSaaSで顧客ごとの個別カスタマイズ部分が大きい場合 |
【「SaaSだから自社利用目的」と機械的に判断しない】ことが重要です。サービスの本質と契約形態を踏まえて、適切な区分を選択する必要があります。
会計と税務の取扱いの差異
ソフトウェア開発費の処理で多くの事業者がつまずくのが、会計基準と税務上の取扱いの差異です。
自社利用ソフトウェアにおける考え方の違い
自社利用ソフトウェアの資産認識について、会計と税務は次のように考え方が異なります。
| 区分 | 考え方 | 処理 |
|---|---|---|
| 会計(保守的) | 将来の収益獲得・費用削減が【確実】となった段階で資産認識 | 確実になるまでは研究開発費として費用処理 |
| 税務(積極的) | 将来の収益獲得・費用削減が【明らかにならないことが確実】な場合のみ費用処理 | それ以外は原則として資産計上 |
会計は「確実か否か」を基準に保守的に判定するのに対し、税務は「明らかに収益獲得・費用削減にならないとは言えない」場合は資産として認識する積極的な考え方を取ります。
【税務調査の実務では、自社利用ソフトウェアの判断について税務署側から「資産計上すべき」と是正指摘を受けるケースが増えている】ため、特に注意が必要です。
「研究開発費」と「試験研究費」と「開発費」は別概念
ソフトウェア開発費を扱う際に、よく混同される3つの用語を最初に整理しておきます。
| 用語 | 意味 | 会計/税務 |
|---|---|---|
| 研究開発費 | 会計基準上の用語。研究と開発のために発生する費用(費用処理) | 会計 |
| 試験研究費 | 税法上の用語。研究開発税制の対象となる費用 | 税務 |
| 開発費(繰延資産) | 新技術採用・市場開拓等の【特別な支出】(繰延資産扱い) | 会計・税務共通 |
この3つは似ていますが、それぞれ異なる概念です。【ソフトウェアの通常の開発活動は、繰延資産の「開発費」には該当しません】。ソフトウェア事業者が押さえるべきは、会計上の「研究開発費」と税務上の「試験研究費」の使い分けです。
会計上の研究開発費と税務上の試験研究費は範囲が違う
両者は重なる部分が多いものの、範囲は完全に一致しません。実務上意識すべき主な差異は以下のとおりです。
| 項目 | 会計(研究開発費) | 税務(試験研究費) |
|---|---|---|
| 既存ソフトの「著しい改良」 | 含まれる | 含まれる |
| 既存ソフトの【通常の改良】 | 含まれない | 含まれる可能性 |
| バグ取り・機能維持 | 含まれない | 含まれない |
【会計上は研究開発費に該当しなくても、税務上は試験研究費として税額控除の対象になる費用がある】点が、ソフトウェア事業者にとって特に重要です。
上場準備中の企業は二重対応が必要
会計監査を受ける企業(上場準備中含む)は、会計基準に準拠した決算書を作成したうえで、税務申告書上で会計と税務の差異を調整する必要があります。具体的には別表での申告調整が発生します。
会計監査を受けない中小企業の実務上の対応
非上場かつ非大会社の場合、通常は会計監査を受けないため、税法基準で会計処理を行うのが実務上の基本となります。この場合、税務上の「将来の収益獲得・費用削減にならないことが明らかな場合のみ費用処理、それ以外は資産計上」というルールに従うことになります。
つまり、中小ソフトウェア事業者の多くは、迷ったら【資産計上を選択するのが税務リスクを避ける現実的な対応】となります。
市場販売目的ソフトウェアにおける考え方の違い
市場販売目的のソフトウェアについても、会計と税務で処理が異なる場面があります。
| 論点 | 会計 | 税務 |
|---|---|---|
| 製品マスター完成までの費用 | 研究開発費(費用処理) | 研究開発費に該当する部分以外は取得価額算入が原則 |
| 「著しい改良」に要した費用 | 研究開発費(費用処理) | 将来の収益獲得・費用削減にならないことが明らかな場合以外は資本的支出 |
| 著しい改良に該当しない機能改良費用 | 資産計上 | 資本的支出として資産計上(処理は概ね一致) |
【会計上は研究開発費として費用処理した「著しい改良」が、税務上は資産計上を求められる】可能性があります。会計監査を受ける企業の場合は別表で加算調整を行います。中小企業で会計監査を受けない場合は、税法基準に従って当初から資産計上する処理が現実的です。
「製品マスター完成」をどう実証するか
市場販売目的ソフトウェアでは、研究開発フェーズと制作フェーズの境目(製品マスター完成時点)を客観的に説明できる証憑が、税務調査で重要となります。原価管理台帳・社内稟議書・作業完了報告書・業務日報・プロトタイプの仕様書などを整備しておくと、製品マスター完成までの費用を研究開発費として処理する妥当性を税務調査でも説明しやすくなります。
取得価額の算定方法
ソフトウェアを資産計上する場合の取得価額の算定方法を、法人税基本通達7-3-15の2と7-3-15の3に基づいて整理します。
自己制作ソフトウェアの取得価額
自己制作(自社開発)の場合、以下の項目を取得価額に算入します。
| 算入する項目 | 内容 |
|---|---|
| 原材料費 | 制作に要した原材料費 |
| 労務費 | 開発担当者・PM・プロジェクトリーダーの人件費 |
| 経費 | その他制作に要した経費 |
| 直接費用 | 事業の用に供するために直接要した費用 |
【労務費にはコーディング担当者だけでなく、プロジェクトマネージャーやリーダーの人件費も含まれる】点が見落とされがちです。設計レビュー・進捗会議・要件定義など、プロジェクトに関連する会議参加時間も労務費の対象です。
一方で、以下の作業時間は取得価額に含まれません。
| 取得価額に含めない時間 | 内容 |
|---|---|
| 社内研修・自己学習 | スキル向上のための時間 |
| 他プロジェクトの応援 | 当該プロジェクト外の業務 |
| 全社会議・採用活動 | プロジェクトに無関係な活動 |
| 企画検討段階のコスト | プロジェクト稟議承認前の検討時間 |
合理的な配賦基準で継続適用すれば税務上認められる
法人税基本通達7-3-15の2の後段では、【合理的であると認められる方法により継続して計算している場合】には、原価計算の方法が認められると規定されています。すべての作業時間を完璧に区分する必要はなく、Backlog・Asana等の工数管理ツールでプロジェクトごとの作業時間を記録し、給与・賞与・法定福利費を稼働時間比で按分する方法を継続適用すれば、税務上認められます。プロジェクト外の時間(研修・全社会議等)は別カテゴリで集計し、PM・リーダーの業務はプロジェクト関連時間として直接労務費に算入します。
取得価額に算入しないことができる費用
法人税基本通達7-3-15の3により、以下の費用は取得価額に算入しないことができます。
| 費用 | 内容 |
|---|---|
| 仕損じが明らかな費用 | 製作計画の変更等で不要となった費用 |
| 研究開発費 | 自社利用については将来の収益獲得・費用削減にならないことが明らかなものに限る |
| 少額の間接費・付随費用 | 製作原価のおおむね3%以内の金額 |
耐用年数と減価償却の実務
ソフトウェアを資産計上した後は、定められた耐用年数で減価償却を行います。
利用目的別の耐用年数
| 利用目的 | 耐用年数 |
|---|---|
| 複写して販売するための原本(製品マスター) | 3年 |
| 自社利用のソフトウェア | 5年 |
| 開発研究用のソフトウェア | 3年 |
国税庁の「No.5461 ソフトウエアの取得価額と耐用年数」に明記されています。
償却方法
ソフトウェアの減価償却は、原則として【定額法】によります。市場販売目的のソフトウェアについては、実務指針上は見込販売収益(数量)に基づく減価償却も認められていますが、税務上は定額法での計算が基本となります。
ソフトウェア仮勘定の活用
開発期間中の費用は、いったん「ソフトウェア仮勘定」として無形固定資産の仮勘定に集計します。完成・事業供用開始時点で、ソフトウェア仮勘定からソフトウェア(本勘定)へ振り替え、減価償却を開始します。
具体的な仕訳例は以下のとおりです。
(開発期間中:制作費用の集計)
ソフトウェア仮勘定 500,000 / 普通預金 500,000
(完成・事業供用開始時)
ソフトウェア 6,000,000 / ソフトウェア仮勘定 6,000,000
(事業供用開始月から減価償却:自社利用、定額法5年)
減価償却費 100,000 / ソフトウェア 100,000
(6,000,000 ÷ 60か月 = 100,000円/月)
バージョンアップ・改修時の処理
既存ソフトウェアに対する支出は、その性質によって処理が分かれます。
| 支出の性質 | 処理 |
|---|---|
| 機能維持・保守・障害除去のための支出 | 修繕費として費用処理 |
| 新たな機能追加・機能向上のための支出 | 資本的支出としてソフトウェアに加算 |
| 著しい改良 | 会計上は研究開発費/税務上は将来の収益獲得・費用削減にならないことが明らかな場合以外は資本的支出 |
「著しい改良」の判定はグレーゾーンになりやすく、税務調査でも論点となりやすい部分です。バージョンアップの企画書や仕様書には、改修内容を具体的に記録しておくことが重要です。
税務調査で指摘されやすいポイント
ソフトウェア開発費に関する税務調査では、以下のような点が頻繁に指摘されます。
指摘①|費用処理した開発費の資産計上漏れ
最も頻発するのが、自社利用ソフトウェアを費用処理していたが、税務調査で「将来の収益獲得・費用削減が見込まれる」として資産計上を求められるケースです。
判定の根拠となる証憑として、社内稟議書、制作原価管理台帳、作業完了報告書、サービス開始日を示す資料といった書類を必ず整備しておきましょう。【見積書や稟議書に「開発」「構築」「要件定義」等のキーワードが記載されていれば、税務はその実態を確認します】。仕訳の摘要だけで資産性を判断できないことを踏まえ、書類を整理しておく必要があります。
指摘②|人件費の取得価額算入漏れ
自己制作ソフトウェアの取得価額に、開発担当者の人件費が算入されていないケースです。工数管理ツールで開発時間を記録し、適切に労務費を取得価額に振り替える運用が必要です。
指摘③|バージョンアップ費用の処理誤り
バージョンアップ費用を一律「保守料」として費用処理してしまうケースです。新機能追加に該当する部分は資本的支出として資産計上が必要となります。
指摘④|事業供用開始時期の判定誤り
ソフトウェアの事業供用開始時期を遅く判定し、減価償却の開始を遅らせるケースは、過大計上として問題となります。サービスの公開日や社内利用開始日を客観的に証明できる資料を残しておきましょう。
まとめ|3区分の判定と書類整備が処理の核
ソフトウェア開発費の処理は、まず【受注制作・市場販売目的・自社利用】の3区分を正確に判定することから始まります。区分が決まれば、それぞれの処理方法は会計基準と税務上のルールに従って機械的に進めることができます。
実務上の最大のポイントは、【書類の整備】です。社内稟議書・制作原価管理台帳・業務日報・作業完了報告書といった証憑が揃っていれば、税務調査でも自信を持って説明できます。会計と税務の差異を理解したうえで、開発プロジェクトの開始時点から書類整備を意識して処理を進めることが重要です。判
