ASC 350-40: 内部利用ソフトウェアの資産計上と費用処理

ASC 350-40—検索で350/40と入力されることが多い基準書トピック—は、内部利用ソフトウェアに関するFASBルールです。つまり、開発コストを当期の費用として計上するのか、無形資産として資産計上して後で償却するのかという問題です。従来の3段階モデル（ASU 2025-06の強制適用日までは、ほとんどの提出企業が依然として適用）では、その答えは1つの表に収まります。

ASU 2025-06（2025年9月18日発行、2027年12月15日以降に開始する年度から強制適用）は、これらの段階ラベルを「完了の可能性が高い」という閾値に置き換え、より多くのコストが費用処理されることを示唆しています。以下のセクションでは、ASC 350-40の適用範囲、段階の詳細、2025年アップデート、資産計上/費用処理のチェックリスト、およびこの選択がEBITDAと貸借対照表に与える影響について説明します。

ASC 350-40の適用範囲​

ASC 350-40は、内部利用ソフトウェアに関するFASB基準です。つまり、自社の業務用に構築または購入するソフトウェアであり、顧客への主要製品として販売するものではありません。例としては以下が挙げられます。

• 社内CRM、ERP、HR、会計システム
• クラウドインフラツールとDevOpsプラットフォーム
• 顧客向けに運営するSaaSプラットフォーム（顧客はサービスとしてアクセスし、インストールするライセンスソフトウェアではない）
• 社内データパイプライン、ダッシュボード、分析ツール
• カスタムワークフローやバックオフィス自動化

顧客が自社のマシンにインストールするライセンスソフトウェアを販売している場合は、外部販売用ソフトウェアに関するASC 985-20が適用され、別のルールがあります。ほとんどの現代のSaaS企業は、顧客がホスト型サービスとしてソフトウェアを利用するため、ASC 350-40に該当します。

この基準が答える中核的な問いは、ソフトウェア構築に費用を費やすとき、そのコストを即時に費用処理すべきか、無形資産として資産計上して将来期間にわたって償却すべきか、ということです。

従来の3段階モデル（ASU 2025-06以前）​

何十年もの間、ASC 350-40は段階ベースのフレームワークを使用してきました。2027年まではほとんどの提出企業に引き続き適用される従来のガイダンスでは、ソフトウェア開発は3つの明確なフェーズに分類されます。

段階1: 予備検討段階​

これは探索フェーズです。要件の定義、技術の評価、ベンダーからのデモ取得、内製・購入・中止の決定などを行います。この段階のすべてのコストは、研究開発費と同様に発生時に費用処理されます。その理由は、経営陣がコミットするまでは、資産となる可能性が高いとは言えないからです。

ここでの活動には以下が含まれます。

• 概念の策定と設計代替案の検討
• ベンダーデモと技術評価
• 費用便益分析と実現可能性調査
• アプローチまたはベンダーの最終選定

段階2: アプリケーション開発段階​

経営陣がプロジェクトを承認し、資金をコミットし、完了の可能性が高い場合に資産計上が始まります。この段階では、実際の構築—コーディング、テスト、設定、統合、インストール—をカバーします。

この段階で資産計上可能なコストには通常、以下が含まれます。

• 開発者、QAエンジニア、プロジェクトマネージャーの給与と福利厚生（ソフトウェアのコーディング、テスト、設定に直接関与した時間のみ）
• 開発作業に対する外部コンサルティング費用
• アプリケーション構築に使用するソフトウェアライセンスとツール
• 開発で消費される材料とサービスの直接コスト
• 利息費用（限られたケース）

資産計上は、ソフトウェアが実質的に完成し、意図した使用が可能な状態になった時点で終了します。通常は、テストが完了し、段階的な展開であってもシステムが本番稼働にデプロイされた時点です。

段階3: 実装後段階​

稼働開始後は、継続的なコストは費用処理に戻ります。トレーニング、保守、バグ修正、定期的なサポートはすべて費用処理されます。例外は、新機能を追加する拡張（既存機能の修正や維持だけでなく）で、段階2と同じ基準で資産計上できます。

2025年の主要アップデート：ASU 2025-06​

2025年9月18日、FASBはASC 350-40を大幅に近代化するASU 2025-06を発行しました。このアップデートは、2027年12月15日以降に開始する年度から強制適用され、早期適用は認められています。

この変更は構造的なものです：3段階モデルは廃止されました。FASBは、要件が進化し「段階」が重複または並行して実行される現代のアジャイルおよび反復的な開発慣行に、従来のフレームワークが適合しなかったため、プロジェクト段階への言及をすべて明示的に削除しました。

新しい原則ベースの閾値​

改訂基準では、以下の両方の条件が満たされた場合にのみソフトウェアコストを資産計上します。

1. 経営陣の承認：経営陣がプロジェクトを承認し、資金をコミットしている。
2. 完了の可能性が高い閾値：プロジェクトが完了し、ソフトウェアが意図した機能を果たす可能性が高い。

2番目のテストが実際の機能を果たします。FASBは、完了の可能性を評価するために重要な開発不確実性という概念を導入しました。以下を評価する必要があります。

• ソフトウェアに、コーディングやテストで検証されていない新規または未証明の機能が含まれているかどうか
• パフォーマンス要件がまだ未確定であるか、大幅な改訂の対象となっているかどうか

重要な不確実性が存在する場合、不確実性が解消されるまで資産計上を延期する必要があります。FASBは、特に要件が継続的に反復されるSaaS企業において、新しいルールによりより多くのソフトウェアコストが費用処理されると予想していることを示しています。

実務上これが意味すること​

真に新しいもの—AIエージェントプラットフォーム、新しい自動化エンジン—を構築しているスタートアップにとって、新しいルールはより多くの支出を早期に営業費用に押し上げる可能性があります。明確に定義されたシステムを拡張している成熟企業にとっては、実務上の影響は小さくなります。いずれにしても、機械的な段階チェックから判断ベースの閾値への移行は、企業が経営判断、技術的実現可能性、プロジェクトの状況についてより明確な文書化を行う必要があることを意味します。

資産計上可能なものと不可能なもの：実用的チェックリスト​

従来の段階モデルを適用するか、新しい原則ベースのテストを適用するかにかかわらず、資産計上可能な支出と費用処理される支出の境界線は、精神としては似ています。以下は実用的なチェックリストです。

一般的に資産計上可能​

• 構築段階における開発者、デザイナー、QAの直接人件費
• それらの従業員の配賦された給与税と福利厚生
• 開発作業に対する外部コンサルティングおよび請負業者費用
• 開発で直接消費されるソフトウェア、ツール、クラウドインフラストラクチャのコスト
• ローンチ後の新機能開発コスト（能力を実質的に拡張する拡張機能）
• 変換ソフトウェア（旧データを新システムに移行するソフトウェア）の開発コスト（データ変換活動自体ではなく）

一般的に費用処理​

• 予備調査、ベンダー選定、実現可能性分析
• 新しいシステムに関する従業員トレーニング
• データクレンジング、調整、レコード移行
• 定期的な保守、バグ修正、軽微なリファクタリング
• 重要な開発不確実性の期間中に発生したソフトウェアコスト
• 開発に直接関連しない一般管理費
• マーケティング、サポート、ローンチ後のカスタマーサクセス活動

タイムトラッキングの問題​

最大の実務上の課題は、エンジニアリング時間の配分です。週40時間働くシニアエンジニアが、100%資産計上可能な作業をしている可能性は低いです。本番環境のデバッグ、チームメンバーの指導、スタンドアップへの参加、レガシーシステムのプルリクエストレビューも行っています。防御可能なタイムトラッキング方法（プロジェクト別にタグ付けされたエンジニアリングチケット、タイムトラッキングソフトウェア、または正式な配分調査）がなければ、資産計上の見積もりは監査の審査に耐えられません。

財務諸表への影響​

同じ金額を資産計上するか費用処理するかで、財務諸表は劇的に異なります。

損益計算書への影響​

資産計上されたコストは、支出した期間の損益計算書に影響しません。代わりに償却されます。通常、内部利用ソフトウェアは3〜5年の定額法です。したがって、1年目の資産計上された100万ドルのエンジニアリング支出は、年間20万ドル〜33万3千ドルの償却費を生み出すだけで、1年目の営業利益を実質的に増加させます。

これが、資産計上がEBITDAを押し上げる理由です。償却は定義上EBITDAから除外されるため、より多くの開発コストを資産計上すると、営業費用（EBITDAを減少させる）から償却（EBITDAに影響しない）へと金額が移動します。SaaSメトリクスを精査する投資家は、このダイナミクスを見通すために「資本化R&D前EBITDA」や、現金ベースのR&Dを使用したルール・オブ・40の計算を見ることがよくあります。

貸借対照表への影響​

資産計上されたソフトウェアは、「資本化ソフトウェア開発コスト」などと表示される長期無形資産として表示されます。これにより：

• 総資産と純資産が増加する
• 収益が資産ベースよりも速く増加する場合にのみ、総資産利益率（ROA）が改善する
• プロジェクトが中止されたり価値が低下した場合に減損テストが必要な資産が生じる

プロジェクトが開発途中で中止された場合、以前に資産計上したコストを償却しなければならず、突然の、しばしば重要な損失が発生します。これが、新しいASU 2025-06が完了の可能性が高い閾値をこれほど重視する理由の一つです。

キャッシュフロー計算書への影響​

資本化された開発コストは通常、投資活動（営業活動ではない）に分類されるため、営業キャッシュフローがより強く見えます。洗練された投資家は、企業を比較する際にこれを調整しますが、ヘッドラインの数字は依然として恩恵を受けます。

企業が問題を起こす一般的な間違い​

監査人や買収者は、同じエラーを繰り返し見ています。

承認前コストの資産計上​

典型的な間違いは、経営陣が正式にプロジェクトを承認する前に費やされたエンジニアリング時間を資産計上することです。文書化された承認と資金コミットメントがなければ、これらのコストは費用処理されるべきでした。経営陣がいつコミットしたかを確立する議事録、取締役会の承認、または書面による署名があることを確認してください。

プロジェクトレベルの文書化がない​

規制当局や監査人が「資産計上したプロジェクトを見せてください」と尋ね、一般的なエンジニアリング支出だけを指し示す場合、負けます。プロジェクトごとの記録が必要です：範囲、承認日、予算、状況、請求された時間。

すべてのエンジニアリング時間を資産計上可能として扱う​

シニアエンジニアは、バグ修正、コードレビュー、会議出席、インシデント対応を行います。これらはすべて資産計上できません。エンジニアリングチームの給与にある割合を掛けるだけの企業は、監査を生き残ることはほとんどありません。

ローンチ後も資産計上を継続​

ソフトウェアが意図した使用に利用可能になった瞬間、資産計上は終了します。その後のバグ修正、パフォーマンスチューニング、軽微な改善は営業費用です。新しく別個にスコープされた機能は新しい資産計上期間を開始できますが、定期的なローンチ後の作業はできません。

減損テストの忘れ​

資産計上されたソフトウェアは資産であり、価値が下落した場合には減損しなければなりません。製品を休止する、機能を廃止する、またはシステムを根本的に書き換える場合、再評価して以前の残高を償却する可能性が高いです。

防御可能なプロセスの構築方法​

資産計上が自社に適していると判断した場合、プロセスはポリシーと同じくらい重要です。

1. ソフトウェア資産計上ポリシーを作成する。 対象となるプロジェクト、承認プロセス、耐用年数の見積もり、時間の配分方法を定義します。CFOまたは監査委員会の承認を得ます。

2. プロジェクトレベルでエンジニアリング時間を追跡する。 これが基礎となるインプットです。Jiraラベル、プロジェクトトラッカーのカスタムタグ、正式なタイムシートのいずれを使用しても、「エンジニアXがプロジェクトZの資産計上可能な作業にY％の時間を費やした」ことを立証できる必要があります。

3. 経営陣の承認を文書化する。 各資産計上プロジェクトには、承認の証拠—日付入りの書面による承認、取締役会議事録、または経営陣が署名したプロジェクト憲章—が必要です。

4. 重要な不確実性を定期的に再評価する。 新しいルールでは、機能がまだ新規または未証明であり、要件が安定しているかどうかを監視する必要があります。エンジニアリングリーダーシップとの四半期レビューが妥当です。

5. プロジェクトごとに償却スケジュールを構築する。 各資産計上プロジェクトは、使用可能になった時点で償却を開始し、その資産の原価基準、累積償却、残存耐用年数を追跡する必要があります。

6. プロジェクトが変更された場合に減損テストを実施する。 資産計上された作業を中止、実質的に書き換え、または廃止するたびに、減損分析を実行し、必要に応じて減損損失を計上します。

簿記にとってこれが重要な理由​

ソフトウェア資産計上は、初日の簿記の規律が何年も後に報われる分野の一つです。シリーズB調達中の投資家は試算表を引き出します。売却プロセス中の買収者は取引を仕訳まで遡って追跡します。IRSはGAAP処理を、独自のルールを持つSection 174のR&D税務処理と比較するかもしれません。帳簿が資産計上プロジェクトを営業費用から分離しておらず、エンジニアリング時間の請求を特定のプロジェクトに結び付けられず、またはクリーンな償却スケジュールを維持していない場合、すべての監査とデューデリジェンスサイクルが苦痛になります。

修正は概念的に簡単です：クリーンな勘定科目構造を維持し、プロジェクトレベルで時間を追跡し、すべての資産計上仕訳の背後にある決定を文書化します。最初からこれを行うことで、後で高くつくクリーンアップを避けられます。

ソフトウェア会計を監査対応に保つ​

最初の社内プラットフォームを資産計上しているのか、数十のプロジェクトにわたって償却スケジュールを運用しているのかに関わらず、クリーンな財務記録が基盤です。Beancount.ioは、透明性がありバージョン管理された帳簿—すべての仕訳が追跡可能で、すべての勘定科目が監査可能で、すべてのレポートが再現可能—を提供するプレーンテキスト会計を提供します。複数のプロジェクトにわたる資産計上開発を追跡しているソフトウェア企業にとって、コードのように読める帳簿は大きな利点です。無料で始めるそして、開発者と財務プロフェッショナルがプレーンテキスト会計に切り替えている理由をご覧ください。