購買や経費の承認が、メールの回覧や口頭の「OK」で回っていないでしょうか。
担当者が変わると基準が揺れ、誰がいつ承認したのかも後から追えない。こうした属人化は、会社が大きくなるほど経営のリスクになります。
NetSuiteには、承認の流れをシステム上で自動化する仕組みが標準で備わっています。この記事では、購買承認・経費承認・稟議という3つの実装パターンを軸に、SuiteFlowを使った承認ワークフローの作り方を整理します。あわせて、内部統制や職務分掌への対応までを解説します。
この記事で分かること
- NetSuiteの承認ワークフローとは何か（標準機能とSuiteFlowの違い）
- 購買承認・経費承認・稟議の3つの実装パターン
- 金額の上限（承認限度額）による多段承認の仕組み
- 職務分掌（SoD）を承認フローに組み込む考え方
- 承認ワークフロー設計でよくある失敗と、その回避策
読了目安：約10分
NetSuiteの承認ワークフローとは
承認ワークフローとは、購買や経費などの取引が処理される前に、決められた承認者のチェックを通す仕組みのことです。
NetSuiteで承認の流れをつくる方法は、大きく2つあります。
1つめは、標準の「承認ルーティング（Approval Routing）」です。 設定だけで使える機能で、上司や承認者の階層と、承認できる金額の上限を決めて運用します。
2つめは、「SuiteFlow（スイートフロー）」です。 SuiteFlowとは、NetSuiteに標準で含まれるワークフロー管理ツールです。業務の流れ（どんな状態を経て、どこで分岐するか）を、画面上の操作で組み立てられます。プログラミングは不要です。標準機能だけでは足りない複雑な条件分岐や多段承認を、ここで作り込めます。
承認限度額という考え方
NetSuiteの承認ルーティングの中心にあるのが「承認限度額」です。
社員ごとに「この金額までは自分で承認してよい」という上限を設定します。上限の範囲内なら自動で承認され、超えた取引は、その金額をカバーできる上位者へ自動で回ります（Oracle公式ヘルプ「Approval Routing」より）。
たとえば、ある社員の購買限度額が30万円だとします。25万円の発注はそのまま通り、50万円の発注は限度額が足りる上長へ自動で回る、という動きです。
なお、標準の承認ルーティングだけを使う場合は、一度にまとめて承認できる件数に上限があるなど、いくつかの制約もあります。こうした制約を超えて柔軟に運用したいときに、SuiteFlowのカスタムワークフローが活きてきます。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットも、同じ進め方を大切にしています。まずは標準機能で回せる範囲を見極め、必要な部分だけをSuiteFlowで作り込んでいきます。
なぜ今、承認フローを「システム」で整えるのか
承認を仕組み化する目的は、単なる効率化ではありません。内部統制と説明責任の土台をつくることにあります。
ここで言う内部統制とは、業務が正しく、不正なく回る仕組みのことです。上場企業や上場準備中の企業では、財務報告の内部統制ルール（J-SOX。金融商品取引法にもとづく制度）への対応も求められます。
「今までどおり」を続けるコスト
メールや紙の回覧、口頭の承認を続けると、次のような問題が積み重なります。
- 誰がいつ承認したのか、証跡（記録）が残らない
- 担当者が交代すると、承認の基準が揺れる
- 承認待ちが見えず、案件が止まっていることに気づけない
- 監査のたびに、承認の証拠を手作業で集める手間がかかる
これらは小さな会社では表面化しにくいものです。しかし拠点や人数が増えるほど、経営判断のスピードと信頼性を確実に削っていきます。
承認をシステムに乗せれば、「誰が・いつ・いくらを・どの根拠で承認したか」が自動で記録に残ります。内部統制を効率化したいという観点は、別記事「会計監査・内部統制の負担を減らすには？」でも詳しく扱っています。
実装パターン①：購買承認
1つめのパターンは、購買発注（Purchase Order）の承認です。発注を確定する前に、上長や購買責任者のチェックを通します。
ここで効くのが、先ほどの承認限度額による自動ルーティングです。金額に応じて、承認者が自動で切り替わります。
SuiteFlowでカスタムする場合は、次のような作り込みができます。
- 承認者が不在のときの代理承認者を設定する
- 部門ごとに承認ルートを分ける
- 金額の段階に応じて、二段・三段の多段承認にする
購買発注だけでなく、購買申請（Requisition）や仕入先請求書（Vendor Bill）の承認も、同じ考え方でワークフロー化できます。これらの設定はNetSuiteの会計設定で有効化します（Oracle公式ヘルプより）。
実装パターン②：経費承認
2つめは、経費精算（Expense Report）の承認です。社員が申請した経費を、上長、必要に応じて経理の順にチェックします。
経費にも承認限度額の考え方が使えます。社員ごとに経費の承認者を指定でき、指定がなければ上司が承認者になります。
ポイントは、購買と経費を別々に設計できることです。それぞれにSuiteFlowで独自のフローを作れるため、「経費は上長一段でよいが、購買は金額が大きいので二段にする」といった使い分けができます。
実装パターン③：稟議承認
3つめは、日本企業で根づいている「稟議」の承認です。
ここは正確にお伝えしておきます。NetSuiteに「稟議」という名前の専用機能があるわけではありません。日本の稟議、つまり複数の関係者が合議して意思決定する流れを、SuiteFlowのカスタムワークフローで再現する、というのが実態に近い表現です。
具体的には、金額・部門・案件の種類によって承認ルートを分岐させ、複数部門の合議を組みます。差し戻しやコメントのやり取りも設計できます。
なお、ここで言う「稟議」は承認の流れの話です。経営層を動かすための稟議「書」（提案文書）の書き方は別のテーマで、関連記事「ERP導入の社内稟議書の書き方」で扱っています。
職務分掌（SoD）を承認フローに組み込む
承認ワークフローを設計するとき、セットで考えたいのが職務分掌です。
職務分掌（Segregation of Duties、SoD）とは、一人の担当者が「申請」と「承認」を兼ねられないように役割を分ける考え方です。同じ人が自分で申請して自分で承認できてしまうと、不正や誤りを止められません。
承認ワークフローが「処理の流れ」を決めるものだとすれば、職務分掌は「誰が何をできるか」を決めるものです。この2つは両輪で、流れだけ整えても、権限設計が伴わなければ統制は効きません。
NetSuiteでは、ロール（役割）ごとにアクセス権を細かく設定できます。誰が起票でき、誰が承認できるかを役割で分けることで、職務分掌を実現します。権限・ロール設計の具体的な考え方は、別記事で掘り下げる予定です。
承認ワークフロー設計でよくある失敗
ここからは、承認フローの設計でつまずきやすい点をお伝えします。
これは「うまくできていない会社」を責めるために書くものではありません。同じ失敗を繰り返してほしくないからこそ、率直に共有します。
失敗①：現場の流れを確認せず、いきなりシステム化する
- よくある現象：今の承認の実態を確かめないまま、理想形だけで設計する
- なぜ失敗するか：実際の運用とズレが生じ、現場が「裏ルート」で回し始める
- どう回避するか：まず現状の承認の流れを書き出し、形になっている部分から乗せる
失敗②：承認者を「役職」で固定しすぎる
- よくある現象：承認者を特定の役職に固定し、不在時の代役を決めていない
- なぜ失敗するか：担当者が休むと承認が止まり、業務全体が滞る
- どう回避するか：代理承認者をあらかじめ設計に組み込んでおく
失敗③：承認ステップを増やしすぎる
- よくある現象：念のためと承認段階を多くし、誰もが「とりあえず通す」状態になる
- なぜ失敗するか：チェックが形だけになり、統制しているつもりで実は機能しない
- どう回避するか：金額や重要度に応じて段階を絞り、本当に必要な関門だけ残す
失敗④：職務分掌・権限設計を後回しにする
- よくある現象：承認の流れは作ったが、誰が何をできるかの権限設計が曖昧なまま
- なぜ失敗するか：申請者が自分で承認できてしまうなど、統制の前提が崩れる
- どう回避するか：ワークフロー設計と権限設計を同時に進める
承認フローの設計に、最初から決まった正解があるわけではありません。大切なのは、完璧を目指して立ち止まることより、まず回してみて、動かしながら磨いていくことです。
ERPの導入や運用は、ITの作業ではなく経営のプロジェクトです。だからこそベンチャーネットは、現場の流れを一緒に確認しながら、対等な伴走者として設計を進めることを大事にしています。
SuiteFlowで作るか、SuiteScriptが必要か
最後に、よくいただく質問にお答えします。承認フローはSuiteFlowだけで作れるのか、それともSuiteScript（NetSuiteの開発言語）が必要なのか、という点です。
結論として、承認ワークフローの大半はSuiteFlowのノーコード操作で作れます。
SuiteScriptが必要になるのは、SuiteFlow標準の機能では表現しきれない複雑なロジックや、外部システムとの連携が絡む場合です。
どこまでをSuiteFlowで作り、どこからSuiteScriptに踏み込むか。その判断軸は、関連記事「NetSuiteのカスタマイズ完全ガイド」で詳しく整理しています。
よくある質問（FAQ）
Q. 承認ワークフローはプログラミングなしで作れますか？
はい。SuiteFlowを使えば、画面上の操作だけでノーコードで作れます。複雑な要件の場合のみ、SuiteScriptでの開発を検討します。
Q. 金額によって承認者を変えられますか？
できます。社員ごとに承認限度額を設定すると、上限を超えた取引が、その金額をカバーできる上位者へ自動で回ります。
Q. 承認者が不在のときはどうなりますか？
SuiteFlowのカスタムワークフローで、代理承認者を設定できます。担当者の休みで承認が止まることを防げます。
Q. 内部統制（J-SOX）への対応に使えますか？
承認の証跡が自動で残り、職務分掌と組み合わせることで、内部統制を支える土台になります。ただし対応の範囲は会社ごとに異なるため、設計時の整理が欠かせません。
Q. 日本独自の「稟議」にも対応できますか？
「稟議」という名前の専用機能はありませんが、SuiteFlowのカスタムワークフローで、金額・部門ごとの合議の流れを再現できます。
まとめ：承認の仕組み化は、内部統制の第一歩
承認ワークフローは、購買・経費・稟議という日々の意思決定を、属人化から仕組みへと移す取り組みです。
NetSuiteなら、標準の承認ルーティングとSuiteFlowを組み合わせ、自社の実態に合わせて承認の流れを設計できます。そこに職務分掌を重ねることで、内部統制の土台が整います。
まず取り組むべきは、自社の承認が今どう回っているかを書き出してみることです。そのうえで、どこから仕組みに乗せるかを決めていけば、無理なく前に進めます。
自社の承認フローをどう設計すればよいか迷われている場合は、現状の整理からご一緒できます。
もう少し詳しく知りたい方へ
あわせて読みたい
