支払承認フローを作ると、次に必ずこう聞かれます。
「これ、証跡として使えるの？」
「監査のとき、何を見せればいい？」
今回は、
NetSuiteに残る「支払承認ログ」を、
監査対応で実際にどう使えるのかを実験してみました。
今回の実験テーマ
-
支払承認ログはどこに残るのか
-
監査で「使えるログ」「弱いログ」
-
よくあるNG回答
-
監査に耐える設計のコツ
① 監査が見たいのは「承認した事実」ではない
まず前提。
監査が本当に知りたいのは：
-
誰が
-
いつ
-
何を根拠に
-
どの金額・どの支払予定日を
-
承認したか
👉
「Yes/No」では足りない
② NetSuiteに残る承認ログの種類
ログ① システムノート（System Notes）
見える内容
-
承認ステータス変更
-
変更者
-
変更日時
-
変更前 / 変更後
👉
最低限の証跡
ログ② ワークフロー履歴
見える内容
-
承認リクエスト発生
-
承認・差戻しアクション
-
承認者
👉
「プロセス」を説明できる
ログ③ 支払請求書の項目履歴
-
金額
-
支払予定日
-
仕入先
👉
承認時点の前提条件
③ 実際に監査対応で使ってみた
想定質問
「この¥150,000の支払、誰が承認しました？」
出したもの
-
支払請求書画面
-
システムノート
-
承認日時点の金額・支払予定日
-
ワークフロー履歴
👉
即OK
④ 監査で詰むパターン
❌ 承認者だけ見せる
👉
-
「何を承認したか分からない」
❌ 最新状態だけ見せる
👉
-
「承認後に変えてない？」
❌ 口頭説明で済ませる
👉
-
「証跡は？」
⑤ 監査に耐える承認ログ設計
ポイント① 承認時スナップショットを残す
-
承認金額
-
承認時支払予定日
👉
後から変えられない項目
ポイント② 再承認の理由を残す
-
支払予定日変更
-
金額変更
👉
なぜ再承認になったか
ポイント③ 承認と支払の関係を説明できる
-
この承認 → この支払
👉
1対多でも追える
⑥ 支払と承認は別物として説明する
監査向けの言い方：
「承認は支払請求書単位で行い、
実際の支払は承認済請求書を元にまとめて実施しています」
👉
これが言えると強い
⑦ CSVや例外処理の説明も準備する
監査でよく聞かれる：
-
CSVインポート時は？
-
管理者操作は？
-
例外対応は？
👉
例外ルール＝統制ルール
まとめ
-
支払承認ログは監査で「使える」
-
見せるのは「承認＋前提条件＋履歴」
-
最新状態だけでは不十分
-
承認ログ設計＝監査設計
NetSuiteの承認フローは
監査対応のためにこそ真価を発揮する。
承認フローは、止めるための仕組みではなく、
「説明できる状態を作る仕組み」 だった。
