企業がシステム開発やソフトウェア導入に資金をかけたとき、その支出は「全額経費（費用）」になるのでしょうか？それとも「資産」として計上するのでしょうか？
この記事では、ソフトウェア計上時の基本ルールから、現代的なSaaS・クラウドの扱い「判断のポイントと証拠」を公認会計士が分かりやすく解説します。
ぜひ最後までお読みください。
（資産計上したソフトウェアの減価償却の論点解説はこの記事では扱いません）
結論：会計処理は「原則3つ＋番外1つ」
ソフトウェアの会計処理は独立した基準ではなく「研究開発費等に係る会計基準（以下、研究開発基準）」という大きな枠組みの一部として定められています。
そのなかで、ソフトウェアをその「制作目的」に応じて大きく3つに分類し、それぞれ異なる会計処理を定めています。
| 制作目的 | 概要 | 会計処理の基本 |
| ①研究開発目的 | 新しい技術や知識を得るための試み | 原則、全額費用（研究開発費） |
| ②市場販売目的 | パッケージソフトとして販売する | 完成前：費用 完成後：内容により資産または費用 |
| ③自社利用目的 | 社内システムや自社サービスの基盤 | 確実性が高い部分は資産/不明は費用 |
| (番外)④受注制作 | 顧客から請け負って制作 | 請負工事等に準じた処理 |
ポイントは「ソフトウェアは全部同じ処理ではない」、何のために作るか（制作目的）で入り口が分かれることです。
なぜ目的で分類するのか｜キーワードは「不確実性」と「客観性」
ではなぜ「制作目的」で分類し、会計処理を変える必要があるのでしょうか。
「研究開発基準」の目的は「投下したコストとその回収可能性を適切に財務諸表へ反映する」ことです。
要は現金等を稼げるか、あるいは現金等の支払額を減らせるか。
資産か費用かが曖昧だと恣意的に（思いのままに）利益操作につかわれるおそれがあります。
利益操作を防ぐため、稼げるか・減らせるかの判断の際には、会計が重視する「不確実性」と「客観性」で考えます。
不確実性
開発初期（研究段階）は「完成するか」「収益を生むか」が不確実なので、資産ではなく費用処理です。
一方、製品マスター完成や社内利用が確実になった段階では、将来便益の確実性が高まる、稼げるという見通しがたつので、資産計上が選択肢になります。
客観性
ソフトウェアは目に見えない無形資産のため恣意的に資産計上すると利益操作になりやすい領域。
だからこそ「確実になった」という説明だけで終わらせず、稟議・予算承認・取締役会議事録・仕様書・テスト結果などの証拠で裏付けるのです。
他人へ説明できる証拠を用意する、と解釈してもよいでしょう。
3つの会計処理の解説（詳細）
それでは、3つの区分それぞれの具体的な会計処理を見ていきましょう。
①研究開発目的のソフトウェア
新しい知識の発見や、新しい技術・製品の開発を目的とするソフトウェアです。
前述の通り、将来の収益獲得がまだ不確実である段階のため、かかった費用は発生した時に全額を「研究開発費」（費用）として処理します。
②市場販売目的のソフトウェア
不特定多数のユーザーに販売することを目的としたソフトウェアです（例：市販のパッケージソフト、ゲームなど）。
開発のフェーズによって処理が分かれます。
- 製品マスター（最初の完成版）ができるまで:まだ研究開発の段階（不確実性が高い）とみなされ、すべて「研究開発費」（費用）として処理
- 製品マスターができた後:機能の改良や強化などに使った支出は、将来の収益に貢献することが確実視されるため「ソフトウェア」（無形固定資産）として資産計上
- (参考)製品の複製:販売用にコピーしたりパッケージングしたりする費用は「棚卸資産（製品）」
なお「製品マスター完成後＝全部資産」ではありません。
完成後でも、著しい改良（主要プログラムの過半を再制作する等）は研究開発費、バグ取り等の機能維持は費用となります。
通常の製品の製造と同じように考えると、完成までの費用は資産になりそうですが、費用処理します。
ここは会計と感覚が異なるところですが、無形固定資産は形がなく仕掛中で終わったものをバラして売るようなことはできません。
「稼げるのかどうか」の判断の比重が重くなると解釈してください。
③自社利用目的のソフトウェア
自社の業務で利用すること、または第三者にサービスを提供するために利用することを目的としたソフトウェアです。
将来の経済的便益（収益獲得や費用削減）の確実性によって判断します。
- 将来の便益が「確実」と認められる場合:「ソフトウェア」（無形固定資産）として資産計上
- 確実性が認められない（または不明な）場合:発生した時に「費用」として処理
現代的なトピック（SaaS・クラウド）の解説
近年増えているSaaS（Software as a Service）やクラウド利用について解説します。
自社でSaaSを開発して提供する場合（ベンダー側）
自社で構築したクラウド基盤を使ってサービスを提供する場合、そのソフトウェアは通常「③自社利用目的」に分類されます。
したがって「将来の収益獲得が確実」と判断された段階から、資産計上が始まります。
他社のSaaS/クラウドを利用する場合（ユーザー側）
多くのSaaS契約は「ソフトウェアそのものを取得する（支配する）」のではなく、ソフトウェアへのアクセスを含むサービス提供を受ける契約です。
この場合、月額利用料は通常「サービス費用」として費用処理します。
一方、導入時の初期設定費用・カスタマイズ費用は、契約内容（成果物の支配の有無、サービスとしての提供か、前払の性格か等）により会計処理が分かれます。
契約条件と役務提供の実態をみて整理してください（本記事では考え方の紹介に留めます）。
具体例と仕訳
ここまでの解説を、具体的な取引と仕訳で確認して定着させましょう。（※金額は単純化しています）
例1：研究開発（AI新技術の研究）
- 状況1-A:AIを活用した新技術の研究プロジェクトで、外部調査費として現金50万円を支払った。
- 仕訳1-A:
| (借) | 研究開発費 | 500,000 | / | (貸) | 現金 | 500,000 |
例2：市場販売（ゲームソフト開発）
- 状況2-A（マスター完成前）:新作ゲームのプログラマー給与として現金300万円を支払った。
- 仕訳2-A：
| (借) | 研究開発費 | 3,000,000 | / | (貸) | 現金 | 3,000,000 |
- 状況2-B（マスター完成後）:発売中のソフトに新機能を追加するため、開発会社に現金200万円を支払った。
- 仕訳2-B:
| (借) | ソフトウェア | 2,000,000 | / | (貸) | 現金 | 2,000,000 |
（ただし、著しい改良なら研究開発費）
例3：自社利用（社内新システム導入）
- 状況3-A（確実性なし）:新システム導入に向けた要件定義コンサル費として現金100万円を支払った（導入効果はまだ不明）。
- 仕訳3-A:
| (借) | 支払手数料（費用） | 1,000,000 | / | (貸) | 現金 | 1,000,000 |
- 状況3-B（確実性あり）:取締役会で導入が正式決定したシステムの開発で、ベンダーに中間金500万円を支払った。
- 仕訳3-B:
| (借) | ソフトウェア仮勘定 | 5,000,000 | / | (貸) | 現金 | 5,000,000 |
（※完成前なので「仮勘定」を使います）
例4：SaaS利用（ユーザー側）
- 状況4-A:他社のクラウド勤怠管理システムを利用し、月額利用料5万円を支払った。
- 仕訳4-A:
| (借) | 支払手数料 | 50,000 | / | (貸) | 現金 | 50,000 |
例5：【発展】SaaSベンダーの継続的な開発
自社でSaaSを開発・提供する企業（ベンダー側）の場合、そのソフトウェアは「③自社利用目的」となります。
リリース後も開発が続くため、内容に応じたこまめな判断が必要です。
簿記の試験では優先度が下がるので、ここは参考程度の意識で見てください。
状況A（初期開発・フェーズ1）
新しいSaaS事業の立ち上げ初期。まだ収益化できるか不確実な実験段階で、エンジニア人件費300万円が発生した。
- 仕訳5-A:（将来の確実性がないため費用処理）
| (借) | 研究開発費 | 3,000,000 | / | (貸) | 未払金 | 3,000,000 |
状況B（本開発・フェーズ2）
事業計画が取締役会で承認され、収益獲得が確実視された。その後、サービスリリースに向けた本開発で、外部ベンダー費500万円が発生した。
- 仕訳5-B:（確実性があるため資産計上）
| (借) | ソフトウェア仮勘定 | 5,000,000 | / | (貸) | 買掛金 | 5,000,000 |
状況C（リリース後の運用）
サービス開始後、①新機能を追加するための開発費200万円と、②既存機能の軽微なバグ修正のための人件費50万円が発生した。
- 仕訳5-C:（機能向上は資産、維持管理は費用）
①新機能追加
| (借) | ソフトウェア | 2,000,000 | / | (貸) | 現金 | 2,000,000 |
②バグ修正
| (借) | 保守費 | 500,000 | / | (貸) | 現金 | 500,000 |
細分化して当てはめているだけ、と気づかれるでしょうが、その通りです。
仕訳は、内容の切り分けを丁寧にして対応しましょう。
実務現場における判断のポイントと証拠
試験問題では「将来の収益獲得が確実となった」という前提条件が与えられますが、実務の現場では、この「確実になった」という判断をどう下すかが難しいところです。
開発担当者の「絶対儲かります！」という主張だけでは、会計上の「客観的な確実性」とは認められません。
実務や監査では、資産計上のための決定的な証拠として、以下のようなドキュメントがあるとよいです。
- 具体的な収益計画やコスト削減効果が明記された「開発計画書」や「稟議書」
- その計画に基づき、開発の実行と予算を正式に承認した「稟議・予算承認・契約・テスト完了報告」など、組織の意思決定を示す客観資料
会社として正式に「この投資は将来の利益を生む確実性がある」と意思決定したという客観的な記録があって初めて、資産計上が正当化されるのです。
ソフトウェアは、無形固定資産、つまり目に実態として見えないので把握しづらく、金額には見積もりが入りがちです。
また循環取引などで架空取引のおそれなどがあり（2025年にも循環取引をした会社が上場廃止になりました）監査では厳しく見られます。
金額算定、文書証拠は客観的であることを重視して用意すると、監査をする公認会計士も受け入れやすくなります。
まとめ
ソフトウェアの会計処理は、一見複雑に見えますが、骨組みはシンプルです。
- まず制作目的で分類（原則3つ＋受注制作）
- 次にフェーズ（完成前／完成後、確実性が高まったか）を見る
- 資産計上は確実性＋客観性（証拠）が揃って初めて正当化される
- 実務では「何を資産／何を費用」と切り分けるために、支出の内容を分解して記録する
簿記の学習では、4つのパターンがあることと、
「市場販売＝マスター完成前は研究開発費」
「自社利用＝確実性で資産または費用」
を型として押さえれば、問題演習で一気に安定します。
実務では、競争や技術革新が激しいソフトウェア、あるいは広く研究開発全般で資料をいちいち作成して残すのはむしろ邪魔になるでしょう。
最低限「ここまで進捗した」「ここまでいったから売れるだろう」などの判断ポイント毎に承認証跡や合意した文章と開発進捗資料を残すようにしてください。
最後までお読みいただきありがとうございました。
記事を読んだ感想、質問、疑問点あるいはご指摘事項がありましたら質問フォームにご記載ください。
可能な限りご回答させていただきます。
コメント