研究開発費の会計
R&D Expense Accounting ・ けんきゅうかいはつひのかいけい
研究開発への支出を費用処理するか資産計上するかを定めるルール
概要
研究開発費の会計とは、新しい製品や技術を生み出すための支出——研究者の人件費、実験材料、試作品の製作費、開発用設備など——を、費用としてその期に処理するか、それとも無形資産として貸借対照表に計上して将来の期間に配分するかを定めるルールです。研究開発は「将来の収益の種まき」ですから、直感的には資産に見えます。しかしその成果が実るかどうかは極めて不確実で、会計はこの「将来性はあるが不確実な支出」の扱いに長く悩んできました。
日本基準の原則は明快で、研究開発費は発生時にすべて費用処理します。一方、国際的な会計基準(IFRS)は研究局面と開発局面を区別し、研究費は費用処理、開発費は一定の要件を満たせば資産計上を求める、という二段構えを取ります。さらにソフトウェアについては日本基準にも制作目的別の細かなルールがあり、研究開発の要素が終わった後の制作費は資産計上される場面があります。「同じ支出でも、基準と局面によって費用にも資産にもなる」——この判断の分かれ目を理解することが、この語のテーマです。
研究開発費の扱いは、単なる経理処理の違いにとどまりません。研究開発に巨額を投じる製薬・IT・製造業では、費用処理か資産計上かの違いが利益の水準を大きく変え、企業間比較や投資判断に直結します。
なぜ生まれたか
会計には、支出の効果が将来に及ぶなら資産に計上し、効果の及ぶ期間に費用配分するという基本原則があります。工場の建物を資本的支出として資産計上し減価償却するのはこの原則の適用で、収益と費用を同じ期に対応させる費用収益対応の原則に沿った処理です。研究開発費も「将来の収益獲得のための支出」ですから、理屈の上ではこの原則の適用候補になります。実際かつては、開発費を繰延資産として計上する処理が広く認められていました。
しかしここに深刻な問題がありました。研究開発の成果は極めて不確実で、成功するかどうか、いつ・いくらの収益を生むかを客観的に予測することがほぼできません。資産計上を認めると、「この研究はきっと実を結ぶ」という経営者の楽観(あるいは意図的な操作)で費用を資産に付け替え、利益をかさ上げする余地が生まれます。実際、成果の見込みのない開発費を資産として積み上げ、後に一括で減損して問題化する事例が各国で繰り返されました。そこで会計基準は、不確実な状況では資産計上を控えめにするという保守主義の考え方に立ち、「発生時に費用処理」を原則とする方向へ収斂しました。企業間の比較可能性——どの会社も同じ処理なら、研究開発の積極性を費用の額で比較できる——も、この選択を後押しした理由です。理論的な美しさ(対応原則)よりも、検証可能性と操作防止を優先した、会計の現実的な割り切りと言えます。
詳細
「研究」と「開発」の区別
会計上の「研究」とは、新しい知識の発見を目的とした計画的な調査・探究を指します。「開発」とは、研究の成果や既存の知識を使って、新しい製品・サービス・生産方法の計画や設計に落とし込む活動です。基礎研究は成果が読めないが、開発は製品像が具体化しており実現性を評価しやすい——この不確実性の差が、両者を区別する意味です。日本基準はこの区別をしても処理は変えず(どちらも費用処理)、IFRSは区別に処理の差を持たせます(研究は費用、開発は要件を満たせば資産計上)。IFRSにおける資産計上の要件は、技術的な完成の実現可能性、完成させて使用・売却する意図と能力、将来の経済的便益の発生可能性、支出を信頼性をもって測定できること、などです。裏を返せば、これらを客観的に示せない限り費用処理となるため、実務上も開発費の大半は費用処理されます。
ソフトウェア会計 — 日本基準の重要な例外
日本基準で「原則すべて費用処理」の重要な例外となるのがソフトウェアです。制作目的別にルールが分かれています。受注制作のソフトウェアは工事契約に準じた収益・原価の処理を行います。市場販売目的のソフトウェア(パッケージ製品など)は、製品としての完成を示す「最初に製品化された製品マスター」の完成までが研究開発費(費用処理)で、その後の機能改良・強化の制作費は無形固定資産として資産計上し、見込販売数量などに基づいて償却します。自社利用のソフトウェアは、その利用により将来の収益獲得または費用削減が確実と認められる場合に資産計上し、利用可能期間(通常5年以内)で償却します。
この構造を一言で言えば、「研究開発としての不確実性が消えた時点から先の支出は資産にしてよい」ということです。製品マスターの完成や、社内利用による効果の確実性という「不確実性が晴れた」ことを示す客観的な区切りを設けて、費用と資産の境界線を引いているのです。クラウドサービス(SaaS)の開発費は自社利用ソフトウェアとして扱われることが多く、IT企業の決算書ではソフトウェア資産の計上額と償却負担が業績を読む重要なポイントになります。
利益への影響と決算書の読み方
費用処理と資産計上の違いは、支出のタイミングと費用のタイミングのずれとして利益に現れます。年間100億円を研究開発に投じ続ける会社を考えると、全額費用処理なら毎期100億円の費用です。仮に資産計上して5年償却するなら、初年度の費用は20億円で済み、利益は80億円かさ上げされます(定常状態に達すれば毎期の費用は同じ100億円に収束します)。つまり資産計上は、研究開発を増やしている局面で利益を大きく見せる効果を持ちます。日本基準採用企業とIFRS採用企業の利益を比較するとき、この処理差は無視できません。研究開発費の総額は損益計算書や注記で開示されるため、「売上高に対する研究開発費の比率」を並べて比較するのが定石です。
もう一つの重要な帰結は、自社で生み出した技術やブランドの価値は貸借対照表に載らないということです。費用処理された研究開発の成果は、どれほど価値があっても資産として計上されません。ところが、その会社を他社が買収すると、買収価額と純資産の差額がのれんや無形資産として買収側の貸借対照表に一気に現れます。「自社創設の無形価値は載らないが、買ってきた無形価値は載る」という非対称は、研究開発費の費用処理という保守的なルールの裏面であり、研究開発型企業の貸借対照表が実態より小さく見える理由でもあります。
実務での落とし穴
実務上の典型的な論点は、費用と資産の境界の判定です。市場販売目的ソフトウェアの「製品マスター完成」の時点認定、自社利用ソフトウェアの「将来の収益獲得・費用削減が確実」の判断はいずれも会計上の見積りと経営判断を含み、資産計上を膨らませて利益を作る粉飾の温床になった例があります。資産計上したソフトウェアが収益を生まないと判明すれば減損(帳簿価額の切下げ)が必要になり、先送りした費用が一括で損失化します。決算書を読む側は、ソフトウェア資産の残高が売上に比べて不釣り合いに膨らんでいないか、償却期間が同業他社より長すぎないかをチェックする、というのが実務の勘所です。
