ソフトウェア開発費の会計税務

30 min readDec 7, 2020

ソフトウェア開発費の会計・税務上の処理について、インターネットで様々な意見を見かける。その多くは「このルールはおかしいからこう変えるべきだ」といった意見で、納得できるものもあるし前提となる認識が誤っているように思えるものもある。

私は経理として、インターネットで何らかのサービスをソフトウェアを通じて提供する複数の会社で何年か働いていた（今はそれを辞めてプログラマ見習いとして働いている）。しかし、何年働いてもソフトウェアの会計・税務は分かりにくい…

そこで、勉強がてらソフトウェアを取り巻く現行の会計・税務の制度がどうなっているかを整理することにした。

なお、ここでいう「会計」は日本基準、米国基準、もしくは IFRS などの一般に公正妥当と認められる会計基準（GAAP: Generally Accepted Accounting Principles）に基づいて財務諸表を作成する手続いわゆる「財務会計」を指し、「税務」は特に断りがなければ日本の法人税 ¹の課税所得計算や申告納付のための手続一般を指すものとする。

会計と税務の違い

ご存知の方も多いと思うが、たまに会計と税務を混同している方を見かけるのと、この先の話の前提となる重要な認識なので初めに整理しておく。

会計上の利益と税務上の課税所得は計算方法が異なる。より正確にいうと、税務上の課税所得は会計上の税引前利益に対して様々な調整を行って計算する ²。

このような制度になっている理由は、両者の目的が異なることに配慮しつつも二重で計算する手間を可能な限り省くためと考えられる。

目的の違い

会計の目的は、株主や債権者などの利害関係者に対して企業の債権債務や純資産をまとめた「財政状態」や一定期間の損益などの「経営成績」を報告することにある。

その一方で租税の目的は所得の再分配と公共投資の財源確保、そして経済政策の実現にある。税務上は（会計での計算を基礎としつつも）課税の公平性を担保しつつこれらの目的を達成するために、様々な政策上の取り決めが行われている。

この「目的の違い」は会計と税務の間に生まれる差を考える上で重要だ。

税務上の課税所得は会計上の損益を基準として計算するが、会計には「課税の公平性」という観点はなく（投資家や債権者の判断に資することが目的なので当然である）原理的・基本的な方針を定めているに過ぎず、費用や収益を計上する基準が「ざっくり」していることが多い。

例えば固定資産の減価償却費について、会計では状況に応じて合理的な範囲で償却方法や耐用年数を決めることができるのが一般的だが、税務ではその資産の種類に応じてそれらが細かく定められている（競走馬の耐用年数は4年で、満2歳から償却を始める…とか）。

実際に差異が生じる類型

会計と税務の差異が生じる類型は大きく分けて3つある。

会計上の債権債務が確定しているかの確認: 例えば、資産の評価損益は会計上は収益や費用となるが、それが確定するまで（例えば子会社の株式であれば清算や売却するまで）税務上の益金・損金とはならない ³。
画一的処理のための統一的な基準の設定: 例えば、減価償却費は会計上の費用として計上した金額を上限として、政令で定める償却限度額の範囲内で税務上の損金として計上することができる ⁴。
政策上の理由で設けられた例外: 例えば、国内外で課される延滞税や行政処分の課徴金、罰金等は会計上は費用/債務となるが税務上は損金にならない ⁵。

ソフトウェア開発費の会計税務間の差異は主に 2. にあたる。

会計と税務が相互に与える影響

会計と税務は日本国内においては互いに影響しあっている。

会計は一般に公正妥当と認められる会計基準に基づいて計算された収益および費用を通じて税務上の課税所得計算に影響を与える。

税務上の課税所得計算の正当性を判断するのは一次的には国税庁に代表される税務当局だが、最終的には司法すなわち裁判所となる。具体的には、税務調査の完了後に何らかの非違が発見された場合、調査された側が結果に納得すれば「修正申告→納付」、納得しなければ「更正処分→仮納付→不服審判→訴訟」という順序で手続が進む ⁶。

この過程で、「一般に公正妥当と認められた」会計基準の「公正妥当」性に関する判断がなされる場合がある。有名な例としては、不動産の流動化に伴う信託受益権に関する税務処理が争点となった「ビックカメラ事件」がある（東京高判平成 25 年 7 月 19 日）。詳細は取り上げないが、この事件で企業会計において一般に公正妥当と認められる会計基準が無条件に司法によってその公正妥当性を認められるわけではないという判断が下されたことは注目に値する。

このように、税務上の課税所得計算においては行政や司法の介入が発生する余地があり、通達や裁判例などを通じて公正妥当性の判断がなされる。その結果が企業会計に影響を与える場合もある。

このように、会計と税務は相互に影響を与えあっている。

税効果会計と繰延税金資産（DTA）

会計上の利益と税務上の課税所得が異なる概念であるとすると、いろいろな問題が生じる。

会計で計上した費用が税務上の損金として認められない場合、法人税額は会計上の税引前当期純利益に実効税率を乗じた額より大きくなることになってしまう。逆に、この差異が一時的なものである場合には将来の法人税額が小さくなる。

これでは会社を取り巻く状況によって最終的な期間損益が大幅に上下し、投資家の判断を誤らせる可能性がある。そのため、会計では税効果会計と呼ばれる分野でこの問題点を解決しようとしている。税効果会計については EY の Web サイトが分かりやすい。

会計・税務の間に生じる収益/益金または費用/損金の差は「繰延税金資産（DTA: Deferred Tax Assets）」または「繰延税金負債（DTL: Deferred Tax Liabilities）」として貸借対照表に計上され、相手勘定を「法人税等調整額」として損益計算書上の税金費用の加減算を行う。

より正確に言うと税効果会計の目的は会計上の「費用/収益」と税務上の「損金/益金」の差を調整することではなく、両者の「資産/負債」の差を調整することで税金費用を合理的に期間按分することにある。

そのため、将来の減算可能性が低い（つまり赤字体質で課税所得を計上する可能性が低い）場合は資産性が認められないので DTA を計上することはできない。また、会計と税務の差のうち将来的に解消される見込みがない差異（永久差異: 例えば行政処分の課徴金や交際費の損金不算入額など）についても DTA を計上することはできない ⁷。

会計の費用は基本的に税務の損金に先行するので、一般的には DTL よりも DTA が計上されることが多い。普通の会計基準では DTA/DTL の主要な内訳を開示することが要求されているので、その注記を見ればその会社でどのような「会計税務間で差が生まれるような処理」をしているか具体的に想像することができる。

DTA を見るときに注目する点

例えばある優良企業がソフトウェアの開発費を会計上は全額費用として計上し、それを税務で全額資産として計上し5年間の定額法による減価償却を行っている場合、事業年度末においては開発費の 4/5 に法人税の実効税率を乗じた金額が繰延税金資産として貸借対照表に計上され、それが次の4年間にわたって取り崩され5年後には消失するはずである。

つまり、以下の3点を見ればその会社のソフトウェアの会計税務に対する立場を大まかに掴むことができる。

開発費総額の予想: プログラマやデザイナーなど、ソフトウェア開発に携わる人がどの程度いるか、外注含めプロダクト開発にどの程度の資金を投下しているか
無形固定資産の確認: ソフトウェアが会計上の無形固定資産として貸借対照表に計上されているか
会計と税務の差: 税効果会計の注記で繰延税金資産の内訳としてソフトウェアの開発費がどの程度計上されているか

ソフトウェアの会計

主要な会計基準として日本基準、米国基準、そして IFRS を題材にソフトウェアの開発に伴う費用の会計処理について整理する。

最後に日本基準の実務について自分の知っている範囲のことを書く。

日本基準

日本ではソフトウェアに関する会計基準として企業会計審議会の「研究開発費等に係る会計基準」および日本公認会計士協会会計制度委員会第12号の「研究開発費等及びソフトウェアの会計処理に関する実務指針」および Q&A において、ソフトウェア開発費の会計処理が示されている。

ソフトウェアの会計処理全体の概要は EY の Web サイトが分かりやすい。

原則的な会計処理は米国基準とほぼ同じで、ソフトウェアの取得形態に関わらず目的別（受注制作・市場販売目的・自社利用）に会計処理を規定している。受注制作は請負工事の会計処理に準じて処理する。

開発費の資産計上については、

市場販売目的: 最初に製品化された製品マスターの完成までの開発費は研究開発費として費用に、それ以外の制作費は原則的に資産として計上する。
自社利用: ソフトウェアの提供により将来の収益獲得または費用削減が確実であると認められる場合には、適正な原価を集計した上で当該ソフトウェアの制作費を資産として計上する。収益獲得が確実とは、例えばそれを用いて外部に業務処理等のサービスを提供する契約が締結されている場合などが挙げられる。

無形固定資産として計上したソフトウェア制作費の償却方法もその利用目的に応じて異なる。

・市場販売目的: 見込み販売数量または見込み販売収益に基づく償却方法により減価償却する。毎期の償却額は残存有効期限（原則3年以内）に基づく均等配分額を下回ってはならない。

・自社利用: 利用実態に応じて最も合理的と考えられる償却方法（一般的には5年以内の定額法）で減価償却する。

市場販売目的のソフトウェアの会計処理は製造業の業務プロセスを参考にしているのではという印象を受ける。

よく争点になる自社利用のソフトウェア開発費については、何をもって「将来の収益獲得または費用削減が確実」といえるかの判断が難しい。よくあるのはソフトウェアへの投資意思決定をする際に作成した事業計画を根拠として収益獲得の可能性を説明することだと思う。

様々な企業の開示を読んでいるとソフトウェアとして無形固定資産に計上されている金額は人員数と平均給与から予想される開発費総額より小さいので、保守的な方向、つまり資産計上しない方向に倒すことが多いように見える。

米国基準

FASB Accounting Standards Codification （ASC）の Topic 730 “Research and Development” の 10-15-4 において、自社利用目的のソフトウェアについては Subtopic 350-40 に、販売目的のソフトウェアについては Subtopic 985-20 においてそれぞれ会計処理を規定していることが記されている。

アメリカのソフトウェア開発費の会計基準は日本とよく似ており、ソフトウェアの利用目的別に会計処理がわかれている。

資産計上については、

・市場販売目的: 技術的可能性が立証された後の製品マスターの作成費用は資産計上し、顧客に販売可能となった（is available for general release to customers）時点で資産計上を停止する。

・自社利用: 開発全体をいくつかの Stage （Preliminary Project → Application Development → Post implementation-Operation）に分ける。開発の内容がソフトウェアの機能向上あるいは機能追加のための開発（Application Development Stage）である場合、その開発にかかった費用を資産計上する。

自社利用ソフトウェアの資産計上には、下記の a. と b. の2つの要件が必要になる。

（ASC. 350-40-25-12 を原文のまま引用）Capitalization of costs shall begin when both of the following occur:a. Preliminary project stage is completed.
b. Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding a computer software project and it is probable that the project will be completed and the software will be used to perform the function intended.Examples of authorization include the execution of a contract with a third party to develop the software, approval of expenditures related to internal development, or a commitment to obtain the software from a third party.

日本基準のように「収益の獲得または費用の削減が確実であるかどうか」という文言は無いが、経営が投資意思決定をしてそれが完成したら意図通りに動作することが probable であれば資産計上する、ということなので最終的に資産計上される金額は日本基準と大きく変わらないと考えられる。

無形固定資産として計上したソフトウェアの償却費については、

・市場販売目的: ユーザーに提供可能となった時点で、「見積総収入を期間配分した金額」または「見積耐用年数を基礎として定額法で期間配分した金額」のどちらか大きい方の金額で償却する

・自社利用: そのソフトウェアの利用の観点から最も合理的な方法で償却するか、見積耐用年数にわたり定額法で償却する

このように主要な内容はほぼ日本基準と変わらない。とはいえ、実際に Subtopic を読んでいくと米国基準の方がより細かい指針や判断基準を提供したり明確で詳細な根拠を要求しているように見える。

IFRS（国際財務報告基準）

IFRS ではソフトウェアに限定した会計基準は存在しない。

ソフトウェアの開発費については、無形資産の一般的な基準である IAS 38 — Intangible Assets に従う。この基準は、 IAS 32 — Financial Instruments: Presentation など、他の基準で特別扱いされているものを除いた一般的な無形資産に適用される。つまり、どのような種類のソフトウェアがどのような目的で作られていようともまずは IAS 38 を参照し、種類や目的に応じて特別な基準がある場合はそれを参照せよということになる。

無形資産の定義は IAS 38 の paragraph 8 ~ 17 に記載されている。重要な属性としては

Identifiablity: 他の資産から独立して識別可能であり、分離して売買や貸し借りできる
Future economic benefits: 収益の増加や費用の削減など、将来の経済的便益をもたらすこと
Control: その経済的便益を獲得するための権利を持っていること（ここで legal enforceability は必要条件ではない）

がある。自社利用や販売目的のソフトウェアは通常これらの条件に該当するだろう。この取得原価を合理的かつ信頼性の高い方法で測定できるときは資産を認識しなければならない。

IAS 38 では自社で無形資産の開発を行う場合は開発全体を以下2つの Phase に分け、前半の開発費を費用として、後半の開発費のうち要件を満たした部分を資産として認識する（paragraph 54 ~ 64）。

Research Phase: 新たな知識の獲得や探索、評価や既存技術の代替手段の探索など、そもそもどういった資産を作れば将来の経済的便益を得られるかの調査研究を目的として行われる活動
Development Phase: 実際に商業的な生産活動を行う前のプロトタイプ作成やテスト、既存資産の改良など、既に将来の経済的便益を生み出すことが実証されている状態で行われる活動

無形資産として計上する際の判断から恣意性を軽減するために、 IFRS は Development Phase で以下 (a) ~ (f) の6要件を全て満たすとき資産計上することを求めている。

(IAS 38, paragraph 57 より原文のまま引用）An intangible asset arising from development (or from the development phase of an internal project) shall be recognised if, and only if, an entity can demonstrate all of the following:(a) the technical feasibility of completing the intangible asset so that it will be available for use or sale.(b) its intention to complete the intangible asset and use or sell it.(c) its ability to use or sell the intangible asset.(d) how the intangible asset will generate probable future economic benefits. Among other things, the entity can demonstrate the existence of a market for the output of the intangible asset or the intangible asset itself or, if it is to be used internally, the usefulness of the intangible asset.(e) the availability of adequate technical, financial and other resources to complete the development and to use or sell the intangible asset.(f) its ability to measure reliably the expenditure attributable to the intangible asset during its development.

(a) は日本基準のいう製品マスターの完成をより抽象的に言い換えた表現といえる。また (c) に見られるように、 IFRS は資産性の判断で日本基準や米国基準と比べて企業（entity）が資産からもたらされる経済的便益を得る能力（ability）を重視しているように見える。ソフトウェアとして資産計上すべき金額の合計は大きな差が生まれる局面は少なさそうだが、資産化要件上の問題で計上のタイミングに差が出ることはありそうだ。

ソフトウェア開発費は一定の基準を満たした場合のみ取得原価で資産計上し、耐用年数にわたって償却されることになる。基準を満たさない場合は発生時に費用処理しなければならない（paragraph 68）。

無形資産は原則的に残存価額をゼロとして償却する（paragraph 100）。償却方法および償却期間は毎決算期末に見直しを行い、予測されるその資産の経済的便益の消費パターンに変化があった場合にはそれを反映して変更される（paragraph 104）。日本基準では販売目的のソフトウェアについては残存期間にわたる均等配分額と見込み販売数量のどちらか大きい方を基準に償却するが、これが IFRS のいう経済的便益の消費パターンにあたるかは微妙なところかもしれない。

ソフトウェア自体を販売目的で開発する際の取り扱いは IAS 38 に加えて IFRS 5 — Non-current Assets Held for Sale and Discontinued Operation を、受託開発する際の取り扱いは IFRS 15 — Revenue from Contracts with Customers を参照。

会計基準間の差異

以上で述べたように、ソフトウェア開発費については基準間で無形固定資産としての計上金額に大きく影響を及ぼすような重要な差異は無い。償却については日本基準や米国基準と比べて IFRS はやや抽象的で基準を読むだけでは想像がつかないので、実務で実際にやってる人の話を聞いてみたいところだ。

本記事では取り上げないが、ソフトウェア開発による収益認識については米国では詳細な基準が定められているのに対して日本では最近ようやく（ソフトウェアに限らない）包括的な収益認識基準ができたという感じなので、その点においては差異が存在している。しかし、収益認識については日本基準も米国基準も IFRS も将来的には同じ方向に向かっていくことは間違いない（最近は FASB と IASB が一緒に作った収益認識基準に日本が後からついていっている）。つまり、収益費用ともにソフトウェア開発に関する会計処理について基準間の差異が重要な課題となる場面に出会うことは将来的にはなくなると考えられる。

実務（日本基準）

私自身に実務経験があるのは日本基準だけなので、それについて書く。間違ってたらすみません。

日本基準において、実際に自社利用のソフトウェアの開発費を会計で資産計上するかは実務指針や社内の意思決定を記録した文書などから個別に判断することになる。例えば事業計画など。

開発費を資産計上する場合は、対象のソフトウェアや機能に対しプロジェクトコード的なものを作り、かかった費用（主に人件費）にそのコードを付けておいて後で集計する。そのような稼働報告をさせられたプログラマの方もいるのではないだろうか。

しかし、経理の実務をやっていた人間として正直に述べると、（特に新規事業をたくさんやるような会社では）ソフトウェアを無形固定資産として計上するのはなかなかハードルが高い。その理由は主に2つある。

一つは収益獲得や費用削減の確実性を開発したソフトウェアや機能ごとに判断することが単純に困難であること。過去との一貫性とどう整合性を取るかの問題とかもあって監査人との調整コストも高い。そこまでして資産計上しても、陳腐化等で将来の収益獲得や費用削減に貢献しないと認められる場合は決算の際に減損することになる。ここまで手間をかけても最大5年の期ズレ（それも開発費全体のいち部分）に過ぎない。

もう一つは税務の損金経理の問題。法人税法上の減価償却費は、会計で費用計上した金額を「上限として」法人税計算の際に損金算入できる。つまり会計で費用として計上しない場合は損金としても計上できないので、その分だけ法人税額が増えることになる。資産計上しようがしまいが中長期的に見ると最終的には減価償却で合計の費用は変わらず、資産計上すると法人税を前倒しで納付することになるので会社側が積極的に資産計上するインセンティブは少ない（5年間の納付額合計は結局変わらないが…）。

これらは単純に実務上の動機の問題で、会計基準に従えば収益獲得または費用削減が確実である場合は資産計上「しなければならない」。しかし、上記の通りハードルがあるというのも事実だと思う。

実際に、会計で自社利用ソフトウェア開発費の大部分を無形固定資産として計上しているソフトウェア企業は意外と少ない（自分の観測範囲では日本より米国のほうが顕著だと思う）。市場販売目的のソフトウェアについては実務をやったことが無いので何も言えないのだが、コンシューマー向けにゲームを開発している会社の開示を読む限り同じような状況のように見える。

まとめ

ここまでで、会計については一般的に以下のことが言える。

主要基準間でソフトウェア開発費の資産計上の取り扱いについて計上金額に重要な影響を及ぼす差異は無い
ソフトウェアの開発費が必ずしも会計で無形固定資産として計上されるわけではない

ソフトウェアの税務

税務上、固定資産のうち使用または時間の経過とともに価値が減少するものを「減価償却資産」と呼び、ソフトウェアはこれに含まれる ⁸。

減価償却資産は企業にとって長期間にわたって収益を生み出す源泉となるので、その取得価額は将来の収益に対する費用の前払いと言える。取得価額は使用や時間の経過による価値の減少に応じて徐々に費用化される。これを減価償却費と呼ぶ。

歴史的に企業会計の観点から減価償却費を測定する様々な合理的・体系的な方法が考え出されてきた。しかし、税務の観点からは画一的な処理の必要性から、会計上の減価償却費を上限とし、その金額と予め政令で定められた減価償却資産の種類別の償却限度額のいずれか小さい金額まで減価償却費を損金算入することができるという制度で画一的処理を図ろうとしている。

税務上の減価償却費の計算方法については法令で定められている通りに行うのみなので、取得価額の計算の方が重要な課題となる。

例外: 減価償却資産からの除外

事業の用に供していない資産は税務上の減価償却資産の定義からは除外される（よって、資産計上もその償却も必要ない）。この「事業の用に供していない」という定義が何を指すかは最終的には行政や司法の判断に属する。

取得価額の計算

会計との違いとして、税務上でソフトウェアを資産計上する際はそれが確実に収益獲得や費用削減に貢献するかという条件は求められていない。つまり、会計では資産計上の要件を満たさなかったとしても税務のみ資産計上しなければならないというケースはある。

ソフトウェアの取得価額の計算方法については、タックスアンサー №5461「ソフトウェアの取得価額と耐用年数」が分かりやすい。

(1) 取得の形態による取得価額の計算方法
イ 購入した場合
 購入の代価＋購入に要した費用＋事業の用に供するために直接要した費用
 この場合、そのソフトウエアの導入に当たって必要とされる設定作業及び自社の仕様に合わせるために行う付随的な修正作業等の費用の額は、取得価額に算入します。
ロ 自社で製作した場合
 製作等に要した原材料費、労務費及び経費の額＋事業の用に供するために直接要した費用(2) 取得価額に算入しないことができる費用
 次のような費用は、取得価額に算入しないことができます。
イ 製作計画の変更等により、いわゆる仕損じがあったため不要となったことが明らかであるものに係る費用
ロ 研究開発費(自社利用のソフトウエアについては、その利用により将来の収益獲得又は費用削減にならないことが明らかであるものに限ります。)
ハ 製作等のために要した間接費、付随費用等で、その合計額が少額(その製作原価のおおむね3％以内の金額)であるもの

これだけ読むと「自社開発でソフトウェアの開発にかかった人件費はほぼ全て資産計上しなければならないのか？」とも思えるが、実はそうとも言い切れない。

法人税法の法令解釈通達7–3–15の2を見ると、取得価額の根拠となる開発費の原価計算について「合理的であると認められる方法により継続して計算している場合には、これを認めるものとする。」とある。

7－3－15の2 自己の製作に係るソフトウエアの取得価額については、令第54条第1項第2号の規定に基づき、当該ソフトウエアの製作のために要した原材料費、労務費及び経費の額並びに当該ソフトウエアを事業の用に供するために直接要した費用の額の合計額となることに留意する。
 この場合、その取得価額については適正な原価計算に基づき算定することとなるのであるが、法人が、原価の集計、配賦等につき、合理的であると認められる方法により継続して計算している場合には、これを認めるものとする。（平12年課法2－19「八」により追加）

「課法」とは法律の名前ではなく、法令解釈通達の改正を示す税務当局の内部文書で、いちおう公開もされている: 平成12年課法2–19。

この「合理的であると認められる方法」については、通達でこれ以上詳細な説明は与えられていない。実務上は、自社利用ソフトウェアの場合は開発全体を複数の主要な機能とそうでない開発に分割し、機能ごとにどのチームやメンバーがどれだけ貢献したかを記録しておいてその割合に応じて主要な部分の開発費（給与・賞与など）を資産計上し残りを損金として計上することが多いと思う。

この区分は「資本的支出」と「修繕費」と呼ばれる。

資本的支出と修繕費

ソフトウェアの開発においては、主要な機能を開発する以外にも様々な活動がある。例えば意図通りに動作しない「バグ」を修正したり、規模の拡大によって低下したパフォーマンスを回復させるためにメンテナンスしたり、様々なケースが考えられる。このような活動にかかった費用は修繕費と呼ばれている。資産化の対象になるような支出を資本的支出と呼ぶ。

定義は法人税法の法令解釈通達7–8–6の2に詳しく書かれている。

7－8－6の2 法人が、その有するソフトウエアにつきプログラムの修正等を行った場合において、当該修正等が、プログラムの機能上の障害の除去、現状の効用の維持等に該当するときはその修正等に要した費用は修繕費に該当し、新たな機能の追加、機能の向上等に該当するときはその修正等に要した費用は資本的支出に該当することに留意する。（平12年課法2－19「十」により追加）

なお、資本的支出と修繕費の区分が明確でない場合は最低7割を資本的支出とするというルールが定められている。

7－8－5 一の修理、改良等のために要した費用の額のうちに資本的支出であるか修繕費であるかが明らかでない金額（7－8－3又は7－8－4の適用を受けるものを除く。）がある場合において、法人が、継続してその金額の30％相当額とその修理、改良等をした固定資産の前期末における取得価額の10％相当額とのいずれか少ない金額を修繕費とし、残額を資本的支出とする経理をしているときは、これを認める。（昭55年直法2－8「二十六」により追加、平7年課法2－7「五」、平19年課法2－7「八」により改正）

これを私は勝手に7:3ルールと呼んでいる。なぜ7割？という疑問はあるものの、法律関係の画一的処理を図るためこのようなルールを定めているのかもしれない。

これを言い換えると、ソフトウェアの取得価額を会計・税務で資産計上するか否かに関わらず、税務上何を資本的支出と捉え何を修繕費として捉えるかを記録していない場合は無条件でその開発費の最低7割を資本的支出としてソフトウェアの取得価額に加算しなければならないことになる。

このような処理を何もやってない会社は税務調査が行われたときに資産化の漏れに伴う法人税額の過少申告を指摘される可能性がある。さすがに顧問税理士がついているような会社で何もやってないということはないだろうが…

移転価格税制

ソフトウェア開発に限らないのだが、外国にある関係会社と取引がある場合、移転価格税制（TP: Transfer Pricing）が重要課題になることがある。

例えば、日本で開発したソフトウェアを通じて海外のA国にサービスを展開する際にA国に完全子会社を設立しその法人で事業を運営する（しかし、ソフトウェアのローカライズ的な開発は全て日本で行っている）場合を考える。

A国法人は日本法人にローカライズの開発費を支払う義務を負うと考えられるが、この価格は税制を無視すれば自由に決めることができる。もし日本で利益がガッポガッポ出ていてA国が赤字なら、法人税額を考えると日本でなるべく多くの費用を負担した方が連結グループ全体では納税額が減少することになる（日本の税収が減ってA国の将来的な税収が増える）。

移転価格税制ではこのような租税回避策を防ぐため、現実の取引対価ではなく関係会社間の取引が「独立当事者間の取引において通常設定される価格（arm’s length price）」で行われたとみなし、その差額によって生じた所得の差によって生じる利益に課税することができる。先の例ではA国にとっては損をすることになるが、通常は二国間の租税条約（やその類型となる OECD モデル条約）でそのような取り扱いが認められている ⁹。

多くの場合で無形資産の取得価額計算は究極的には期ズレに過ぎないが、移転価格はその国の課税権に関わる問題なので税務当局としても時間や人員を投資する価値がある。ソフトウェアや製薬などの研究開発は人件費が中心なので付け替えしやすく、移転価格で問題になりやすい要素があると思う。

悪意がなくても関係会社間の取引が arm’s length price でなされていないとみなされる場合は申告漏れを指摘される可能性があるので、注意する必要がある。

個人的な意見

個人的意見だが、ソフトウェアの会計税務はルールが抽象的で分かりにくいと感じる。

会計については将来的に米国基準と IFRS に収斂していくことは間違いなく、世界中で同じような会計基準が使われることになる。個人的な意見としては IFRS は抽象的すぎるので米国基準にも頑張ってほしい。米国基準は米国基準で問題があったりするが…

税務では通達で資本的支出と修繕費の区別に関する行政当局の判断基準をより詳細に公開してほしいと思うことはある。

感想

長々と書いたが、そんなに面白くない結論になってしまった…

ぶっちゃけソフトウェア開発費が会計税務でどう扱われようが究極的には数年間の（それもさほど大きくない）期ズレに過ぎないので、現実を反映しつつ手間が少ない方法に収斂していくと思う。

移転価格税制は特殊な分野で、何か起きたときのダメージが大きいが一般的によく知られた知恵が無いところ。企業活動がグローバル化していく中で重要性が高まる分野だとは思う。

最後に

私自身は公認会計士でも税理士でも弁護士でも公務員でもないただの素人なので本記事の利用は自己責任でお願いします。記事に誤りがあれば、コメント等でご指摘いただけると助かります。

なお、法人税の申告についてはお近くの税理士もしくは管轄の税務署に、財務会計については自社の会計監査人や財務会計責任者などにお問い合わせください。

脚注

¹ 一口に法人税といってもいろいろあるのだが、主題と関係ないので法人税の詳細な分類の話はしない。ここでは一般的な一事業年度ごとの所得に課税される法人税を指す。

² 法人税法22条4項では課税所得の根拠となる益金または損金の金額は「別段の定めがあるものを除き、一般に公正妥当と認められる会計処理の基準に従つて計算される」ものとしており、同74条1項では「確定した決算に基づき」確定申告を行うことになっている。つまり、法人税制は 1. GAAP → 2. 会社法 → 3. 法人税法という三段階の計算が行われることを想定している。 3. の枠組みが逆に 1. と 2. に影響を与えるケースはある（例えば税効果会計）。

³ 法人税法25条、同33条を参照。

⁴ 法人税法31条を参照。

⁵ 法人税法55条を参照。

⁶ この手順については以前「税務調査で誤りが見つかる割合」という記事に書いた。

⁷ 繰延税金資産のうち会社が回収の見込みが無いと判断した部分については評価性引当金として控除し、控除後の金額を貸借対照表に計上する。その内訳は開示する必要がある。

⁸ 法人税法施行令13条を参照。

⁹ 移転価格税制以外にも、先進国の課税当局では協力して国際課税ルールの穴を防ぐための取り組みが行われている。それらは「税源浸食と利益移転（BEPS: Base Erosion and Profit Shifting）プロジェクト」と呼ばれる。