ソフトウェア業界の収益認識と受注制作の範囲｜請負・準委任・派遣の違い

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

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

ソフトウェア取引に特有の慣行：契約前着手と契約書の不十分さ

ソフトウェア開発の取引には、他の業種ではあまり見られない慣行があります。代表的なのは、顧客の予算手続が終わる前に「先に作業を始めておいてほしい」と頼まれ、正式な契約書がないまま開発に入るケースです。もう1つは、作りながら仕様が固まっていくため、起こりうる変更をすべて契約書に書き込むことができず、書面だけでは合意の全体がつかめないケースです。

こうした慣行の背景には、ソフトウェアが目に見えない成果物であり、しかも開発の途中で要求が変わりやすいという性質があります。外部の人が完成度を確かめにくく、発注者と受注者の間でしか状況が分からないことも多いため、取引の実在性や進み具合を第三者が確認しにくいという問題も生まれます。さらに、技術の変化に合わせて取引の内容が複雑になり、機器・ライセンス・開発・保守を1つの契約で引き受けたり、協力会社に何層にも再委託したりする形が広がっています。

図1　無形で仕様が変わりやすいという性質から慣行が生まれ、それぞれが収益認識の論点につながる

会計の側から見ると、これらの慣行はそれぞれ別の論点につながります。契約前の着手は「いつ契約が成立したのか」、書き切れない合意は「契約の範囲や変更をどう把握するか」、1つの契約に複数の要素がある取引や多段階の下請は「履行義務をどう分けるか」「自社は本人か代理人か」という問題です。収益認識の基本は、顧客に約束した財やサービスが移転する様子を、受け取る見込みの対価で描くことにあります。自社の都合ではなく、顧客から見て何を約束しているかを考える姿勢が求められます。

架空のN社の案件で流れを見てみます。4月に顧客から口頭で内示を受けて作業を始め、6月に画面の追加を頼まれ、7月にようやく正式契約を結び、12月に検収を受けました。この間、経理担当者は各時点で確かめるべきことがあります。

図2　正式契約より前に原価が発生し、途中で範囲が変わることもある。各時点で会計上の確認事項がある

4月から6月の原価をどこに集計するか、追加した画面の対価がいくらになるのか、正式契約がどこまでをカバーしているのかを、後からではなくその都度確かめておくことが、正しい収益認識の前提になります。仕様の追加や契約変更の会計処理はシステム開発のフェーズ別契約と仕様追加｜契約の結合・変更と保証の会計処理で詳しく扱います。

契約書単位から「契約」単位へ：口頭や内示も契約になりうる

収益認識の会計基準（企業会計基準第29号「収益認識に関する会計基準」）でいう「契約」は、紙の契約書のことではありません。法的な強制力のある権利と義務を生じさせる、当事者間の取決めを指します（第5項）。契約は書面だけでなく、口頭や取引慣行によっても成立しうるとされています（第20項）。

このため、基本契約書・個別契約書・覚書といった複数の書類が合わさって1つの契約になることもあれば、書類のない口頭の合意が契約になることもあります。これまで契約書ごとに売上を管理していた会社では、「契約書の単位」と「会計上の契約の単位」が一致しない場面が出てくる点に注意が必要です。

図3　複数の書類や口頭の合意が、まとめて1つの契約になることがある

会計上の契約として扱うには、5つの要件をすべて満たす必要があります（第19項）。当事者が契約を承認して義務を果たすことを約束していること、移転する財やサービスに関する各当事者の権利を識別できること、支払条件を識別できること、契約に経済的実質があること、対価を回収できる可能性が高いことです。内示だけで着手している案件は、特に2つ目と3つ目、つまり作業範囲と対価・支払条件がはっきりしているかが問題になります。

図4　内示書や口頭の合意でも、5つの要件を満たせば収益認識上の契約になる

たとえば、内示書に「画面設計と帳票設計を7月末までに実施、月額単価×人月で精算」と書かれ、顧客の部長名で発行されていれば、正式契約前でも契約の要件を満たす可能性があります。一方、営業担当者が電話で「来月から始めてほしい」と言われただけで、範囲も金額も決まっていなければ、まだ契約とはいえません。その段階で発生した原価は案件別に記録し、契約が成立するまでは収益を計上しない扱いになります。

図5　権利義務の強制力、5つの要件、相手の権限者の指示の3点を順に確かめる

口頭の合意を契約として扱う場合は、なぜ正式な契約書を交わせないのか、範囲・スケジュール・対価・支払条件がどう決まっているのか、指示が相手側の正当な権限を持つ人から出ているのか、の3点を書面で残しておくことが欠かせません。これは後ほど内部統制の章で具体的な手順として説明します。

複合取引と本人・代理人：システムインテグレーターの論点

システムインテグレーター（SIer）は、複数のメーカーの機器やソフトウェアを組み合わせ、顧客のシステムを一括して構築します。導入後の保守やトレーニング、プロジェクト管理の支援まで同じ契約に含めることも多く、1つの契約に性質の違う財とサービスが入る「複合取引」になりがちです。

収益認識では、収益を計上する単位は契約書ではなく履行義務です。架空の例として、総額50,000千円の一括契約に、サーバー機器20,000千円、ライセンス8,000千円、受注制作の開発15,000千円、1年間の保守7,000千円が含まれているとします。それぞれが別個の履行義務であれば、取引価格を配分したうえで、機器は引渡し時、開発は進捗に応じて、保守は12か月にわたって、というように別々のタイミングで収益を計上します。

図6　1つの契約に性質の違う要素が入る。要素ごとに認識の時点が変わりうる

複合取引でもう1つ重要なのが、本人か代理人かの判定です。顧客に財やサービスを提供する過程に他の会社が関わる場合、自社が自ら提供するなら本人として対価の総額を、他社が提供するよう手配するだけなら代理人として手数料などの純額を収益にします（企業会計基準適用指針第30号「収益認識に関する会計基準の適用指針」第39項・第40項）。

判定は、まず顧客に提供する特定の財・サービスを識別し、次にそれを顧客に渡す前に自社が支配しているかを判断する、という2段階で行います（同第42項）。履行義務の単位ではなく、特定の財・サービスごとに判定する点に注意してください。支配しているかどうかの判断材料としては、契約を履行する主たる責任、在庫リスク、価格を決める裁量の3つが例示されています（同第47項）。これらに重み付けはなく、契約の内容に照らして総合的に判断します。

図7　判定は契約全体ではなく、顧客に渡す特定の財・サービスごとに行う

判定の結果は、利益の額には影響しなくても、売上高の大きさを大きく変えます。先ほどの例で、サーバー機器を18,000千円で仕入れて20,000千円で納品していたとします。本人なら売上高20,000千円・売上原価18,000千円ですが、代理人なら売上高は差額の2,000千円だけになります。売上高を経営指標にしている会社ほど、判定の影響は無視できません。

図8　機器の販売価格20,000千円・仕入18,000千円の場合、利益は同じでも売上高が10分の1になる

ソフトウェア関連の取引で、代理人と判断される可能性が高いのは次のような場面です。

取引の場面	代理人と判断されやすい理由
機器やパッケージにわずかな設定作業だけ加えて転売する	自社の付加価値が小さく、実質は仕入れて流しているだけ
受注した開発のプロジェクト管理を協力会社にすべて任せる	履行の主たる責任を自社が負っていない
仕様や販売価格の決定にまったく関与していない	価格を決める裁量がない
在庫を持たず、顧客の注文を受けてから直送させる	在庫リスクを負っていない

本人・代理人の考え方の全体像は収益認識の本人と代理人｜総額か純額かを決める3つの指標で解説しています。

受注制作のソフトウェアの範囲：契約形態ではなく成果物で判断

受注制作のソフトウェアとは、契約の形式にかかわらず、特定の顧客向けに制作して提供するソフトウェアのことです（収益認識に関する会計基準第14項）。もともとは「研究開発費等に係る会計基準」で、市場販売目的・自社利用と並ぶ3つの区分の1つとして定められ、請負工事に準じて処理するものとされていました。収益認識の会計基準の導入により、工事契約の会計基準やソフトウェア取引の実務対応報告は廃止されましたが、受注制作のソフトウェアの範囲は従来の考え方を引き継いでいます。

従来から、契約が請負か委任かSES契約かといった形態は問いませんでした。顧客の注文に応じて、あらかじめ仕様が決まっていないプログラムを作るなど、ソフトウェアとしての機能を持つ成果物を給付する取引であれば、受注制作に含まれます。逆に、成果物のはっきりしない保守契約のようにサービスの提供そのものが目的の契約や、開発の現場に人を出して作業してもらうこと自体が目的の契約は含まれません。

図9　契約の名前ではなく、特定の顧客向けの成果物を渡す約束かどうかで判断する

受注制作に当たるかどうかは、その後の会計処理の入口になります。受注制作であれば、一定の期間にわたって進捗度に応じて収益を認識するか、工事損失引当金の対象になるか、期間がごく短い場合の代替的な取扱いを使えるか、といった検討に進みます。これらは受注制作ソフトウェアの進捗度と収益認識｜インプット法・原価回収基準・損失引当で解説します。標準化された製品を不特定多数に売る場合は、パッケージソフト販売の収益認識｜出荷・ダウンロード・返品・委託販売・サポートの考え方になります。

図10　同じ準委任でも、成果物を渡すかどうかで結論が変わる。最終的には実態で判断する

目安として、請負の開発委託と成果完成型の準委任は、受注制作に当たる可能性が高いといえます。ただし、取引先との力関係などにより、契約書には表れない約束が実際には存在することもあります。書面の文言だけでなく、検収の有無、完成責任の実態、作業指示の出し方まで確かめたうえで判断してください。

請負・準委任（履行割合型・成果完成型）・派遣の違い

ソフトウェア開発でよく使われる契約形態は、請負、準委任（SES契約と呼ばれることもあります）、派遣の3つです。法律上の性格の違いが、会計上の判断にも影響します。

図11　義務の中身、成果物への責任、誰が指示するかの3点が大きな違い

請負は、仕事を完成させることを約束し、完成した結果に対して報酬を受け取る契約です（民法第632条）。完成させる義務があるため、納品物が契約の内容に合わない場合は契約不適合責任を負います。準委任は、法律行為ではない事務を任される契約で（民法第656条）、受託者は注意を尽くして作業する義務（善管注意義務）を負うものの、請負のような契約不適合責任は負いません。派遣は、労働者派遣法に基づき、受託者が人を送り出し、派遣先の指揮命令の下で働いてもらう契約です。作業を提供する点は準委任に似ていますが、指示を出すのが発注者側である点が決定的に違います。

準委任には2つの型があります。作業した時間や割合に応じて報酬が生じる「履行割合型」（民法第648条）と、作業の成果に対して報酬が生じる「成果完成型」（民法第648条の2）です。成果完成型は、契約不適合責任こそ問われませんが、成果物が合意した水準に届かなければ債務不履行として損害賠償を求められる可能性があり、実質的には成果物に責任を負う契約といえます。

図12　成果完成型は成果物と引換えに報酬を受けるため、請負に近い性格をもつ

請負の契約不適合責任は、2020年4月施行の改正民法で、従来の瑕疵担保責任から整理されたものです。顧客は、修補などの追完、代金の減額、損害賠償、契約の解除という4つの権利を持ちます。会計上は、検収後の手直しに備える引当金や、代金減額の可能性を変動対価として見積るかどうかの検討につながります。

図13　2020年4月施行の改正民法で、旧来の瑕疵担保責任から整理された

実務では、システム開発の工程ごとに契約を分ける例が多く見られます。要件定義は成果完成型の準委任、設計から製造・テストまでは請負、稼働後の保守は履行割合型の準委任、という組み合わせが典型です。さらに、1次請けが2次請けに、2次請けが3次請けにと再委託が重なる多重下請の構造では、誰がどこまで責任を負うのかがあいまいになりがちです。契約ごとに自社がどこまで責任を負うのかをはっきりさせておくことが、会計判断の前提にもなります。

図14　工程ごとに契約形態が変わり、下請が重なるほど責任の範囲があいまいになりやすい

なお、履行割合型の準委任や派遣は、受注制作の範囲に入るかどうかを特に慎重に見る必要があります。作業時間に応じた報酬であれば、役務の提供として、作業した期間に応じて収益を計上するのが通常です。

口頭契約と契約書と実態のずれへの内部統制

ここまで見てきたように、ソフトウェア取引では書面と合意内容がずれやすく、それがそのまま収益認識の誤りにつながります。売上の前倒しや架空の受注を防ぐ観点からも、契約の識別に関する内部統制は重要です。

まず、内示で着手する案件です。着手前に、正式な契約を結べない理由が合理的であること、作業範囲・スケジュール・対価・支払条件が明確であること、指示が相手の正当な権限者から出ていることを書面で確かめ、社内の承認を受ける流れを作ります。着手後は原価を案件別に集計し、正式契約を結んだ時点で内示との差異を確認します。

図15　着手前に、理由・条件・権限者の3点を書面で残し、承認を受ける

失注や仕様変更が起きたときに、どちらが費用を負担するかを決めておかないと、損失処理の判断も遅れます。次の表は、典型的な場面と経理の対応の整理例です。

場面	費用負担の取決め	経理の対応
正式契約に至らず失注	内示書に精算条項あり	精算額を請求し、回収可能性を検討
正式契約に至らず失注	取決めなし	集計した原価を費用に振り替える
仕様変更で作業が無駄になった	顧客負担で合意	契約変更として対価を見積る
仕様変更で作業が無駄になった	自社負担	総原価の見積りを見直し、赤字なら引当金を検討

次に、契約書の形式と実態のずれです。法的には準委任として結んでいても、完成責任や検収があり請負に近い取引になっている場合や、請負なのに作業報告書だけを納めていて具体的な成果物がない場合があります。履行義務を正しく識別するには、契約を識別する段階で実態に目を向ける必要があります。

図16　契約書の名称だけで処理を決めず、成果物・責任・指示系統の実態を確かめる

実務では、営業部門が結んだ契約を経理部門がレビューする手順を決め、毎回同じ順番で確かめると判断がぶれにくくなります。書類がそろわない案件は着手前に経理へ回す運用にしておくと、決算期になって慌てることがありません。開発プロジェクト全体の不正リスクと統制についてはソフトウェア開発の不正リスクと内部統制｜工数付替え・外注費・資産計上で取り上げています。

図17　営業から回ってきた契約を、毎回同じ順番で確かめると判断がぶれにくい

よくある質問

最初の一歩は、進行中の案件の契約書類の棚卸しです

進行中の案件ごとに、契約書・覚書・内示書・発注メールを集め、契約形態、成果物の有無、含まれる要素（機器・ライセンス・開発・保守）を一覧にしてください。書類がない案件や、形式と実態が違いそうな案件が浮かび上がれば、優先して確かめるべき対象が分かります。

まとめ

ソフトウェア取引の収益認識は、契約書の単位ではなく、強制力のある合意としての「契約」を識別するところから始まります。口頭や内示でも要件を満たせば契約になり、1つの契約に複数の履行義務が含まれることもあります。機器や協力会社が関わる取引では本人・代理人の判定が売上高を大きく左右します。受注制作のソフトウェアに当たるかは、請負・準委任・派遣という形式ではなく、特定の顧客向けの成果物を約束しているかで判断します。契約形態ごとの法的な違いを踏まえつつ、書面と実態のずれを拾う内部統制を整えておくことが重要です。収益認識の5つのステップ全体は収益認識基準 完全ガイド｜5つのステップと実務対応の全体像もあわせてご覧ください。

本記事の根拠

• 企業会計基準委員会 企業会計基準第29号「収益認識に関する会計基準」
• 企業会計基準委員会 企業会計基準適用指針第30号「収益認識に関する会計基準の適用指針」
• 民法（e-Gov法令検索）
• 労働者派遣事業の適正な運営の確保及び派遣労働者の保護等に関する法律（e-Gov法令検索）
• 企業会計審議会「研究開発費等に係る会計基準」

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