SaaS事業を続けていると、機能改良は止まりません。毎週のようにリリースがあり、大小の改善が積み重なっていきます。
そこで経理が困るのが、これをどう処理するかです。全部を資産にすると固定資産台帳が膨れ上がりますし、かといって全部を費用にしてよいのかも判断がつきません。そもそも、どこからどこまでを1件として数えるのかがはっきりしません。会計基準はパッケージソフトを前提に作られているため、この状況を直接想定していないという事情もあります。
この記事では、非上場のSaaS事業者を念頭に、税務処理を軸にした現実的な捌き方を整理します。
まず費用処理できる範囲を見極める
いきなり資産計上の話に入る前に、確認したいことがあります。その改良、そもそも資産にする必要があるでしょうか。
改良の件数が多くても、資産計上が必要なものはごく一部ということも十分にあり得ます。ここを丁寧に見ておくと、後の管理がずいぶん楽になります。
性質による区分
| 改良の性質 | 処理 |
|---|---|
| バグ修正、障害対応 | 修繕費として費用処理 |
| 現状の機能を維持するための手直し | 修繕費として費用処理 |
| 新しい機能の追加、処理能力の向上 | 原則として資本的支出 |
| 既存機能の著しい改良 | 会計上は研究開発費、税務上は資本的支出になることが多い |
判断の分かれ目は、その支出によってソフトウェアの価値が高まったか、使える期間が延びたかどうかです。動かなくなったものを動くように直したのなら修繕費、できなかったことができるようになったのなら資本的支出、という整理になります。
実際には、この二つが一つの作業に混ざっていることがよくあります。障害の原因を直すついでに処理速度も上げた、といったケースです。この扱いは後述します。
何を1件と数えるか
金額基準を使うなら、何をもって1件と数えるかを決めておく必要があります。
通達が判定の単位としているのは、一の計画に基づいて同一の固定資産について行う修理・改良等です。支払いの回数やチケットの枚数ではなく、一つの目的をもったまとまりで数える、という考え方です。
ただし、これをどう社内の管理単位に落とすかは、開発の進め方によって幅があります。決まった正解があるわけではありません。
小さな改善であれば、チケット1枚がそのまま一つの改良ということもあります。一方、大きな機能追加なら、複数のチケットとスプリントにまたがっても、企画としては一つのまとまりです。前者をチケット単位で数えるのは自然ですし、後者を企画単位で数えるのも自然です。
実務では、開発の企画やエピックの単位を使うのが扱いやすいと思います。目的が一つに定まる範囲で切れますし、工数の集計もその単位でできるためです。すでにプロジェクトコードで原価管理をしているなら、それをそのまま使えます。
やってはいけないこと
単位の決め方に幅があるとはいえ、避けるべき処理ははっきりしています。
一体で進めている開発を、金額基準を下回らせるために分けることです。一つの機能追加を工程ごとに発注し直したり、期をまたがせたり、チケット単位で細かく計上したりして、20万円未満に見せる。こうした処理は認められません。
判断に迷ったら、その改良が「何のためにやるのか」を考えてみてください。目的が一つなら、途中で何回に分かれていても一つのまとまりです。
なお、一つの改良が2以上の事業年度にわたって行われる場合は、各事業年度ごとに要した金額で判定することとされています。大きな機能開発が期をまたぐ場合、この扱いが効いてくることがあります。ただしこれは、期をまたいだ結果としてそうなる場合の話です。
決めたら変えない
単位の決め方に幅があるということは、裏を返せば、会社が決めて説明する必要があるということです。
その年の利益に応じて単位を変えるような運用は、説明ができません。細かく切れば費用処理が増え、大きく括れば資産計上が増えるので、恣意的な操作の余地があると見られます。
一度決めた単位は文書にして、毎期同じように運用します。
金額による判定
性質で判断しきれない場合や、金額が小さい場合には、金額による基準が使えます。ここは3つの基準があり、使える場面が違います。
| 基準 | 内容 | 使える場面 |
|---|---|---|
| 少額・周期の短い費用 | 20万円未満、またはおおむね3年以内の周期で行われるもの | 資本的支出であることが明らかでも使える |
| 形式基準 | 60万円未満、または前期末取得価額のおおむね10パーセント以下 | 資本的支出か修繕費か区分が明らかでない部分のみ |
| 区分の特例 | 支出額の30パーセントと前期末取得価額の10パーセントのいずれか少ない額を修繕費とする | 上記で判定できない場合。継続適用が条件 |
順番に見ていきます。まず1件20万円未満なら、新機能の追加であっても修繕費として処理できます。小さな改良の多くはここで片付きます。
20万円以上の場合、次に見るのが60万円の基準です。ただしこれは、資本的支出か修繕費か区分が明らかでない部分にしか使えません。新機能の追加のように資本的支出であることがはっきりしている支出には適用できません。
先ほど触れた、障害対応と機能向上が混ざっているようなケースがこれにあたります。切り分けようとしても工数の内訳が判然としない、という部分について60万円未満なら修繕費にできます。
前期末取得価額の10パーセント以下という基準も併用できます。既存のソフトウェアの取得価額が大きい会社なら、60万円を超えていてもこちらで救えることがあります。
それでも決まらない場合の30パーセント基準は、継続適用が条件です。有利なときだけ使うということはできません。
このほか、青色申告をしている中小企業者等であれば、少額減価償却資産の特例を使える場面もあります。ただし年間の限度額があり、他の資産の取得と枠を分け合うことになります。適用できるかどうかは個別の判断になるため、必要に応じて顧問税理士に確認してください。
費用処理できる範囲を整理すると
以上を踏まえると、社内ルールはたとえば次のような形になります。
| 場面 | 処理 |
|---|---|
| バグ修正、障害対応 | 金額にかかわらず修繕費 |
| 1件20万円未満の改良 | 修繕費 |
| 保守と機能強化が混在し切り分けが難しい部分で60万円未満 | 修繕費 |
| 上記以外 | 資産計上 |
この基準を通すと、資産計上が必要な件数はかなり絞られるはずです。企画単位で数えて年間30件の改良があっても、資産になるのは数件から10件程度という会社が多いのではないかと思います。
大事なのは、この基準を文書にして毎期同じように運用することです。その年の利益に応じて基準を変えるような運用は、税務調査で説明できません。
資産計上する場合の処理
絞り込んだ結果、資産計上が必要なものについて見ていきます。
独立した新たな資産として償却する
資本的支出は、既存のソフトウェアと種類と耐用年数を同じくする新たな減価償却資産を取得したものとして扱います。自社利用のソフトウェアであれば耐用年数5年、定額法で、事業供用月から月割で償却します。
ここで誤りやすいのが、既存のソフトウェアに金額を加算して、その残りの期間で償却するという処理です。これはできません。
資本的支出を既存資産に加算したり合算したりする特例は存在しますが、平成19年3月31日以前に取得した資産や、定率法を採用している資産が対象です。定額法しか認められないソフトウェアでは使えません。
残存期間で償却すると、本来の5年償却よりペースが速くなります。差額は償却超過額として損金に算入されず、申告での加算が必要になります。
台帳が膨らまないようにする
原則どおりに処理すると、資産計上した改良の件数だけ固定資産が増えます。年10件なら5年で50件になります。
ここで使えるのが、同じ月に事業供用した改良の原価を合算し、1件の資産として台帳に登録する方法です。「2026年8月リリース分」といった単位でまとめます。
この方法が使えるのは、償却の計算結果が変わらないためです。事業供用月が同じで耐用年数も同じなら、個別に登録しても合算して登録しても、各年度の償却限度額は一致します。台帳の管理単位を変えているだけで、税務上の処理を変えているわけではありません。
注意点は、事業供用月をまたいで合算しないことです。8月リリース分と9月リリース分を四半期でまとめると、償却の開始月が変わってしまいます。まとめる単位は月次にしておきます。
機能を廃止したときの除却
月ごとにまとめて登録すると、その月の資産の中に複数の機能が含まれます。後にその中の一部の機能だけを廃止したとき、どう扱うかという問題が出てきます。
まとめて登録した資産の一部だけを除却するには、その機能に対応する未償却残高を合理的に区分できることが必要です。区分できなければ、除却損の計上は難しくなります。
対応としては、まとめて登録する場合も、内訳として機能ごとの原価をワークシートに残しておくことです。台帳は1件でも、内訳が分かる資料があれば、廃止時に按分の根拠を示せます。
大きな機能や、将来的に廃止する可能性が見えている機能については、最初から単独で登録しておくという判断もあります。
簡便法は存在しない
「半年分だけ減価償却を計上する」「機能ごとに3年で償却する」といった簡便法は認められていません。事業供用月から月割で計算します。
会計上の扱いをどう考えるか
ここまで税務を中心に見てきました。会計上の扱いにも触れておきます。
非上場企業はどこまで求められるか
会計監査を受けていない非上場企業であれば、税務上の処理に合わせて会計処理を行うのが一般的です。税務と会計で別々の帳簿を持つ負担を考えれば、現実的な選択だと思います。
ソフトウェアの会計処理には「研究開発費等に係る会計基準」があり、自社利用ソフトウェアは将来の収益獲得または費用削減が確実であることが資産計上の要件とされています。ただ、この基準が強制適用されるのは会計監査を受ける会社です。
日本公認会計士協会の研究資料によれば、上場しているSaaS企業でも、開発費用を全額費用処理している会社が一定数あります。処理には幅があるのが実態です。
将来の上場を視野に入れているなら
一方、上場を検討しているなら、早い段階から会計基準に沿った処理を整えておく必要があります。監査法人との協議は方針を固めてからではなく、固める過程で始めるほうが円滑です。
その場合、税務処理とは別に、会計上の資産計上の単位や研究開発費との区分を検討することになります。この記事の範囲を超えるため、上場準備に入る段階で専門家に相談することをおすすめします。
記録をどう残すか
処理の根拠を後から説明できるようにしておくことが、実務では大きな意味を持ちます。
タスク管理ツールで足りる
紙の要件定義書を作って合議体で承認し押印する、という統制は、アジャイル開発では現実的ではありません。要件定義から実装まで数日で進むことも珍しくないからです。
Backlog、Notionといったタスク(プロジェクト)管理ツール上で必要な記録を残す方法で十分に対応できます。
| 主な残す記録 | 方法 |
|---|---|
| 改良の内容 | チケットの記述欄に要件と機能詳細を書く |
| 資産計上か費用処理かの判定 | チケットにラベルやカスタム項目で記録 |
| 工数 | 各エンジニアがタスクごとに入力 |
| リリース日 | リリース日を入力 |
| 承認 | リリース時に上長が承認するステップを設ける |
原価をどう集計するか
資産計上する改良については、その原価を集計する必要があります。中心になるのは人件費です。
タスク管理ツールに記録された工数に、担当者の人件費単価を掛けて算出します。PMやリーダーがそのプロジェクトに関わった時間も含めます。一方、社内研修や全社会議、他プロジェクトの応援といった時間は含めません。
集計した原価は、月次でソフトウェア仮勘定に振り替えておき、リリース時に本勘定へ移して償却を始めます。
厳密にすべての時間を区分する必要はありません。税務上も、合理的と認められる方法で継続して計算していれば、その方法が認められます。工数管理ツールの記録に基づく按分で足ります。
社内ルールを文書にする
最後に、決めたことを文書にまとめておきます。難しい書式は要りません。次の項目が書いてあれば十分です。
| 項目 | 内容 |
|---|---|
| 費用処理と資産計上の判定基準 | 性質による区分と金額基準 |
| 台帳への登録単位 | 機能ごとか、月ごとにまとめるか |
| 償却の方法 | 耐用年数5年、定額法 |
| 原価の集計方法 | 工数の記録方法と人件費単価の算定 |
| 判断に迷った場合の相談先 | 顧問税理士 |
この文書があると、担当者が変わったときの引き継ぎが楽になります。税務調査で処理の根拠を聞かれたときにも、その場で考えるのではなく、決めてあることを示せます。
まとめ
機能改良を捌くうえで、最初にやるべきは判定の単位を決めることです。通達が単位としているのは一の計画に基づく修理・改良等なので、一つの目的をもったまとまりで数えます。小さな改善ならチケット1枚、大きな機能追加なら企画全体、という形で自社の開発の進め方に合わせて構いません。ただし、一体で進めている開発を金額基準を下回らせるために分けることはできません。決めた単位は文書にして、毎期同じように運用します。
単位が決まったら、費用処理できる範囲を見極めます。全部を資産にする前提で考えると管理が破綻しますが、実際には修繕費や金額基準で処理できるものが相当あります。
金額基準は3つあり、使える場面が違います。20万円未満か3年以内の周期なら資本的支出が明らかでも修繕費にでき、区分が不明な部分については60万円未満または前期末取得価額の10パーセント以下という基準が使えます。それでも決まらない場合の30パーセント基準は継続適用が条件です。
資産計上するものについては、既存のソフトウェアに加算するのではなく、独立した新たな資産として5年定額法で償却します。
台帳が膨らむ問題は、同じ月に事業供用したものを1件にまとめて登録することで抑えられます。償却の計算結果は変わりません。ただし、後に一部の機能を廃止する可能性を考えて、内訳が分かる資料は残しておきます。
記録はタスク管理ツール上で足ります。紙の統制を作り込む必要はありません。工数の記録と、リリース時の承認、そして判定の根拠が残っていれば、処理の説明はできます。
決めた基準は文書にして、毎期同じように運用します。利益の状況に応じて基準を動かすような運用は、後から説明できなくなります。判断に迷う論点があれば、決算を待たずに顧問税理士に相談しておくと、処理の組み直しを避けられます。
