日本公認会計士協会・IT業界における特殊な取引検討プロジェクトチーム報告「情報サービス産業における監査上の諸問題について」の解説
ソフトウェアの制作･販売等を事業とする公開会社の会計不正事件の発覚
情報サービス産業に属する会社の監査上の留意事項とこれらに係る会計基準の設定の提言についてとりまとめ
平成17年3月11日（日本公認会計士協会）
「情報サービス産業における監査上の諸問題について」
『監査上の諸問題』
ソフトウェア関連ビジネス
無形のソフトウェアを取引対象
↓特性
ソフトウェア関連取引の実在性や経済合理性、ソフトウェア資産の実在性が検証しにくい
情報サービス産業に属する会社
不正な会計処理により、監査上のリスクが高くなる場合があるとして注意喚起
業種に属する会社の監査
不正会計を防止するための内部統制を厳格に評価
ソフトウェア関連取引については形式的な証憑類のみでなく、取引の実態を考慮
→取引の実在性やソフトウェア資産の実在性を検証
こういった監査上の取り扱い
結果として会計監査を受ける会社にも影響を与える
『監査上の諸問題』
ソフトウェアの売上計上やソフトウェア仕掛品の資産性について具体的な会計処理に関する検討結果
不正な会計処理を防止するための会社の内部統制についても言及
Ⅰ 「情報サービス産業における監査上の諸問題について」で取り上げられている問題点
情報サービス産業における会計処理場の問題点
① ソフトウェア開発に蹴る収益の認識基準
② ソフトウェア開発における仕掛品の資産性
③ 商社的な取引を利用した不正取引及び収益と原価の総額表示･純額表示
④ 複合的な契約に関する取引要素ごとの収益計上
情報サービス産業に属する会社の監査実務
常に議論されてきた事項
我が国
これらの諸問題を解決するための会計処理基準は存在しない
『監査上の諸問題』で特に強調されている点
③商社的な取引を利用した不正会計及び収益と原価の総額表示･純額表示に関する問題
Ⅱ ソフトウェア開発における収益の認識基準
１．検収基準の適用方法について
収益認識基準：ソフトウェア開発を請け負う企業
顧客の研修辞典において売上計上する方法（検収基準）
開発されたソフトウェア
目に見えるものではなく、実際に完成し、引渡され、顧客によって検収されたのかという点
→第三者が確認することは困難
検収の事実
顧客が発行する検収書に基づいて確認する方法が通常
実務上
実際にソフトウェアが完成していないのに検収書が発行
実際に検収されソフトウェアが稼動しているのに検収書が発行されないケース
→検収の実態を表していない形式的な検収書に基づいて収益計上
⇒売上形状の時点について問題のある会計処理
『監査上の諸問題』２（１）
「収益の実現を認識するための検収基準を実態に合わせて適用することが困難な場合が見受けられる。」
ソフトウェア開発の売上
検収書のみに頼って計上する方法
→問題のある会計処理を防止することはできない
『監査上の諸問題』６（２）
米国基準「ソフトウェアの収益認識」（AICPA SOP97-2）を参考
→我が国の会計慣行に適用できる事項を整理
ソフトウェア開発における検収基準
（１）取引証拠
（２）引渡しの完了
『監査上の諸問題』３（１）①
監査上の手続き
「必要に応じて社内における検査報告書や得意先から入手した検査結果通知書等を確認する。」
企業側の対応
検収基準の適用
ソフトウェアの感性テストによって全ての機能の開発が完了し、問題なく稼動することを確かめた上で、検収書を入手する社内ルールにしておく必要
２．部分完成基準の適用方法について
ソフトウェアの開発請負契約
開発フェーズを区切り、フェーズごとに顧客に引渡し、検収を受け、代金の請求を行うケース
「分割検収」が業界の慣習として存在
『監査上の諸問題』２（１）
「契約書や発注所、検収初頭の書面の内容だけでなく、フェーズごとに検収される対象物が、ソフトウェアとして成果物たる機能を実際に有しているかについても検討が必要である。」
→フェーズごとの受注額や成果物を恣意的に決定する
→売上高や利益の操作が行われる可能性がある
分割検収を利用した売上や利益操作の発生を防止するため
×単に契約書に記載されているフェーズごとの受注額に基づいて売上を計上する取り扱い
各フェーズの成果物に見合うフェーズごとの公正な受注額が設定されるよう契約締結前の事前チェック体制を整えておく必要
フェーズごとに精度の高い完了確認ができる開発管理体制も整備しておく必要
契約内容として以下の要件を満たしている必要
・
区分したフェーズごとに実際に独立した成果物が示されていること
・
区分したフェーズごとの成果物にそれぞれの公正な対価が設定されていること
・
区分したフェーズごとに顧客に引渡され、検収されることが明示されていること
・
区分したフェーズごとに対価を請求し、入金される条件となっていること
上記の要件を満たさない契約が締結された場合
最後のフェーズの引渡しの完了を終え、全体としての顧客の検収が得られるまで
→売上を未計上とする会計処理
Ⅲ ソフトウェア開発における仕掛品の資産性
１．ソフトウェア仕掛品の評価について
ソフトウェア開発に要した原価
契約ごとに設定されたプロジェクトコードに集計
完成･引渡まで仕掛品として会計処理
仕掛品
受注額が完成時の予定原価以上であることによってその資産性が確保
受注額を超える原価の発生
ソフトウェア仕掛品を評価減するなどの会計処理が必要
ソフトウェアの受託開発
開発を開始するまでに受注額が確定することは稀
設計が進み使用が固まって方受注金額が確定することが多い
ソフトウェアの原価
ほとんどが社内人件費や外注費で占められる
→仕様変更
見積原価が異なってくる
開発途中で不具合が発生すると稼動の増加に伴い当初の予定を大幅に超過する原価が発生する
⇒受注額と予定原価の確定が難しい
⇒仕掛品の評価減が適時に必要な額だけ計上できない可能性がある
『監査上の諸問題』２（２）
「仕掛品の資産性については、その計上の前提となる受注金額が合意に至らずに仕掛品残高の全部または一部が回収できなくなる危険性に留意しなければならない。」
ソフトウェア開発
受注金額や予定原価を見込むことが困難な面が多い
開発
受注予定額と予定原価を見積もって開発に着手するはず
ソフトウェアを開発する企業
受注予定額や予定原価を適切に見込める制度が用意されていない場合
→予期しない多額の評価減が計上される可能性
ex)前期の決算において計上していた仕掛品が、実は評価減が必要であったことが後になって判明することもありうる
↓防止するためには
開発開始に先行して受注予定額と予定原価に関する精度の高い見積
社内承認を得た上で、開発の進捗とともに適時に受注予定額と予定原価の見直しを行う体制
＊ 完成時の予定原価と実績喧嘩との比較管理も重要な内部統制
２．仕掛品原価の恣意的な集計について
ソフトウェア開発の原価
ほとんどが人件費
開発の進捗状況
第三者によって客観的に把握しづらい
→社内人件費や外注費
本来集計すべきプロジェクトコード以外のプロジェクトの原価として処理する
開発中にプロジェクトコード間の原価の付け替えを行う
すでに検収し発生した外注費を未計上のままとする
→プロジェクト別の原価実績が予定原価を超えてないように仮装
仕掛品の評価減が適切に行われていない可能性に注意が必要
『監査上の諸問題』２（２）
「プロジェクトごとの仕掛品の原価の集計に恣意性が入り込んでいないかどうかについても留意しなければならない。」
不正会計を防止するため
内部統制の整備
・
外注取引の発注時には、予めプロジェクトコードを特定して発注承認を行うルールとする
・
プロジェクト間の原価の付替え処理は、社内承認を得た上で実施されるルールとする
・
発注承認されたもののうち未収となっている外注費については、費用の計上漏れがないかチェックするルールとする
Ⅳ 商社的な取引を利用した不正取引及び収益と原価の総額表示･純額表示
１．商社的な取引について
ソフトウェア開発を行う企業
背景
開発期間の短期化
ソフトウェアテクノロジーの高度化
目的
人的資源の適正化、開発リスクの切り出しなど
→開発作業の全部あるいは一部を外注先に委託するケースが多い
我が国におけるソフトウェア業界の構造（多段階的請負構造）
大手ソフトウェア開発会社の下に階層化した非常に多くの外注下請け会社が存在する
『監査上の諸問題』２（３）
「情報サービス産業の多段階請負構造の中では、ソフトウェア開発の一部として、ハードウェアやすでにパッケージ化されたソフトウェアの流通も頻繁にあり、情報サービスを提供する企業間で商社的な取引が日常的に行われている。」
仲介取引
ハードウェアやパッケージソフトウェアなどの「商社的取引」のうち、売り手が在庫リスクを負わず、また、売り手によって物理的にも機能的にも付加価値が増加されない帳簿を通過するだけの取引
架空売上の計上や利益操作などを目的とした不正取引に利用される可能性がある点を問題視
・
販売先あるいは仕入先の紹介に伴う取次ぎ取引
・
最終ユーザや元受先からハードウェア等を指定されている取引
・
与信補完や口座新設の省略による取引時間の短縮などを目的とした取引
２．仲介取引を利用した不正取引
（１）スルー取引
複数の企業間で売上金額の増額を目的として行われる仲介取引等のケース
（２）Uターン取引
自社が基点及び終点となってその間に商社的な取引が行われ、最終的に自社が販売した商品・製品等が複数の企業を経由して自社にU ターンして戻り、在庫または償却資産として保有されるケース
（３）クロス取引
複数の企業が互いに商品･製品等をクロスしていったん販売しあい、その後在庫を保有しあうケース
Uターン取引
商品や製品に開発作業が加えられ、あたかも実態がある取引のように仮装されるケース
通常とはかけ離れた高額な価格で契約
実際には対象となる商品･製品が実在しない伝票だけの架空取引
３．商社的取引の会計処理について
我が国
商社的な取引慣行に適用される特別の会計処理基準はない
米国
「収益を本人として総額計上するべきか代理人として純額表示すべきか」（FASB EITF99-19）という基準
『監査上の諸問題』６（１）
会計慣行へ適用することの可能性について検討
事実関係や状況に基づいて決定されるべきであり、その決定に当っては、以下の指標を検討すべきと規定
○売上を総額で計上する指標
① 会社が契約において主たる債務者であること
② 会社が通常の在庫リスクを有していること
③ 会社に販売価格を設定する裁量があること
④ 会社が商製品･サービスに付加価値を加えていること
⑤ 会社に業を選択する裁量があること
⑥ 会社が商製品･サービスの仕様の決定に関与していること
⑦ 会社が受注後あるいは輸送中に起こる物質的な損失リスクを負うこと
⑧ 会社が貸倒リスクを負うこと
○売上を純額で計上する指標
① 会社ではなく、会社の仕入れ業者が契約の主たる債務者であること
② 会社が獲得する金額が確定していること
③ 会社ではなく仕入業者が貸倒リスクを追うこと
『監査上の諸問題』
スルー取引やクロス取引
上記指標を手がかりに売上高と原価を総額表示すべきか純額表示すべきかを決定することになると結論
純額表示する場合
仲介者として本来得ることが出来る合理的な手数料かどうかにより、営業外利益として表示することも検討
正当な仲介取引
上記の指標に基づき総額表示とするのか純額表示とするのかの判断が求められている
Uターン取引
売上取引が実在しない架空取引
売上計上は妥当ではないと判断
スルー取引やクロス取引
総額表示となることを防止する必要
Uターン取引
売上高を取り消す等の対処
すべての仲介取引
個別に総額表示すべきか純額表示すべきかを検討する
→実務上難しい
各社で各指標を自社の実態に合わせてチェックリスト化
一定金額以下の仲介取引については、社内で決めた一定粗利率以下の取引を純額表示とするルール
Ⅴ 複合的な契約に関する取引要素ごとの収益計上
ソフトウェアの請負開発やパッケージソフトウェアの使用許諾を行った場合
期間ごとの保守契約やバージョンアップ契約、トレーニングといったサービスをあわせて提供することが一般的
付随的な取引要素
ソフトウェア開発取引や仕様許諾取引とは別個のもの
→同一の契約書に記載され、各取引要素が複合的に契約される場合
＊ 各取引要素ごとの金額の内訳の明示がないこともある
『監査上の諸問題』２（４）
・ システム開発請負契約に保守機関も含まれているケース
・ ソフトウェア･ライセンス契約に他の役務提供契約が含まれているケース
・ ソフトウェア･アウトソーシング契約のなかで、ハードウェア及びソフトウェアの販売や開発請負とサービス提供とが混在しているケース
・ ソフトウェア販売価額に期間的なシステム利用料や保守料が含まれているケース
複合的な契約となる場合
取引要素ごとに適切な会計処理が必要
ex)ソフトウェアの開発請負やハードウェアの販売
検収基準によって売上を計上
ソフトウェア・ライセンス
使用許諾開始とともに売上を計上
期間的なシステム利用料や保守料、バージョンアップ取引
契約上の役務提供期間にわたって収益計上
『監査上の諸問題』６（３）
「情報サービス産業においては、契約上、各要素に係る金額が恣意的に決められ、公正価値によっていない場合がある。」
複合的な取引が利益操作に利用される可能性がある点を問題視
米国基準「複数の製品･サービスを伴う収入取引の会計」（FASB EITF00-21）
「たとえ契約上でそれぞれの要素の対価を定めたとしても、それぞれの要素の価格は、当該約定価格に関わらず契約科学総額を各要素の構成価値で按分することによって算定すると規定しおり、適切な会計処理基準を検討する上で一つの参考になる。」
複合的な契約となる場合
各取引要素の公正価値に基づいてそのうち早稲を契約書に明示することが先決
＜参考文献＞柴谷哲朗「日本公認会計士協会・IT業界における特殊な取引検討プロジェクトチーム報告「情報サービス産業における監査上の諸問題について」の解説」『企業会計』Vol.57,No.7、中央経済社、2005年7月