ソフトウェア会計と実務

公認会計士　堀場 雅史

1. プロジェクト・コードの設定

ソフトウェアの受注契約に関しては、一契約の中に複数の取引要素が含まれるケースが少なくありません（ソフトウェア取引の収益の会計処理に関する実務上の取扱い 3参照）。また、プロジェクトによっては開発期間が長期にわたるものもあります。

このような特徴を踏まえ、プロジェクト別の収益や原価、採算性を適切に把握する趣旨から、まず受注契約の中に含まれる取引要素を識別し、取引の性質に応じてプロジェクト・コードを設定する場合が多いと思われます。

（1）一契約の中に複数の取引要素が含まれるケース

例えば、同一契約にソフトウェアの開発請負と保守サービスが含まれている場合、それぞれにプロジェクト・コードに枝番を付してプロジェクトを細分化することが考えられます。これにより取引要素別の採算性の把握が可能となり、類似の取引についての対価決定の際、有用な情報が得られることにもつながります。

（2）滞留プロジェクトの区分

完成予定時期が経過したプロジェクトについては何らかの理由で滞留しているわけですが、客先と受注金額で合意が得られていないケースや、予期しない不具合が発生しその修正作業に予定以上の工数がかかるケースなどが考えられます。総じて、費やしたコストを全額回収できるかどうか、つまり棚卸資産の評価の観点から、帳簿価額を上回る収益が獲得できず評価損の計上の要否が問題となることが多いです。このようなケースにおいては、プロジェクト・コードに滞留の事実を示すアルファベットや記号を追加することにより、評価損の適時把握が可能となります。

（3）契約変更があった場合の取り扱い

契約の主要な部分に変更がなく、変更後も旧契約の業務の大部分が変更なく継続しているような場合には、例えば旧コードに枝番を付すことにより、新旧契約を一体として棚卸資産の評価減の要否を検討することが考えられます。一方で、契約の変更により旧契約の業務内容が大きく変更となるような場合、旧コードとは別のコードを新たに設定し、評価減の要否も旧コードとは区分して検討することが考えられます。

なお、設定したプロジェクト・コードについては全社的に周知し、上記のようなケースにおける取り扱いや作業時間・経費の各プロジェクトへの集計方法について、業務を担当する各部署の担当者とすり合わせを行っておくことも重要です。
 

2. 収益の認識

（1）工事進行基準と工事完成基準

ソフトウェアの受注制作においては、工事契約に関する会計基準に従い、①工事収益総額、②工事原価総額、③決算日における工事進捗度のそれぞれについて、信頼性をもって見積もることができる場合には工事進行基準、それ以外の場合には工事完成基準を適用します（工事契約に関する会計基準（以下、工事契約基準）　第5項 ・ 第9項）。

特にソフトウェアの受注制作においては、その性質上、工事進行基準の適用に当たり以下のような点に留意が必要です。

① 工事収益総額の見積りについて

プロジェクト開始時に契約書や注文書において受注金額が確定している場合、工事収益総額について信頼性の高い見積りが可能と考えられますが、ソフトウェアの請負開発契約においては事前に受注金額が確定しないケースもあります。このような場合、それ以外の手段で金額の合理的な見積りが可能なのか、見積もられた金額がプロジェクト完了時に確実に対価として回収できるのかどうかを慎重に検討する必要があります。

② 工事原価総額の見積りについて

ソフトウェアの受注制作においては、プロジェクト開始時に仕様の詳細まで詰められない場合や、想定外の事象の発生などによって追加的な工数が生じる場合も多く、実行予算による管理や予算・実績比較により、見積りに変更があった場合にも適時・適切な原価総額の見直しが必要となります（工事契約基準 第50項・第51項 参照）。

③ 工事進捗度の見積りについて

工事進捗度の見積り方法として、原価比例法が多く採用されてきています。この場合、プロジェクト間の原価の付け替えによる不正な経理処理が行われる可能性に留意が必要です。例えば、採算性の高いプロジェクトへの付け替えにより工事進捗度を恣意的に高めることが考えられます。このため、部門責任者等の適切な管理者が、プロジェクト担当者からのヒアリングをもとに、実際の作業の進捗と工事進捗度の間に乖離がないかどうかを定期的に確認する、会計仕訳において合理的な理由のないプロジェクト間の原価振替がないかどうかを確認する等の対応も重要となります。

（2）収益認識に関するその他の留意点

ソフトウェア取引の収益の会計処理に関する実務上の取扱い2（2）は、取引の実在性、成果物の提供や対価の成立に関し、疑義が生じている場合として下記のような場合を例示しており、該当する場合には慎重な対応が必要です。

1. a契約書の取り交わしが完了しておらず、成果物の提供の完了の前提となる取引の実在性に疑義があるケース
   
   
2. b通常は検収により成果物提供の完了を確認するような場合において検収書等がない、又は入金予定日になっても入金がない等、成果物の提供の完了に疑義があるケース
   
   
3. c売上計上後に顧客に対して多額の返金又は大幅な値引が見込まれている、又は類似の取引で過去にそのようなケースが多く発生している等、対価の成立に疑義があるケース

3. 予算管理

終了したプロジェクトについては、当初予算と実績を比較し、差異の要因を分析します。一般的に考えられる差異の要因としては、以下のようなものが考えられます。

• 顧客から仕様変更や機能の追加等が求められる場合
  
  
• 予算の見積りの精度が低く、計画工数と実績工数との間に乖離がある場合
  
  
• 予算作成後、受注金額に変更があった場合
  
  
• 予算策定時には想定しえなかったバグ修正等

差異の要因については定期的に情報共有を行い、改善活動やより精度の高い予算の策定に役立てます。また、終了していないプロジェクトについても、検収予定時期を大幅に超過しているような案件がないかどうか、あるいは契約未了の案件がないかどうかを定期的に確認し、想定外の損失が発生しないように対処することも重要です。

 

プロジェクト別の業績管理表の例

1．最終的に損失が見込まれる受注契約がある場合

特定の契約について、原価総額が収益総額を超過する可能性が高く、かつ、その金額を合理的に見積ることができる場合には、その超過すると見込まれる額のうち、当該契約に関してすでに計上された損益の額を控除した残額を、損失が見込まれた期の損失として処理し、工事損失引当金を計上することとなります（工事契約基準　第19項）。

 

表による不採算プロジェクトの管理例

（注）滞留プロジェクトについては、枝番として「Z」を付している。

2．プロジェクトで使用する固定資産の資産価値についての検討

ソフトウェア開発企業については、業界の技術革新のスピードも速く、経営環境の変化により会社のプロジェクト全体の業績が悪化してしまうケースが想定されます。また、社内で利用するソフトウェアについて、当初予定していた効果の発現が期待できないケースや陳腐化が認められるケース等、資産価値が問題となる場合も考えられます。特に、下記のような状況に該当しないかどうか、留意が必要です。

（1）自社利用ソフトウェア

自社利用ソフトウェアは、将来収益の獲得又は費用削減が確実であると認められる場合のみ、その取得価額を無形固定資産として計上することが認められます（研究開発費及びソフトウェアの会計処理に関する実務指針　第11項）。このため、将来収益獲得又は費用削減効果が認められない場合又は確実かどうか不明である場合には、費用処理が求められます。

また、ソフトウェアの機能が陳腐化した等の理由で、利用可能期間の中途に使用見込みがなくなった場合には、有形資産と同様に除却処理を行う必要があります（研究開発費及びソフトウェアの会計処理に関するQ&A Q19）。

（2）減損会計の適用

プロジェクトで使用される固定資産につき、下記のような状況が認められるケースがあります（固定資産の減損に係る会計基準　二　1．）。

• 資産又は資産グループを使用するプロジェクトの採算が悪化し、営業損益や営業キャッシュ・フローが継続的にマイナスとなる場合
  
  
• 市場環境の変化に対応してビジネスモデルを見直すようなケースにおいて、資産又は資産グループの使用目的・方法の変更が必要となり、回収可能価額が著しく下落することが見込まれるような場合
  
  
• 技術やノウハウの汎用化に伴って、資産又は資産グループを使用するプロジェクトに関し経営環境の著しい悪化が認められるような場合
  
  
• 資産又は資産グループの市場価格が著しく下落するような場合

減損の兆候に該当するケースでは、プロジェクトから得られる割引前将来キャッシュ・フローによりこれらの帳簿価額を回収できるか否かを検討し、回収できないと判断される場合には、減損損失を認識します（固定資産の減損に係る会計基準　二　3．）。