いつか役に立つかもしれないソフトウェアの会計の話
Supershipグループ Advent Calendar 2020の12/22の記事です。
注: 筆者は会計の専門家ではありません。実務においてはここに書かれている内容を鵜呑みにせず、専門家へ相談してください。
自己紹介
Supershipで検索エンジンやデータ基盤にまつわる事業の責任者をやりつつ、プロダクト開発本部というエンジニア組織でマネジメントをしている @sanojimaru です。
もともとエンジニアから起業しAppVadorという動画広告のサービスをやっていたのですが、縁あってSupershipにjoin後、様々な事業を転々としながら今に至ります。不本意ながらビジネス側の人になってしまい、開発の最前線から離れがちなので、今日は、全然技術関係ない面白くない話として、ソフトウェアの会計にまつわる用語について簡単に紹介させてください。
ソフトウェア会計基準とは
そもそも会計基準とは何でしょうか。
会計基準 - Wikipediaを開くとこのような説明があります。
会計基準(かいけいきじゅん)とは、主に財務会計における財務諸表の作成に関するルールをいう。
聞き慣れない単語ですが、財務会計と財務諸表が重要そうです。
まずは財務会計を掘り下げます。
財務会計(ざいむかいけい、英: financial accounting)は、財務諸表を核とする会計情報を、企業外部の利害関係者(株主、債権者、徴税当局など)に対して提供することを目的とする会計である。 経営者や企業内部の管理者に対する情報提供を目的とする管理会計とは内容が大きく異なる。
ざっくり、会社の状態を外部の利害関係者に提供するための情報と思っておけばよさそうです。企業は株主から資本(主にお金)を調達し、時に銀行から融資を受けて事業を行い、儲けた利益の一部を株主に還元し、借り入れは返済し、税金を納めます。この一連の企業活動を行う上でとても重要な情報です。
次に財務諸表とは、基本的にこの3点を指します。それぞれに役割があり、財政状態は健全か、会社がちゃんと儲かっているか、資金繰りは大丈夫か、などを確認できたりします。
- 貸借対照表(BS)
- 損益計算書(PL)
- キャッシュフロー計算書(CF)
財務諸表というとっても大切な情報を作成する上でのルールが会計基準という理解で良さそうです。
数ある会計基準の中でも、ソフトウェア開発費を対象にしたソフトウェア会計基準は、日本においては2000年3月以降に義務付けられたようです。
企業は2000年3月以降の決算から、この基準に沿ってソフトウェア開発費を会計処理することが義務付けられた。 コンピューターの発達による高度情報化社会の進展の中で、企業活動におけるソフトウェアの重要性は増し、それに伴いその支出も増加している。
重要なのは、ここで言及されている会計処理が主にソフトウェア開発に掛かる費用の処理であることです。ソフトウェア開発に掛かる費用の大部分はエンジニアの人件費です。一般的には大なり小なり人手を掛けて、何らかの方法(TeamSpiritやらエクセルやら)で工数管理が行われていると思います。この工数管理が不適切(会計基準に沿わない状態)であることで、意図せず不正会計を行ってしまう危険性があります。逆に、適切な人的リソースの運用と工数管理をセットで行うことが、財務状況の健全化や事業収益の安定化を図ることができそうです。小難しいですがとても大切そうです。
具体的には、日本公認会計士協会が研究開発費及びソフトウェアの会計処理における実務指針というドキュメントを公開していました。
コーディングルールと会計基準は守らないと後が大変そうです。
資産計上
またWikipedia引用しようとググったらすごくいい記事が見つかってしまったのでインターネットすごいと思いました。書きたいこと全部書いてありました。
ソフトウェアを適切に資産として計上することで、減価償却という考え方を適用できるようになり、事業としては長期的な投資の意思決定ができるようになる。
ソフトウェア会計基準とは、「何でもかんでも減価償却で先送りしていいわけではありません。ソフトウェアの資産計上はこの範囲内でやりなさい」というルールのようです。
研究開発費及びソフトウェアの会計処理における実務指針によると、
市場販売目的のソフトウェアの制作に係る研究開発の終了時点は、製品番号を付すこと等により販売の意思が明らかにされた製品マスター、すなわち「最初に製品化された製品マスター」の完成時点である。この時点までの制作活動は研究開発と考えられるため、ここまでに発生した費用は研究開発費として処理する。「最初に製品化された製品マスター」の完成時点は、具体的には次の2点によって判断する。
1. 製品性を判断できる程度のプロトタイプが完成していること
2. プロトタイプを制作しない場合は、製品として販売するための重要な機能が完成しており、かつ重要な不具合を解消していること
これは市場販売目的のソフトウェアの場合ですが、製品化可能か判断できるプロトタイプが完成しているか、実際に製品化可能なソフトウェアが完成していることが条件となり、それ以前のプロトタイピングや未完成のソフトウェア開発費は研究開発費として処理する必要がありそうです。
自社利用のソフトウェアの資産計上の検討に際しては、そのソフトウェアの利用により将来の収益獲得又は費用削減が確実であることが認められるという要件が満たされているか否かを判断する必要がある。その結果、将来の収益獲得又は費用削減が確実と認められる場合は無形固定資産に計上し、確実であると認められない場合又は確実であるかどうか不明な場合には、費用処理する。
こちらは自社利用のソフトウェアの場合ですが、収益獲得または費用削減の効果が確実な場合のみ、資産計上可能なようです。効果ははっきりしないけどテスト導入してみる、みたいなものは費用として処理されそうです。
研究開発
ソフトウェア開発に掛かる費用の中で、資産計上ができないものが研究開発費です。研究開発費及びソフトウェアの会計処理における実務指針によると、研究開発費はこのように定義されています。
「研究開発費等に係る会計基準」では、研究とは、「新しい知識の発見を目的とした計
画的な調査及び探究」であり、開発とは、「新しい製品・サービス・生産方法(以下、
「製品等」という。)についての計画若しくは設計又は既存の製品等を著しく改良するた
めの計画若しくは設計として、研究の成果その他の知識を具体化すること」とされている
これは資産計上での説明と表裏一体になりそうですが、例として「オンプレサーバーで稼働しているシステムのクラウド移行を検証するPoC」などは完全に研究開発になりそうです。
また、下記のような記述もあり、リリース後のソフトウェアにおいても、著しい改良においては新規開発と同様の扱いになりそうです。
製品マスターの機能の著しい改良に要した費用
従来の製品マスターとは別個の新しいマスターの制作のためのコストとみなされるよ
うな費用は、研究開発費として処理する。
保守
資産計上されているソフトウェアにおいても、そのソフトウェアの機能維持に要した費用は資産計上ではなく費用処理となるようです。bugfixやミドルウェアのアップデートなど、機能面に影響のないものは全て費用処理されると思ってよさそうです。
(2) ソフトウェアの機能維持に要した費用
バグ取り、ウィルス防止等の修繕・維持・保全のための費用は、発生時の費用として処理する。
最後に
普段何となく工数管理してるものの、企業活動としてはとても重要なことなので少しでも興味をもってもらえると嬉しいなと思いましたが、テーマが大きすぎてとりとめない感じになってしまいました。少し反省してます。
お約束ですが、全然技術的じゃない話も書かせてくれる心の広いエンジニアチームに興味が湧いた方は
【Supership株式会社 採用サイト】
是非ともよろしくお願いします。
Author And Source
この問題について(いつか役に立つかもしれないソフトウェアの会計の話), 我々は、より多くの情報をここで見つけました https://qiita.com/sanojimaru/items/cb0b43ff7d13779efb55著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .