開発費・資産系
自社開発ソフトの資産計上・減損・除却。開発プロジェクトそのものが会計イベントになる領域
「開発に着手したら、経理から『このプロジェクトは資産計上します』と言われた」「作り直しプロジェクトの途中で、監査から減損の話が出てきた」「とっくに止めた旧システムが、帳簿にはまだ載っていた」。このカテゴリは他のカテゴリと入口が違います。トリガーになるのは「実装する機能」ではなく、開発プロジェクトそのものです。自社で使うソフトウェアを作る行為は、会計上は「資産を作る行為」になることがあります。
そして、資産計上・減損・除却の判定材料は、現場にしかありません。 いつ要件が固まったか、誰がどの作業に工数を使ったか、あの機能の作り直しが始まったこと、旧システムを止めたこと——経理はこれらを自動的には知りえません。判定するのは経理ですが、兆候を検知して伝えられるのは作る側だけです。このカテゴリの各ページは「何を検知したら、経理に何を投げるか」の形で書いています。
なお、このカテゴリの根拠は法令ではなく会計基準・実務指針（と税務上の取り扱い）が中心で、上場か非上場か、会計基準ベースか税務基準ベースかで扱いの温度差があります。細かい判定はせず、「自社ではどう扱っているか」をまず経理に確認するところから始めてください。
こんな状況になっていたら
- 自社サービスの新規開発・リプレースが始まるのに、資産計上するかどうかを誰も経理に確認していない
- 工数の集計に、開発作業と、調査・PoC・新メンバーのキャッチアップ期間が区別なく混ざっている
- 資産計上して作った機能の「作り直し」「フルリニューアル」が始まろうとしている
- 「効果が出るのは後続フェーズの完成後」という構成の開発で、後続フェーズの凍結が先行フェーズの資産（仮勘定）に響くことを誰も意識していない
- もう使っていない機能・旧システムが、止めた記録もないまま帳簿に載り続けている
開発の状況別の確認事項
| 開発の状況 | 主な確認事項 |
|---|---|
| 自社開発ソフトの資産計上（新規開発・大規模改修に着手する） | 「この開発、資産計上前提？」を着手前に経理に確認する。資産計上するなら、工数集計の開始時点（要件確定・稟議）と、資産に乗せない作業（調査・PoC・キャッチアップ・保守）の区分を最初に決める。工数管理の設計がそのまま会計記録の元データになる |
| 資産計上した開発の減損（方針転換・計画未達・遊休化） | 凍結したはずの仕様の大幅変更、資産計上済み機能の作り直し、事業ピボット、後続フェーズの凍結、収益計画の大幅未達は減損の兆候になりうる。決算で経理が気づくのでは遅い。現場で起きた時点で経理に共有する |
| 使わなくなったソフトの除却（機能・システムの廃止、リプレース） | 使わなくなったことが明らかなら、物理的な廃棄がなくても帳簿から落とせる扱いがある。「今後使わない」ことを示す日付のある記録（廃止の稟議・停止作業の記録・リポジトリのアーカイブ）を残し、経理に共有する |
このカテゴリの勘所
経理は現場を見ていません。 残高DBや支払い期日と違って、資産計上・減損・除却のトリガーは開発現場のできごと（着手・方針転換・停止）です。経理が決算作業で気づいたときには、工数は区分できない形で集計済み、停止の記録は残っていない、ということが起きます。逆に言えば、作る側が「これは経理に伝えるやつだ」と気づけさえすれば、あとは定型の連絡ひとつで済みます。各ページに経理への連絡テンプレを置いているので、そのまま使ってください。
判定はしない。検知して伝える。 資産計上の要否も、減損損失の要否・金額も、除却のタイミングも、決めるのは経理・会計士です。作る側の仕事は、判定に必要な現場の事実（日付・工数・意思決定の記録）を、判定できる形で残しておくことです。
あわせて確認
- 企画・着手前のチェックは → フェーズ1：機能企画・要件定義時
- 運用中・廃止時のチェックは → フェーズ5：運用継続中
- 外注で開発する場合の支払い期日は → 外注費の支払い管理（外注制作費も取得価額に関わります）