2015/5/14
このところ、番外編(投資)の記事が続いたが、今回はもとのIFRS15「顧客との契約から生じる収益」へ戻りたい。今回は、ソフトウェアの受託開発契約を例に、“契約”の扱いについて詳細を見ていこうと思う。ソフトウェア受託開発契約は、受注までの顧客とのやり取り、サービスと製商品の組合せなど契約内容が多岐にわたること、契約変更を伴う可能性が高いことなどから、他の業種の参考になりやすいと思われるからだ。
久しぶりなので、ざっと今までの流れを記載すると、最初に斜め読みして全体の手掛かりを得、その後、“5つのステップ”を営業などの業務活動面から眺め、基準の目的に“キャッシュ・フロー”と記載されていることの意味を考え、IFRS15が採用しなかった収益認識モデルへ寄り道し、IFRS15の適用範囲を規定する“顧客”と“契約”について考えてきた。今回は“契約の識別”について、実務をイメージしながら、もう少し掘り下げたい。
改めて、“5つのステップ”を思い出してみよう。今回は、このうち第1のステップが中心となる。
1. 顧客との契約の識別
2. 履行義務の識別
3. 取引価格の算定
4. 取引価格の履行義務への配分
5. 履行義務の充足
さて、ここから、ソフトウェア受託開発の(想像上の)例と共に、IFRS15の内容を見ていこう。
販売管理システムの受託開発を得意とするA社があるとしよう。A社は、1から全てを開発するのではなく、他社が開発したパッケージ・ソフトを顧客の要求・状況に合わせて選択し、カスタマイズして納品する。顧客の要望により、ハード・ウェアの選定・納入や従業員へのシステム教育、稼働後の運用サポートも行う。
A社はセミナーを開催して、出席した潜在顧客と名刺交換を行い、後日連絡を取って訪問し、潜在顧客の状況について詳細な情報を入手する。この段階で、潜在顧客ごとのファイルを作成し、訪問するたびに情報を蓄えていく。
ある潜在顧客Bが、製品ごとの組織を顧客ごとの組織へ組織再編を行ったが、システムが追いついていないという悩みを持っていることを察知した。即ち、顧客との取引履歴、営業マンの訪問記録、売上・回収管理などが、従来の製品別組織のシステムのままで管理されており、顧客とどのような取引をしたか、営業マンがどのような情報収集や提案をしたか、売上実績や債権回収状況はどうか、といったことを顧客ごとに網羅的に知りたい場合に、一々、異なるシステム間で名寄せや突き合わせをしなければならない状況だった。しかし、この潜在顧客Bの現業部門は、無駄があると分かりつつも、現行システムが使い慣れているので、リプレースに抵抗していた。
そこでA社は、現行システムを統合された新しいシステムにリプレースした場合の経済効果等について調査することを潜在顧客Bへ勧め、その調査に関するコンサルティングを申し出た。が、断られた。潜在顧客Bは、そのような調査にコストをかける習慣がなかったのだ。
この段階でA社の潜在顧客管理ファイルには、数々の訪問記録と、コンサルティングの提案書が記録され、その提案書には失注のフラグが立てられた。訪問や提案書作成に要したコストも、勤怠管理システムや会計システムから集計されていたが、もちろん、資産計上されることはなかった。
ところが、後日、この潜在顧客Bの経営層から次のような申し出があった。
コンサルティングに費用は払えないが、わが社の実情に合ったシステム構築に係る概算費用と経済効果について、簡単に見積もってもらいたい。そのための調査にはいくらでも協力する。社内を説得する材料が欲しい。
A社は、次の方針を決めて、新しいプロジェクト・コードを潜在顧客ファイルへ登録した。そして、潜在顧客Bの経営者へ面談のアポを入れた。
顧客関連記録の名寄せや突き合わせのコスト削減より、組織を顧客ごとへ変更した目的を実現させること(=顧客満足度のアップ、収益獲得機会を逃さない)の方が、経営的な意味が大きいことを説明する。そのためのシステム開発と位置付けるべきであることを説明する。
簡単な調査では、大規模システム導入の総費用を正確に見積もることは到底できないので、参考情報として非常にざっくりした数字を提示する。
改めて、潜在顧客Bの実情に合ったシステムを導入するために、どのパッケージ・ソフトをどのようにカスタマイズするのが良いか、方針を決定する社内プロジェクトの立上げと、この企業からの常駐者数名、数ヶ月程度の無償のサポートを提案する。
この社内プロジェクトの結果、潜在顧客B自身が経営上のメリット・ディメリットについて量的にも質的にも評価できるようになると説明する。(新システムを開発するかどうかは、その結果、潜在顧客自身で決定する。)
A社は、この社内プロジェクトをサポートするなかで、大規模システム開発・導入に不慣れな潜在顧客Bに、最新のIT技術状況や他社事例などの情報を提供し、新システム導入後の業務イメージや経営に提供できる新しい情報のイメージを持ってもらうつもりだ。さらには、現場を巻き込んだシステム開発プロジェクトの進め方のイメージをこの社内プロジェクトのリーダーへ教育したり、多くのヒアリングを重ね、接触することで現場の人々が持っているシステム変更への抵抗感を薄める効果もあると考えている。
潜在顧客Bの経営者との面談の結果、今度の提案は歓迎された。社内プロジェクトの成果への期待と共に、これに関わる従業員への教育効果が高く評価された。A社は、このプロジェクトの成功を確信した。経営上のメリットがあることは明らかと思えるし、数ヶ月の間、経営者をはじめとする多くの潜在顧客Bの従業員と密接に関われることは、システム開発の意思決定やその後の開発プロジェクトの成功に大きな影響を与えるだろう。
さて、この段階でステップ1をクリアできるだろうか。即ち、契約を識別できるか。
無償のサポートについてであれば、可能かもしれない。しかし、無償なので、契約を識別しても収益認識という面からの意味はない。ただ、このプロジェクトに係るコスト集計はしておいた方が良いかもしれない。しかし、その後のシステム開発プロジェクトに関する契約は、もちろん、まだ識別できない。
数ヶ月後、この社内プロジェクトはA社の目論見通りに成功し、潜在顧客Bはシステム開発を決定した。一応、システム開発業者の選定手続きは行ったが、A社が選ばれた。この社内プロジェクトを通じて、プロジェクト・リーダーだった潜在顧客Bの従業員は、この社内プロジェクト・チームが発展して組成されるシステム開発チームを運営していく自信を深め、その後も、A社と一緒に仕事をすることを望んだ。社内プロジェクトのオーナーであった経営者も、A社を信頼した。
この段階であれば、システム開発に関する契約を識別し、ステップ1をクリアできるかもしれない。しかし、IFRS15は、契約を識別する要件を 9項に定めているので、確認してみよう。
(a)
契約の当事者が、契約を承認(書面で、口頭で又は他の取引慣行に従って)しており、それぞれの義務の履行を確約している。
(b) 企業が、移転すべき財又はサービスに関する各当事者の権利を識別できる。
(c) 企業が、移転すべき財又はサービスに関する支払条件を識別できる。
(d)
契約に経済的実質がある(すなわち、契約の結果として、企業の将来キャッシュ・フローのリスク、時期又は金額が変動すると見込まれる)。
(e)
企業が、顧客に移転する財又はサービスと交換に権利を得ることとなる対価を回収する可能性が高い。対価の金額の回収可能性が高いかどうかを評価する際に、企業は、顧客が期限到来時に当該対価の金額を支払う能力と意図だけを考慮しなければならない。企業が権利を得ることになる対価の金額は、企業が顧客に価格譲歩を提供する可能性があることにより対価に変動性がある場合には、契約に記載された価格よりも低くなることがある(第52項参照)。
システム開発契約は通常多額となるので、少なくとも書面での契約が必要だ。しかし、契約書はあるものの、正式な承認はまだだった。一応、契約書案では、A社と顧客企業Bの役割分担が明確に定められている。数ヶ月も一緒に仕事をしてきた両者であれば、その分担についても共通イメージを持ちやすかっただろう*1。
契約の実態・中身については問題なさそうだ。但し、1点、心配なことがある。上記 (e) の問題だ。潜在顧客Bの、対価の支払い意思は良いとして、問題は対価の支払い能力だ。
無償のサポート・サービスを行っていたA社のメンバーが、潜在顧客Bの財務情報を入手した。それによると、近年、業績が思わしくない。運転資金には窮してはいないが、多額のシステム投資には不安を覚えた。潜在顧客Bの経営者も、事業規模の割に過大投資気味ではないかと口にしていた。
そこで、改めて、A社は潜在顧客Bの社内プロジェクト・メンバーと相談し、次のような方針で契約内容を見直すことにした。
(契約の分割)
契約は、一括契約ではなく、2期に分割する。第1期に顧客情報の共有など、経営意思決定に役立つシステムを優先して開発・稼働させ、事業戦略上のメリットをなるべく早く実現させることを狙う。但し、開発の複雑性は増し、トータルの契約期間は長期化する。第2期の契約は、第1期終了時の状況を踏まえて、改めて、費用見積もりや契約締結手続きを行う。
(契約額の減額)
開発チームについて、潜在顧客Bのメンバーを増員するとともに、A社からのメンバーを減らし、潜在顧客Bの関与の度合いを高める。なるべくパッケージ・ソフトをカスタマイズせず、そのまま利用する方針を強化する。開発作業は潜在顧客Bの社内ですべて行う。これらの結果、契約額を減額する。但し、潜在顧客Bは、プロジェクト・メンバーとなる従業員に対する IT 教育予算を増額する。
(支払条件)
システム稼働時の一括払いから、均等額の毎月払いへ変更する。
以上の結果、再作成された契約書は、A社と潜在顧客Bの両社内で正式な承認を受けることができた。この段階で、A社の顧客ファイルでは、このプロジェクトに受注フラグが立てられた。そして、上記の IFRS15.9の要件も満たし、会計上も契約として識別されることになった。
ということで、今後はしばらくこの例を色々いじりながら、IFRS15の規定を見ていきたい。
ところで、これを書きながら、前回(468−5/12)の記事の東芝の進行基準の原価見積もりのことが気になった。建設土木工事にも不確定要素はあるが、システム開発に比べれば原価見積もりしやすいのではないか。問題の発端になったのはインフラ工事の一部とされているが、システム部分だろうか。
それにしても、3期累計の営業損益ベースの影響額が 500億円とは、かなり多額だ。ただ、期間損益にズレがあっただけかもしれないので、期末剰余金への影響は意外と僅かになるかもしれない。とはいえ、原価管理のかなり根本的な部分がおかしい可能性がある。恐らく、リスク管理やモニタリングだけでなく、統制環境にも欠陥があるとの指摘を避けられないように思う。問題は根深そうだ。
ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
*1 さて、ここでこの役割分担について、一つ、みなさんに考えていただきたい。ソフトウェア受託開発は、顧客にとってサービスを受けたのだろうか、それとも、製品の購入だろうか。答えは「どちらもあり得る」だ。即ち、契約次第だ。そして、この契約で定められた役割の違いが、会計処理にも大きな影響を与える。
例えば、製造業の外注加工契約でも同じようなことはある。原材料や工程完成品を外注先に支給して、加工賃を支払うパターンであれば、サービスの提供を受けたことになる。一方、外注先が全てを整えた製品を納入するのであれば、仕入取引ということになる。支給した原材料、及び、それに外注先が加工を加えた仕掛品(の原材料費部分)は、発注者が所有するので、外注先に保管されているものでも発注者のB/Sへ計上される。製造業の場合は、“モノ”に着目すれば、両者をシンプルに分類できる。
ところが、これをソフトウェアの受託開発へ当てはめて考えると、原材料となるべき“モノ”が見当たらない。では、何に着目するか。それが“役割分担”ということになる。
・開発の主体は誰か
最も重要な点だが、契約上、開発の主体が顧客企業とされていれば、ソフトウェア会社はサービス提供企業という位置付けになる可能性が高い。一方、ソフトウェア会社が開発主体とされていれば、完成品を顧客企業へ納入するイメージになる。ただ、これらの契約上の規定が、実質を伴っていることが重要で、以下のようなところで検討される。
・開発の成果物(設計書、仕様書、プログラム、運用マニュアルなど)は誰のものか
成果物が直ちに顧客企業のものとなり、顧客企業が管理するのであれば、顧客企業が開発主体となっている可能性が高い。一方、成果物が一定期間、ソフトウェア会社に留置されていたり、その一部の権利(例えば、転用権など)がソフトウェア会社に残る場合は、ソフトウェア会社側が開発主体と考えられる可能性が高まる。
・開発はどこで行われ、誰が管理するか
当然ながら、開発が顧客企業内で行われ、その開発プロジェクトを顧客企業の従業員が指揮・管理する(=プロジェクト・リーダーとなる)パターンが、最も、顧客企業が開発主体である可能性が高まる。開発プロジェクトは、顧客企業とソフトウェア会社の混成チームであっても構わない。ただ、プロジェクト・リーダーが誰か、というのは重要だ。
・・・
以上の結果、会計処理には次のような影響がある。
(5. 履行義務の充足=収益認識のタイミング)
開発主体が顧客企業、それをソフトウェア会社がサポートするという役割分担になれば、ソフトウェア会社はサポート・サービスを提供するのであり、収益認識は、サービスの提供ごと、或いは、提供期間に基づいて行われる可能性が高い。ソフトウェア会社が開発し、それを顧客企業へ納入するのであれば、それを受領・検収した時に収益認識される可能性が高い。
(2. 履行義務の識別、3.
取引価格の算定、4. 取引価格の履行義務への配分)
当然ながら、サービスか、製商品の納入かで、履行義務の項目・内容も異なってくる。それが異なれば、契約対価も、対価の履行義務への配分も全て変わってくる。
最近のコメント