システム開発費は経費？ソフトウェア資産計上・研究開発費・改修費を税理士が解説

その1,500万円が何のための支出なのかを確認する必要があります。

実際に会社で使用する業務システムを完成させるための開発費であれば、

原則としてソフトウェアの取得価額

になります。

「外注費」という請求書の科目名だけで、その年の経費になるわけではありません。

はい。

税務上、ソフトウェアは無形固定資産である減価償却資産です。

会社が自ら製作したソフトウェアについては、

原材料費

労務費

その他の経費

事業で使用するため直接要した費用

を合計したものが原則として取得価額になります。

外注か内製かで決まるわけではありません。

例えば開発会社へ、

・要件に基づく設計
・プログラミング
・データベース構築
・画面開発
・テスト
・導入設定

などを委託し、最終的に会社が使用するシステムが完成するのであれば、その開発費は原則としてソフトウェアの取得価額を構成します。

勘定科目や請求書名ではなく、支出の実質で判断します。

「業務委託費」

「外注費」

「開発費」

という名前だけで一括経費にはできません。

自社製作のソフトウェアについては注意が必要です。

法人税法施行令と法人税基本通達では、ソフトウェアの製作に要した労務費も取得価額に含めることとされています。

例えばエンジニアが半年間、新しい業務システムの開発に専属で従事していたのであれば、その開発に直接対応する人件費はソフトウェアの取得価額に含める方向になります。

税務上取得価額に含めるべき直接労務費であれば、給与として支払ったという理由だけで全額当期費用にはできません。

決算時に開発プロジェクトへ直接対応する金額を合理的に集計し、ソフトウェアの取得価額へ反映する必要があります。

全部ではありません。

新しいソフトウェアの製作に直接対応する部分を合理的に集計します。

例えば、

・タイムシート
・プロジェクト別工数
・開発チケット
・作業日報
・Git等の開発履歴
・プロジェクト管理ツール

などを使って開発工数を把握しておくと説明しやすくなります。

合理的な工数管理に基づくのであれば、そのような考え方になります。

重要なのは、

後から利益に合わせて適当な割合を作らないこと

です。

普段から工数を記録しておく方が安全です。

自社製作ソフトウェアは、適正な原価計算に基づいて取得価額を算定するのが原則です。

一方、法人税基本通達では、製作等のための間接費・付随費等について、

合計額が製作原価のおおむね3％以内の少額なもの

であれば、取得価額に算入しないことができる取扱いがあります。

ですから、直接開発費と少額な間接費は分けて考えます。

自社利用ソフトウェアについては、その説明だけでは足りません。

ここは会計と税務を混同しやすいところです。

税務上、自社利用ソフトウェアの研究開発費について取得価額から外せるのは、

そのソフトウェアを利用しても、将来の収益獲得または費用削減にならないことが明らかな場合

に限られています。

そこが重要です。

国税庁は、

将来の収益獲得・費用削減になるかどうか不明なものについても、税務上は取得価額に算入する

と説明しています。

ですから、

「まだ成功するか分からない」

「まだ研究中」

というだけで全部費用処理できるわけではありません。

そこが会計と法人税で違うところです。

国税庁自身も、企業会計では将来の収益獲得・費用削減が確実でない、または不明な場合に費用処理されることがある一方、

税務では、

「効果がないことが明らか」な場合を除き、取得価額へ算入する

と説明しています。

そのため、

会計上費用＝税務上もそのまま損金

とは限りません。

個別判断ですが、完成する業務システムそのものを作る作業と、本当に独立した研究・技術検証は分けて考える必要があります。

例えば、

・技術的に実現できるかを確認するためだけの検証
・採用しなかった方式の実験
・完成システムに組み込まれず不要となった検証プログラム

などについて、税務上の研究開発費や仕損じとして取得価額から外せるかを検討します。

一方、

「実際に採用する画面を作っている」

「本番データベースを構築している」

「完成システムに残るプログラムを書いている」

のであれば、単に社内で「研究フェーズ」と呼んでいるだけでは取得価額から外せません。

名称だけで一律に判定するのは避けた方がよいです。

完成するソフトウェアを製作するために直接必要な設計・仕様策定であれば、原則として取得価額へ含める方向で検討します。

逆に、特定のシステム製作へ入る前の純粋な事業調査、比較検討、不要となった技術検証などは、内容に応じて別途判断します。

そのとおりです。

完成するソフトウェアを直接形成するための支出かどうか

を中心に見ます。

完成させて事業使用できる状態にするために必要なテスト・修正であれば、原則として取得価額を構成する方向です。

まだ完成前のソフトウェアを正常に動作させるための工程だからです。

一方、稼働後に発生した不具合を直す費用は、後ほど説明する「修繕費」の論点になります。

製作計画の変更などによって仕損じとなり、

不要になったことが明らかな部分

については、取得価額に算入しないことができる取扱いがあります。

もちろんです。

本当にそのプログラムを廃棄し、完成したシステムにも利用していないことを説明できる必要があります。

例えば、

・仕様変更記録
・廃止した開発チケット
・ソースコード管理履歴
・プロジェクト会議記録
・社内承認資料

などを残しておくとよいでしょう。

国税庁はここを明確にしています。

購入したソフトウェアについて、

導入に必要な設定作業

自社仕様へ合わせるための付随的な修正作業

に要した費用は、そのソフトウェアの取得価額に算入します。

単純化すれば、

500万円＋100万円＝600万円

を取得価額として検討することになります。

設定費100万円だけを支払手数料等として一括経費にするとは限りません。

既存ソフトウェアの仕様を大幅に変更し、

実質的に新しいソフトウェアを製作した

といえる場合には、その費用は新しいソフトウェアの取得価額になります。

新システム完成後に旧システムを使用しないことが見込まれる一定の場合には、旧ソフトウェアの残存簿価が、新しいソフトウェアを製作するための原材料費として新システムの取得価額に含まれる取扱いがあります。

単純に旧システムの残存簿価を除却損にして、新システムだけ別資産とするとは限らないので注意が必要です。

通常の運用保守や、現在の機能を維持するための費用であれば、原則として期間費用として処理する方向です。

ただし「保守費」という契約名でも、中に新機能開発が含まれていれば分けて考える必要があります。

国税庁の法人税基本通達では、

プログラムの機能上の障害を除去する修正

現在の効用を維持する修正

に要した費用は修繕費に該当するとしています。

したがって、既存機能を本来の状態へ戻すための純粋なバグ修正であれば、原則として修繕費を検討します。

新しい機能の追加や、既存機能の向上に該当するのであれば、原則として資本的支出です。

その500万円を支払年度に全額修繕費にするのではなく、ソフトウェアへの資本的支出として減価償却する方向になります。

その請求書だけでは税務処理を決めにくいです。

同じ「改修」でも、

バグ修正なら修繕費、

新機能追加なら資本的支出

となる可能性があります。

作業内容の明細をもらってください。

むしろ非常に重要です。

システム関係は現物を見ても、

「この500万円が何の機能を作った費用か」

が分かりません。

仕様書、見積書、作業報告書、チケット、リリースノートなどを残しておく方が説明しやすくなります。

契約内容と実際の作業を確認します。

日常的な障害対応、監視、問い合わせ対応などと、

新機能開発・性能向上

が一つの契約に混ざっているなら、金額的重要性も踏まえて合理的に区分する必要があります。

大規模な新機能開発まで「年間保守料」という名前だけで全額経費にするのは危険です。

国税庁は、ソフトウェアの税務上の耐用年数について、

複写して販売するための原本または研究開発用：3年

その他：5年

としています。

一般的な自社利用の業務システムは「その他」に該当し、5年となるケースが一般的です。

ここも注意してください。

「研究開発のために使うソフトウェアそのもの」と、

「ソフトウェア製作過程で発生する研究開発費」

は別の話です。

国税庁は、特定の研究開発にのみ使用するため取得・製作したソフトウェアであっても、原則として減価償却資産に該当するとしています。

その場合、研究開発用ソフトウェアとして3年の耐用年数が適用されることがあります。

「研究」という言葉が付けば全部即時経費になるわけではありません。

市場販売目的のソフトウェアについても、製品の元となる「製品マスター」は資産として扱います。

国税庁は、

完成品となるまでに製品マスターへ行った改良・強化費用

も、そのソフトウェアの取得価額に算入するとしています。

完成する製品マスターを形成する改良・強化であれば、その方向になります。

完成後に顧客へ提供するための複製等に係る費用とは分けて管理する必要があります。

例えば自社利用システムについて、

外注開発費　1,200万円

自社エンジニア直接人件費　400万円

導入設定費　100万円

だったとします。

すべて完成した業務システムに直接対応する費用だとすれば、

取得価額1,700万円

としてソフトウェア計上を検討します。

一般的な自社利用ソフトウェアで5年に該当する前提なら、そうなります。

ただし、実際の減価償却はソフトウェアを事業の用に供した時点から始めます。

開発会社へ代金を払った日から自動的に償却が始まるわけではありません。

逆です。

完成するソフトウェアの取得価額を構成する費用であれば、

まだ事業供用していないから経費

ということにはなりません。

開発中の資産として集計し、完成して事業使用を開始した後に減価償却を開始することになります。

通常はそう考えます。

支払日ではなく、完成して実際に事業の用に供した時期を確認します。

決算直前のシステム開発では、検収日、本番リリース日、利用開始日などの記録を残しておくことが重要です。

自社がソフトウェアそのものを取得・製作している場合とは分けて考えます。

単にクラウドサービスを一定期間利用するための月額料金であれば、通常はサービス利用料として期間費用を検討します。

一方、高額な初期設定・専用開発・カスタマイズ等が付いている場合には、その支出の実質を確認する必要があります。

「クラウドだから全部経費」とだけ判断するのも避けた方がよいでしょう。

大規模開発では不十分になりやすいです。

開発期間中から、

・どのプロジェクトか
・どの作業をしたか
・誰が何時間従事したか
・完成システムに残る作業か
・廃棄した検証部分か
・稼働後の保守か
・新機能追加か

を追える状態にしておくことが重要です。

できれば、

「システム開発・保守一式　2,000万円」

ではなく、

・設計
・プログラミング
・テスト
・導入設定
・通常保守
・バグ修正
・新機能追加

など、作業内容と金額が分かる明細を残してもらう方がよいです。

最終的には作業の実態で判断しますが、明細があるのとないのとでは大違いです。

開発後に税理士が、

「2,000万円のうち、いくらがバグ修正でいくらが新機能追加ですか？」

と推測する状態は避けた方がよいでしょう。

私は次の順番で整理します。

まず、

自社利用か、市場販売目的か

を確認します。

次に、

完成するソフトウェアを直接製作する支出か

を確認します。

そのうえで、

研究開発費として取得価額から外せるものか

仕損じとして不要になったものか

稼働後の修繕か、機能追加か

を分けます。

そのとおりです。

ソフトウェア税務では、

勘定科目ではなく、その支出で何を作ったのか

を見ることが重要です。

開発規模が大きくなるほど、プロジェクト開始時から費用を区分しておくことをおすすめします。