市場販売目的のソフトウェアの資産計上｜製品マスター完成時点と改良費の扱い

執筆　公認会計士・税理士 鈴木佑也

※本記事は2026年10月7日時点の公表資料に基づきます。

市場販売目的とは：製品マスターを作り複写して売るソフトウェア

市場販売目的のソフトウェアとは、製品マスターと呼ばれる「複写できる完成品」を作り、そのコピーを広く一般の顧客に売ることを目的とするソフトウェアです。パッケージソフトが典型例で、通常このように処理するのは作り手であるベンダーだけです。ソフトウェアの3つの区分の全体像はソフトウェアの定義と3つの区分｜コンテンツとの線引きと会計処理の出発点で整理しています。

よくある進め方を見てみます。まず、売り先と販売見込みを盛り込んだ事業計画と予算について社内の承認を得て、開発プロジェクトを始めます。企画と設計を固め、開発と試作を重ねて製品マスターを仕上げ、そのコピーを製品として出荷・配信していきます。

図1　架空の製品Aの例です。製品マスターの完成（10月）を境に、費用から資産へ切り替わります

ここで大切なのは、製品マスターと製品（複製品）を区別することです。製品マスターそのものは売り物ではなく、機械設備のように「製品を作るための道具」の役割を果たします。だから無形固定資産として計上し、販売に応じて償却していきます。一方、顧客に渡す複製品は棚卸資産で、売れたときに売上原価になります。

図2　製品マスターは機械のように「製品を作る道具」として無形固定資産に、複製品は棚卸資産になります

架空の例で考えます。ソフトウェア会社が販売管理パッケージ「製品A」を開発し、4月に企画の承認を受け、10月に製品マスターが完成、翌年1月に発売したとします。4月から10月の完成までにかかった4,800万円と、完成後に機能の改良にかかった2,100万円では、会計処理がまったく異なります。以下、その理由と判断の方法を順に見ていきます。

この区分に当たるかどうかは、作り手が「複写して多くの顧客に売る」ことを目的にしているかで決まります。同じ会社が作るソフトウェアでも、自社のサービス提供に使うもの（SaaSなど）は自社利用、特定の顧客の注文で作るものは受注制作です。市場販売目的と判断する根拠として、事業計画に想定販売本数や価格、販売開始時期が書かれているかを確認しておくとよいでしょう。

研究開発が終わるのは「最初に製品化された製品マスター」の完成時

この区分では、研究開発の終わりをいつとみるかが資産計上の出発点です。会計基準の考え方では、製品番号を付けるなどして販売する意思をはっきり示した最初の製品マスターが完成した時点で、研究開発が終わったとみなします。

この時点より前の活動は、本当に製品として売れるものができるのか、将来の収益につながるのかがまだ分からない段階です。そのため、完成までにかかった支出は研究開発費とし、その期の費用に落とします。研究開発費の範囲そのものについては研究開発費の範囲と会計処理｜ソフト開発で研究・開発に当たる例と当たらない例で詳しく扱います。

図3　架空の数値です。完成前の4,800万円は研究開発費、完成後の2,100万円を製品マスターの取得原価にします

製品Aの例では、完成前の4,800万円はすべて研究開発費です。完成後の2,100万円は製品マスターの取得原価に入れ、無形固定資産に計上します。完成日が1か月ずれるだけで、資産と費用の金額が数百万円単位で動くこともあります。完成時点の判断と、それを裏付ける資料が重要になるのはこのためです。

なお、「最初に製品化された」という言葉には意味があります。製品としての最終完成版を指すのではなく、販売を前提とした最初のマスターができた時点を指します。最終版を待って資産計上を始めるのでも、試作に入った時点で始めるのでもない点に注意してください。

実務では、開発部門が考える「完成」と、会計上の「完成」がずれることがよくあります。開発部門は発売できる品質になった時点を完成と呼びがちですが、会計上はそれより前の、販売を前提とした最初のマスターができた時点が目印です。経理担当者は、開発計画のどのマイルストーンを会計上の完成とみるかを、開発の初期に開発部門とすり合わせておくと、決算での議論がスムーズになります。

完成の判断基準：プロトタイプか、重要機能と重要な不具合の解消か

では、製品マスターが完成したかどうかは何で判断するのでしょうか。移管指針第8号「研究開発費及びソフトウェアの会計処理に関する実務指針」（旧会計制度委員会報告第12号）と、移管指針第11号「研究開発費及びソフトウェアの会計処理に関するQ&A」は、開発の進め方に応じて2つの目安を示しています。

1つ目は、製品として成り立つかどうかを判断できる程度の試作品（プロトタイプ）ができていることです。試作品を作る方式では、それを使って市場で受け入れられるか、競合製品に対抗できるかを検討し、発売時期や価格を決められるようになります。新しい技術を使う場合は、その技術が製品で実際に使えることも試作品で確かめられます。

2つ目は、試作品を作らない方式の場合で、製品として売るために必要な重要な機能ができあがっており、かつ重要な不具合が解消されていることです。

図4　プロトタイプを作る方式かどうかで、確認する内容が変わります

完成といっても、すべてが仕上がっている必要はありません。たとえば入力画面や帳票のレイアウトに調整の余地がある、操作性をもう少し良くしたい、処理速度をさらに上げたいといった課題が残っていても、直し方の見通しが立っていて、製品として仕上げるうえで決定的な問題ではないと確認できていれば、要件を満たすとみてよいでしょう。

海外で作られた製品を日本語版にして売る場合も同様です。日本語化に技術的な大きな障害がないと確認できていれば、研究開発の段階はもう終わっていると考えてよいでしょう。逆に、日本語の文字処理のために中核部分を作り直す必要があるような場合は、まだ研究開発の途中と考えるべきです。

図5　解決方法が明確で、製品の完成にとって重要でなければ、研究開発は終わったと判断できます

製品マスターを資産にする4つの要件と原価の集め方

研究開発が終わった後にかかる製品マスターの制作費は、きちんとした原価計算で取得原価を求め、無形固定資産に計上します。実務指針は、製品マスターを資産として扱う前提として、次の4つの性質を挙げています。①製品マスター自体は販売の対象ではない、②機械装置のように、これを複写して製品を作る、③著作権などの法的な権利を持っている、④適正な原価計算によって取得原価を明確にできる、の4つです。

図6　4つすべてを満たすことが前提です。特に原価計算の仕組みは事前の準備が必要です

制作途中のものはソフトウェア仮勘定、完成したものはソフトウェアといった勘定で、いずれも無形固定資産に計上します。貸借対照表では、制作途中の分に重要性がある場合を除き、両者をまとめて「ソフトウェア」などの科目で表示するのが一般的です。

原価計算の流れとしては、製品マスターの制作費をいったん製造原価に含め、制作途中分と完成品を当期製造費用から無形固定資産に振り替えます。製品マスターの償却費は、その期に売れた数量に見合う額を、製造原価を通さず売上原価に直接入れるのが望ましい処理です。償却の具体的な計算方法は市場販売目的ソフトウェアの減価償却｜見込販売数量と3年均等額の比較計算で解説します。

図7　償却費は製造原価を通さず、売上原価に直接入れる方法が望ましいとされています

製造原価の勘定を使っていない会社では注意が必要です。開発の専業ではない会社や規模の小さい会社では、開発メンバーの人件費が会計システム上いったん売上原価や販管費に入っていることがよくあります。こうした会社では、製造原価として集計していないからといって資産計上を省略してよいわけではありません。その場合は、人件費だけでなく、開発用機器の償却費や諸経費も含めて、対象となる費用を漏れなくソフトウェア仮勘定に集め直す必要があります。

特に、開発メンバーが他の業務と兼務している場合は、作業時間の比率などで費用を配賦します。たとえばエンジニア3名の人件費が月210万円で、作業報告上、製品Aの制作に70％、既存製品の保守や社内業務に30％の時間を使っていたなら、147万円をソフトウェア仮勘定に、63万円を販管費などに振り分けます。配賦のルールは社内基準として文書にし、配賦割合の根拠となる資料を毎月残しておきます。

図8　架空の数値です。作業時間の比率で配賦し、比率の根拠となる作業報告を保存します

図9　いったん販管費などに入った費用を、漏れなく拾ってソフトウェア仮勘定に振り替えます

完成後の支出の4分類：著しい改良・機能維持・通常の改良・製品の原価

製品マスターが完成した後も、改良や修正の支出は続きます。これらは性質によって次の4つに分けて処理します。

分類	内容の例	会計処理
著しい改良	新しいマスターを作るのと同じくらいの大幅な改良	研究開発費
機能維持	不具合の修正、ウイルス対策などの保守	発生時の費用
通常の改良・強化	操作性の向上、機能の追加（著しいものを除く）	製品マスターの取得原価
製品の原価	保存媒体、複写作業、マニュアルの外注、包装、担当者の人件費	製品の製造原価

図10　上から順に当てはめると、迷いにくくなります

製品マスターの機能を改良・強化する活動の費用は、基本的に資産として扱います。もっとも、その改良が「著しい改良」に当たる場合は、改良が終わるまでは研究開発が終わっていないと考え、研究開発費として処理します。著しい改良とは、研究や開発の要素を含む大幅な改良で、完成までに相当の技術的困難を伴うものをいいます。実務指針は例として、主要なプログラムの過半を作り直す場合や、動作環境（OS、開発言語、プラットフォームなど）を変えたり増やしたりするために大がかりな手直しが要る場合を挙げています。

製品Aの完成後1年間に、新しいOSに対応するための大幅な作り直しに900万円、不具合修正に120万円、操作性改良に350万円、保存媒体と説明書の制作に80万円、合計1,450万円を支出したとします。新OS対応が著しい改良に当たるなら900万円は研究開発費、不具合修正の120万円は発生時の費用、操作性改良の350万円は製品マスターの取得原価、媒体・説明書の80万円は製品の製造原価です。

4分類のうち判断が分かれやすいのは、「機能維持」と「通常の改良」の境目です。不具合の修正と同時に小さな機能改善を行うことはよくあります。その場合は、作業の目的と工数の内訳を見て、主に不具合を直すための作業なのか、価値を高めるための作業なのかを区別します。区別できないまま全額を資産に入れると、費用にすべき保守費が資産に紛れ込み、後の償却で利益を先送りすることになるため注意が必要です。

図11　架空の数値です。資産になるのは操作性改良の350万円だけで、残りは費用または製造原価です

図12　技術的に相当の困難を伴う大幅な改良かどうかで判断します

バージョンアップは大幅か小幅かで分ける

市場販売目的のソフトウェアでは、定期的なバージョンアップが欠かせません。Q&Aは、バージョンアップを大きく2種類に分けて考えています。製品の大部分を作り直すような大幅なバージョンアップは、設計をゼロからやり直すのと同じで、著しい改良に当たるため研究開発費になります。一方、既存の製品に機能を加えたり使い勝手を良くしたりする小幅なバージョンアップは、基本的な設計を大きく変えずに価値を高めるものなので、ソフトウェアとして資産に計上します。

図13　基本設計から作り直すかどうかが分かれ目です

製品Aで考えると、機能を追加したVer.1.5は資産計上、不具合だけを直したVer.1.6は機能維持として費用、エンジンから全面的に作り直したVer.2.0は研究開発費というように、版ごとに中身を見て判断します。なお、大幅なバージョンアップでも、新しい製品マスターが完成した後に発生する制作費は、改めて資産計上の対象になります。

実務で迷いやすいのは、製品名や版番号の付け方と中身が一致しないケースです。営業上の理由で「2.0」と名付けても中身が機能追加なら小幅なバージョンアップですし、「1.8」でも中核部分を作り直していれば大幅なバージョンアップです。版番号ではなく、どの程度の設計変更があったかで判断してください。判断のために、リリースごとに変更したプログラムの範囲（全体の何割程度か）、変更の目的、基本設計の変更の有無を開発部門に記録してもらうと、経理での判定が格段に楽になります。アジャイル開発のように小刻みにリリースする場合の線引きはアジャイル開発のソフトウェア資産計上｜開始時点とバージョンアップの線引きで扱います。

図14　版ごとに中身を確認して処理を決め、判断理由を記録しておきます

証拠を残す：工程完了資料と配賦の社内基準

ここまで見てきたように、市場販売目的のソフトウェアの処理は、完成時点と支出の性質の判断に大きく左右されます。そのため、判断を裏付ける資料を開発の流れの中で作っておくことが欠かせません。

まず、資産化の始まりを明確にするため、要件定義に沿って開発工程をはっきり区切り、各工程が終わったことが分かる資料を作って保管します。企画段階の稟議書や事業計画、設計レビューの記録、テスト結果と不具合の一覧、製品番号を付与した記録などがこれに当たります。

図15　開発工程の区切りごとに、完了したことが分かる資料を作って保管します

資料	作るタイミング	経理での使い道
プロジェクト稟議書	開発の開始前	販売目的と予算の確認
工程完了報告	各工程の終了時	完成時点の特定
作業報告（工数）	毎日〜毎週	原価の集計と配賦
配賦の社内基準	期首（変更時）	兼務者の按分の根拠
リリース記録	版ごと	改良費の4分類の判定

次に、原価の集め方です。プロジェクトコードごとに集計すべき製造原価が分かること、資産計上を始めた時点がはっきりしていること、販売計画が合理的であることの3点を、プロジェクトの管理資料で説明できるようにしておきます。兼務者の配賦ルールも、社内基準として文書にしておく必要があります。

期末の処理にも注意点があります。製品マスターから複写した製品のうち、期末時点でまだ売れていないものや複写作業の途中のものは、棚卸資産の仕掛品などとして計上し、販売した時点で売上原価にします。このとき、製品マスターの償却費は、配分すべき原価がまだ確定しないため、仕掛品の原価には含めません。

図16　架空の数値です。複製品の原価に製品マスターの償却費は含めません

海外の基準では、開発費の資産計上を要件ベースで判断します。日本基準との違いは開発費の資産計上｜IAS38無形資産の6要件と日本基準との違いで整理しています。また、税務上のソフトウェアの取得価額や改良費の扱いはソフトウェアの税務｜取得価額・研究開発費・修繕費・償却・開発受託で解説します。

最後に、決算の前には、完成日と根拠資料、原価の漏れと配賦、完成後の支出の分類、期末の複製品の扱いの4点を順に確認します。監査では、完成日の判断が資料で説明できるか、完成前の費用が資産に紛れ込んでいないか、兼務者の配賦率が実態と合っているかが特に確認されやすい点です。

図17　完成時点・原価の網羅性・改良の分類の順に確認します

よくある質問

最初の一歩は、進行中の製品ごとに「完成日」とその証拠を決めることです

いま開発している製品ごとに、製品マスターの完成をどの資料で示すか（試作品の評価記録か、テスト結果か、製品番号の付与か）を決め、開発部門と共有してください。完成日と証拠が決まれば、その前後で費用と資産を分ける集計のルールも自然に決まります。

まとめ

市場販売目的のソフトウェアは、販売の意思を示した最初の製品マスターが完成するまでの費用を研究開発費とし、それ以降の制作費を無形固定資産に計上します。完成の目安は、製品性を判断できる試作品の完成、または重要な機能の完成と重要な不具合の解消です。製品マスターは4つの要件を満たすものとして適正な原価計算で取得原価を集め、兼務者の費用は社内基準で配賦します。完成後の支出は著しい改良・機能維持・通常の改良・製品の原価の4つに分け、バージョンアップは大幅なら研究開発費、小幅なら資産です。いずれの判断も、工程ごとの完了資料と配賦の記録が支えになります。

本記事の根拠

• 研究開発費等に係る会計基準（企業会計審議会）
• 移管指針一覧（企業会計基準委員会）
• 移管指針第8号「研究開発費及びソフトウェアの会計処理に関する実務指針」
• 移管指針第11号「研究開発費及びソフトウェアの会計処理に関するQ&A」

免責：本記事は一般的な情報提供を目的とし、個別案件に対する法務、会計、税務その他の専門的助言を構成するものではありません。実際の対応は、最新の法令・取引所規則・公表資料を確認し、必要に応じて専門家へご相談ください。