ソフトウェアの減価償却と耐用年数｜自社利用ソフトの目安を解説

「システムやアプリの開発にかけた費用は、その年の経費で落とせるのか、それとも何年かに分けて処理するのか」——発注を検討する段階で、この減価償却の扱いに戸惑う担当者は少なくありません。完成したソフトウェアは多くの場合「資産」として扱われ、耐用年数にわたって少しずつ費用にしていきます。この記事では、ソフトウェアの減価償却と耐用年数の一般的な考え方を、資産計上の基本・自社利用ソフトの年数の目安・償却方法・少額の一括費用・制作途中の扱い・保守費との違い・資金繰りへの影響まで、発注前に押さえておきたい順で整理します。なお、税務・会計の取り扱いは会社の状況や制度改正で変わるため、本記事は一般的な目安であり、実際の処理は必ず顧問税理士や会計士に確認してください。会計処理の全体像は、開発費の会計処理と資産計上の解説記事もあわせてお読みください。

ソフトウェアの減価償却とは（システムは「資産」になる）

減価償却とは、長く使う資産の取得費用を、使う期間にわたって少しずつ費用にしていく会計上の仕組みです。建物や機械と同じように、システムやアプリのソフトウェアも「何年も業務に役立つもの」と考えられるため、多くの場合いったん資産として計上し、そこから毎年少しずつ費用（減価償却費）にしていきます。

• 費用処理：支払った年度にまとめて経費にする。その年の利益は下がるが、翌年以降には残らない。
• 資産計上＋減価償却：いったん資産として記録し、耐用年数にわたって毎年少しずつ費用にしていく。

システム開発費、とくに完成後に長く使うソフトウェアは、将来にわたって業務に役立つ（収益を生む・コストを減らす）と考えられるため、資産計上して減価償却するのが一般的な整理です。「大きな投資をしたのに、思ったほど今期の経費が増えなかった」という感覚は、この償却の仕組みから生まれます。どの支出を資産に計上し、どこからを費用にするかという費用と資産の分かれ目そのものについては、開発費の会計処理と資産計上の解説記事で詳しく整理しているので、判断の全体像を知りたい場合はそちらを起点にすると分かりやすくなります。

自社利用ソフトの耐用年数と償却方法の目安（5年・定額法）

減価償却でまず気になるのが「何年で、どう配分して費用にするのか」、つまり耐用年数と償却方法です。自社の業務のために使うソフトウェア（受発注・在庫・顧客管理などの業務システム）は、一般的に5年で償却する例が多いとされます。たとえば取得価額が500万円のソフトウェアなら、単純計算で毎年100万円ずつを5年かけて費用にしていくイメージです。

そのうえで、無形固定資産であるソフトウェアは、一般的に定額法で償却する例が多いとされます。定額法は、取得価額を耐用年数で均等に割り、毎年同じ額を費用にしていく方法です。毎年の費用が一定になるため、資金計画や利益の見通しが立てやすいという利点があります。

項目	一般的な目安
自社利用ソフトの耐用年数	5年とされることが多い
複写して販売する原本など	別の年数が定められる場合がある
償却方法	定額法（毎年一定額）で償却する例が多い
償却の考え方	取得価額 ÷ 耐用年数で毎年費用化
費用に計上する名目	減価償却費（無形固定資産の償却）

ただし、耐用年数はソフトウェアの種類や利用実態によって異なる場合があります。外部に販売する目的で作る「市場販売目的のソフトウェア」は、自社利用とは扱いが変わりますし、税制上の区分によっても年数や方法が動くことがあります。「5年・定額法」はあくまで自社利用ソフトの代表的な目安であり、具体的な年数・方法は税務上のルールに従い、税理士の指示を優先してください。まずは「これは社内の業務を回すための自社利用ソフトだ」という前提を、相談時に共有しておくと話が早く進みます。

大切なのは、資産計上した年に全額が経費になるわけではない、という点です。500万円をかけても、初年度の経費は償却した一部にとどまり、残りは翌年以降に繰り越されます。そのぶん初年度の利益は一括費用より高く出やすく、納税額にも影響します。逆に言えば、開発した効果が続く数年間にわたって費用を平準化できるため、単年度で利益が大きく振れるのを避けられる、という見方もできます。なお、システムを使うのをやめた場合や、大きく作り替えて古いものが不要になった場合には、まだ費用にしきれていない残りの金額（未償却残高）を、その時点でまとめて処理する扱いになることもあります。

少額なソフト・中小企業の特例

金額の大きさによって、扱いが変わる点も押さえておきましょう。取得価額が一定額未満のソフトウェアについては、資産に計上して数年かけて償却するのではなく、その期の費用として一括処理できる制度が設けられています。

• 少額なもの：取得価額が一定額未満なら、資産計上せずまとめて費用処理できる区分がある。
• 一定額の範囲のもの：数年で均等に費用化できる特例が使える場合がある。
• 中小企業向けの特例：一定の条件を満たす中小企業が、少額の減価償却資産をまとめて費用にできる特例（少額減価償却資産の特例など）が用意されていることがある。

これらを使えると、発注初年度の利益を圧縮でき、資金繰りの面でも扱いやすくなります。5年に分けて償却するのではなく、その年にまとめて費用にできれば、投資した年の税負担を軽くしやすいためです。とくに利益が出ている年度に導入する場合、少額判断や中小企業の特例を使えるかどうかで、手元に残る資金の見え方が変わってきます。

ただし、金額の区切り・適用できる会社の条件・対象や上限額・適用できる期間は、税制で細かく定められており、改正されることもあります。「いくら未満ならこう」「中小ならこの特例が使える」という数字や条件は目安にとどめ、自社がその年度に実際に適用できるかは、必ず税理士に確認してください。とくに特例には「年間の合計額に上限がある」「対象となる資産の種類が限られる」といった細かな条件が付くことが多く、自己判断で適用すると後から否認されるリスクもあります。特例の適用可否は、会計処理全体の設計にも関わるため、開発費の会計処理と資産計上の解説記事とあわせて、発注前に方針を相談しておくと安心です。

制作途中のソフトウェア仮勘定の扱い

ひとつのシステムは、発注してから完成するまでに数か月かかることも珍しくありません。この完成前の開発費をどう扱うかも、迷いやすいポイントです。一般的には、次のように整理されます。

• 開発の途中：まだ完成していない段階の開発費は、いったん「ソフトウェア仮勘定」という科目に集計しておく。この段階では償却は始めない。
• 完成・稼働：完成して業務で使い始めたら、仮勘定に集めた費用を本来のソフトウェア（無形固定資産）へ振り替え、そこから減価償却を始める。

つまり「いつから償却が始まるか」は、完成して使い始めたタイミングが基準になります。決算期をまたいで開発が続く場合、期末時点ではまだ仮勘定に計上され、償却は翌期以降に始まる、という流れになりやすい点も押さえておくとよいでしょう。「今期に大きな費用が立つはず」と見込んでいたのに、完成が翌期にずれ込んで今期は償却が始まらなかった、というズレも起こり得ます。発注のタイミングと決算月の関係は、資金計画のうえでも意識しておくと安心です。

実務では、要件定義・設計・開発・テストといった工程ごとに費用を記録しておくと、後から「どの費用をいつから資産に入れるか」を整理しやすくなります。発注時の見積書や契約書で工程が分かれていると、こうした集計にも役立ちます。逆に「開発一式」でまとめられた見積書だと、仮勘定への集計や完成時の振り替えで、何をどう按分するか判断に迷いやすくなります。

保守費・改修費は「資産」か「費用」か

システムは作って終わりではなく、運用しながら手を入れ続けるものです。この保守や改修にかかる費用は、減価償却の対象になる資産なのか、それともその期の費用なのかで扱いが分かれます。基本的な整理は次のとおりです。

• 費用処理になりやすいもの：不具合の修正、現状維持のための保守、軽微な調整など、今ある価値を保つための支出。
• 資産計上になりやすいもの：新しい機能の追加、大幅な作り替えなど、システムの価値を新たに高めるための支出。価値を高めた分は、あらためて資産計上し減価償却の対象になることがある。

判断の軸は「現状維持か、価値の上乗せか」です。表示崩れの修正や項目名の変更は現状維持に近く費用処理と整理されやすい一方、「手作業だった集計を自動化する機能を新たに足す」といった改修は、価値を高めるため資産計上の対象と見られやすくなります。ただ、実際には「修正なのか機能追加なのか微妙」というケースも多く、線引きは簡単ではありません。たとえば既存機能の使い勝手を良くする改修は、見方によって現状維持とも価値向上とも解釈でき、判断が分かれやすい典型例です。だからこそ、契約書・作業依頼書・作業内容の記録を残しておくことが重要です。何のための支出かが説明できれば、税理士との相談で適切な処理を判断しやすくなります。保守費そのものの相場観はシステムの保守費用の解説記事にゆずりますが、月額で契約している保守料は、支払った期の費用として処理するのが一般的です。年間の保守費は初期の開発費の1割前後が目安とされることが多く、金額としても無視できないため、開発費と分けて把握しておくと会計処理も運用計画も立てやすくなります。会計上の詳しい切り分けは開発費の会計処理と資産計上の解説記事も参考にしてください。

減価償却が資金繰り・節税に与える影響

同じ金額を払っても、減価償却する（資産計上する）か、少額で一括費用にするかで、手元の資金や納税のタイミングの見え方が変わります。

観点	一括で費用にした場合	資産計上して償却する場合
初年度の利益	大きく下がる	あまり下がらない
初年度の税負担	軽くなりやすい	費用処理より重くなりやすい
翌年以降	費用は残らない	償却費として毎年続く
決算書の見え方	資産は増えない	無形固定資産が計上される

一概にどちらが得とは言えません。その年の利益を抑えて納税を軽くしたいなら少額判断や一括費用が向く場面もありますし、融資などで決算書の資産を厚く見せたいなら資産計上して償却するほうが合う場面もあります。ここで注意したいのは、処理方法は「利益を減らしたいから全部費用で落とす」といった都合だけで自由に選べるものではない、という点です。金額や支出の性質によって原則的な扱いはある程度決まっているため、まずは原則としてどう処理すべきかを確認し、そのうえで使える特例があるかを検討する、という順序が安全です。分割払いやリースで導入する場合の考え方は分割払い・リースでのシステム導入の解説記事も参考になります。

発注前に整理しておきたいチェックリスト

減価償却をスムーズに進めるために、発注の段階で次の点を整理しておくと安心です。

• この開発費は資産計上して償却するか、一括費用にできるか、税理士に見込みを確認したか
• 見積書・契約書で工程（要件定義・設計・開発・テスト）が分かれているか
• 少額判断や中小企業の特例が使える可能性があるか、その年度のルールを確認したか
• 保守・改修の費用が、開発費と分けて記載されているか
• 決算月と発注・完成のタイミングの関係を確認したか（償却の開始時期に関わる）
• 納品後にソースコード（成果物）の権利が自社に渡るか（資産としての位置づけにも関わる）

とくに、見積書の内訳が「開発一式」とだけ書かれていると、後から工程や保守を切り分けにくく、会計処理でも苦労します。中身が読める見積書をもらっておくことが、処理のしやすさにもつながります。開発そのものの費用相場を先に押さえたい場合は、システム開発の費用相場の解説記事もあわせて読むと、金額の見当がつけやすくなります。

一律料金だと償却の見通しも立てやすい

減価償却を考えるうえで地味に効くのが、「総額が最初に確定しているか」です。見積もり型では、仕様の相談や追加のたびに金額が動くため、「結局いくらを資産に計上して、毎年いくら償却するのか」が着地まで読みにくくなります。

D-oneAppは、料金を一律100万円（より大規模なプロプランは一律200万円）にしています。減価償却の観点では、次の点がメリットになります。

• 着手前に総額が確定：資産計上額・毎年の償却費の見込みを、発注前から税理士と相談できる。
• 追加費用なし：後から金額が膨らまないため、期中で処理方針を組み替える手間が起きにくい。
• 成果物（ソースコード）の権利を譲渡：納品物が自社のものになるため、資産としての位置づけも整理しやすい。

金額が最初に固まっていれば、「今期の利益にどう響くか」「少額判断が使えそうか」といった相談も、発注前に前もって進められます。処理方針を決めてから発注できるのは、資金計画のうえで大きな安心材料です。

まとめ

ソフトウェアの減価償却は、「完成して長く使う自社利用ソフトは資産計上し、耐用年数にわたって少しずつ費用にする」のが出発点です。自社利用ソフトの耐用年数は5年が代表的な目安で、償却は定額法で毎年一定額ずつ、というのが一般的な整理でした。取得価額が一定額未満なら少額として一括費用にできる制度や、中小企業向けの特例が使える場合もあります。制作途中はソフトウェア仮勘定に集計し、完成時に振り替えて償却を始める——保守・改修費は「現状維持か価値の上乗せか」で扱いが分かれる、と押さえておきましょう。ただし年数・償却方法・特例の適用可否は、いずれも制度改正や個別事情で変わるため、本記事はあくまで一般的な目安です。実際の処理は必ず顧問税理士や会計士に確認してください。会計処理の全体像は開発費の会計処理と資産計上の解説記事で確認できます。「うちの場合はどう償却する？」が気になったら、まずはお気軽に無料相談ください。