ポイント：会計基準、ソフトウェア取引、新会計ルール、「ソフトウェア取引の収益の会計処理に関する実務上の取扱い」、財務会計基準機構、企業会計基準委員会

「ソフトウェア取引の収益の会計処理」の要約

　企業会計基準委員会より、平成18年3月30日に「ソフトウェア取引の収益の会計処理に関する実務上の取扱い（以下、実務対応報告）」が公表されたことは前回のコラムに書きました。自分の頭の整理の為に、少し抜粋してまとめてみたいと思います。

　無形の資産であるソフトウェアの内容及び状況の確認の困難さや、その開発を巡る技術環境の高度化及び多様化を背景として、いくつかの不適切な会計処理が指摘されています。この問題の解決には、ソフトウェア取引の収益の認識及び測定に関する会計処理基準の明確化も必要ではないかという意見が多くなっています。

1.ソフトウェア取引の範囲及びその特質

(1)ソフトウェア取引の範囲

　本実務対応報告でいうソフトウェアとは「研究開発費等に係る会計基準」に定めるソフトウェアを対象とするものである。実務対応報告の対象とするソフトウェア取引は収益認識に関連するものであるため、研究開発費等会計基準に定めるソフトウェアの取引のうち、販売を目的として開発される次の２つの取引を主として対象とする。

① 市場販売目的（パッケージ）のソフトウェア取引

② 受注制作（オーダーメイド）のソフトウェア取引

(2)ソフトウェア及びその取引の特質

ソフトウェア及びその取引の特質として次の点を挙げることができる。

① 無形の資産であること　ソフトウェアは、外部からその状況や内容を確認することは難しく、実際の開発作業においても、当事者間でプロジェクトが完結することが多いため、その当事者以外は開発状況を確認することが難しい。

② 技術革新により取引が多様化・高度化していること　ソフトウェアの開発を巡る技術環境の著しい変化に対応するため、取引が多様化し、複数の要素のある取引を同一の契約書等において締結していることが多く、また、取引が高度化し、外部資源の活用が一般化しており、下請取引（多段階請負構造）が慣行化している。

2.ソフトウェア取引の収益認識

(1)ソフトウェア取引における収益認識の考え方

　ソフトウェアが無形の資産であるために、その状況や内容確認の困難さはあるが、その収益の認識においては、当該取引の実在性、一定の機能を有する成果物の提供が完了し、その見返りとしての対価が成立することが必要である。

① 市場販売目的のソフトウェア取引　ソフトウェア取引の特質からその内容の確認が難しいという中でも、市場販売目的のソフトウェア取引については、一般的に、企業（ベンダー）の側でその仕様（スペック）がすでに確定しているため、納品が完了した時点で実質的に成果物の提供が完了している。

② 受注制作のソフトウェア取引　一方、受注制作のソフトウェア取引については、基本的にオーダーメイドによるものであり、その仕様（スペック）は確定していないため、通常、顧客（ユーザー）の側で契約内容に応じて、成果物がその一定の機能を有することについての確認が行われることにより成果物の提供が完了すると考えられる。

(2) 収益を認識するにあたっての留意事項

　収益認識には、ソフトウェア取引の実在性、一定の機能を有する成果物の提供の完了及びその対価の成立という事実が必要となるが、特に次のようなケースについては、一般的に、それらの事実の存在について疑義が生じる。したがって、このようなケースにおいて収益を認識するにあたっては、企業は、それらの事実の存在を確認し、客観的に説明ができるようにする必要がある。

① 成果物の提供の完了の前提となる取引の実在性に疑義があるケース　通常は契約書等を取り交すべき取引において、当該取引に関する契約書等につき、ドラフトしか存在していない場合や、本来の顧客（ユーザー）との間で契約書等を取り交すには至っておらず、第三者であるパートナー（協力会社）との間で契約書等を取り交すにとどまっている。

② 成果物の提供の完了に疑義があるケース　通常は検収により成果物提供の完了を確認するような場合において、検収書又はこれに類似するものが入手されていない。もしくは、検収書又はこれに類似するものを入手しているにもかかわらず、入金予定日を経過しても未だに入金がない、若しくはソフトウェアの主要な機能に関するバグの発生等により作業を継続している。

③ 対価の成立に疑義があるケース　売上計上後に顧客（ユーザー）に対して多額の返金又は大幅な値引が見込まれている、若しくは類似の取引で過去においてそのようなケースが多く発生している。

(3) 分割検収における収益認識に関しての会計上の論点

　受注制作のソフトウェア取引においては、ひとつのソフトウェア開発プロジェクトをいくつかの作業ごとのフェーズに分けて契約を締結し、各フェーズごとに検収を行う、分割検収が見受けられる。

　ソフトウェア開発のフェーズ分けには、例えば、設計段階の完了、開発段階の完了といった時系列的な分割と、購買システムの完了、経理システムの完了といったシステムの引渡しを伴う物的な分割のケースがある。特に、収益認識との関係においては、前者の時系列的な分割の場合、問題となることがある。

　ソフトウェア取引の収益認識には、取引の実在性を前提として、一定の機能を有する成果物の提供が完了し、その見返りとしての対価が成立することが必要である。そのため、契約が分割された場合においても、一般的には、最終的なプログラムが完成し、その機能が確認されることにより収益認識されることになる。

　ただし、最終的なプログラムの完成前であっても、例えば、顧客との取引において、分割された契約の単位の内容が一定の機能を有する成果物の提供であり、かつ、顧客（ユーザー）との間で、納品日、入金条件等について事前の取決めがあり、その上で当該成果物提供の完了が確認され、その見返りとしての対価が成立している場合には、収益認識の考え方に合致しているため、収益認識は可能である。

　つまり、分割検収において、成果物の提供の完了の確認がなく、単に作業の実施のみに基づく場合や入金条件のみに関連しているだけでは、収益認識は認められない。

3.ソフトウェア取引の複合取引についての会計上の考え方

　ソフトウェア取引の中には、サービスの提供や機器の販売のように異なる種類の取引を同一の契約書等で締結している複合取引がある。こうした複合取引においては、取引の種類ごとに収益認識時点が異なる場合がある。そのような場合、問題が生じるケースがある。

① 市場販売目的のソフトウェアとソフトウェア関連サービスの複合取引　ソフトウェア販売に保守サービスやユーザー・トレーニング・サービスが含まれているケース、または、ソフトウェア・ライセンス販売（使用許諾）にアップグレードの実施が含まれているケース

② 受注制作のソフトウェアとソフトウェア関連サービスの複合取引　システム開発請負契約に期間的なシステム利用や保守サービスに関する契約が含まれているケース

4 ソフトウェア取引の収益の総額表示についての会計上の考え方

　ソフトウェア取引においては、技術革新による取引の多様化や高度化に伴い、複数の企業を介する取引が見受けられるが、このような取引には、在庫リスクを抱えて行われる取引だけでなく、物理的にも機能的にも付加価値の増加を伴わず、会社の帳簿上通過するだけの取引も存在する。

　このような複数の企業を介する情報サービス産業におけるソフトウェア関連取引において、委託販売で手数料収入のみを得ることを目的とする取引の代理人のように、一連の営業過程における仕入及び販売に関して通常負担すべきさまざまなリスク（瑕疵担保、在庫リスクや信用リスクなど）を負っていない場合には、収益の総額表示は適切でない。

　特に、例えば、次のようなソフトウェア関連取引については、販売者は、一般的に、通常負担すべきさまざまなリスクを負っていることが明らかでないと考えられるため、収益の総額表示を行うためには、当該リスクを負っていることを示すことが必要となる。

5 適用にあたっての留意事項

　本実務対応報告は、ソフトウェア取引の収益の会計処理について、現行の会計基準等を踏まえた実務上の取扱いを整理したものであるため、その会計上の考え方については基本的にはすでに適用されていると考えられる。

　この最後の留意事項はちょっぴり心が痛む指摘である･･･。また、要約の過程で重要な項目が抜けているといけないので、是非原文を読んでいただきたいと思う。

(財)財務会計基準機構・企業会計基準委員会のＨＰ
　　「ソフトウェア取引の収益の会計処理に関する実務上の取扱い」

2006年06月12日宿澤直正記

[事務所TOP] [コラム一覧へ]