Definition
ソフトウェア開発企業の監査で、開発段階と研究段階の区分が不明確だった事例は珍しくありません。金融庁の2023年度モニタリングレポートでは、受託開発案件において開発開始時点の判定根拠が不十分とされた事例が複数指摘されています。境界線を1ヶ月ずらすだけで、資産計上額が数百万ユーロ変動する。調書上の判定時点がずれていれば、検査で防御できない。
仕組み
IAS 38.57は研究支出と開発支出を明確に区別しています。研究段階とは、新知識の習得を目的とした計画的調査活動。この段階の支出は全額費用化されます。開発段階は、研究成果を商品化・サービス化するための活動であり、IAS 38.59が掲げる6要件を全て満たす場合に初めて資産化が認められる。
6要件は以下のとおりです。(1) 技術的な実現可能性、(2) 資産の完成と販売(または使用)の意図、(3) 販売又は使用のための市場の存在、(4) 技術的・財政的資源の確保可能性、(5) 開発段階の支出を信頼性をもって測定できること、(6) 資産の使用による経済的便益の可能性が高いこと。1つでも欠ければ、その時点では資産化できません。
実務では、ソフトウェア開発、医薬品開発、鉱業権の取得・開発が該当することが多い。正直なところ、開発段階に入った時点を明確に文書化するのが最も難しい部分です。その時点の判断根拠は後からでは追跡できなくなる。意思決定時の同時期的な証拠が必要であり、後追い的な調書では検査に耐えません。
計算例:テクノロジー開発企業
企業名:東京ソフトウェア開発株式会社 業種:受託ソフトウェア開発 会計年度:2024年度(IFRS適用企業) 売上高:3,200万ユーロ
支出の段階判定 同社は新型生産管理システム「ProdControl」の開発を開始しました。開発チームは初期3ヶ月を技術調査(可能性検討、既存システム分析)に充てた。支出額は450万ユーロ。この段階は市場可能性の確認前であり、販売意図も固まっていません。IAS 38.9の定義に基づき、研究段階と判定。450万ユーロは全額費用化。
調書メモ:「研究段階の支出」ファイルに、当該期間のタイムシート、プロジェクト会議議事録(技術実現可能性の記載なし)、支出明細を保管。費用化根拠を監査調書に記載。
開発段階への移行判定 4ヶ月目、顧客A社(大手製造業)とのプロトタイプデモ後、本格開発の受託契約を締結。その時点でIAS 38.59の6要件を評価しました。(1) プロトタイプ完成により技術的実現可能性が高い、(2) A社との書面契約で販売意図確定、(3) 契約金額150万ユーロで市場存在を確認、(4) 人員・システムリソース確保済み、(5) 開発管理システムで支出追跡が可能、(6) 契約金額超過の可能性なし。全6要件を充足。この時点から開発段階と認識。
調書メモ:受託契約書、契約時点の取締役会決議(開発ゴーサイン)、開発開始直前の技術実現可能性評価報告書をファイルに保管。「開発段階移行の根拠」調書に6要件の評価表を作成。
開発段階支出の資産化 開発段階開始後の支出(人件費・外注費・ハードウェア)1,200万ユーロを自社開発無形資産に計上しました。毎月の支出額を開発進捗率で按分し、按分不可能な共有支出(管理人員給料の一部等)は費用化。
調書メモ:開発期間中の月次支出明細、開発完了時の最終支出額、開発進捗率の計算根拠(マイルストーン達成度)。
商品化完了と償却の開始 12ヶ月後、開発完了。顧客A社への納入予定。この時点で資産認識が確定し、残存耐用年数5年(予定)で定額法による償却を開始しました。年間償却費:240万ユーロ(1,200万ユーロ ÷ 5年)。
調書メモ:開発完了報告書(QA承認、顧客承認)、耐用年数の見積根拠(顧客契約のサポート期間等)、償却計算表。
結論:開発段階と研究段階の区分が曖昧であれば、450万ユーロが誤って資産化されるか、1,200万ユーロが誤って費用化される可能性がある。境界線の判定時期(顧客契約締結日)を明確に文書化することが、監査上の最大の争点。
レビュアーと実務者が見落とすこと
金融庁の2023年度モニタリングレポートでは、ソフトウェア開発企業を対象とした監査で、開発段階と研究段階の区分基準が不明確な事例が複数指摘されました。受託開発では、顧客契約時点と開発開始時点にズレが生じやすく、その間の支出区分が曖昧になる。繁忙期に複数の開発案件を並行して見ていると、各案件の段階移行時点を個別に追跡する余裕がなくなるのが現場の実態。
IAS 38.59の6要件を部分的にしか評価しないケースも目立ちます。「技術的実現可能性」と「販売意図」だけで判定し、「見積りの信頼性」や「経済的便益の可能性」を十分に検討していない。IAS 38.64は、資産化の見積りが信頼性をもって決定できない場合は資産化不可と定めている。見積りの不確実性が高い開発(受託先企業の経営状況が不安定、開発仕様の大幅変更リスク等)では、この評価が手薄になりがち。
段階区分の同時性の欠如も問題です。開発段階移行の判定が、契約締結後数ヶ月経ってから行われるケース。その間の支出計上根拠が宙に浮く。IAS 38は段階移行の時点を明確に定めるよう求めており、判定は当該時点の情報のみに基づくべきもの。後発的な判定は結果論であり、後知恵判定として審査で防御困難。
自社開発無形資産 vs. 既製ソフトウェア購入
既製ソフトウェアを購入する場合、IAS 38ではなくIAS 16(有形資産)の会計処理が適用されることがあります(購入権を含むライセンス)。ライセンス期間が限定され、企業が使用期間を制御できない場合はIFRS 16(リース)の対象になることも。自社開発との最大の違いは、開発段階と研究段階の区分が存在しない点。購入時に全額資産化が決定されるため、段階判定の支出按分が不要です。
既製ソフトウェアの場合、IAS 38.33に基づきライセンス期間にわたって定額法で償却します。自社開発は開発期間中の支出が資産に計上されるため、償却開始時期が開発完了時点に遅延する。既製購入は購入年度から償却が始まり、自社開発は完了年度から。結果として、初期段階では既製購入のほうが利益圧迫が大きくなる傾向にあります。
開発完了後の減損監視
自社開発無形資産の減損兆候を見落とすケースは少なくありません。IAS 36に基づき、毎年の減損テストが必要。開発完了後に市場環境が悪化した場合(顧客需要の急減、競合製品の出現、技術の陳腐化等)、直ちに減損評価を行う。実務では開発完了時の資産計上に注目が集まり、その後の減損監視が手薄になる傾向がある。調書上、開発完了後の減損レビュー手続が記載されていない案件は、品管レビューで引っかかります。
関連する用語
- 研究支出:市場化前の新知識習得活動の支出。全額費用化。IAS 38.54 - 開発支出:商品化・サービス化の活動支出。6要件充足時に資産化。IAS 38.59 - 技術的実現可能性:実装可能性と技術的困難さの度合い。開発段階認識の必須要件 - 経済的便益:資産使用から将来キャッシュフローが流入する可能性。IAS 38.59(f) - 償却:開発完了後、予定耐用年数で定期的な費用化。IAS 16.50に準拠
関連する基準と資料
- IAS 38第57項から第67項:自社開発無形資産の認識・測定 - IAS 36:無形資産の減損 - IAS 8:会計方針の選択と推定
---