2026年03月13日

NetSuiteでサービス業の収益を可視化｜プロジェクト別収益管理の設計と実現

サービス業（SI、コンサル、広告、保守運用、BPOなど）では、売上・原価・工数が「案件（プロジェクト）」単位で動きます。一方で、会計は月次締め、現場は日々の進行、営業は受注見込みという時間軸のズレがあり、プロジェクト別収益管理が崩れやすいのが実情です。

典型的には、次のような課題が起きます。

売上は請求ベース、原価は発生ベースで、案件別の粗利が月次で揃わない
外注費や経費が案件に紐づかず、後で配賦（はいふ）して精度が落ちる
進行中案件の「見込み粗利」を説明できず、管理会計が形骸化する
例外（追加作業、契約変更、検収遅れ）が増えるほどExcelが増殖する

結論として、NetSuiteでもプロジェクト別収益管理は十分に実現可能です。ただし「何をプロジェクトで管理し、何を会計で確定させるか」を分けて設計しないと、入力負荷や内部統制の歪みが出ます。本記事では、サービス業がNetSuiteを使いこなすための現実的な設計方針と、標準機能・設定・開発・連携の判断軸を整理します。

1 結論：NetSuiteは“プロジェクト会計”を軸に、収益認識・原価・工数をつなげられる
2 どんなサービス業・体制ならうまく回るか
3 プロジェクト別収益管理は「業務設計」と「データ設計」が9割
4 標準機能／設定／開発／連携をどう使い分けるか
5 実務の進め方：要件→設計→テスト→移行→運用までの最短ルート
6 よくある失敗と回避策
7 まとめ
8 おわりに

結論：NetSuiteは“プロジェクト会計”を軸に、収益認識・原価・工数をつなげられる

プロジェクト別収益管理で押さえるべき要素は大きく3つです。

売上（収益認識）：契約条件に沿って、いつ・いくら売上にするか
原価：外注費・経費・労務費（工数）を案件へ寄せる
見える化：確定（会計）と見込み（管理）を混ぜずに並べる

NetSuiteでは、プロジェクト（案件）を中心に、取引（受注・請求）、費用（仕入・経費）、工数（タイム入力）を紐づけ、レポートやダッシュボードで横断できます。さらに収益認識（Revenue Recognition）や、必要に応じて高度な収益管理（Advanced Revenue Management：ARM）を使うことで、契約条件に応じた売上計上も設計できます（適用可否は契約形態・運用体制に依存します）。

どんなサービス業・体制ならうまく回るか

NetSuiteでプロジェクト別収益管理が効果を出しやすい条件は次の通りです。

案件別に採算を見たい（赤字案件の早期検知、単価改定、外注最適化）
案件数が増え、Excel集計が破綻しかけている
受注〜請求〜仕訳が部門をまたぐ（営業・PM・経理の分業）
締めを短縮したい（月次の着地見込みを早めたい）

一方、次の条件が強い場合は、標準だけでなく設計の工夫や周辺システム連携を検討した方が安全です。

工数管理が分単位で厳密、承認ルートが複雑（例：多階層・多拠点）
契約が多段（基本契約＋個別契約）で、変更が頻繁
売上計上ルールが複雑（複数の履行義務、返金条項、出来高の高度運用など）

プロジェクト別収益管理は「業務設計」と「データ設計」が9割

NetSuite導入・活用でつまずきやすいのは、機能不足よりも「プロジェクト粒度」と「責任分界」が曖昧なまま進むことです。最低限、次を先に決めると議論が前に進みます。

プロジェクト（案件）粒度：契約単位か、作業単位（フェーズ）か、顧客単位か
収益の確定タイミング：検収、請求、役務提供、出来高など（会社の会計方針に従う）
原価の寄せ方：外注・経費は直接付けるのか、間接費を配賦するのか
工数の位置づけ：労務費として計上するのか、採算管理のKPIとして扱うのか
例外処理：契約変更、追加作業、キャンセル、値引、検収遅れの扱い

これらは経理・現場・ITで合意が必要です。合意がないまま設定や開発に入ると、稼働後に「入力されない」「締めで調整だらけ」「監査で説明できない」状態になりがちです。

標準機能／設定／開発／連携をどう使い分けるか

プロジェクト別収益管理は、すべてをNetSuite単体で完結させる必要はありません。判断軸は「差別化要件か」「変更頻度」「会計・統制への影響」「運用体制」「将来拡張」「データ統合」「総保有コスト（TCO）」です。

標準：プロジェクト×取引×費用×工数を一気通貫で紐づける

標準寄せが向くのは、次の条件です。

案件別の採算を月次で見られれば良い（リアルタイム厳密性は必須ではない）
入力ルールを統一できる（最低限のマスタ整備・コード体系が作れる）
プロジェクトの開始〜完了〜クローズの運用が定義できる

この場合、プロジェクト（案件）をキーにして、受注・請求・購買・経費・タイムを紐づけ、レポートで粗利や進捗を追います。ここで重要なのは「紐づけ漏れを作らない」ことです。外注費や経費がプロジェクト未指定で起票されると、後工程の配賦が増えて精度が落ちます。

設定・ワークフローで吸収：承認統制と入力品質を先に固める

サービス業の“現実”として、プロジェクト別収益管理は入力品質で決まります。NetSuiteでは、ロール（役割）ごとの権限、必須項目、承認ワークフローを組み合わせて、次を実現します。

最小権限：現場は必要な入力だけ、経理は締め関連、管理者は設定・監査ログ
必須化：費用・経費・タイムにプロジェクト（または部門等）を必須入力
承認：タイム承認、経費承認、購買承認をロールに応じて段階化
変更管理：本番反映手順、設定変更の記録、監査に耐える運用ルール

「機能を足す」より先に、「正しく入る仕組み」を作る方が、締め短縮と説明可能性に直結します。

追加開発（SuiteScript等）を選ぶ場面：差別化要件・例外処理が多い場合

開発が向くのは、例えば以下です。

契約変更が多く、履歴管理や自動調整の業務差別化がある
プロジェクトのフェーズ別に自動でタスク生成・原価計上ルールを切り替えたい
監査対応として、特定条件での入力制御やアラートが必要

副作用として、保守性（担当者交代時の引き継ぎ）、将来改修、テスト工数が増えます。特に会計・締め処理に触れる開発は影響範囲が大きいので、Must/Should/Couldで優先度を整理し、標準代替の余地を必ず検討します。

外部連携を選ぶ場面：工数・契約・請求が“別の主戦場”にある場合

既存のPSA（Professional Services Automation）や工数管理SaaS、請求・契約SaaSが業務の中心にある場合、NetSuiteは会計の中核として位置づけ、API/バッチ/ETLで連携する設計が現実的です。

連携設計で必ず決めるべきことは次の通りです。

目的：締め短縮か、採算精度か、入力負荷削減か
同期対象：顧客・プロジェクト・従業員・品目などのマスタ、請求・費用などのトランザクション
更新方向：片方向/双方向（双方向は整合性設計が難しくなる）
ID設計：外部IDの保持、突合キー、重複防止
障害時運用：再送、冪等性（同じデータを送っても二重登録にならない）、手動復旧手順
監査性：ログ、証跡、誰がいつ何を送ったか

実務の進め方：要件→設計→テスト→移行→運用までの最短ルート

プロジェクト別収益管理を「使える形」で立ち上げるには、次の順番が安全です。

Step1：要件定義で決める（成果物：要件一覧・粒度表・責任分界）

プロジェクト階層（案件/フェーズ/タスク）をどう持つか
売上計上（収益認識）ルール：いつ、何をトリガーに、どの仕訳が立つか
原価の範囲：外注費・経費・労務費の扱い、配賦の有無
締めの運用：締め前に何を揃えるか（未承認タイム、未計上費用など）
レポート要件：確定PL、見込み粗利、予実、部門別など

Step2：データ設計（成果物：マスタ設計・コード体系・データ品質基準）

プロジェクトコードの体系（顧客・年度・連番など）と採番ルール
部門/ロケーション/クラス等の使い分け（管理軸の混線を防ぐ）
必須入力項目の定義（入力漏れを物理的に減らす）
データ品質基準（欠損・重複・整合性）とチェック方法

Step3：権限・承認・締め設計（成果物：権限表・承認フロー図・締めチェックリスト）

ロール別の最小権限（閲覧/登録/承認/修正/削除）
職務分掌（入力者と承認者、経理の締め権限の分離）
締め処理の前提（締め後修正のルール、例外時の申請）

Step4：テスト（成果物：テスト観点表、例外シナリオ一覧）

プロジェクト別収益管理のテストは、画面操作より「例外」と「締め」を厚くします。

契約変更（増額/減額/期間変更）時の売上・原価の追随
検収遅れ・請求遅れが月次にまたがるケース
未承認タイム、費用の計上漏れがある状態でのレポートの見え方
権限制御（見えてはいけない案件が見えないか、締め後修正ができないか）
性能（案件数・仕訳数が増えたときのレポート速度）

Step5：移行・稼働後運用（成果物：移行手順、教育資料、問い合わせ運用）

移行対象：進行中プロジェクト、未請求、未計上費用、契約残など
移行リハーサル：整合性チェック、差異原因の特定、やり直し手順
教育：ロール別（PM/メンバー/経理/管理者）に入力と判断を分ける
定着KPI：入力遅延、未承認件数、締め日数、エラー率

よくある失敗と回避策

失敗1：プロジェクト粒度が揺れて、レポートが信用されない

原因：契約単位と作業単位が混在し、比較できない
兆候：同じ顧客でも案件ごとの売上・原価の付け方がバラバラ
対策：粒度表（何をプロジェクトにする/しない）を作り、採番・登録ルールを固定

失敗2：費用・工数が紐づかず、月末に“寄せ集め”になる

原因：入力必須化や承認が弱く、未入力が放置される
兆候：月末に経理がプロジェクト付け替えを大量に実施
対策：プロジェクト必須、未承認の見える化、締め前チェックリスト運用

失敗3：会計の確定値と見込みを混ぜて、説明不能になる

原因：見込み粗利を仕訳で表現しようとして無理が出る
兆候：月次で戻し仕訳が増える、監査・経営会議で説明が破綻
対策：会計（確定）と管理（見込み）をレポート設計で分離し、指標定義を明文化

失敗4：連携が属人化し、障害時に止まる

原因：API連携の仕様・ログ・再送手順が整備されていない
兆候：データ不整合が起きても原因追跡できない、復旧が手作業
対策：IF仕様書、監視、エラー通知、手動復旧手順、監査ログをセットで整備

まとめ

NetSuiteでも、サービス業に必要なプロジェクト別収益管理（売上・原価・工数の紐づけと可視化）は実現可能です。

成功の鍵は機能選定より先に、プロジェクト粒度、収益認識、原価の寄せ方、例外処理を業務・会計・ITで合意することです。標準機能を軸に、承認・権限・必須化で入力品質を担保し、差別化要件のみ開発や外部連携を検討するのがTCO面でも安全です。テストは「例外」と「締め」を厚くし、会計の確定値と管理の見込みを混ぜないレポート設計にすることで、月次の説明可能性が上がります。