NetSuiteの承認ワークフロー実装ガイド|稟議・購買承認と内部統制対応(SuiteFlow活用)

月末の夕方、部長の机に発注書の束が届きます。

メールで返した「OKです」は、どの発注書への返事だったのか。

監査の前には、経理がその返信を一通ずつ探し出すことになります。

NetSuiteの承認ワークフローとは、発注や経費などの取引を処理する前に、決められた承認者の確認を通す仕組みです。

標準の承認の機能と、SuiteFlow(画面の操作で流れを組む道具)で作れます。

金額に応じて承認者を切り替える多段の承認も、プログラミングなしで組めます。

ただ、仕組みを入れても、承認の渋滞は消えません。

対象を広げすぎると、承認者が中身を見なくなるからです。

では、何を承認にかけ、何をかけないのか。

目次

この記事で分かること

  • NetSuiteで承認の流れを作る4つの方法と、その違い
  • 設定を進める順番と、つまずきやすい点
  • 購買・経費・稟議の型と、汎用の申請を作るか・つなぐかの判断
  • 承認を減らす基準と、職務分掌の考え方

言葉の整理:SuiteFlowは、NetSuiteに標準で含まれるワークフローの道具です。

職務分掌は、1人が申請と承認を兼ねないように役割を分けることです。

承認限度額は、社員ごとに「この金額までは承認なしで進めてよい」と決める上限を指します。

NetSuiteで承認の流れを作る方法

4つの方法

Oracleの公式ヘルプは、承認の方法として3つを挙げています。

これに、Oracleが提供するSuiteApprovals SuiteAppを加えると4つです。

方法中身向く場面
Approval Routingの機能上司と承認限度額で回す、いちばん基本の方法金額で承認者が決まる単純な流れ
標準のSuiteFlowのワークフロー用意された承認のワークフローを使う基本より少し柔軟にしたい
カスタムのSuiteFlowのワークフロー条件の分岐や多段の承認を自由に組む部門や案件で流れが変わる
SuiteApprovals SuiteApp階層の承認と、承認の委任などをまとめて扱う仕訳や受注なども同じ考え方で承認したい

(出典:Oracle NetSuite公式ヘルプ「Approval Routing」「SuiteApprovals SuiteApp」、2026年9月確認)

公式ヘルプによると、どの方法でも、承認の設定は会社全体にかかります。

部門ごとに方法を選び分けるのではなく、会社として1つに決めることになります。

SuiteApprovalsの対象は、仕訳・経費報告・発注書・購買申請・受注・仕入先請求書などです。

日本のアカウントでの使い方は、アカウントの担当に聞いてください。

承認限度額で、承認者が自動で切り替わる

公式ヘルプの説明では、承認限度額は次のように働きます。

  • 上限より少ない経費や購買の申請は、自動で承認される
  • 上限を超えると、その金額を承認できる上司か承認者へ回る
  • 権限の足りる人が見つかるまで、上へ回っていく
  • 誰も権限が足りない場合は、取引に警告が出る

(出典:Oracle NetSuite公式ヘルプ「Supervisors, Approvers, and Approval Limits」、2026年9月確認)

この流れを図にすると、次のとおりです。

承認限度額で、承認者が自動で切り替わる 上限より少ない申請は自動で承認される。上限を超えると金額を承認できる上司か承認者へ回り、足りる人が見つかるまで上へ回る。誰も足りなければ取引に警告が出る。 承認限度額の働き 経費・購買の申請 上限より少ない 上限を超える 自動で承認 上限の足りる 上司・承認者へ 足りる人が 見つかるまで上へ 誰も足りなければ 取引に警告 承認者を待たずに 処理が進む
承認限度額で、承認者が自動で切り替わる

たとえば、ある社員の購買の上限を30万円とします(架空の数字です)。

25万円の発注はそのまま通ります。

50万円の発注は、上限の足りる上長へ回ります。

承認には2種類ある

種類中身NetSuiteでの実現
業務の承認発注・経費・請求など、取引に紐づく承認標準の承認機能とワークフローで対応
汎用の申請備品購入の相談、出張届、社外への持ち出し許可など標準にはない。カスタムレコードとワークフローで作る

NetSuiteに承認の機能がないわけではありません。

業務の承認は標準にあり、汎用の申請を作る余地が残っている、という関係です。

紙の稟議書で回している申請の多くは、後者に当たります。

Odooのアプリとの対応は、OdooのアプリはNetSuiteで何に当たるかで扱っています。

承認の仕組みそのものの比べ方は、承認・チャット・電話・IoTはNetSuiteとOdooでどう違うかにあります。

承認をシステムに乗せると、何が残るか

目的は、効率化だけではありません。

内部統制と説明責任の土台をつくることにあります。

内部統制は、業務が正しく、不正なく回る仕組みのことです。

上場企業や上場を準備中の会社では、財務報告の内部統制の制度(J-SOX)への対応も求められます。

メールや紙、口頭の承認を続けると、次の問題が積み重なります。

  • 誰がいつ承認したのか、記録が残らない
  • 担当者が交代すると、承認の基準が揺れる
  • 承認待ちが見えず、案件が止まっていても気づけない
  • 監査のたびに、承認の証拠を手作業で集める

システムに乗せれば、「誰が・いつ・いくらを・どの根拠で承認したか」が記録に残ります。

監査の負担の減らし方は、会計監査・内部統制の負担を減らすにはで扱っています。

設定を進める順番と、つまずく点

承認の設定は、画面を開く前の準備で半分が決まります。

次の順で進めると、手戻りが少なくなります。

  1. 承認の棚卸し:いまの承認を書き出し、業務の承認と汎用の申請に分ける(第10章の表)
  2. 減らす判断:第5章の3段階に当てはめ、承認しないものを先に外す
  3. 方法を1つ選ぶ:設定は会社全体にかかるため、4つの方法から会社として決める
  4. 機能を有効にする:Approval Routingは、機能の有効化の画面でオンにする
  5. 社員ごとに登録する:上司、経費の承認者、承認限度額を社員の記録に入れる
  6. 権限を分ける:起票できるロールと、承認できるロールを分ける(第6章)
  7. 例外を組み込む:代理の承認、委任、事後承認の範囲を決める
  8. 月末の件数で試す:実際に集まる量の取引で、承認の画面を動かしてみる

(出典:4〜5はOracle NetSuite公式ヘルプ、2026年9月確認)

途中でつまずきやすいのは、次の4つです。

つまずき原因手当て
取引に警告が出て止まる金額を承認できる人が、階層のどこにもいない上限の階段に抜けがないか、社員の登録を見直す
上司が承認しなくなった経費の承認者を決めると、上司は階層から外れる意図した経路かを、登録の段階で決めておく
月末の一括承認が終わらないApproval Routingでは一度に25件までしか承認できない件数を見て、承認しない候補を先に減らす
退職や異動で経路が空く承認者を個人で固定していた代理の承認者を決め、年1回見直す

(出典:Oracle NetSuite公式ヘルプ、2026年9月確認)

購買・経費・稟議の型

購買の承認

発注書(Purchase Order)を確定する前に、上長や購買の責任者の確認を通します。

承認限度額によって、金額に応じた承認者へ自動で回ります。

SuiteFlowで作り込めば、次のことも組めます。

  • 承認者が不在のときの代理の承認者
  • 部門ごとに分かれた承認の経路
  • 金額の段階に応じた、2段・3段の承認

購買申請(Requisition)や仕入先請求書(Vendor Bill)も、同じ考え方で承認にかけられます。

経費の承認

社員が申請した経費を、上長、必要に応じて経理の順に確認します。

公式ヘルプでは、社員ごとに経費の承認者を決められ、決めていなければ上司が承認します。

購買と経費は、別々に設計できます。

「経費は上長1段、購買は金額が大きいので2段」といった使い分けもできます。

稟議の承認

NetSuiteに「稟議」という名前の専用の機能はありません。

複数の関係者が合議する日本の稟議を、カスタムのSuiteFlowで再現する形になります。

金額・部門・案件の種類で経路を分け、差し戻しやコメントのやり取りも設計します。

稟議「書」の書き方は別のテーマです。

ERP導入の社内稟議書の書き方で扱っています。

汎用の申請は、中に作るか、専用サービスとつなぐか

汎用の申請をNetSuiteの中に作るなら、次の3つを組み合わせます。

  1. 申請を入れる箱(カスタムレコード:申請の種類・金額・理由・添付)
  2. 承認の経路(ワークフロー:条件による振り分け、複数の承認、差し戻し)
  3. 一覧の画面(承認者が、自分の未処理をまとめて見る画面)

手間はかかります。

その代わり、見積や在庫の情報を同じ画面で見ながら承認できます。

承認された申請から発注へつなぐ流れも、自然に作れます。

観点NetSuiteの中に作る専用サービスとつなぐ
申請の種類10種類程度まで。項目も定型数十種類。部署ごとに様式が違う
経路の複雑さ金額・部門で分岐する程度役職と部門の組み合わせで細かく変わる
既存のExcelの様式作り直す前提Excelの帳票をそのまま画面にしたい
承認した後の処理発注や経費につなげたい承認が終われば十分

分かれ目は、承認した後の処理まで同じ場所でつなげたいかどうかです。

つなげたいなら、NetSuiteの中に作ります。

承認が終われば十分なら、専用サービスとつなぎ、結果だけをNetSuiteに戻します。

作り込みや連携の量は、導入費用にも響きます。

ベンチャーネットが支援したNetSuite導入の費用では、3名程度・開発なしの事例が150万円程度・1.5か月でした。

100名程度で外部システムとの連携開発を含めた事例は、2億円程度(うち開発約7割)・1.5年です。

差を生むのは、機能範囲・開発(特に外部連携)・社内の体制・ユーザー数の4つです。

4事例の条件は、NetSuiteの料金・費用・価格に載せています。

設計は「何を承認しないか」から始める

冒頭の問いへの答えは、1つの基準に行き着きます。

止めて防げる損失が待たせて生じる損失より大きいか。

大きい申請だけを、承認にかけます。

少額の消耗品を複数名の承認にすると、この計算は合いません。

承認を増やしすぎると、承認者は中身を見なくなります。

形だけの承認は、統制を強めるどころか弱めます。

承認の重さを3段階に分ける

段階対象例
承認しない記録だけ残す日常の消耗品、少額の交通費
上長1名その場で判断できる部門予算内の支出、通常の出張
複数名後戻りが難しい判断高額の支出、契約、社外への情報提供

大半の申請は、真ん中に入るのが健全です。

承認の重さを3段階に仕分ける 止めて防げる損失が、待たせる損失より大きいかを問い、承認しない・上長1名・複数名の3段階に分ける。 承認の重さを3段階に仕分ける 止めて防げる損失は、 待たせる損失より大きいか 申請の種類ごとに問う 承認しない(記録だけ) 日常の消耗品、少額の交通費 上長1名 部門予算内の支出、通常の出張 複数名 高額の支出、契約、社外への情報提供 大半の申請は「上長1名」に入るのが健全
承認の重さを3段階に仕分ける

承認ではなく、事実で止める設計もあります。

前受金の入金がなければ次の工程に進めない、という統制がその例です。

考え方はNetSuiteの前受金管理で扱っています。

例外の手続きをセットで決める

設計でいちばん忘れられるのが、例外です。

次の3つは、必ず起きます。

  • 承認者が出張や休暇で不在
  • 急ぎで、当日中に決めたい
  • 承認者本人が申請者になる

決めていないと、現場が独自に回避します。

「部長が不在なので進めておきました」が当たり前になれば、仕組みは形だけになります。

代理承認、事後承認の範囲と記録の残し方、上位者への振り替え。この3つを設計の段階で決めます。

SuiteApprovalsには、承認の権限を委任する仕組みもあります(出典:Oracle NetSuite公式ヘルプ、2026年9月確認)。

職務分掌と、SuiteScriptが要る場面

承認の流れが「処理の順番」を決めるなら、職務分掌は「誰が何をできるか」を決めます。

流れだけ整えても、権限の設計が伴わなければ統制は効きません。

同じ人が自分で申請し、自分で承認できてしまう。

これでは、不正や誤りを止められません。

NetSuiteでは、ロール(役割)ごとに権限を細かく決め、起票と承認を分けます。

設計の考え方は、NetSuiteの権限・ロール設計ベストプラクティスで扱っています。

承認の流れの大半は、SuiteFlowの画面の操作で作れます。

SuiteScript(NetSuiteの開発言語)が要るのは、SuiteFlowで表しきれない複雑な処理や、外部のシステムとの連携が絡む場合です。

境目の考え方は、NetSuiteのカスタマイズ完全ガイドをご覧ください。

判断の物差し|NetSuiteの中で承認を回すか

中で回すのが合うのは、次のような会社です。

  • 承認の後に、発注・支払・仕訳までつなげたい
  • 監査や上場の準備で、承認の記録を取引と一緒に残したい
  • 申請の種類が10種類程度に収まる

別の方法を考えてよい場合もあります。

  • 申請が数十種類あり、様式が部署ごとに違う → 稟議の専用サービスとつなぐ
  • 取引が少なく、承認者も1〜2名 → いまはメールと記録の表で足りることもある
  • ERPを入れ替える段階で、小さく始めたい → Odooの承認アプリなどと比べる

条件と向く方法を対応させると、次のとおりです。

NetSuiteの中で承認を回すか:逆引き 承認の後に発注・支払・仕訳までつなげたいなら中で回す。申請が数十種類なら専用サービスとつなぎ、取引が少なければメールと記録の表、小さく始めたいならOdooの承認アプリなどと比べる。 こうしたいなら、この方法 承認の後に発注・支払・ 仕訳までつなげたい NetSuiteの 中で回す 申請が数十種類あり、 様式が部署ごとに違う 専用サービス とつなぐ 取引が少なく、 承認者も1〜2名 メールと 記録の表 ERPを入れ替える段階で、 小さく始めたい Odooの承認 アプリと比べる 分かれ目は、承認した後の処理まで 同じ場所でつなげたいかどうか
NetSuiteの中で承認を回すか:逆引き

製品の比べ方は、OdooとNetSuiteを徹底比較で扱っています。

これから入れる会社は、自社の金額の段階で承認者が切り替わるか、代理と差し戻しがどう見えるかをデモで見てください。

すでに回している会社は、年に1回、次の4点を見直します。

  • 申請の種類ごとの、却下と差し戻しの割合
  • 承認待ちが長く止まる申請の種類
  • 退職や異動で、承認者が空いたままの経路
  • 代理承認や事後承認が、日常になっていないか

よくある失敗3つ

失敗1:紙の様式と回覧の順番を、そのまま再現する

起きること:稟議書と同じ項目・同じ順番をシステムに作る。押印欄まで写したのに、現場は「裏の経路」で回し始める。

原因:紙の様式には、紙だから必要だった項目が含まれています。承認の実態を見ないまま、形だけを写していました。

避け方:現状の承認の流れを書き出し、「何を判断するために、誰が、何を見るか」から設計し直します。標準の機能に業務を合わせる考え方(Fit to Standard)も、先に決めておきます。

失敗2:承認を増やし、却下の出ない承認を放置する

起きること:念のためと段階を増やし、誰もが「とりあえず通す」状態になる。ほぼ全件が通る申請の種類があっても、誰も見直さない。

原因:承認は、増やすときだけ議論されます。減らす仕組みがありません。

避け方:金額や重要度で段階を絞ります。年に1回、申請の種類ごとに却下の割合を見ます。1年間ほぼ全件が通っている種類は、事後の記録で足りる可能性が高いものです。

失敗3:代理の承認者と権限を後回しにする

起きること:承認者が休むと承認が止まる。あるいは、申請者が自分で承認できてしまう。

原因:承認者を役職で固定し、不在のときの代役と権限を決めていなかった。

避け方:代理の承認者を最初から設計に入れ、ワークフローと権限の設計を同時に進めます。

ベンチャーネットならこう見る|承認の見える化→整理整頓→3つの選択

承認の相談で、ベンチャーネットが最初に開くのはSuiteFlowの画面ではありません。

いま社内で回っている承認の一覧です。

製品や方法が決まっていても、見える化からやり直します。

型1:見える化→整理整頓→Fit&Gap

  1. 承認の見える化:申請の種類、件数、承認者、却下の有無を現場に聞いて書き出す
  2. 整理整頓:3段階に当てはめ、やめる・まとめる・そろえる承認を決める
  3. Fit&Gap:残った承認を、Approval Routingと標準のSuiteFlowに照らし合わせる

Fit&Gapは、業務と機能の合う・合わないを一つずつ見る作業です。

2段目で承認を減らしておけば、3段目で照らし合わせる数も減ります。

型2:標準に合わせる/開発する/残す

標準で収まらない承認は、次の3つから選びます。

  • 標準に合わせる:経路を単純にし、承認限度額と標準のワークフローで回す
  • 開発する:汎用の申請や複雑な経路を、カスタムのSuiteFlowやアドオン開発(NetSuiteリブート)で作る
  • 残す:数十種類の様式がある稟議は、専用サービスに残して結果だけを戻す
ベンチャーネットの進め方:見える化→整理整頓→Fit&Gap→3つの選択 業務の見える化、整理整頓、NetSuite標準機能とのFit&Gap、そして標準に合わせる・開発する・残すの3択で決める。 ベンチャーネットの進め方業務の見える化いまの業務フローを現場に聞いて描く整理整頓やめる・まとめる・そろえる業務を決めるFit&GapNetSuiteの標準機能と照らし合わせる3つの選択標準に合わせる/開発する/残す製品が決まっていても、見える化から始める
ベンチャーネットの進め方:見える化→整理整頓→Fit&Gap→3つの選択

新しい機能は、順次加わります。

2026.1では、仕訳の承認の流れを整える機能が紹介されています(出典:Oracle NetSuite公式サイト、2026年9月確認)。

日本での提供は、アカウントの担当に確認してください。

承認の要件を伺うのは、営業ではなく導入コンサルタントです。

伝言を挟まないので、「なぜこの承認が要るのか」をその場で聞き返せます。

承認の手間のうち、AIや自動化で消せるものの例はNetSuiteあるある15選にあります。

今日できること|承認の棚卸し表を作る

いま社内で回っている承認を、次の表に書き出してみてください。

申請の種類月の件数・承認者の数この1年の却下3段階のどれか
(例)消耗品の購入40件・2名なし承認しない候補

最後の列で「承認しない」「上長1名」に移せるものが見つかれば、それだけで待ち時間が減ります。

表ができたら、業務の承認と汎用の申請に色分けしておきます。

第3章の設定の順番は、この表から始まります。

よくある質問

Q1. 承認ワークフローはプログラミングなしで作れますか?

はい。

SuiteFlowを使えば、画面の操作だけで作れます。

複雑な要件の場合だけ、SuiteScriptでの開発を検討します。

Q2. 金額によって承認者を変えられますか?

できます。

社員ごとに承認限度額を決めると、上限を超えた取引が、その金額を承認できる上位者へ自動で回ります。

Q3. 承認者が不在のときはどうなりますか?

代理の承認者を決められます。

SuiteFlowのカスタムのワークフローで、代理の承認者を設定できます。

担当者の休みで承認が止まることを防げます。

Q4. 内部統制(J-SOX)への対応に使えますか?

内部統制を支える土台になります。

承認の記録が自動で残り、職務分掌と組み合わせることで統制の土台が整います。

ただし対応の範囲は会社ごとに違うため、設計の段階での整理が欠かせません。

Q5. 日本独自の「稟議」にも対応できますか?

専用の機能はありませんが再現できます。

SuiteFlowのカスタムのワークフローで、金額・部門ごとの合議の流れを再現できます。

Q6. Odooの承認アプリ(Approvals)のような、汎用の申請アプリはありますか?

汎用の申請アプリは標準にはありません。

発注・経費・請求など、取引に紐づく承認は標準の機能で行えます。

どの取引にも属さない汎用の申請は、カスタムレコードとワークフローで作ります。

申請の種類が多く様式もさまざまな場合は、稟議の専用サービスとつなぐ方法もあります。

Q7. 承認を減らす基準はありますか?

止めて防げる損失と待たせる損失を比べます。

止めることで防げる損失のほうが大きい申請だけを、承認にかけます。

年に1回、却下の割合を見て、ほぼ全件が通る種類は事後の記録に移します。

まとめ

  • 承認の方法は、Approval Routing・標準のSuiteFlow・カスタムのSuiteFlow・SuiteApprovalsの4つ
  • 設定は、棚卸し→減らす判断→方法の選択→有効化→社員の登録→権限→例外→月末の試験の順
  • Approval Routingでは一度に25件まで。月末に集まる会社は、先に承認を減らす
  • 設計は何を承認しないかから。止めて防げる損失が大きい申請だけを承認にかける
  • 汎用の申請は、中に作るか、専用サービスとつなぐかを、承認した後の処理で選ぶ

月末に届く発注書の束は、仕組みだけでは薄くなりません。

承認を1枚の表に書き出し、外せるものを外す。

部長の机を軽くする作業は、そこから始まります。

もう少し詳しく知りたい方へ

承認の棚卸しから、SuiteFlowの作り込み、権限の設計まで、ご相談をお受けしています。

上場の準備の内部統制は、NetSuiteでIPOの内部統制を実現する方法もご覧ください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

持田 卓臣のアバター 持田 卓臣 株式会社ベンチャーネット代表取締役

持田 卓臣(もちだ たくおみ)
株式会社ベンチャーネット 代表取締役

ヒューレット・パッカード社でITコンサルタントとして従事した後、2005年に株式会社ベンチャーネットを設立。
Oracle NetSuite Solution Provider Partner として、中堅・中小企業向けクラウドERP「NetSuite」の導入・運用支援を提供しています。
SEO・広告・SNS・ウェブ・MA・SFAと一気通貫で培ってきたデジタルマーケティング領域の業務知見を活かし、NetSuiteを軸とした経営DXを支援しています。
著書:『普通のサラリーマンでもすごいチームと始められる レバレッジ起業「バーチャル社員」があなたを救う』(KADOKAWA、2020年)

コメント

コメント一覧 (4件)

目次