「システム開発会社から届いた請求書を、今期の経費で落としていいのか、それとも資産に計上して数年かけて償却しなければならないのか」——数百万円から数千万円規模のシステム開発費用を前に、こう手が止まってしまう経理・情シス担当者は少なくありません。
判断を難しくしているのは、システム開発費用が「一律にこう処理する」と決まっていないことです。同じ開発でも、金額・開発の目的・将来どれだけ収益や効率化に貢献するかによって、費用計上になるケースと資産計上になるケースに分かれます。しかも「費用で落として今期の利益を圧縮したい」という経営層の意向と、「資産だと否認されたら追徴される」という税務リスクが、担当者の肩に同時にのしかかります。
さらに厄介なのが、資産計上する場合に「見積の内訳のどこまでを資産の取得価額に含めるのか」という問題です。要件定義費・設計費・開発費・テスト費・諸経費——手元の見積書に並ぶ行項目を、そのまま資産に算入していいのか、一部は費用にできるのかが判然としません。
本記事では、この「費用か資産か」を発注者自身が当てられるように、判断を3つの分岐に整理してお伝えします。まず冒頭で全体像を早見表で示し、続いて使う勘定科目、3つの判断分岐、資産計上したときの取得価額と仕訳、少額で費用化できる特例、減価償却の年数、そして最も気になる「税務調査で否認されやすいポイント」までを順に解説します。読み終えたとき、自社のシステム開発費用について「この支出は費用、この支出は資産計上して5年償却」と当たりをつけ、顧問税理士に論点を絞って相談できる状態を目指します。
なお、本記事は会計・税務の一般的な考え方を整理する解説です。個別の会計処理は会社の状況や契約内容によって結論が変わるため、最終的な判断は必ず顧問税理士・公認会計士にご確認ください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
システム開発費用は「費用計上」と「資産計上」のどちらになるのか
最初に結論からお伝えします。システム開発費用は、すべてが今期の経費になるわけでも、すべてが資産になるわけでもありません。支出の性質によって「今期の費用として落とせるもの」と「資産計上して数年かけて償却するもの」に分かれ、その分岐点はおおむね次の3点で決まります。
- 金額（少額なら費用化できる選択肢がある）
- 開発の目的・性質（新しいシステムを作るのか、既存システムを直すのか）
- 将来の収益獲得・費用削減が確実か（確実なら資産、不確実なら費用）
費用計上と資産計上の違い、なぜ判断が必要なのか
費用計上とは、支払った金額をその期の損金（経費）として一度に処理することです。今期の利益を圧縮できるため、節税の観点では発注者にとってありがたい処理です。
一方の資産計上は、システムを「無形固定資産（ソフトウェア）」として貸借対照表に計上し、その金額を耐用年数（自社利用なら原則5年）にわたって少しずつ費用化していく処理です。たとえば1,000万円のシステムを資産計上して5年で償却する場合、1年あたり経費にできるのは200万円ずつ。残りは資産として帳簿に残り続けます。
なぜこの判断が必要かというと、ソフトウェアは形のない資産でも「将来にわたって会社の収益に貢献する」性質を持つからです。会計のルールでは、複数年にわたって役立つ支出は、その効果が及ぶ期間に按分して費用化するのが原則とされています。だからこそ「一度に経費にできるのか、数年に分けるのか」をその都度判断する必要が生じます。
費用か資産かを分ける早見表
まずは手元の請求書を見ながら、自社の支出がどちらに当たりそうか、次の早見表で当たりをつけてください。詳しい判断基準は記事後半で1つずつ掘り下げます。
支出の内容 | 主な処理の方向性 | 想定される勘定科目 |
|---|---|---|
新しい業務システム・Webシステムを新規開発（金額が大きい） | 原則 資産計上（完成まではソフトウェア仮勘定→完成後ソフトウェア） | ソフトウェア仮勘定／ソフトウェア |
取得価額が少額（おおむね30万円〜40万円未満、後述の特例） | 費用計上できる選択肢あり | 消耗品費・支払手数料 等 |
既存システムの保守・障害対応・軽微な修正 | 原則 費用計上 | 修繕費・支払手数料・外注費 等 |
将来の収益貢献が不確実な段階の開発（PoC・調査研究等） | 費用計上（研究開発費） | 研究開発費 |
完成後の運用・サポート・サーバー利用料 | 費用計上 | 通信費・支払手数料・外注費 等 |
ポイントは、「システム開発費用」とひとくくりにせず、請求書や見積書の中身を上記の区分に分解して見ることです。1枚の請求書の中に、資産計上すべき開発費と、費用計上できる保守費が混在しているケースも珍しくありません。
システム開発費用で使う主な勘定科目
判断フローに入る前に、本記事で登場する勘定科目を、システム開発の文脈に絞って押さえておきましょう。簿記の基礎はあっても、これらがシステム開発のどの支出に当てはまるのかは、実務で経験しないとイメージしにくい部分です。
ソフトウェア仮勘定とソフトウェア
ソフトウェア仮勘定は、開発中でまだ完成していないシステムにかかった費用を、一時的に集計しておくための勘定科目です。建設中の建物を「建設仮勘定」で処理するのと同じ発想で、完成前のソフトウェアを「仮置き」しておくイメージです。要件定義から開発・テストまで、資産計上の対象となる費用を完成までこの科目に積み上げていきます。
ソフトウェアは、完成して実際に使い始めたシステムを計上する無形固定資産の勘定科目です。システムが完成し事業の用に供した時点で、ソフトウェア仮勘定に集計していた金額をこの「ソフトウェア」へ振り替え、そこから減価償却を始めます。
つまり「開発中はソフトウェア仮勘定、完成後はソフトウェア」と覚えておくと、資産計上の流れがつかみやすくなります。
研究開発費（費用計上になるケース）
研究開発費は、新しい知識の発見や新製品・新サービスの研究・開発にかかった費用を処理する科目です。重要なのは、研究開発費に該当する支出は、原則として発生した期の費用として処理する点です。
システム開発でこれが問題になるのは、たとえば「新技術を使えるか検証するための試作（PoC）」や「まだ実現できるか分からない段階の調査・研究」のように、将来本当に収益や効率化につながるかが不確実な支出です。こうした「成果が見込めるかまだ分からない」段階の費用は、資産ではなく研究開発費として費用処理する方向になります。
修繕費・支払手数料・外注費など（保守・運用・少額の経費）
完成後のシステムにかかる費用の多くは、費用計上の勘定科目で処理します。
- 修繕費：既存システムの障害対応、不具合の修正、現状を維持するためのメンテナンス費用
- 支払手数料：保守契約料、サポート料、各種サービス利用料など
- 外注費：運用・保守を外部に委託した際の費用
- 通信費：クラウドサーバーの利用料、回線費用など（契約内容により他科目もあり得ます）
ただし「修繕費」と名前がついていても、実態が機能追加・性能向上にあたる場合は資産計上が必要になることがあります。この点は税務調査でも問われやすいポイントなので、のちほど詳しく取り上げます。
費用計上か資産計上かを判断する3つの分岐
ここからが本記事の核心です。手元の支出を「費用」と「資産」に振り分けるために、3つの分岐質問を順番に当てていきましょう。
まず判断の流れを整理すると、次のようになります。
分岐1：その支出は少額か？
└ Yes → 費用化できる選択肢あり（少額特例・一括償却へ）
└ No → 分岐2へ
分岐2：新規開発か、既存システムの保守・改修か？
└ 保守・現状維持の修正 → 原則 費用計上（修繕費 等）
└ 新規開発・機能追加 → 分岐3へ
分岐3：将来の収益獲得・費用削減が確実か？
└ 確実 → 資産計上（ソフトウェア）
└ 不確実・不明 → 費用計上（研究開発費）
それぞれの分岐を具体的に見ていきます。
分岐1｜金額で判断する（少額なら費用化の選択肢がある）
最初の関門は金額です。「システム開発費用は全部を資産にして償却しなければならない」と思い込んでいる方が多いのですが、取得価額が少額であれば、要件を満たすことで費用化できる制度があります。
具体的には、取得価額が10万円未満なら原則として費用処理、青色申告の中小企業者等であれば一定額未満まで一括で経費にできる特例も使えます。金額のラインと特例の詳細は記事後半の「少額・短期で費用計上できるケース」で詳しく整理しますので、ここでは「少額なら費用にできる道がある」とだけ押さえてください。
なお、ここでいう「少額かどうか」は、システム1件（一体として機能する単位）の取得価額で判定するのが基本です。大規模なシステム開発はこのラインを大きく超えるため、分岐2・分岐3で判断することになります。
分岐2｜新規開発か、保守・改修か（保守は原則費用）
次に見るのは、その支出が「新しい価値を生み出す開発」なのか「既存システムを維持するための支出」なのかという点です。
- 既存システムの保守・障害対応・現状維持の修正 → 原則として費用計上（修繕費など）
- 新しいシステムの新規開発、または明確な機能追加・性能向上 → 資産計上の検討対象（分岐3へ）
ここで間違えやすいのが、「保守契約の中で行われた機能追加」です。たとえば月額の保守費用の中に、実質的には新機能の開発が含まれている場合、その部分は保守（費用）ではなく資産計上が必要になることがあります。名目ではなく実態で判断するのが原則です。この落とし穴は、税務調査でも指摘されやすいポイントなので、後ほど改めて取り上げます。
分岐3｜将来の収益獲得・費用削減が確実か（確実なら資産、不確実なら研究開発費）
新規開発や機能追加だと判断したら、最後の分岐は「そのシステムが将来、収益を生んだり費用を削減したりすることが確実か」という点です。
自社利用のソフトウェアについては、「その利用により将来の収益獲得または費用削減が確実であると認められる場合」に資産計上するのが会計上の考え方とされています。逆に、収益や効率化につながるかどうかが不明・不確実な段階の支出は、資産ではなく研究開発費として費用処理する方向になります。
判断の目安は次のとおりです。
状況の例 | 将来の貢献 | 処理の方向 |
|---|---|---|
業務を効率化する基幹システムを完成させ、実際に運用を開始する | 確実 | 資産計上（ソフトウェア） |
受注済みの業務を回すための新システムを開発する | 確実 | 資産計上（ソフトウェア） |
新技術が使えるか検証するためのPoC・試作 | 不確実 | 費用計上（研究開発費） |
将来のサービス化を見据えた調査研究段階 | 不明 | 費用計上（研究開発費） |
ただし、ここには企業会計と税務会計でとらえ方が分かれる難所があります。税務上は「明らかに将来の収益獲得・費用削減につながらない」と言える場合に限って費用処理が認められる、という整理になっており、安易に「不確実だから研究開発費で費用化」とすると否認されるおそれがあります。この税会の違いは記事後半で詳しく解説します。
資産計上の実務｜取得価額に含める費用と仕訳例
分岐の結果「資産計上する」と判断したら、次に直面するのが「見積の内訳のどこまでを資産の取得価額に含めるのか」という実務上の悩みです。手元の見積書を見ながら確認していきましょう。
取得価額に含めるもの・含めないもの（見積内訳マッピング表）
システムを自社で制作する（外注も含む）場合、その制作に直接要した費用は取得価額に算入するのが原則です。一方で、研究開発に該当する部分や、製作に直接かかわらない費用は取得価額から除く、あるいは費用処理する余地があります。
発注者が手元に持っている見積内訳を、おおまかに次のように当てはめてみてください。
見積内訳の行項目 | 取得価額への算入 | 補足 |
|---|---|---|
要件定義費（資産化を判断した後の工程） | 含める | システム制作に直接要する費用 |
外部設計・内部設計費 | 含める | 制作に直接要する費用 |
開発（プログラミング）費 | 含める | 制作の中心となる費用 |
テスト費（システムテスト・受入テスト） | 含める | 完成までに要する費用 |
外注費（開発委託分） | 含める | 制作に直接要する委託費用 |
導入支援・初期設定費 | 含める方向 | 事業供用までに要する費用は算入が原則 |
操作研修・トレーニング費 | 含めない方向 | 制作そのものではない費用は除く検討 |
保守・運用費（完成後） | 含めない | 費用計上（修繕費・支払手数料 等） |
将来が不確実な調査・PoC段階の費用 | 含めない | 研究開発費として費用処理 |
注意したいのは、要件定義のような上流工程の費用です。「将来の収益獲得・費用削減が確実」と判断できる段階に入ってからの開発関連費用は取得価額に含めますが、まだ実現可能性を見極めている調査・研究段階の費用は研究開発費として費用処理する、という線引きになります。どの時点から資産化に切り替えるかは判断を要するため、契約や開発の実態を踏まえて顧問税理士に確認するのが安全です。
ソフトウェア仮勘定からソフトウェアへの振替仕訳例
資産計上する場合の典型的な流れは「開発中はソフトウェア仮勘定に積み上げ、完成・事業供用時にソフトウェアへ振り替える」というものです。具体的な仕訳イメージは次のとおりです（金額は例。消費税の処理は簡略化しています）。
開発費用の支払い時（開発中・仮勘定に集計）
借方 | 金額 | 貸方 | 金額 |
|---|---|---|---|
ソフトウェア仮勘定 | 5,000,000 | 普通預金 | 5,000,000 |
システム完成・事業供用時（仮勘定から本勘定へ振替）
借方 | 金額 | 貸方 | 金額 |
|---|---|---|---|
ソフトウェア | 5,000,000 | ソフトウェア仮勘定 | 5,000,000 |
この振替を行った後、ソフトウェアとして計上した金額を耐用年数にわたって減価償却していきます。償却の年数・方法は「資産計上した場合の減価償却」で解説します。
契約形態（請負・準委任）が資産化のタイミングに与える影響
見落とされがちですが、システム開発をどの契約形態で発注したかも、資産化のタイミングに影響します。
- 請負契約：成果物（完成したシステム）の納品を約束する契約です。完成・検収という明確な区切りがあるため、「いつソフトウェア仮勘定からソフトウェアへ振り替えるか」「いつ事業供用とみなすか」のタイミングを判断しやすいのが特徴です。
- 準委任契約：作業（労働）の提供を約束する契約で、成果物の完成自体は契約上の義務になりません。完成という明確な区切りがないため、どの時点で「資産として完成した」とみなすかの判断が難しくなる場合があります。アジャイル開発のように機能を継続的にリリースしていく形態では、特にこの点が論点になります。
発注時に「どこまでが資産化の対象で、いつ完成とみなすか」を意識して契約形態や検収条件を整理しておくと、後の会計処理がスムーズになります。判断に迷う場合は、契約書と開発の実態を顧問税理士に共有して確認するのが確実です。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
少額・短期で費用計上できるケース｜一括償却と少額減価償却資産の特例
「システム開発費用はすべて資産にして数年で償却しなければならない」というのは、よくある誤解です。取得価額が一定額未満であれば、税務上認められた方法で費用化できる選択肢があります。「費用にできれば今期の利益を圧縮できる」という発注者のニーズに、合法的に応える手段として押さえておきましょう。
10万円未満は費用、10万〜20万円未満は一括償却資産
取得価額のラインによる基本的な扱いは次のとおりです。
- 10万円未満：原則として、取得した期に全額を費用処理できます（消耗品費など）。
- 10万円以上20万円未満：「一括償却資産」として、取得価額を3年間で3分の1ずつ均等に費用化できる制度を選べます。
一括償却資産は、本来の耐用年数（ソフトウェアなら5年）にかかわらず3年で償却できるため、5年償却より早く費用化できるのがメリットです。詳しくは弥生の一括償却資産の解説も参考になります。
中小企業者等の少額減価償却資産の特例（取得価額の上限と年300万円まで）
青色申告をしている中小企業者等であれば、「少額減価償却資産の特例」を使って、より大きな金額まで一括で費用化できます。
この特例では、取得価額が一定額未満の減価償却資産について、年間300万円を限度に、取得して事業に使い始めた期の費用として全額を損金算入できます。対象となる取得価額の上限は、令和8年度（2026年度）の税制改正で次のように変わりました。
取得時期 | 取得価額の上限 | 年間限度額 |
|---|---|---|
2026年3月31日までに取得 | 30万円未満 | 300万円 |
2026年4月1日以降に取得 | 40万円未満 | 300万円 |
（参考：少額減価償却資産の特例について（弥生）、上限額は2026年度税制改正で40万円未満に引き上げ。年間限度額300万円は据え置き）
ソフトウェアもこの特例の対象になり得ます。たとえば取得価額が35万円のシステムを2026年4月1日以降に取得し、青色申告の中小企業者等で年間の合計が300万円以内であれば、5年償却せずに取得した期に全額費用化できる、という選択肢が生まれます。
ただしこの特例には、青色申告であること、中小企業者等の要件を満たすこと、年間合計300万円の枠内であることなど、いくつかの適用条件があります。自社が要件を満たすか、また他に少額資産を取得していて枠を使っていないかを含めて、顧問税理士に確認してから適用してください。
資産計上した場合の減価償却｜耐用年数と償却方法
資産計上すると判断したシステムは、その後、耐用年数にわたって減価償却していきます。決算後まで見据えて「何年でどう償却するのか」の見通しを立てておきましょう。
耐用年数（自社利用5年・販売原本／研究開発用3年）と定額法
ソフトウェアの法定耐用年数は、用途によって次のように定められています（出典：国税庁 No.5461 ソフトウエアの取得価額と耐用年数）。
ソフトウェアの用途 | 法定耐用年数 |
|---|---|
自社利用（社内で業務に使う） | 5年 |
複写して販売するための原本、研究開発用 | 3年 |
多くの発注者にとって関係するのは「自社利用の5年」です。業務システムや社内向けWebシステムを自社で使う目的で開発した場合、原則として5年で償却します。
ソフトウェアの償却方法は定額法です。たとえば取得価額1,000万円のソフトウェア（自社利用・5年）なら、毎年200万円ずつ均等に費用化していく計算になります。
償却開始のタイミング（事業供用日）と月割
減価償却は、ソフトウェアを「取得した日」ではなく「事業の用に供した日（実際に使い始めた日）」から開始します。開発が完了しても、まだ運用を始めていなければ償却は始まりません。
また、期の途中から使い始めた場合は、その期は使った月数に応じた月割計算になります。たとえば期首から数えて9か月目に使い始めた場合、その期の償却費は1年分のうち残り月数分（例：4か月分）だけ計上する、という形です。
使われなくなったシステムの除却・減損
償却の途中でシステムが使われなくなることもあります。事業の刷新で旧システムを廃棄した場合などは、帳簿に残っている未償却の金額を除却損として計上します。
また、システムが当初想定したほど収益や効率化に貢献しなくなり、投資額を回収できる見込みが立たなくなった場合には、減損の検討が必要になることもあります。技術の陳腐化が速いシステムでは、会計上の耐用年数を法定の5年より短く（たとえば3年程度に）設定して償却する企業もあります。ただし税務上は法定耐用年数が基準となるため、会計と税務で差が生じる点に注意が必要です。除却・減損の判断は専門的な要素が大きいので、顧問税理士・会計士に相談しましょう。
企業会計と税務会計の違い｜税務調査で否認されやすいポイント
ここまで「費用か資産か」の判断軸を見てきましたが、実は同じ支出でも、企業会計（決算書を作るためのルール）と税務会計（税金を計算するためのルール）でとらえ方が分かれることがあります。検索者の最大の不安——「費用で落としたら、後で税務調査で否認されるのではないか」——に正面からお答えします。
判断基準のズレ（企業会計＝不確実なら費用／税務＝原則資産）
自社利用ソフトウェアの「将来の収益獲得・費用削減が確実か」という判断について、企業会計と税務会計では力点が異なります。
- 企業会計：将来の収益獲得・費用削減が確実とは言えない（不確実・不明な）場合は、資産計上せず費用処理する方向に傾きます。保守的に「資産として残さない」判断をしやすいルールです。
- 税務会計：原則は資産計上で、「明らかに将来の収益獲得・費用削減につながらない」と言える場合に限って費用（研究開発費等）として認める、という整理です。
つまり、企業会計の感覚で「確実とは言い切れないから費用でいいだろう」と処理すると、税務上は「いや、これは資産計上すべきだ」と判断され、否認につながるおそれがあります。費用化したい発注者ほど、この税会のズレを理解しておくことが大切です。より専門的な解説は、企業会計と税務の違いを整理した会計ベンダーや会計事務所の一次寄りの情報も参照してください。
税務調査で否認されやすいポイント（保守名目の機能追加・先行費用の扱い）
実際の税務調査では、次のようなケースで「これは費用ではなく資産だ」と指摘されやすい傾向があります。
- 保守名目だが、実態は機能追加・性能向上：保守契約や修繕費として費用処理していても、中身が新機能の開発やシステムの大幅な改良であれば、その部分は資産計上が必要と判断されます。名目より実態が重視されます。
- 要件定義や調査を「研究開発費」として費用化したが、本開発が確実だった：実現可能性が見えていて本開発に進むことが確実な段階の費用まで研究開発費に含めると、「資産化すべき取得価額を費用化した」と指摘されるおそれがあります。
- 複数の支出をまとめて少額判定：本来は一体のシステムなのに、工程ごとに分割して「それぞれ少額だから費用」とするのは、取得価額の判定単位を恣意的に分けたとみなされるリスクがあります。
いずれも「費用で落としたい」気持ちが先行すると陥りやすい落とし穴です。実態に即した処理を心がけ、判断に迷う部分は記録（議事録・仕様変更の経緯など）を残しておくと、調査での説明がしやすくなります。
顧問税理士・会計士に相談すべき論点の整理
ここまで読んでいただければ、自社のシステム開発費用について、ある程度の当たりはつけられるはずです。そのうえで、次のような論点は専門家に相談することをおすすめします。
- 資産化に切り替える「将来の収益貢献が確実」と言える時点はいつか
- 見積内訳のうち、取得価額に含める範囲と費用化できる範囲の線引き
- 保守費の中に資産計上すべき機能追加が含まれていないか
- 少額減価償却資産の特例などの適用要件を自社が満たすか
- 会計上の耐用年数を法定より短くする場合の税務との差異
論点を整理してから相談すれば、税理士との打ち合わせも短時間で的確に進み、処理の確度も上がります。
まとめ｜発注段階から会計を見据えて見積内訳を整理する
システム開発費用の勘定科目と「費用計上か資産計上か」の判断を、改めてチェックリストとして整理します。手元の請求書・見積書を見ながら当てはめてみてください。
- 金額は少額か → 10万円未満は費用、少額減価償却資産の特例（中小企業者等・青色申告で、2026年4月以降取得は40万円未満・年300万円まで）に当てはまれば費用化の選択肢あり
- 新規開発か、保守・改修か → 保守・現状維持の修正は原則費用（修繕費等）、新規開発・機能追加は資産計上を検討
- 将来の収益獲得・費用削減が確実か → 確実なら資産計上（ソフトウェア）、不確実・不明なら研究開発費として費用計上
- 資産計上する場合 → 開発中はソフトウェア仮勘定に集計、完成・事業供用時にソフトウェアへ振替、自社利用は耐用年数5年・定額法で償却
- 税会のズレに注意 → 企業会計の感覚で費用化すると税務で否認されることがある。保守名目の機能追加・先行費用の扱いは特に注意
最後に、実務でぜひ取り入れていただきたい備えがあります。それは、システム開発を発注する段階で、開発会社に「要件定義・設計・開発・テスト・保守を分けた見積内訳」を依頼しておくことです。見積が工程ごとに分かれていれば、後から「どこまでが資産の取得価額で、どこからが費用になる保守か」を切り分けるのが格段にスムーズになります。一括の総額だけの見積だと、決算時に内訳を再構成する手間が発生し、税務調査でも説明が難しくなりがちです。
会計処理は発注の後工程に見えますが、実は発注時の見積の取り方で、後の処理のしやすさが大きく変わります。本記事で論点を整理したうえで、自社の状況に合わせた最終的な処理は、必ず顧問税理士・公認会計士にご確認ください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 開発費の一部だけを費用計上し、残りを資産計上することはできますか？
できます。1枚の請求書や見積書の中でも、要件定義〜テスト費は資産の取得価額に含め、完成後の保守・運用費は費用計上するなど、行項目ごとに区分して処理するのが原則です。工程別の内訳が分かる見積書を発注時に取得しておくと、後からの切り分けが格段に楽になります。
- アジャイル開発のように毎月継続的にリリースされる場合、いつ「ソフトウェア仮勘定」からソフトウェアに振り替えればよいですか？
準委任契約のアジャイル開発では完成という明確な区切りがないため、「業務に供用できる単位の機能がリリースされた時点」を事業供用日とみなして都度振り替えるか、一定の区切り（フェーズ完了・検収等）で振り替える方法が考えられます。判断基準は契約書と開発実態によって異なるため、方針を顧問税理士に確認してから運用してください。
- 保守費用の中に機能追加が含まれているかどうか、どうやって判断すればよいですか？
名目ではなく実態で判断します。保守契約や月額費用の中で「新しい画面・機能の追加」「性能向上を目的とした改修」が行われた場合、その部分は保守（修繕費）ではなく資産計上の対象です。定期的に開発会社から作業内容の報告を受け、「現状維持か、新機能追加か」を区別する記録を残しておくと税務調査での説明が容易になります。
- 少額減価償却資産の特例（30万円・40万円未満）は、複数回に分けて支払う開発費にも使えますか？
判定はシステム1件（一体として機能する単位）の取得価額の合計で行います。分割払いや複数回請求であっても、同一システムの取得価額を合算した金額が基準となるため、支払いを分けただけでは少額判定になりません。また同一システムの費用を工程ごとに分割して少額と判定するのは税務上のリスクがあります。
- 税理士に相談する前に、自社で準備しておくべき書類は何ですか？
「工程別の見積内訳書」「契約書（請負か準委任か）」「検収書または完成確認の記録」「開発目的と期待する業務効果をまとめたメモ」の4点を揃えると、論点の絞り込みがスムーズです。特に「新規開発か保守か」「将来の収益貢献が確実か」の判断根拠となる資料を優先して準備してください。
