ＩＴ業界における特殊な取引検討プロジェクトチーム報告
情報サービス産業における監査上の諸問題について
平成 17 年３月 11 日 日本公認会計士協会
１．はじめに
昨今の日本の産業構造は、コンピュータ・ソフトウェア（以下「ソフトウェア」
という。）をツールとした情報サービス産業分野の重要性が増加している。従来のハ
ードウェアを中心とした業態の企業においても、情報サービス産業分野への進出が行
われており、幅広い業種、業態にこの傾向が見られる。
平成16年は、情報サービス産業に絡んだ不適切な会計処理の事例が、いくつか明
るみに出たことから、日本公認会計士協会としてもこの問題を放置できないと判断し、
当面の監査上の留意事項及び会計基準の明確化への提言について取りまとめを行っ
た。
この取りまとめは、主要な監査事務所へのインタビューにより情報サービス産業
の特質を洗い出し、論点を整理したものである。
最近の事例及び上記インタビューから、情報サービス産業における会計環境の特
質として、取引対象のソフトウェアあるいはサービスの実在性、取引の経済合理性、
取引価額の妥当性及び取引先との共謀などの諸問題が指摘されるところである。
このような会計環境は、監査のリスク・アプローチの観点から整理をするならば、
固有リスクに係る問題ということができる。ここで問題とされている取引は、売上取
引、仕入取引及び在庫という企業における中心的な取引であることから、監査アプロ
ーチとしては内部統制の評価を通した統制リスクの評価を厳格に実施する必要があ
るが、最近の不適切な事例を見る限りそれだけでは必ずしも十分ではなく、固有リス
クを明確に識別した上で、実証的監査手続を駆使した深度のある監査が必要と考える。
以下に当面の監査上の留意事項及び会計基準の明確化への提言を取りまとめたの
で、ここに記載されていることを参考として、会員各位においては業態にかかわりな
く、十分な職業的懐疑心をもって深度のある監査を実施されたい。
２．情報サービス産業における会計環境の特質
情報サービス産業において展開されるソフトウェア開発・販売（ライセンス販売
を含む。）は、その事業の対象物が「無形」の資産であり、この「無形」資産の開発
を巡る技術環境は著しいスピードで高度化しかつ多様化している。
情報サービス産業の特質としては、事業の対象物が「無形」であることから、外
− 1 −
部からその開発状況や内容を確認することは難しく、さらに実際の開発作業において
は企画・設計から検収・完成に至るまで、実質的にそのプロジェクトチーム内で完結
することが多く、またライセンスにしてもその当事者以外は内容や実在性を確認する
ことは難しいということが挙げられる。このため、企業として内部統制が十分に機能
しにくい特質がある。
また、技術環境の著しい変化に対応するため、情報サービスを提供する企業は、
経営資源を社内に蓄積するだけでなく、必要に応じて外部から積極的に支援を受ける
傾向にあり、下請取引が幅広く行われている。さらにそれは一次的な段階に留まらず、
多段階請負構造が業界として慣行化している。
このような産業としての特質を背景に、情報サービス産業における会計環境の特
質を検証すると以下のような事象を取り上げることができる。
(1) ソフトウェア開発における収益の認識
ソフトウェア開発においては、ソフトウェアの品質水準について得意先の了解が
得られない場合でも、システムの稼動開始とともに検収書が発行されることがある。
また、場合によっては検収書が発行された後にもバグ対応などで作業が継続して行
われていることもある。一方で、システムは稼動しているにもかかわらず適時に検
収書を入手できない場合もある。
したがって、収益の実現を認識するための検収基準を実態に合わせて適用するこ
とが困難な場合が見受けられる。
また、ソフトウェア開発プロジェクトを幾つかのフェーズに分けて検収を行う、
「分割検収」が業界の慣行として存在している。この場合、契約書や発注書、検収
書等の書面の内容だけでなく、フェーズごとに検収される対象物が、ソフトウェア
として成果物たる機能を実際に有しているかについても検討が必要である。
(2) ソフトウェアの機能仕様の見積りの困難性と受注金額確定のタイミング
ソフトウェア開発における仕掛品は、作業等（労務費・外注費・経費）の積上原
価であり、その作業等は得意先からの受注に基づくシステム開発計画や作業スケジ
ュールに従って実施したもので、受注金額により回収できることを前提としている。
しかし、現実的な作業手順として、プロジェクト着手後に詳細な機能仕様を詰め
ていく作業が行われるため、着手時点ではプロジェクト全体で必要な作業の質・量
を正確に見積もるのは困難である場合が多い。このため、ソフトウェア開発では、
受注金額が締結されないまま作業が進むケースが多く見受けられる。さらに、仕様
設計段階から開発段階に移っても顧客から追加で要求が出され、何度も仕様変更が
行われ、追加作業が発生することも多い。
したがって、仕掛品の資産性については、その計上の前提となる受注金額が合意
に至らずに仕掛品残高の全部又は一部が回収できなくなる危険性に留意しなけれ
ばならない。
− 2 −
また、受注金額の確定時期の問題だけでなく、ソフトウェアは「無形」資産であ
ることから、外部からその開発状況や内容を確認することはその特質上難しいとい
った問題も抱えている。それ故、プロジェクトごとの仕掛品の原価の集計に恣意性
が入り込んでいないかどうかについても留意しなければならない。
(3) 商社的な取引慣行の存在
情報サービス産業の多段階請負構造の中では、ソフトウェア開発の一部として、
ハードウェアや既にパッケージ化されたソフトウェアの流通も頻繁にあり、情報サ
ービスを提供する企業間で商社的な取引が日常的に行われている。商社的な取引は
在庫リスクを抱えて行われる取引だけでなく、中には物理的にも機能的にも付加価
値の増加を伴わず、会社の帳簿上通過するだけの仲介取引も存在する。
特にこの仲介を目的とした取引は、
① 販売先あるいは仕入先の紹介に伴う取次取引
② 最終ユーザーや元請先からハードウェア等を指定されている取引
③ 与信補完や口座新設の省略による取引時間の短縮などを目的とした取引
として、従来から業界の慣行として行われてきている。
しかし、複数の企業が関与した仲介取引の場合には取引全体の実態が非常に判別
しにくいことから、近年、名目上は仲介取引であるものの、本来の仲介以外の目的
で取引が実行され、不正取引に利用された事例も見受けられる。
問題が見受けられる事例としては、以下のような事項がある。
① 複数の企業間で売上金額の増額を目的として行われる仲介取引等のケース（ス
ルー取引）
このほか、取引の目的としては、売上金額増額だけに限らず、仕入先又は販売
先との他の取引行為に対する利益補填の目的で行われるケースや、仲介企業を介
在させて納入までのタイムラグを利用した押し込み販売を行うケースなど多々
考えられる。
② 自社が起点及び終点となってその間に商社的な取引が行われ、最終的に自社が
販売した商品・製品等が複数の企業を経由して自社にＵターンして戻り、在庫又
は償却資産として保有されるケース（Ｕターン取引）
ただし、販売した商品・製品等がそのままではなく、開発作業が加えられてい
るケースもある。
また、開発行為そのものがＵターンしている、つまり、自社が外注先に発注し
た開発行為の全部又は一部を当該外注先から又は当該外注先の外注先から再び
自社で受注しているケースも想定し得る。
③ 複数の企業が互いに商品・製品等をクロスして一旦販売し合い、その後在庫を
保有し合うケース（クロス取引）
また、在庫を保有しないとしても、外部に販売するに当たり互いを介在させる
− 3 −
ケースもある。
上記のような仲介取引も含めた商社的な取引については、一般に公正妥当と認め
られる企業会計の基準に照らして、収益が実現しているのか否か、収益が実現して
いるとしても、これを総額で表示することが取引の実態を表しているのか否かを検
討しなければならない。特に複数の企業を介在して行われている場合には、実態が
分かりにくくなっていることから、慎重な対応が求められる。また、販売したハー
ドウェアやソフトウェアに価値そのものが存在するのかどうかについても留意し
なければならない。この中にはライセンスやコンサルティングの名目で提供される
サービスも含まれる。
(4) 契約形態の複雑性
情報サービス産業においては、ソフトウェアの開発やソフトウェア・ライセンス
販売をした後においても、期間的な保守サービスやトレーニングといったサービス
を併せて提供することが一般的である。これらの取引は経済行為としてはソフトウ
ェア開発取引とは別個の取引ととらえられるが、同一の契約書等において締結され
ていることがあり、中には金額の内訳が記載されていない場合もある。
例示を挙げると以下のような事項が想定される。
① システム開発請負契約に保守期間契約も含まれているケース
② ソフトウェア・ライセンス契約に他の役務提供契約が含まれているケース
③ ソフトウェア・アウトソーシング契約の中で、ハードウェア及びソフトウェア
の販売や開発請負とサービス提供とが混在しているケース
④ ソフトウェア販売価額に期間的なシステム利用料や保守料が含まれているケ
ース
このように複数の取引行為が同一の契約書等に記載されている場合であっても
会計上は契約内容ごとに、あるいは取引形態ごとに収益の認識を判断しなければな
らない。すなわち、引渡基準により売上計上すべきか、又は将来の一定期間にわた
って売上計上すべきかを検討する必要がある。
３．物・サービスの内容確認
情報サービス産業における主要な業務を取引形態に従って整理してみると、(1)ソ
フトウェアを制作し、納品することを目的とする開発型、(2)契約に基づいて様々な
サービスを提供することを目的とするコンサルティング型、(3)システム（ソフトウ
ェアを含む。）やライセンスを取次販売することを目的とする商社型に分類すること
ができる。いずれの取引形態においても、物・サービスの内容を確認することが難し
いという情報サービス産業固有の特質があるが、その特質を十分に理解して深度ある
監査手続を実施することが必要である。
以下、取引形態ごとに、その特質と物・サービスの内容を確認する上での留意点
− 4 −
について述べる。
(1) 開発型
① 販売取引
ソフトウェアは、前述したように無形の資産であり、その実態が見えにくいた
め、当事者以外がその状況について確認することが難しいという特質がある。し
かしながら、ソフトウェアは、単に制作し、納品すれば良いというわけではなく、
得意先から要求された品質水準を満たし、その検収を受けることが必要である。
そのため、得意先に出荷する前には、社内で検査を実施し、バグの発生状況を確
認する。また、納品後の得意先においても起動状況を検査する等の手続が行われ
る。
（内容確認する上での留意点）
売上高の会計記録について、形式的に契約書、注文書、納品書（控）及び検収
書等と照合するだけでなく、必要に応じて社内における検査報告書や得意先から
入手した検査結果通知書等を確認する。この場合、営業担当者や経理担当者だけ
でなく、開発担当者に対して開発や検査の状況について質問を行うことは、その
実態を確かめる上でより効果的である。さらに、その実態確認において、十分な
心証が得られない場合、ＩＴ専門家に依頼してソフトウェアの外観チェック（フ
ァイルサイズ、ファイルネーム）や仕様書との整合性の確認、あるいはシステム
の起動状況の確認をしてもらうことも有効である。
② 人件費・外注費取引
システム開発に係る原価には、社内や外注先における作業時間等のように物的
に確認することが困難なものが多く含まれる。しかしながら、システムを開発す
るには、その開発計画書である開発体制図、仕様書、作業スケジュール表、作業
依頼表といったものが必要不可欠であり、社内や外注先の作業について、開発計
画に従って要員をスケジューリングし、作業を依頼するという手続が行われる。
また、こうしたシステム開発の過程は、開発議事録や作業報告書、品質判定のた
めの検査といった形で記録として残される。なお、外注先にシステム開発をすべ
て行わせる場合においても、必要とされる品質水準を満たしているか社内検査が
行われ、バグの発生状況を確認している点に留意する。
（内容確認する上での留意点）
外注費の会計記録について、形式的に契約書、検収書又は請求書等と照合する、
また、労務費の会計記録について、執務情報等の原価計算資料とを照合するとい
った手続を実施するほかに、必要に応じて社内の開発体制図や作業スケジュール、
作業管理資料等との整合性について検証を行う。特に、外注先からの見積書や会
社が提出する発注書の記載が「○○一式」あるいは「○月分」というように、抽
象的で、具体的な作業内容が記載されていない場合には、上記手続を実施すると
− 5 −
ともに、開発担当者に開発の状況について質問をし、より具体的に内容確認を行
うことが効果的である。なお、外注先にシステム開発をすべて行わせる場合、社
内検査の結果、必要とされる品質水準を満たしていると社内的に判断しているか
どうか確認することも有効である。
(2) コンサルティング型
コンサルティングには、請負契約、委任契約、ＳＥＳ契約等があり、契約の内容
によって提供されるサービスが異なる。請負契約が成果物をその対価とするのに対
して、委任契約とＳＥＳ契約は、作業そのものをその対価とする。また、委任契約
が受託者の管理下で作業が行われるのに対して、ＳＥＳ契約は委託者の指示に従っ
て作業が行われる。そのため、請負契約や委任契約であれば、受託者が、作業実施
のための計画書、スケジュール表等を作成し、成果物や作業報告書等によって作業
の進捗状況を管理するのに対して、ＳＥＳ契約であれば、委託者側でこうした管理
を行う。ただし、契約によっては、一つの契約に、成果物の引渡しと作業による役
務提供が含まれているものもあり、提供するサービスを区分して把握する必要があ
る。
（内容確認する上での留意点）
契約書や注文書を吟味することで、コンサルティングがどのようなサービスに該
当するのか検討する。その上で、売上高の会計記録に対して検収書や請求書等と照
合するだけでなく、必要に応じて請負契約であれば、納品成果物やこれに係る計画
書、仕様書等との整合性を確認する。委任契約であれば、作業報告書や作業状況管
理表との整合性を確認する。ＳＥＳ契約であれば、作業報告書や作業依頼表との整
合性を確認する。また、納品成果物や作業の状況について十分な心証を得ることが
できない場合、取引先の管理部門等窓口担当者以外の部署に対して取引確認を行う
ことも有効である。なお、ＳＥＳ契約については、作業時間に応じて売上高が変動
するのが通常であり、受注案件ごとに、社内の作業時間を反映した人件費と、これ
に係る売上高を対比することも効果的である。
(3) 商社的取引型
ソフトウェアが含まれるシステムの販売は、個別性が強く、ユーザーにおける導
入作業や検査手続を必要とするため、商社的に取引を行う場合であっても、契約書
等に検査立会の条項が含まれており、検査結果の通知書を入手している。また、ユ
ーザーが直接の取引先でない場合、ユーザーからは検査結果の通知書を入手しない
が、通常、ユーザーや開発元を含めたところで、見積り、開発仕様、納品検査等に
係る打合せを行っており、これに係る記録が残されている。
また、ライセンスの使用許諾については、通常、社内やユーザーにおいて品質に
係る検査は行われず、契約書とこれに従って受払いされるロムのシリアルナンバー
やアクセスキーによって管理される。シリアルナンバーは、一つのロムに対して一
− 6 −
つ付されるもので、同じナンバーが他のロムに付されることはないため、同一物を
認定する上でも非常に有効であり、受払の事実を直接的に確認する手段となる。ア
クセスキーは、ユーザーがその使用許諾を受けたソフトウェアにアクセスすること
を可能にするキーであり、受払の事実を直接的に確認することはできないが、アク
セスキーの解除実績はユーザーによるアクセスや利用状況を示すものである。
（内容確認する上での留意点）
システム販売の会計記録について、取引先との間で交わされる形式的な契約書、
注文書、検収書等とを照合するだけでなく、必要に応じてユーザーにおける検査結
果報告書等を確認する。また、ユーザーの検査結果を確認できない場合、ユーザー
を含めた見積り、開発仕様、納品検査等に係る打合せ議事録等で、物・サービスの
内容確認を行うことが効果的である。
ライセンスの使用許諾について、シリアルナンバーに基づいてロムが受払管理さ
れている場合には、たな卸立会を実施する。また、たな卸立会を実施することがで
きない、あるいは適当でない場合は、ライセンサーに対してソフトウェアの使用許
諾の状況について残高確認を実施する。ライセンスの使用許諾に係る売上高や仕入
高の会計記録については、契約書や納品書、検収書等との照合を行うほか、その取
引量がアクセスキーの解除実績で示されるユーザーのアクセスや利用状況と比較
して余りに大きい等、異常が認められた場合には、取引先の管理部門等窓口担当者
以外の部署に対して取引確認を行うことも有効である。
４．異常な商社的取引に対する留意点
情報サービス産業においては、多段階的請負構造やシステム開発の一部としての
ハードウェアやパッケージ化されたソフトウェアの流通が頻繁に行われており、商社
的な取引が日常的に行われている。その中でも、物理的にも機能的にも付加価値の増
加を伴わず、会社の帳簿上通過するだけの取引（スルー取引）、複数の情報サービス
企業を経由して最終的に起点となった企業に商品・製品等が戻ってくる取引（Ｕター
ン取引）、複数の企業が互いに商品・製品等をクロスして販売し合い、その後在庫を
保有しあう取引もしくは在庫を保有しないで単に売上を相互にスルーする取引（クロ
ス取引）は、取引全体としては実態のない利益操作目的の異常な商社的取引と考えら
れるため、監査人として慎重な対応が求められる。
例えば、Ｕターン取引では複数の企業を経由する間に手数料等が上乗せされ、起
点となった企業へ同一物が還流される。監査人としては、売上の実在性を検証し、取
引の真偽を確認するために、取引全体像の実態を把握し、売上計上された商品・製品、
ソフトウェア等と同一物が再び会社に還流しているものはないか慎重に検討する必
要がある。
一般的に注文書、納品書、検収書、請求書等を確認するだけでは、取引実態の把
− 7 −
握や同一物認定は困難な場合が多い。システム内容が具体的に判明できない（例えば、
見積書や発注書の記載が「○○一式」あるいは「○月分」というように、具体的な作
業内容が記載されていない場合）、ユーザーが特定できない、取引内容が会社や取引
先の事業と関連性が認められない等の異常な場合は、開発・販売計画や作業報告書・
進捗管理表の確認、検査結果報告書の確認、ユーザーを含めた打合せ議事録の確認、
開発者や営業担当者への質問、取引先への取引確認（サービス内容、金額、納期、支
払条件等の具体的な取引条件を明記した取引確認状を取引先管理部門に直接発送し
回収する）等を実施し、取引実態を把握する必要がある。
さらに、商品・製品、ソフトウェア等の取得の経済合理性を確かめるとともに、
在庫の受払管理、滞留状況の把握、期末評価を通じて、取引実態を把握し、同一物認
定を行う必要がある。また、売上物件が固定資産として還流する場合もあるため、固
定資産について、販売されている商品・製品、ソフトウェア等と同等の機能をもって
いるかどうか検討を行うことも同一物認定の有効な手続の一つと考えられる。
いずれにしても、異常な商社的取引は、証憑等が形式的には整合している場合が
多く、複数の情報サービス企業を介在しているため、取引実態が非常に判別しにくい。
監査人としては、特に深度ある監査手続の実施が要求されるところである。
監査手続を実施した結果得られた監査証拠が、監査意見表明のために十分でない
と判断した場合は、さらに必要と認める監査手続を実施することになるが、十分な監
査証拠を入手できたとの心証が得られない場合は、監査範囲の限定として取り扱うか
どうかについて検討することになる。
５．取引価額の合理性の検証
通常の独立した第三者との取引であれば、双方が合意した価額は経済合理性があ
ると客観的に認められるが、第三者と共謀して不正を目的として取引が行われた場合
には、その取引価額には恣意性が入り込み、経済合理性がある客観的な価値とはかけ
離れていることが考えられる。
特に情報サービス産業が事業の対象とするソフトウェアやそれに付随するライセ
ンスなどは、「無形」資産であり、物あるいはサービスの確認ができたとしても、そ
の価値の特定には「有形」資産より困難さが伴う。ソフトウェアの開発請負における
受注金額であれば、作業等の積上原価がそのベースであり、その作業等は得意先から
の受注に基づくシステム開発計画や作業スケジュールに従って実施したものである
ことから、その取引価額に合理性は見い出し易い。しかし、その一方でパッケージ化
された販売用のソフトウェアや使用許諾等のライセンスについては、不特定多数に対
して供給することを前提にしていることから、その取引価額の合理性を特定すること
は難しい場合が多い。事業上のノウハウの提供やコンサルティングなどの取引価額も
同様である。
− 8 −
したがって、監査上は物あるいはサービスの確認と併せて、取引価額の合理性に
ついて多面的に検証を行うことが必要である。
(1) 分析的手続による検証
企業活動の中で日常的に行われている大量の取引のすべてを対象に取引価額の
合理性を検証することは当然に不可能であるから、まずは分析的手続を用いること
が網羅性・効率性の観点からは必要であり、異常な取引価額を発見するためのきっ
かけにもなり得る。
分析的手続の具体的な手法としては、個々の商品・製品ごと又はサービス形態ご
との取引価額及び取引単価の時系列的な推移比較や計画値との比較、取引先ごとの
取引価額及び取引単価の比較などが挙げられる。分析の過程においては特に単発的
でかつ取引金額が大きい取引には留意を要する。また、決算日近くでの金額の大き
な取引にも留意が必要である。
各取引の粗利益率の水準を検証することも、取引価額の合理性を検証する上で有
効である。他の取引に比べて粗利益率が非常に高い水準の取引については、物ある
いはサービスの内容確認を厳格に行う必要がある。また、仲介を目的とした取引は、
在庫リスクを抱えている取引と比べて調達金利・諸経費などの取引コストを粗利益
で回収する必然性が乏しいことから、粗利益率は一般的に低い水準となる。特に仲
介取引を擬制し不正を目的としてスルー取引、Ｕターン取引、クロス取引が行われ
ている場合には、取引金額が大きいにもかかわらず、粗利益率が非常に低い水準で
行われる傾向がある。ただし、粗利益率が通常の水準で取引が行われているスルー
取引等もあるためその点は留意を要する。
(2) 「無形」資産の評価アプローチ
分析的手続や個別的検証手続によって不正の疑義がある取引が特定された場合、
あるいは不正の疑義まではいかないまでも売上金額自体の合理性について客観的
な資料等が入手できない場合において、「無形」資産の取引価額の合理性を直接的
に確かめることが必要となるが、その際には以下の三つの評価アプローチに基づく
検証が参考となる。なお、監査人自身での評価が困難な場合には、各評価アプロー
チに関する専門家を利用することが必要である。
① インカムアプローチ
「無形」資産の経済的寄与の流列を推計し、経済的寄与を積み上げて「無形」
資産の価値を計算する方法である。ディスカウント・キャッシュ・フロー法や超
過収益力法、バランスシート法などが具体的な手法として用いられている。イン
カムアプローチは「無形」資産を活用して収益を得る事業モデルそのものであり、
「無形」資産の評価としては広く適していると言われる。
② コストアプローチ
現時点で「無形」資産を再作成する場合に要するであろうコストの総額を「無
− 9 −
形」資産の価値として計算する方法である。
開発コストをかければ同じ経済的寄与をもたらす資産が複製できると考えら
れる場合には有効な方法であり、再現性の高いソフトウェアの評価には比較的適
していると言われている。
③ マーケットアプローチ
評価を行う「無形」資産に類似した「無形」資産の取引価格を市場調査するこ
とで、「無形」資産の価値を類推しようとする方法である。類似の事例が存在す
るのであれば有用な方法である。
なお、上記のような評価アプローチ方法を形式的に適用することは、かえって取
引実態から乖離してしまうことがあることから、採用する方法が取引実態と合理的
に整合していることを慎重に検討しなければならない。
取引内容に疑義がある取引を発見した場合には、取引の真正を確かめるため、単
に関与先より提示された取引価額に関する資料と照合するだけでなく、監査人とし
て取引価額の合理性を多面的に検討することが必要である。
６．会計処理
情報サービス産業の特有の状況に対応し、実態を反映した適切な会計処理を行う
ためには、会計処理基準についても明確にすべき点が多い。特に、(1)総額・純額表
示の区分、(2)収益の認識時点、(3)複数の要素のある取引等の取扱いについて検討を
要する。以下には、この三つのポイントに関連する米国基準を参考に取り上げ、かつ、
現行我が国の会計慣行への適用可能性について検討した。
(1) 総額・純額表示の区分
総額・純額表示の区分が特に問題となるのは、①スルー取引、②クロス取引、③
Ｕターン取引等で取引の実態がないと判断される場合であるが、取引実態があると
される場合であっても、総額表示が適切ではない場合も存在する。
収益について、総額、純額、いずれで表示すべきかに関する具体的な基準は我が
国の会計基準では明確でないため、米国基準における取扱いが参考になる。FASB
EITF（Emerging Issues Task Force）99-19「収益を本人として総額計上すべきか
代理人として純額表示すべきか（Reporting Revenue Gross as a Principal versus
Net as an Agent）」では、主に情報サービス産業の多くの事例を検討した結果、総
額、純額いずれで計上すべきかについて、単一の指標で判断するのではなく、以下
の指標が示す事実関係と状況に基づいて総合的に判断すると規定されている。
（売上を総額で計上する指標）
− 10 −
ア．取引において主たる債務者（ユーザーに対してサービス責任を負う者）であ
る。
イ．商品受注前又は顧客からの返品に関して一般的な在庫リスクを負っている。
ウ．自由に販売価格を設定する裁量がある。
エ．商品の性質を変えたり、サービスを提供することによって付加価値を加えて
いる。
オ．自由に供給業者を選択する裁量がある。
カ．製品やサービスの仕様の決定に加わっている。
キ．商品受注後又は発送中の商品に関して物的損失リスクを負担する。
ク．代金回収にかかる信用リスクを負担する。
（売上を純額で計上する指標）
ア．供給業者が契約の主たる債務者である。
イ．会社が稼得する金額は確定している。
ウ．供給業者が信用リスクを負う。
上記指標を手がかりに情報サービス産業の特有の取引を検討すると、
① スルー取引のケースでは、取引の形式よりも実態に着目し、売上を総額で計上
する指標のいくつかを具備していると認められる場合には、総額で計上すること
が合理的であるが、単に手数料収入を対価として代理人又は仲介人として行動し
ていると判断されれば、手数料収入のみを純額で計上することになる。
② クロス取引のケースでは、 業者間の取引に経済合理性としての実態があるかに
ついて、
・ 商品受注前又は顧客からの返品に関して一般的な在庫リスクを負っている。
・ 製品やサービスの仕様の決定に加わっている。
・ 自由に販売価格を設定する裁量がある。
・ 代金回収にかかる信用リスクを負担する。
などの条件を満たしているか検討すべきである。その結果、業者間取引に実態が
ないと判断されれば、かかる取引は相殺後の純額で計上することが合理的である。
③ Ｕターン取引のケースは、収益表示の問題というよりはむしろ、取引の真実性
の問題（会計事実としてとらえるべきかという問題）であり、そもそも売上計上
は妥当ではないと判断される。
また、これらの取引において、取引に介在する会社に一定の利鞘（場合によって
は損失）が発生する場合もあるが、取引自体を純額で表示するにしても、仲介者と
して本来得ることのできる合理的な手数料かどうかにより、営業取引区分に表示す
ることが適切であるか検討を要する。
(2) 収益の認識時点の問題
収益の認識時点に関する具体的な基準も我が国の会計基準では明確でなく、米国
− 11 −
基準における取扱いが参考になる。AICPA SOP（Statement of Position）97-2「ソ
フトウェアの収益の認識 (Software Revenue Recognition)」にて、ソフトウェア
の使用許諾、販売及びリース取引等に関するソフトウェア業界特有の収益認識基準
を規定しており、以下の条件をすべて満たす場合のみ収益認識が認められるとされ
ている。
① ソフトウェア取引に関する立証可能な取引証拠が存在すること
② ソフトウェアの引渡しが完了していること
③ 対価が固定あるいは確定していること
④ 販売代金の回収可能性が高いこと
上記指針を手がかりに情報サービス産業の特有の取引を検討すると、①取引証拠、
②引渡しの完了、③対価が固定あるいは確定といった点で次のような事象が見受け
られ、問題取引に至ることがあるため、他の監査証拠を十分に入手して慎重な検討
を行うことが必要である。なお、④の販売代金の回収可能性については、特に情報
サービス産業の特有の問題ではなく、全業種に共通の問題であるため本報告では触
れていない。
① 取引証拠
・ 取引先の法務部等部署による契約書承認に時間がかかり、決算日現在ドラフ
トしか存在していない。
・ 取引先の法務部等部署による契約書承認に時間がかかり、この時間を短縮す
るねらいでパートナー（協力会社）を取引に仲介させて、パートナー企業との
契約書をそろえる。
・ 契約書は存在するものの、ライセンス、又はその対象となるソフトウェアが
実在していない。監査人に示すことができるライセンス契約は実在しない虚偽
の書類である。
② 引渡しの完了
・ 得意先に内部統制上の問題があり、正式な承認手続を経ないまま検収書が発
行されている。また、検収書に得意先の社印やシステム担当責任者の印ではな
く、個人の認印で押印されている。
・ ソフトウェアの品質水準について得意先の了解が得られない場合でも、シス
テムの稼動開始とともに形式的に検収書が発行されている。
・ 検収書を入手しているにもかかわらず、入金予定日に入金がない。検収後も
バグの発生により作業が継続しており、追加原価が発生している。
・ 開発作業が予定よりずれ込み、実際の開発作業終了は決算日後であるにもか
かわらず、得意先の予算消化都合により決算日までに形式的に検収書が発行さ
れている。
− 12 −
・ 業界慣行として検収書の交付が行われていないということを口実として売上
計上している。
また、部分検収、すなわち一つの開発プロジェクトを作業ごとのフェーズに分
けて契約を締結し、各フェーズの検収をもって売上を計上する実務が見られるが、
以下のような問題が見受けられる。
・ 得意先との契約をフェーズ分けし、各々の契約額を操作することによって利
益操作をしている。
・ 後のフェーズになって発覚したトラブルにより、 プロジェクトが中止になり、
検収済みの前フェーズの代金が回収されない、あるいは代金返還を求められる。
・ 開発プロジェクト全体の完成をもって機能するシステムであり、各フェーズ
の独立性が十分でない。
・ フェーズの区切りが単純に手付金の入金日に結び付けられているだけである。
③ 対価が固定あるいは確定
・ 価格について得意先と合意に至らないまま売上計上し、その後、顧客に対し
て返金あるいは値引きが実施される。
・ ライセンスの使用許諾後にバージョンアップが行われ、旧ライセンス契約分
について事後的に返金される。
・ ライセンスの使用許諾について、事後的にボリュームディスカウントが予定
されている。
(3) 複数の要素のある取引
ソフトウェア取引実務において、ソフトウェア・ライセンスの使用許諾のほかに、
アップグレードの実施、保守サービスの提供、アウトソーシング・サービスの提供、
リース契約、機器（ハードウェア）販売などを複合して契約する場合がある。この
場合、要素ごとの販売価額をいかに算定するかが問題となる。
情報サービス産業においては、契約書上、各要素に係る金額が恣意的に決められ、
公正価値によっていない場合がある。例えば、ライセンスの使用許諾と保守サービ
スを一体契約する場合、サービスは使用許諾、保守の順に提供されることから、ラ
イセンスの使用許諾に係る契約額を公正価値より大きな金額とすることにより、ラ
イセンスの使用許諾時に売上を前倒しする場合が考えられる。
この点に関しても米国会計基準（EITF00-21「複数の製品・サービスを伴う収入
取引の会計（Revenue Arrangement with Multiple Deliverables）」）では、たとえ
契約上でそれぞれの要素の対価を定めたとしても、それぞれの要素の価格は、当該
約定価格にかかわらず契約価額総額を各要素の公正価値（当該ソフトウェアベンダ
ーに固有の立証可能な公正価値）で按分することによって算定すると規定しており、
適切な会計処理基準を検討する上での一つの参考となる。
− 13 −
以上のように、情報サービス産業の特有の状況に対応し、実態を反映した適切な会
計処理を行うためには、会計処理基準についても明確にすべき点が多い。特に、(1)
総額・純額表示の区分、(2)収益の認識時点、(3)複数の要素のある取引等の取扱いに
ついて会計処理基準の設定が望まれるところである。
７．おわりに
(1) 深度ある監査の実施
本報告は、情報サービス産業を取り巻く監査上の諸問題について取りまとめたも
のであるが、ここで示した監査上の留意点は、必要最小限のものであるので、各監
査局面においては、更に深度ある監査を実施することが必要である。
(2) 企業会計基準委員会への提言
我が国では収益の認識に関する明確な会計基準が設定されていないという問題
については、日本公認会計士協会のみでは解決できないため、企業会計基準委員会
における明確な会計基準の設定を提言する。
以 上
− 14 −