支払承認フローを作った直後は、だいたいこう思います。
「これで勝ちだ」
「もう勝手に払われることはない」
でも、運用を回し始めると
“普通にすり抜ける”事故が起きます。
今回は、
実際に起きやすい「承認フローすり抜けパターン」を
NetSuiteで再現してみたログです。
今回の実験テーマ
-
承認フローが効かない瞬間
-
なぜ止まらなかったのか
-
どう防ぐべきか
事故パターン① 承認後に支払予定日を戻す
やったこと
-
支払予定日：5日後 → 承認必須
-
承認済になる
-
支払予定日：30日後に変更
起きたこと
-
❌ 再承認されない（設計次第）
-
承認済のまま
👉
判断条件が消えたのに、履歴が残る
防止策
-
支払予定日変更＝必ず再承認
-
承認日時を記録
事故パターン② 承認後に金額だけ修正
やったこと
-
¥90,000 → 承認不要
-
承認済
-
¥150,000 に修正
起きたこと
-
承認ステータスがそのまま
-
支払作成可能
👉
金額が変わっても再判断されない
防止策
-
金額変更トリガーで承認リセット
-
変更前後金額を比較
事故パターン③ 一部支払で抜ける
やったこと
-
高額支払請求書を承認
-
少額だけ先に支払
-
残額を後日支払
起きたこと
-
後半支払時、再承認なし
👉
「承認は1回」の落とし穴
防止策
-
支払金額での承認も検討
-
支払請求書ではなく支払承認に切り替える（限定的）
事故パターン④ まとめ払いで混ざる
やったこと
-
承認済と未承認の請求書を同時選択
-
まとめて支払作成
起きたこと
-
承認済しか見てないつもりが
-
未承認も一緒に払われる
👉
一覧のチェックが甘い
防止策
-
承認済のみ支払対象に制限
-
検索条件で制御
事故パターン⑤ 権限が強すぎる
やったこと
-
経理に管理者ロール付与
-
ワークフロー制御を無視
起きたこと
-
承認なしで支払作成可能
👉
ERPあるある
防止策
-
管理者ロールを分離
-
支払権限を最小化
事故パターン⑥ CSVインポート
やったこと
-
支払請求書をCSVで一括登録
起きたこと
-
承認フロー未起動
-
即支払可能状態
👉
静かに一番危険
防止策
-
CSV後に強制承認ステータス
-
インポート専用ワークフロー
⑦ 事故は「機能」ではなく「隙間」で起きる
NetSuiteの承認フローは、
-
正常系：強い
-
例外系：素通りしがち
👉
人が考えない経路から抜ける
まとめ
-
承認フローは作っただけでは守れない
-
「変更」「一部」「まとめ」「権限」「CSV」が地雷
-
再承認トリガー設計が命
NetSuiteの承認は
“守りたいものを何度でも問い直す仕組み”。
