IFRS 15 収益認識フローチャート: テクノロジー業界版 | ciferi

IFRS 15は、上場企業が連結財務諸表で適用する基準だ。日本基準(企業会計基準第29号「収益認識に関する会計基準」)も、基本的にはIFRS 15と同一の原則に基づいている。ただし、実装の詳細や判断基準の運用では、両基準に微妙な相違がある。特に以下の領域では注意が必要。...

使い方

  • 契約の特性を入力する: 顧客との契約がSaaS型か、買い切りライセンスか、複数要素のバンドルか。
  • 5段階モデルに沿ったステップを辿る: 各ステップで判断が必要な箇所に、ガイダンスと計算例を提示した。
  • 収益認識タイミングを決定する: 一時点認識か、期間にわたる認識か。控除すべき変動対価があるか。
  • 監査調書用に記録する: フローチャートの判断経路をエクスポートし、そのまま監査ファイルに組み込める。

国際基準と日本の実務

IFRS 15は、上場企業が連結財務諸表で適用する基準だ。日本基準(企業会計基準第29号「収益認識に関する会計基準」)も、基本的にはIFRS 15と同一の原則に基づいている。ただし、実装の詳細や判断基準の運用では、両基準に微妙な相違がある。特に以下の領域では注意が必要。
パフォーマンス・オブリゲーション(履行義務)の識別
テクノロジー企業のSaaS契約には、ソフトウェア利用権、技術サポート、アップデート提供、カスタマイズが含まれることが多い。これらが独立した履行義務か、統合された単一の義務かを判定する際、金融庁の検査で指摘されるケースが相次いでいる。監基報では、顧客が独立した価値を享受できるか、そして当該要素が契約内で区分可能か、という2つの基準を厳密に適用する必要がある。
変動対価の制約
初期導入時にコミッション払いする案件、あるいは年間利用量に基づくボーナス支払いを伴う契約では、認識する収益を必ず制約する。見積もり額が実現する見込みが高くても、その見込みが当初の見積では過度に楽観的だと判断されれば、金融庁のモニタリングで不正指摘を受けることがある。
返金可能性とリターン権
テクノロジー企業の営業実務では、「最初の30日間は返金可能」という契約条件が一般的だ。この場合の収益認識額は、返金リスクを控除した額を上限とする。返金可能性の見積もりが不十分だと、監査人からのチャレンジを受ける。

テクノロジー業界特有の認識パターン

1. SaaS型サブスクリプション


顧客が毎月ソフトウェアへのアクセス権を得る。パフォーマンス・オブリゲーションは「毎月のアクセス権提供」。このため、収益は毎月認識される。
計算例:
株式会社テックソリューション東京は、クラウド顧客管理システムの年間サブスクリプションをA法人に販売した。契約金額は年額240万円(月額20万円×12ヶ月)。導入時に全額前払い。

2. ライセンス+サポートのバンドル


ソフトウェア買い切りライセンス(一時点認識)と、3年間の保守サービス(期間にわたる認識)がセットで販売される。
計算例:
大阪のIT開発会社・株式会社データウェア大阪は、設計支援ソフトのライセンスと3年間の技術サポートをB製造業に売却。契約金額は合計900万円。内訳の独立売価は、ライセンス500万円、サポート400万円。

3. カスタマイズと保守の関連性


顧客向けにカスタマイズしたソフトウェアを納入し、その後、定期的な保守を提供する場合。カスタマイズは一時点認識、保守は期間認識が基本だが、カスタマイズと保守が不可分な場合は単一の長期パフォーマンス・オブリゲーションとなることもある。
金融庁の検査では、この判定が不正確である指摘が多い。「カスタマイズ版は、保守がなければ価値がない」という論理で、両者を統合されるケースが散見される。実際には、カスタマイズ後の成果物が独立して価値を持つか否かで判定する。

  • パフォーマンス・オブリゲーション: 月次アクセス権(12個の別々の義務)
  • 認識タイミング: 毎月20万円を認識
  • 会計処理: 前払い時に前受金240万円。毎月末に20万円を収益に振替
  • イタリック体の補足:監査人は、システムアクセスログと月次請求書を照合し、義務の充足を確認する
  • パフォーマンス・オブリゲーション: 2つ(ライセンス、サポート)
  • 取引価格配分: 比例配分:ライセンス = 900万円 × (500万円 ÷ 900万円) = 500万円、サポート = 400万円
  • 認識タイミング: ライセンスは引渡時に一時点で500万円認識。サポートは36ヶ月で月次約11.1万円ずつ認識
  • イタリック体の補足:取引価格配分の根拠(各要素の独立売価)は、契約の別紙に記載し、監査調書に含める

フローチャート:5段階モデル

テクノロジー企業の契約に特化した判断フロー。各ステップで、一般的な誤りと対処法を示した。

ステップ1:契約の識別


まず契約が存在するか。以下の5要件を全て満たす必要がある。

ステップ2:パフォーマンス・オブリゲーション(履行義務)の識別


契約内の各約束(商品・サービス)が独立した義務か、それとも統合されるか。テクノロジー業界では、ここが最も判定が難しい。
明確に独立している例:
統合される可能性が高い例:
判定基準は、IFRS 15.27〜29に示された3要件。
計算例:
神戸のシステム開発会社・株式会社ウェブテック神戸は、C不動産会社向けに賃貸管理システムを開発・導入する。契約内容は以下。
パフォーマンス・オブリゲーションの判定:
取引価格配分: 各義務の独立売価に基づき比例配分。開発・納入物の独立売価が1,200万円、初期サポートが300万円、技術サポート(年200万円×3年)が600万円の場合。
1,200万円 ÷ 2,100万円 = 57.1% → 開発・納入は2,100万円 × 57.1% = 1,200万円
300万円 ÷ 2,100万円 = 14.3% → 初期サポートは2,100万円 × 14.3% = 300万円
600万円 ÷ 2,100万円 = 28.6% → 技術サポートは2,100万円 × 28.6% = 600万円
会計処理:
イタリック体の補足:監査人は、取引価格配分の根拠として、各要素の独立売価を示す証拠(過去の単独販売価格、市場価格、コスト・プラス・マージン計算)を監査調書に求める。特に技術サポートの価格は妥当性が問われやすい。

ステップ3:取引価格(対価)の決定


顧客に請求できる対価の額。以下の要素を調整する。
変動対価:
テクノロジー企業の契約では、以下のような変動要素が一般的。
変動対価をいくら認識するか。2つの方法がある。
計算例
SaaS企業・株式会社テック上海は、100社の顧客に月額基本料金を請求している。基本料金は月5万円。これに加えて、各顧客は月間API呼び出し回数が10万回を超えた場合、超過分1,000呼び出しあたり2,500円を請求される。
過去3年間の利用データから、以下の分布が観測されている:
変動対価の見積(期待値法):
期待値 = 30% × 0円 + 50% × 5,000円 + 20% × 12,500円 = 0円 + 2,500円 + 2,500円 = 5,000円
月次の認識対価: 月額基本料金5万円 + 変動対価5,000円 = 5万5,000円(見積額)
ただし、実際の利用が見積を下回る可能性も考慮する(制約の原則)。例えば、新規顧客では見積が過度に楽観的かもしれない。その場合、より保守的な対価を認識。
イタリック体の補足:監査人は、過去の実績データを用い、変動対価の見積が妥当か検証する。特に新規顧客カテゴリーでは、サンプル検証やシステムの利用量レポート出力確認が必要。
重大な融資成分:
顧客が先払いする場合、その支払と実際の商品・サービス提供の間に時間差があれば、融資成分を考慮することもある。ただし、1年以内の時間差なら、実務上は融資成分を無視してもよい。
顧客への支払(対価の減額):
契約の一部として、企業が顧客に金銭を支払う場合(顧客への割引、インセンティブ)。これは取引価格から控除する。例えば、新規顧客に初月無料というプロモーション。これは対価の一部であり、売上全体を減額する。

ステップ4:取引価格をパフォーマンス・オブリゲーションに配分


複数の独立した履行義務がある場合、取引価格をそれぞれに按分する。
方法は、各義務の独立売価(スタンドアロン売価)に基づく比例配分。
独立売価の根拠:
計算例再掲(ステップ2と同じ神戸のシステム開発会社):
開発1,200万円、初期サポート300万円、3年技術サポート600万円。合計2,100万円。
各義務の配分:

ステップ5:義務の充足時期の判定と収益認識


各パフォーマンス・オブリゲーションが、一時点で充足されるか、期間にわたって充足されるか。
一時点認識の判定基準(IFRS 15.35):
テクノロジー企業では、ソフトウェア・ライセンス付与が典型的な一時点認識。顧客に対して、特定の時点で利用権が移転する。ただし、ライセンスの性質(利用権か所有権か)で判定が分かれる。
期間にわたる認識の判定基準(IFRS 15.35):
以下のいずれかを満たす場合。
計算例:
福岡の人事管理システム企業・株式会社HRテック福岡は、D上場企業と3年間のSaaS利用契約を締結。年額300万円(月額25万円)。契約期間は2025年4月〜2028年3月。
判定:
仕訳例:
2025年4月1日(契約開始):
売上計上ではなく、契約資産(またはキャッシュ受領)として処理。
毎月末(4月末、5月末...):
売上高:25万円
イタリック体の補足:監査人は、月次の売上計上が実際のサービス提供(システムの稼働状況、アクセス権の有効性)と一致しているか、ログやダッシュボード出力で確認する。
  • 契約承認と履行意思: 署名済みの契約書、購入発注書、あるいは継続的な取引慣行による黙示的承認。テクノロジー業界では、メールによる合意、Slackでの了承も「承認」と判定される場合がある。ただし、後日に異議が出た場合に防御可能か、という視点から判断する。
  • 各当事者の権利義務の識別: 企業が提供するアクセス権、ライセンス、データの範囲。顧客の支払い義務。特にSaaS契約では、「利用可能なストレージ容量」「同時ユーザー数」「月間API呼び出し回数」といった制限条件が権利を定義するため、契約書に明記する必要がある。
  • 対価条件の識別: 固定額か変動額か。マイルストン支払いか。変動対価がある場合、その見積方法(期待値法か最頻値法か)も含む。テクノロジー企業では「利用量に基づく追加費用」が一般的だが、この見積精度は監査上のリスク項目。
  • 商業的実質: 企業のキャッシュフロー(額、タイミング、リスク)が契約により変わるか。ほぼ全ての営利的な取引は該当する。
  • 対価の回収可能性: 顧客の信用状況。特に新規顧客やスタートアップ企業との契約では、回収見込みを厳密に評価する。返金条項がある場合、その発生確率も考慮。
  • SaaS の月次アクセス権(毎月が別々の義務)
  • ライセンスと保守サービス(異なる商品カテゴリー)
  • カスタマイズ開発と、その後の保守(不可分)
  • 初期導入サービスと、ソフトウェアのアップデート権(統合的価値)
  • 顧客が独立した価値を享受できるか: 当該商品・サービスが、顧客によって単独で、または入手可能な他のリソースと組み合わせて、経済的便益をもたらすか。ソフトウェア保守が、そのソフトウェア本体がなければ無価値ならば、独立していない。
  • 契約内で区分可能か: 企業が提供する商品・サービスを、顧客の視点から判別できるか。企業が複数の場所で同一商品を単独販売していれば、区分可能性の証拠となる。
  • 統合の度合い: 企業が提供する他の商品・サービス、および顧客が既に取得した資産との関連性。例えば、カスタマイズが基盤ソフトを大幅に改変し、そのカスタマイズなしに基盤ソフトの価値が大きく減少する場合は、統合される。
  • 要件定義・設計・開発:1,200万円
  • 初期導入サポート(3ヶ月):300万円
  • その後3年間の技術サポート:600万円
  • 合計:2,100万円
  • 開発成果物(カスタマイズ済みシステム): 独立したPO。顧客はこれを取得した時点で価値を享受できる。納入時に一時点認識。
  • 初期導入サポート: 開発成果物の引渡後、顧客がシステムを実運用する準備を支援。これ単独では対価を払わない可能性が高い(開発に統合されている)。ただし、実務では初期サポートを分離する場合もある。ここでは、顧客が「システム納入後のサポート」に明確に対価を設定しているため、独立した義務と判定。
  • 3年間の技術サポート: 明確に独立。期間にわたる認識。
  • 開発納入時:売上高1,200万円、開発費充当
  • 初期サポート期間(3ヶ月):毎月100万円ずつ売上認識
  • 技術サポート(36ヶ月):毎月16.7万円ずつ売上認識
  • 従量課金: SaaSの追加使用量に基づく追加費用
  • パフォーマンスボーナス: システムの稼働率目標達成時のボーナス支払い
  • 返金可能性: サブスクリプション開始後30日以内なら全額返金
  • 数量割引: 追加ライセンス購入で割引
  • 期待値法: 複数の可能性がある場合、確率加重平均を計算。大量の類似契約(SaaS利用者1,000社)でこの方法が有効。
  • 最頻値法: 最も可能性が高い単一の金額を選択。契約が少数で、かつ結果が二項的(達成か未達か)なら有効。
  • 30%の顧客:基本範囲内(追加費用なし)
  • 50%の顧客:月平均12万回呼び出し(追加費用月5,000円)
  • 20%の顧客:月平均15万回呼び出し(追加費用月12,500円)
  • 過去の単独販売価格: 企業が同一商品を単独販売した場合の価格
  • 市場価格調査: 競合企業による同等商品の販売価格
  • 原価プラス・マージン法: 商品の原価に標準的マージン(例:40%)を上乗せした価格
  • 開発:2,100万円 × (1,200万円 ÷ 2,100万円) = 1,200万円
  • 初期サポート:2,100万円 × (300万円 ÷ 2,100万円) = 300万円
  • 技術サポート:2,100万円 × (600万円 ÷ 2,100万円) = 600万円
  • 商品所有権が顧客に移転する。
  • 顧客がその資産を支配する。
  • 企業が当該資産に対する支配を失う。
  • 顧客が、企業のパフォーマンスから生じる利益を同時に受け取り消費している。例えば、月次のSaaS利用。顧客は毎月、その月のサービスから価値を引き出している。
  • 企業のパフォーマンスが顧客が支配する資産を作成・向上させている。顧客が既に控有する資産に、企業が継続的に価値を追加する場合。例えば、顧客のシステムを継続的に改良する開発契約。
  • 企業のパフォーマンスが、他に代替用途のない資産を生成し、企業が当該資産完成時点までの対価について回収可能な権利を有している。例えば、カスタム製造。企業は、期間にわたり義務を果たす過程で、部分的な対価回収権を持つ。
  • パフォーマンス・オブリゲーション:月次のソフトウェア・アクセス権
  • 充足時期:期間にわたる認識。顧客は毎月、その月のサービスから価値を得ている。
  • 認識方法:進捗度測定法。テクノロジー企業では、経過期間に基づく線形法が一般的。毎月25万円を認識。

よくある誤り

テクノロジー企業の監査で金融庁やPCAOBから指摘されやすい事項。

1. 返金可能性の過小評価


「初期30日間は返金可能」という条件を、契約開始時に認識額から控除していないケース。実際の返金率(過去3年間で5〜10%)に基づき、対価を制約する必要がある。

2. パフォーマンス・オブリゲーションの過度な統合


カスタマイズ開発と保守を「単一の長期義務」と判定し、全体を工事進行基準で認識。実際には、カスタマイズ完了時に納入物の大部分の価値が実現されるため、開発部分は一時点認識すべき場合も多い。

3. 変動対価の見積精度不足


「顧客の追加利用料は見積もりが難しいので、ゼロで認識」という過度な保守的対応。実際の過去データを用い、期待値法で合理的に見積もるべき。

4. 独立売価の根拠不備


複数要素の配分で、各要素の独立売価を「経営層の判断」のみで決定。市場比較やコスト積み上げの根拠が監査調書に欠ける。金融庁の検査では、この根拠資料の提示を求められることが多い。

5. 契約修正の処理誤り


顧客が追加機能の導入を要望した場合、その修正が「新規契約」「既存契約への追加」「既存義務の修正」のどれに該当するか。判定を誤ると、収益認識のタイミングに大きな影響を及ぼす。

関連資料