従来、長期・大規模な請負工事については、企業会計原則において工事進行基準と工事完成基準の選択適用が認められてきました。しかしながら、基準では、特に工期の長さに言及していません。「長期の請負工事でなくとも、会計期間をまたぐ工事については工事進行基準を適用すべき場合があると考えられる（基準53項）」と基準が示しているように、単に工期が短いということだけをもって工事進行基準を適用しないとする判断はできないと考えられます。

ただし、「工期がごく短いものは、通常、金額的な重要性が乏しいばかりでなく、工事契約としての性格にも乏しい場合が多いと想定される（基準53項）」と基準は言及しており、また、このような工期がごく短いものは工事進行基準によらずに、「通常、工事完成基準を適用することになると考えられる（基準53項）」とし、工事契約としての性格が乏しいことを理由に工事完成基準による収益の認識基準の適用を示唆しています。

「工期がごく短いもの」の具体的な期間を基準は明示していません。このため、どのように考えればよいかが論点となってきます。なお、基準は「会計期間をまたぐ取引」について言及しているため、会計期間をまたがない工事契約は問題とならないと考えられます。ただし、基準が想定している会計期間には四半期決算も含まれると考えられますので注意が必要です。これは、適用指針30項において、一部簡便的な方法を用いることは認められているものの、要件を満たした工事契約については工事進行基準によって収益を計上すべきことが四半期決算でも求められているためです。

それでは、会計期間をまたぐ工事契約についてはどのように考えればよいのでしょうか。「工期がごく短いもの」は、金額的な重要性が乏しいことに加え、工事契約としての性格にも乏しい場合が多いという特徴を基準は示しています。

このため、該当する取引が与える損益への影響が重要でないことが必要ですが、さらに、工事契約としての性格についても検討しなければなりません。工事契約としての性格に乏しい場合とは、例えば、「作業の積み上げによる詳細な実行予算書を作成する必要がないほどの簡易なソフトウエア制作」、「原価の見積もり、実績比較、差異分析、見積もりの見直しといった原価管理を行う必要がない取引」、「開発を作業単位に分割、あるいはブレークダウンしなくともマネジメントできるような取引」など、いずれも、工事契約として原価管理や管理体制の構築による管理工数のコストをかけても、その効果が見合わないほどの取引が該当すると考えられます。このような契約は工事契約としての性格が乏しいことから、工事完成基準による収益認識を適用することになると考えられます。

受注制作ソフトウエアは最終ユーザーと契約した元請企業が、制作するソフトウエアの一部、あるいは全部を協力会社に発注することが少なくありません。また、協力会社はさらに孫請企業に作業を発注するなど、多重下請構造を特徴とする産業構造であると言われています。

期末における工事進捗度を見積もる場合、協力会社に委託した作業の進捗をどのように取り扱うかについては基準に明記されていません。想定される取り扱いとしては、大きく二つの方法が考えられます。一つは、自社が協力会社の作業を検収した場合に、その検収した部分については自社の作業進捗に加味するという考え方です。もう一つは、自社が検収しているか否かに関係なく、協力会社から期末日における協力会社の工事進捗度についての情報提供を受け、当該情報を加味した上で自社の工事進捗度を算定するという考え方です。

前者の考え方によれば、協力会社の作業が完了し、検収が行われた時点で自社の原価が確定するため、当該実際発生原価をもって工事進捗度を算定することができます。この考え方によれば、協力会社の作業を、検収という形で自社が確認することができますし、通常、作業の完了時には成果物に関する情報が報告書や何らかの納品物として納められるなど、客観的な証憑を伴うケースが多いため、工事進捗度の信頼性ある見積もりという観点からは客観的な根拠を示すことができます。ただし、検収は、通常、会計期間とは関係なく行われるため、期末日時点の協力会社の進捗度は反映されません。特に、作業のほとんどを一括して発注している場合には、作業の最終段階まで実際発生原価が集計されず、工事進行基準でも工事完成基準を適用した場合と結果的にはほとんど変わりが無い場合があります。

一方、協力会社から期末の進捗度を報告させる後者の考え方によれば、協力会社も含めたソフトウエア制作に対する期末日の工事進捗度を把握できるため、作業実態に近い進捗度を算定することができます。ただし、協力会社からの進捗度についての報告は、それが十分に信頼のおけるものであるかどうかを自社で確認しなければなりませんが、協力会社からのよほどの協力がない限り、実務的にはかなり難しいと思われます。また、協力会社からすれば、発注者はお得意さまとなるため、工事進捗度の報告について過度なプレッシャーを受け、恣意的に発注者にとって有利な報告を行う可能性は皆無ではありません。協力会社からの報告に基づく工事進捗度を利用する場合には、上記の点をクリアし、協力会社の管理を発注者が行えるような環境が整うことが前提となると考えられます。

なお、二つの考え方の長所を活かす方法として、協力会社への発注方法を変更する、あるいは発注単位を細かく分割するなどの方法も考えられます。協力会社への発注方法の変更については、協力会社に対して、請負契約ではなく、ソフトウエア・エンジニアリング契約等、かかった工数を精算するような契約方法が考えられます。この方法ですと、一定期間ごとに精算を行い、その都度検収されることによって、実際原価としてコストが集計されていくことになります。

ソフトウエア制作企業の中には、連結子会社に作業の一部を行わせている会社もあると考えられます。親会社の個別決算上、連結子会社であっても「協力会社の工事進捗度の取り扱い」と考え方に基本的な違いはありません。ただし、連結子会社における原価管理の整備・運用状況や、実際の数値に関するデータなどは、協力会社の場合とは異なり、比較的入手しやすい側面もあると考えられます。

連結決算上の考え方について、基準では特段の明記はありませんが、親会社と子会社が同一のシステム制作を行う場合で、親会社が工事進行基準を適用しようとするときは、子会社も工事進行基準が適用できるような体制を構築しておくことが望ましいと考えられます。例えば、子会社が信頼性をもって工事総原価を見積もることができない場合には、通常、連結上の工事総原価も、信頼性をもって見積もることができないと考えられるため、子会社がネックとなって、工事進行基準を適用する要件を満たしていないと判断せざるを得ないケースなどが考えられるためです。

また、親会社、子会社で同一のシステムを制作していても、プロジェクトコードが異なるなど案件別に名寄せすることが困難なケースが見受けられます。連結会社間でのプロジェクトコード採番のルール化を行っておくなど、事前に準備すべき事項を洗い出し、早めに対応を図る必要があると考えられます。