一人目の経理になったらやるべきこと（無形固定資産編）
目次
チェックポイント
ありがち論点、ソフトウェアです。
今回の範囲
有形固定資産の回でもフライングしましたw 無形固定資産と書きましたが、もう論点はソフトウェアです。
ソフトウェアの計上、正しくしていますか？ という点に尽きます。
ソフトウェアは計上されているけど…
B/S見た時にソフトウェア計上されている場合、 まず確認しなきゃいけないのは計上根拠です。
実際によくあるのは、こんな例です。
- システム外注してて、その外注費を100%ソフトウェアに計上する
- 一番最初に作った基幹システムのみ、ソフトウェア計上がされている
- 外注に聞いたら、新規開発6割くらいって聞いたから外注費を6：4で資産計上している
残念ながら、こんな場合は正しく計上されていないので、
以下のステップで計上しなおしましょう！
ステップ①：まず前提を知る
前提と知っていなければならないことは、
会計と税務で計上基準がずれる、ということです。
ものすごく簡単に言うとこんな違いになります。
【会計】
- ソフトウェアが将来利益を出すことが確実な場合、資産計上する。
- つまり、赤字の場合は、将来利益を出すのが確実とは言えないため、費用計上しなきゃいけない。
【税務】
- とりあえず資産計上。
そうなんです。厄介なのは多くのスタートアップの場合、
会計と税務で不一致になるんですよね。
ただ、税務面でソフトウェア計上は確実にしなきゃいけないので、
赤字決算の場合でも、いずれ会計でもやるんだからと指針を作成しましょう。
より詳細に、ソフトウェアの計上を知識面から押さえたい、という方は
以下のリンクおススメです。
ステップ②：ソフトウェアの計上根拠を探る
ソフトウェア計上で重要な考え方は、新規開発と保守メンテナンスです。
新規開発とは以下のようなことを言います。
新規開発にあたる部分はソフトウェアとして計上します。
- 基幹システムのコア部分の開発（ないと動かないよ）
- 新機能の追加（今までなかった機能リリースしたよ）
- バージョンアップ（全体見直してレベルアップさせたよ）
では、保守メンテナンスはどうでしょうか。
保守メンテナンスにあたる部分は、費用計上になります。
- 既存機能のバグ修正
- 既存機能の保守
- とにかくシステムに付加価値を与えない作業
以下のようにまとめるとわかりやすいかもしれません。
新規開発＝システムに付加価値を与えるもの
保守メンテナンス＝既存機能に関わる作業
ステップ③：工数を区分しよう
新規と保守の考えはわかった。
じゃあ、その工数をどうやってわければいいのだ、と。
外注や業務委託のみ開発に当たっていて、
社員は開発エンジニアに対して、指揮命令を行っている場合は比較的簡単です。
ソフトウェア計上対象になるのは、外注・業務委託のみになりますので、
彼彼女らに日報や月報を提出いただき、項目・作業工数を基に外注コストを按分します。
この時に注意していただくのは、項目のところに必ず
新規開発か保守かわかるように、フラグを付けていただくことです。
(もしくはプロジェクトコードなどで明瞭に管理していることが分かること）
常にエビデンスとして提出することを意識して、第三者に理解できるようにすることが重要です。
難しいのは、社内エンジニアが開発に当たっているケースです。
スタートアップのエンジニアはとにかく多能工です。
タスク管理はしているけど、新規・保守の区分が難しいケースは多々あります。
この場合は定義づけしていきましょう。
どのタスクが新規開発で、どのタスクが保守作業なのかを場合分けしていきます。
また、チームが分かれている場合は簡単です。
開発メインでやっているチームは、新規開発にあたる工数、
保守メンテナンスチームは、保守メンテナンス工数とばっさり区分できます。
この場合重要なのは、納得性と透明性です。
開発チームのタスクや保守メンテナンスチームのタスク一覧を見せてと監査法人に言われたら
どや顔で出せる体制づくりと、そのタスク一覧が定義と矛盾がないようにしましょう。
ステップ④：ストーリーを考える
じゃあ、後は積み上げ…の前にちょっと立ち止まりましょう。
いったいいつから、ソフトウェアを計上すればいいのかと。
考えてみてくださいよ。
ソフトウェアの耐用年数は大体5年です。
現時点ですでに5年経過しているものはもう償却しきっているので、
過去を振り返る必要はないのです。
さらに、開発のロードマップを見て、
最初の基幹システムから大規模補修がなかったら…
ソフトウェア計上は現時点では必要ないかもしれません。
このように、現時点でどのような状況にいるのかを整理して、
どの部分をソフトウェア計上するべきかを描きましょう。
積み上げ計算をするのはそのあとです。
計算は定額法で償却なので、難しくないです。
方法は有形固定資産で語ったシュミレーションと同じです。
まとめ
- ソフトウェアが計上されていたら妥当性を検討する
- ソフトウェアは会計と税務で不一致になる可能性がある
- 計上で大事なのは、新規と保守
- 計上ストーリーも考えてね
これさえ意識すれば、ソフトウェア計上も恐れることはない…はず！
言い忘れましたが、きちんとエンジニアに協力を依頼することも重要です。
