月末、経理の担当者が、年払いの契約を12で割る表を開きます。
期の途中でプランを変えた顧客の行だけ、日割りを手で直していきます。
経営会議の前には、ARRをもう一度、別の表で数え直します。
SaaS・ソフトウェア企業が伸びると、どこかでこの「会計と契約管理の壁」にぶつかります。
サブスク収益認識とは、契約期間にわたるサービスの売上を、提供の進み具合に合わせて計上することです。
年払いで一括入金しても、売上は12か月に分けて計上する、といった扱いです。
NetSuiteは、サブスクの請求（SuiteBilling）、収益認識、SaaS指標を同じ基盤でつなげられるクラウドERPです。
つまずきの根は、請求・収益認識・指標がつながっていないことにあります。
ただ、全部をNetSuiteに寄せるのが正解とは限りません。
では、どこを寄せ、どこを外に残すのか。
この記事で分かること
- SaaS企業がぶつかる3つの壁と、その根にある問題
- NetSuiteのSuiteBilling（サブスク請求）と収益認識の機能の役割
- ASC606・日本の収益認識基準と、NetSuiteの機能の関係
- ARR・MRR・チャーンなどの指標を経営に使う考え方
- 請求を「標準に合わせる／開発する／残す」で分ける考え方と、費用・期間の目安
言葉の整理：ARRは年間の経常収益、MRRは月間の経常収益です。
チャーンは解約率、LTVは顧客生涯価値、CACは顧客獲得コストです。
SaaS企業がぶつかる3つの壁
SaaSの会計は、モノを売る会社の会計と構造が違います。
入金の時期と、売上に計上できる時期がずれるからです。
壁1：請求が複雑になる
- 期の途中のプラン変更（日割りの計算が要る）
- 従量課金や、ユーザー数に応じた変動
- 年払い・月払いの混在、複数年の契約
手作業や汎用のツールでは、請求のミスが起きやすくなります。
壁2：収益認識が難しい
たとえば、年額120万円の契約で、4月に一括で入金があったとします（架空の数字）。
入金は4月に120万円でも、売上は4月から毎月10万円ずつ計上します。
残りは、まだ提供していないサービスの分として負債に置きます。
契約にサポートや初期費用が混ざると、売上の配分は一気に複雑になります。
スプレッドシートで計算し続ければ、月次決算は長くなるばかりです。
壁3：SaaS指標がすぐに出ない
ARR、チャーン、LTVなどは、会計ソフトから自動では出てきません。
報告のたびに、スプレッドシートを作り直すことになります。
3つの壁は、別の問題に見えます。
けれども根は同じです。
請求・収益認識・指標がつながっていないことが、手作業を生んでいます。
壁と根の関係を図にすると、次のとおりです。
サブスク請求「SuiteBilling」
SuiteBilling（スイートビリング）は、NetSuiteのサブスク請求の機能です。
定期の請求の発行から、契約の変更までを扱います。
Oracle NetSuite公式サイトでは、次のような点が案内されています（出典：Oracle NetSuite公式、2026年9月確認）。
- 定額・段階制・従量制を、プロモーションや顧客別の料金と組み合わせられる
- 1回払い・継続・従量の課金を組み合わせられる
- 将来の日付の請求書の日割りを、自動で計算する
請求がNetSuiteの会計と同じ基盤で動くため、外部のツールとの同期の手間が減ります。
| データの流れ | 担う機能 | つながることで減る手作業 |
|---|---|---|
| 契約・変更 | SuiteBilling | 変更のたびの請求額の手計算 |
| 請求 | SuiteBilling | 請求書の作成と会計への転記 |
| 売上の計上 | 収益認識の機能 | 月ごとの配分の表計算 |
| 指標 | SaaS Metric Reporting | 報告のたびの集計 |
詳しくはNetSuiteのSuiteBillingをご覧ください。
なお、すべてのケースでSuiteBillingが合うとは限りません。
大量の少額課金を扱うB2Cでは、外部の請求ツールが向く場面もあります。
収益認識｜ASC606・日本の基準とNetSuite
会計基準の枠組み
ASC606は、米国の収益認識の会計基準です。
日本では、企業会計基準第29号「収益認識に関する会計基準」があります。
IFRS第15号の基本的な原則を取り入れることを出発点に作られました（出典：企業会計基準委員会、2026年9月確認）。
日本の基準は、次の5つのステップで収益を認識します。
- 顧客との契約を識別する
- 契約の中の履行義務を識別する
- 取引価格を算定する
- 履行義務に取引価格を配分する
- 履行義務を充足した時に、または充足するにつれて収益を認識する
適用は、2021年4月1日以後に始まる事業年度の期首からです（出典：企業会計基準委員会、2026年9月確認）。
自社が適用の対象か、どう扱うかは、顧問の会計士と決めてください。
NetSuiteの収益認識の機能
NetSuiteでは、ARM（Advanced Revenue Management）と呼ばれる機能が収益認識を担います。
公式サイトでは、ASC606・IFRS15などの基準への準拠に役立つと案内されています。
決めたスケジュールやマイルストーンにもとづき、収益を自動で認識します（出典：Oracle NetSuite公式、2026年9月確認）。
SuiteBillingの請求と同じ基盤にあるため、データを二重に持たずに済みます。
日本の基準での設定の仕方は、会計士と決めてから入れます。
詳しくはNetSuiteの収益認識と新しい収益認識基準への対応をご覧ください。
SaaS指標を経営に使う
SaaS指標は、事業の健全さを測る計器のようなものです。
成長しているのか、解約に削られていないかを、数字でつかめます。
NetSuiteには、SaaS指標を扱う機能（SaaS Metric Reporting）があります。
Oracleのヘルプでは、次のように説明されています（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
- 取引や契約から、新規・アップセル・ダウンセル・チャーンの影響を自動で作る
- MRR・ARRを扱える
- 使うには、請求の機能（Advanced Billing）を有効にすることが前提
画面での見方はNetSuite Subscription Metricsで扱っています。
指標は、経営の言葉として使ってこそ意味があります。
チャーンが下がれば、将来の収益が読みやすくなります。
ARRが正確に出れば、投資家への説明に根拠が加わります。
スプレッドシート併用とNetSuite統合の比較
| 観点 | スプレッドシート・外部ツール併用 | NetSuite統合 |
|---|---|---|
| サブスク請求 | ツールごとに分散。契約変更は手作業 | SuiteBillingで扱う |
| 収益認識 | 手計算。月次決算が長くなりやすい | 収益認識の機能で自動化 |
| SaaS指標 | 報告のたびに集計し直す | 請求・契約のデータから出す |
| データの整合 | システム間の同期でずれる | 同じ基盤でつながる |
| AIとの親和性 | データが散らばり、AIに任せにくい | 契約・請求・売上がそろい、解約の兆しの点検などにAIを使いやすい |
判断の軸は、いまの規模だけではありません。
「3年後にこの運用が回るか」という視点が、決裁の場面で効きます。
判断の物差し｜合う会社・合わない会社
NetSuiteが合う会社
- B2Bで、契約の変更（アップグレード・解約・更新）が多い
- 監査や投資家への報告で、収益認識の根拠を示す必要がある
- 海外の子会社や、複数の事業を持つ予定がある
NetSuite以外が合う会社・急がない会社
- 大量の少額課金のB2C → 外部の請求ツールと会計ソフトの組み合わせが合う場合がある
- 契約が少なく、日々の経理の手間を減らしたい → 国産の会計ソフトやOdooが合う場合がある
- 契約が数十件で、表計算で回っている → いまは入れず、指標の定義をそろえるだけでも効果がある
比べ方はOdooとNetSuiteの比較やAIでスクラッチ開発とERP、どちらを選ぶべきかをご覧ください。
状況から逆引きすると、次のとおりです。
これから選ぶ会社と、いまの仕組みを見直す会社
これから仕組みを選ぶ会社
会計ソフトと外部の請求ツールで回している段階なら、次の順で考えます。
- いちばん痛い壁（請求・収益認識・指標）を1つ決める
- その壁が、契約数が2倍になっても回るかを考える
- 外部の請求ツールを残すか、NetSuiteに寄せるかを決める
外部のツールを残す場合は、連携の設計が要ります。
Stripeとの連携はNetSuiteとStripeの連携で扱っています。
費用と期間の目安も、ここで持っておきます。
ライセンスは、ミニマム構成で月額20万円〜が出発点です。
導入費用は、NetSuite認定パートナー（Solution Provider）であるベンチャーネットの支援例で見ると、幅があります。
3名程度・1.5か月の150万円程度から、100名程度・1.5年の2億円程度までです。
購買・販売・プロジェクト管理を入れた30名程度の事例は、1年・2,000万円程度でした。
差を生むのは、業務の範囲、開発の量（とくに外部システムとの連携）、社内の体制、ユーザー数です。
4事例の中身はNetSuiteの料金・費用・価格にあります。
いまの仕組みを見直す会社
すでにNetSuiteを使っていても、請求や指標を外で管理している会社は少なくありません。
請求を外のツールで行い、会計へは月末にまとめて入れている。
ARRを、経営会議の前に手で集計している。
別のERPや会計ソフトの保守・契約の更新が近い。
どれかに当てはまるなら、まず「どのデータがどこにあるか」の一覧を作ります。
そのうえで、請求・収益認識・指標のどれから寄せるかを決めます。
よくある3つの失敗
失敗1：請求ツールとERPを別々に持ち、二重管理になる
起きること：契約の変更のたびに、複数のシステムへ手で転記する。月末にツールの間で数字が合わない。
原因：データの受け渡しが多く、転記のミスと時間差が生まれた。
避け方：請求と収益認識を、同じ基盤に置けないかをまず検討します。
すべて統合するのが正解とは限りません。
第9章の「標準に合わせる／開発する／残す」で、どこを統合し、どこで外部のツールを活かすかを分けます。
失敗2：収益認識の自動化を一度に仕上げようとする
起きること：すべての契約の形の自動化を狙い、要件定義が終わらない。稼働が遅れる。
原因：SaaSの契約の形は、事業の成長とともに変わります。
最初から全部を作ると、稼働の前に時間と費用を使い切ります。
避け方：代表的な契約の形から運用を始め、例外は後から足します。
日本の会社では、財務会計まで一度に載せるのはハードルが高めです。
段階を分けることをお勧めしています。
失敗3：SaaS指標を後から付け足そうとする
起きること：ARRやチャーンを会議の直前に手で集計する。部署によって指標の定義が違う。
原因：指標は、どの取引をどう記録するかで決まります。
データの持ち方が決まっていないと、後から正しく出せません。
避け方：導入の設計の段階で、「どの指標を、どう取るか」を先に決めます。
定義を1枚の表にし、経営と経理で合意しておきます。
ベンチャーネットならこう見る｜請求を3つに分ける
SaaS企業の相談で、ベンチャーネットが最初に聞くのは3つです。
- 契約の形の数：変更の頻度もあわせて聞く
- いちばん痛い壁：請求・収益認識・指標のどれか
- 収益認識の扱い：会計士と決めてあるか
ベンチャーネットはNetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
そのため、請求を全部NetSuiteに寄せる前提では話を始めません。
標準に合わせる／開発する／残す
請求は、契約の形ごとに3つに分けます。
- 標準に合わせる：代表的な契約の形は、SuiteBillingの標準の機能で扱う。料金体系のほうを標準に寄せる
- 開発する：課金の仕組みが製品と一体で独自なら、請求を作って会計と連携する。AIスクラッチ開発も選択肢に入る
- 残す：大量の少額課金は、外部の請求ツールを残し、会計とつなぐ
どれを選ぶかは、契約の形を数えた後に決めます。
開発を選ぶほど、導入費用だけでなく、稼働後の保守の手間も増えます。
変わること・注意が必要なこと
寄せる範囲が決まったら、稼働の前に次の点を伝えます。
- ライセンス費用：ユーザーやモジュールを足すと上がることがある
- 締め処理：売上の計上と締めの考え方が、いまの会計ソフトと違うことがある
- 帳票：いまの請求書の形を、どこまで再現するかで導入費用が変わる
稼働後3〜6か月は、操作の研修と運用のルールづくりを1つの工程として計画に入れます。
ここを削ると、現場がスプレッドシートとの併用に戻りやすくなります。
契約は、導入の段階は請負契約に対応しています（準委任も相談可）。
稼働後は、運用保守の契約が前提です。
導入して終わりではなく、事業の成長に合わせて一緒に直していく形です。
今日できること｜契約の形を数える
1時間で、次の表を埋めてみてください。
| 契約の形 | 件数 | 請求の周期 | 途中の変更の多さ |
|---|---|---|---|
| （例）月額・ユーザー課金 | 120件 | 月 | 多い |
| （例）年額・初期費用あり | 30件 | 年 | 少ない |
※件数は説明のための架空の例です。
形が5つ以内なら、代表的な形から始める進め方が取りやすくなります。
10を超えるなら、料金体系そのものを整理する価値もあります。
第9章の3つの分け方も、この表の行ごとに決められます。
よくある質問
Q1. SaaS企業がNetSuiteを入れる一番の利点は何ですか
請求・収益認識・SaaS指標を1つの基盤でつなげられることです。
スプレッドシートの寄せ集めから抜け出し、決算の長期化を防ぎやすくなります。
経営判断に使う数字も、早く出せるようになります。
Q2. NetSuiteはASC606に対応していますか
収益認識の機能（ARM）がASC606やIFRS15への準拠に役立つと案内されています。
スケジュールにもとづいて収益を自動で認識します（Oracle NetSuite公式、2026年9月確認）。
詳しくはNetSuiteの収益認識をご覧ください。
Q3. 日本の収益認識基準でも使えますか
基準の考え方に沿った設定を会計士と決めて使います。
日本の基準は、IFRS第15号の基本的な原則を取り入れています（企業会計基準委員会）。
自社の契約での扱いを先に決めてから、設定に落とします。
Q4. StripeやChargebeeなどから乗り換えるべきですか
外部のツールを残すほうが合う場合もあります。
大量の少額課金などでは、外部のツールが向く場面があります。
「標準に合わせる／開発する／残す」で、どこを統合し、どこで外部を活かすかを分けます。
Q5. 導入にはどのくらいの費用がかかりますか
ライセンスはミニマム構成で月額20万円〜が出発点です。
モジュール・ユーザー数・オプションで変わり、数百万円規模になることもあります。
導入費用は別で、ベンチャーネットが支援した例では150万円程度から2億円程度まで開きがあります。
正式なライセンスの金額はOracleの営業が示します。
Q6. 収益認識や財務会計から始めるべきですか
必ずしもそうではありません。
まず回せる範囲から始め、財務会計は第2段階以降に回すことが多くあります。
いちばん痛い壁から始めるのが基本です。
Q7. SaaS指標はNetSuiteの中で出せますか
SaaS Metric Reportingの機能でMRR・ARRやチャーンを扱えます。
請求の機能（Advanced Billing）を有効にすることが前提です（Oracle NetSuiteのヘルプ、2026年9月確認）。
日本での提供の条件は、アカウントの担当に確かめてください。
まとめ：どこを寄せ、どこを残すか
- SaaS企業の壁の根は、請求・収益認識・指標がつながっていないこと
- NetSuiteは、SuiteBilling・収益認識の機能・SaaS指標を同じ基盤でつなげる
- 日本の収益認識基準の扱いは、会計士と決めてから設定する
- 請求は「標準に合わせる／開発する／残す」で契約の形ごとに分ける
- いちばん痛い壁から始め、段階を分けて広げる
月末に年払いの契約を12で割る作業は、仕組みでなくせます。
その前に、契約の形がいくつあるかを数えてみてください。
どこを寄せ、どこを残すかは、その表から決まります。
もう少し詳しく知りたい方へ
自社のサブスクの形だと、どう設計すべきか。
契約の形の整理から、ご相談をお受けしています。
