SaaSベンダーのソフトウエア会計基準への対応

現行基準は現在の開発環境に対応できていない

ソフトウエア開発環境の変化

「研究開発費等に係る会計基準」、会計制度委員会報告第 12 号「研究開発費及びソフトウェアの会計処理に関する実務指針」が公表されたのは、それぞれ1998年、1993年であり、その後抜本的な改正はなされておりません。

これらの現行制度は、製品マスターを制作し、その複写を販売することを前提に考えられています。 当時の環境は、社内のクライアントコンピュータにソフトウエアをインストールし、複数人で共有するにしても、社内サーバーにデータベースを構築して共有するオンプレミス型が主流でした。社内サーバーは、メンテナンスの手間や故障のリスクと無縁ではいられず、また、情報共有できる範囲にも物理的な限界がありました。

インターネット環境の発達により2023年現在では、多くのプロダクトがクラウド環境で提供されており 、クライアントコンピュータからブラウザでサーバーにアクセスします。ベンダー側も自社でサーバーセンターを保有しているのではなく、AWSなどのクラウドサービス環境を利用してサーバーを構築していることが一般的です。

そのため、ユーザー、ソフトウエアベンダー双方にサーバーは設置されておらず、ユーザーはAWSなどのクラウド環境のサーバーにブラウザを介してアクセスする構造となりました。

会計基準上の制作目的が現在環境に適合していない

現行基準上は、制作目的に応じた会計処理が定められております。

現在主流となっているソフトウエアプロダクトの提供方式では、明確に上記の制作目的に当てはめることができません。

SaaSプロダクトの制作目的は何になるのか

ユーザーはあくまでもソフトウエアにブラウザを介してアクセスしているに過ぎず、 ソフトウエアそのものを入手する訳ではありません。ベンダーもソフトウエアのアクセス権を販売して利益を得ることを目的に開発しており、ソフトウエアそのものを販売することを意図していないので、「市場販売目的」に分類するのは無理があるように感じられます。

当然、受注制作しているわけでもないため、現行基準に無理やり当てはめると「自社利用目的」なると考えられ、上場企業に対するアンケートでも、広く「自社利用目的」として会計処理が行われていることが示されています。

ソフトウエアの分類	会社数
自社利用目的のソフトウエア	１６社
市場販売目的のソフトウエア	１社
資産計上してない	９社

「収益獲得の蓋然性」をどのように考えるか

自社利用目的ソフトウエアの収益獲得への貢献

SaaS型のプロダクトを自社利用目的だと解釈した場合、新たな問題が生じます。会計基準は、「ソフトウエアの利用により自社の費用を削減することができるか。」により収益獲得の蓋然性を判断すべきであると考えています。

自社利用目的は、社内で利用するシステムを自社で開発したようなシチュエーションを想定しているためです。自社で利用するけれども、そのアクセス権を販売して事業を営もうとする場合、どのように収益獲得の蓋然性を判断すべきかが問題となりますが、明文の記載はないため解釈に委ねられることになります。

多くの上場企業では資産計上し５年以内の定額法の償却を実施

多くの上場企業では、開発に要した原価を機能別にプロダクトコードを付して区分集計し、自社利用目的であるから５年以内の定額法で償却を行っております。

ただ、ソフトウエアそのものを販売する訳ではない以上、ソフトウエアそのものに収益獲得の蓋然性を観念できるかは議論のあるところであり、ソフトウエア開発に要した費用の資産計上を行わず、全て費用処理している企業も存在します。

また、基準の考え方に準拠することを重視すれば、ライセンス販売でダウンロードしてユーザーが使用する形態の場合、プログラムそのものを販売することになるため、市場販売目的となり会計処理が異なってきます。同様の経済実態に異なる会計処理が適用されるため、概念フレームワークで示される根本的な原則と矛盾します。監査法人も主観的な判断を行わざるをえない領域となるため、事前のすり合わせが大切になります。

しかし、即時費用処理も一定程度受け入れられている会計処理だという点は着目すべきポイントだと感じます。

ソフトウエアの会計処理は連結会計と複合すると複雑化する

開発専門の在外子会社を保有している企業は多い

相対的に人件費の安いアジアに在外子会社を設け、開発専門の拠点を有している例は多いです。グループ間でソフトウエア開発の委託と受託が生じている場合には、極めて会計処理が複雑化するため注意が必要です。

税務上の要請から１００％親子会社でも利益をのせる必要がある

在外子会社で開発を行い、国内の親会社に納品することになると、税務上の要請から適正な利益を加算して取引価格を決定しなくてはなりません。日本の法人税法等においても、取引価格はあくまでも時価と見做す考え方はありますが、在外子会社の所在地域によっては、現地でより厳しい税務調査が行われることもあります。

下記の記事をご参照ください。

制作目的や資産計上額が連結単体で分離

連結上は、内部利益が消去され、制作目的も企業集団単位で判断するため自社利用目的となり、収益獲得の蓋然性を有する費用のみが資産計上されます。しかし、個別上は、子会社が開発したプロダクトは受注制作目的となり、子会社において棚卸資産として計上され、ユーザー側（親会社）では原則として購入原価の全額が資産計上されます。

勿論、親子会社の契約関係によっては、開発人材の一部を融通してもらう準委任契約に基づくサービスだと捉えられ、子会社に棚卸資産は計上すべきではないという解釈も考えられます。

このように連結と単体で制作目的が分離し、さらに税務上の要請から内部利益が生じて資産計上額が相違することで会計処理が複雑化する可能性があります。決算早期化の障害となることは間違いありません。

資産計上を行わないことも１つの選択肢

上記のような会計処理の複雑化を回避するため、資産計上を一切行わないのも一つの選択肢であると考えます。全額費用計上の会計処理が一定程度受け入れられていることは、会計処理を検討する上で重要なポイントであると感じます。

関連する内部統制もすべて省略できるため、メリットは大きく、監査法人が受け入れるのであれば有力な選択肢であると考えております。

クラウド・コンピューティングの分類

委員会資料では３つに分類

会計制度委員会研究資料第７号「ソフトウェア制作費等に係る会計処理及び開示に関する研究資料」では、クラウドコンピューティングサービスを以下の３つに分類しています。

SaaS「Software as a Service」

ソフトウエアをサービスのように利用できるものであり、現在主流のプロダクトの大半がこちらに該当する。

PaaS「Platform as a Service」

GoogleスプレットシートにおけるGASのようにデータベースや実行環境は準備され、アプリケーション自体はユーザーが用意するものであり、該当するプロダクトは多くない。

IaaS「Infrastracture as a Service」

AWSに代表されるようなインフラ環境のみが提供されるもの。

かつて社内サーバーなどで提供されていたインフラ環境は、現在ではベンダー側がIaaS型クラウドサービスを利用して構築しているようです。

AWSなどのIaaS型サービスの普及の背景には、需要に応じて柔軟に対応可能なことが挙げられます。AWSの設定画面でサーバーの機能やプランをカスタマイズ可能であり、急な環境の変化を恐れる必要がありません。かつては、サーバーに対する負荷の上限を見積もり、これに耐えうるインフラ環境を用意しなくてはなりませんでしたが、AWSでは容易に調整可能であり、利用に応じた使用料金を支払えば済みます。これは、自らサーバーを用意していた環境ではなかったメリットです。

また、様々なプロダクトがクラウド環境で提供されるようになった恩恵は会計業界では特に顕著です。データベースに格納されているデータにURLから容易にアクセスすることが可能になったことで、ソフトウエア間の転記の手間が大幅に削減され、内部統制の構築手法にも大きな影響をもたらしています。

税務上の留意点

別表調整の観点は見落とされがち

収益獲得の蓋然性等	企業会計（研究開発費等に係る会計基準）	法人税法（法人税法基本通達７－３－１５の３）
蓋然性を有している場合	無形固定資産に計上	無形固定資産に計上
不明な場合	一括費用処理	無形固定資産に計上
蓋然性を有していない場合	一括費用処理	一括損金算入

会計基準上は、収益獲得の蓋然性が認められる場合に限り、ソフトウエア制作に係る費用について資産計上が認められております。しかし、税務上は、収益獲得に貢献しないことの蓋然性が認められない限り資産計上することになっています。

そのため、連結会計が必要な法人では、厳密には連結、単体、税務、３つの会計上、資産計上額が分離する可能性があり、会計処理が極めて複雑化してしまうことも十分に考えられます。適切な会計処理を即時性をもって実施できるようにするには、事前の検討が非常に大切な論点と言えます。IPOを目指す会社などで、早い段階で専門家に相談せず、継続性の原則から事後の変更にハードルが生じてしまい、毎月複雑な会計処理と格闘せざるを得なくなった例は多く見受けられます。

別表調整を行っていないベンダーは多い

法人税法の規定に準拠すれば、広範なソフトウエア制作費用を税務上の資産に計上しなくてはなりませんが、このような処理を実施しているベンダーはかなり限定的であることは事実です。

仮に、法人税法の規定に準拠した処理を行うと、ソフトウエア開発を主たる事業として営んでいる事業者では、給与手当の支給等によりキャッシュアウトが生じているにも関わらず無形資産の計上により損金算入できない事態となり、担税力を超えた課税が求められるようなケースも十分に考えられます。他の事業との公平性という観点からも疑問を持たざるを得ません。しかし、租税法に明記されている以上無視することは許容されず、非常に難しい判断が求められる領域です。

内部統制上の問題点

基準が想定しているのはウォーターフォール型の開発

IPO準備企業などで内部統制の整備を始める際、前提となる開発環境の違いが問題となります。基準が想定しているのはウォーターフォール型の開発であるためです。

ウォーターフォール型の開発は、ステップを「要件定義」「設計」「開発」「実装」「テスト」「運用」等に分け、要件定義の段階で開発工程の全体像を固めてしまう方法です。しかし、現在では先に述べたようにクラウド環境へとプロダクトの提供環境が変化しており、AWSにプログラムを上書きすることで、容易にプロダクトを新しいバージョンにアップデートすることができます。

アジャイル開発が主流に

新しい機能の実装や修正も細かくプロジェクトを区分し、反復的に新機能の実装や修正が行われるようになってきました。アジャイル開発と呼ばれる手法です。企業が内部統制の整備を始めようとすると、実際の開発環境はアジャイル開発なのに、基準はウォーターフォール型の開発を前提に記載されているという壁に衝突します。

監査法人も、基準に準拠して監査を行わざるを得ないため、ウォーターフォール型を前提に内部統制の整備を要求せざるを得ません。そのため、どのような内部統制を整備したらよいかは手探りとなりますが、ソフトウエア開発に係る会計処理は、無形資産に関連し、工事進行基準と類似の論点も生じる不正の生じやすい箇所であるため、おのずと監査法人の監査は厳しいものとなります。

要件定義書やリリース判定、開発工数や人員数に係る申請と承認といった典型的な内部統制は残念ながら必須となるでしょう。SaaS型のプロダクトであっても、リリースによりソフトウエア仮勘定から本勘定へ振替がなされ減価償却が開始されますし、研究開発段階では資産計上が許容されないなど、開発の進捗状況が強く損益に影響する点は変わらないからです。採算の取れない大型の開発計画が実行されないかという、リスク管理の観点から内部監査の対象にもなると考えられます。

BackLogなどのタスク管理ツールを利用する

基準が想定しているような、紙の要件定義書を作成して合議体で承認し、押印をするような内部統制の整備は現実的ではありません。アジャイル開発では、要件定義から実装までが数日でなされるような例も珍しくなく、それらが反復的に実施されるからです。

エンジニア向けのタスク管理ツールは、内部統制を意図して開発されていないものの、内部統制に利用できるものが多く、タスク管理の業務プロセスの中に必要な内部統制を組み込む方法が推奨されます。

タスク管理ツール上でタスクのステータスを変更する際に、一定の統制を実施するよう規定を整備します。このような工夫をこらすことで、アジャイル開発と基準上の内部統制に係る要請を上手く融和させることができるでしょう。

ITに係る全般統制への対応

ITに係る全般統制に関しても基準が想定している環境とのギャップに苦しむことがあります。宜しければリンク先をご参照ください。