支払予定日を入れ始めると、次に必ず出てくる要求があります。
「この支払、本当に今払っていい?」
「誰がGO出したのか分からないのが怖い」
今回は、
支払予定日を判断軸にした支払承認フローを
NetSuiteで実際に作って、どう使えるかを試しました。
今回の実験テーマ
-
支払請求書のどこで承認させるか
-
支払予定日をどう判断に使うか
-
承認後、何ができて何ができなくなるか
-
現実的な運用設計
前提整理(今回の設計思想)
承認の対象
-
❌ 支払(Bill Payment)
-
✅ 支払請求書(Vendor Bill)
👉
払う前に止めたい
承認の判断材料
-
支払予定日
-
金額
-
仕入先
① なぜ「支払」ではなく「支払請求書」を承認するのか
支払承認だと起きる問題
-
まとめ払いだと判断が遅れる
-
一部支払と相性が悪い
-
承認時点ですでに実績扱い
👉
遅い
支払請求書承認のメリット
-
早い段階で止められる
-
予定日単位で判断できる
-
修正が簡単
👉
統制しやすい
② 承認フローのルールを決めた
今回のルール
| 条件 | 承認要否 |
|---|---|
| 支払予定日が7日以内 | 承認必須 |
| 金額が¥100,000以上 | 承認必須 |
| それ以外 | 自動承認 |
👉
「いつ払うか」と「いくら払うか」
③ 承認ステータスを作成
カスタムステータス例
-
未申請
-
承認申請中
-
承認済
-
差戻し
👉
支払請求書が主語
④ ワークフローを組んでみた
トリガー
-
支払請求書の保存時
-
または支払予定日変更時
判定条件
-
支払予定日 ≤ 今日+7日
または -
金額 ≥ ¥100,000
アクション
-
承認申請
-
承認者に通知
⑤ 承認中の挙動を確認
実験
-
ステータス:承認申請中
-
支払予定日:5日後
結果
-
❌ 支払作成できない
-
❌ 金額修正できない
-
❌ 削除できない
👉
止まる
⑥ 承認されたらどうなる?
承認後
-
ステータス:承認済
-
支払作成:可能
支払予定日を変更したら?
-
再度承認フローが走る
👉
予定日変更=判断やり直し
⑦ 差戻しされた場合
実験
-
承認者が差戻し
結果
-
ステータス:差戻し
-
修正可能
-
再申請が必要
👉
ちゃんと会話が生まれる
⑧ 実務でハマったポイント
❌ 承認条件を複雑にしすぎる
👉 誰も理解できない
❌ 全件承認
👉 形骸化
❌ 支払段階で承認
👉 遅すぎる
⑨ このフローがハマる会社
-
支払が月末集中
-
キャッシュが潤沢ではない
-
経理と決裁者が分かれている
👉
「判断を前倒し」したい会社
まとめ
-
承認は支払請求書で行う
-
支払予定日は承認判断の軸になる
-
予定日変更=再承認が安全
-
支払前に止められる設計が正解
NetSuiteは
支払を「作業」ではなく「判断」に変えられるERP。