同じ請求を二重に支払わせない、支払実行の承認

月末の27日です。自動車OEM向けに部品を供給する静岡の中堅精密部品メーカー、社員約280名の経理チームが月末の支払バッチを処理しています。担当者が仕入先の請求書をまとめて選択し、支払ボタンを押すと、銀行振込が始まります。その日の午後、同じ仕入先から別の請求書について問い合わせがありました。担当者が画面を開くと、その請求書はすでに支払済みの表示でしたが、念のためもう一度支払いました。これに気付くのは2か月後の仕入先との照合のときです。180万円の重複支払は、すでに取り戻せないところまで進んでいました。

この光景は、怠慢がなくても起きます。必要なのは、資金が実際に動く前に立ちはだかる統制ゲートのない手作業の支払実行だけです。基幹システムは根本原因を取り除きます。独立した承認者が金額と取引先、そして未払済みであることを確認するまで、支払は会社から一円も出ていきません。本記事では、資金を守る支払実行承認ワークフロー、監査証跡が実際に記録する内容、そして現時点で構築済みの統制と開発ロードマップ上の自動銀行実行との間にある正直な境界について解説します。

二重支払と誤送金が資金保護の課題である理由

重複支払や誤った支払がニュースになることはほぼありません。しかし、それはバックオフィスの中で最も大きく回避可能な損失の一つです。コストは一件のミスそのものではありません。ミスが見えないことです。一度多く払いすぎた仕入先が、自発的に電話をかけて返金することはまずありません。誤った取引先に送金された支払は、法務費用や銀行の取消手数料が積み上がるなかで数か月間未回収のまま置かれることがあります。金額の誤った支払は、誰かが照合するまで静かに帳簿を歪ませ続けます。

損失をほぼ不可避にする条件が三つあります。1つ目は職務分掌がないことです。支払を決める人、銀行振込を入力する人、仕訳を記録する人が、誰にも見られることなく三つとも同じ人で済ませられます。2つ目は、承認内容の確定記録がないことです。「承認」と書かれたメールは、編集も削除も誤送信もできます。3つ目は過去の支払に対するシステムチェックがないことです。担当者は記憶か、更新されているかどうか分からないスプレッドシートに頼るしかありません。

基幹システムはこの三つの条件を一度に取り除きます。資金を解放する人は支払バッチを作った人と別でなければなりません。すべての承認はタイムスタンプ、承認者、正確な金額とともに固定されます。そして、すでに解放済みのものを二度支払うことをシステムが拒否します。なぜなら、何がすでに解放されたかを追跡しているからです。

-> 関連：メーカーが走らせる60の承認ワークフローと、一つのERPにまとめるROI

支払実行承認ワークフローが実際にできること

ここでお話しするのは、請求書をスキャンしてうまく払われることを祈る、という話ではありません。基幹システムに組み込まれた本物の支払実行承認ワークフローは、何かが動く前にクリアしなければならない、設定可能な多段階承認の背後に資金の解放を置きます。ワークフローエンジンを読むと、現時点で本当に実装されている機能と、正直にロードマップ上にあるものが見えてきます。

自社の権限規程に合う多段階承認

支払バッチは、担当者がまとめ終わった瞬間に出ていくわけではありません。ワークフローはバッチを定義された承認ルートに紐付け、ステータスは下書き、提出、承認と流れ、1円でも動く前にすべてがクリアされます。小口の請求書が並ぶルーティンバッチであれば、マネージャーの承認1回で十分かもしれません。新規取引先への大型支払であれば、ルートは異なる役職からの独立した承認を2件や3件要求できます。

ルーティングは名前に固定されていません。承認は役職、ポジション、部門宛てにルーティングされるため、組織改編や人員異動を生き延びます。担当者が退職しても支払ワークフローは壊れません。そのポジションの次の人が承認権限を自動的に引き継ぐからです。これが、統制を特定の人の習慣に依存しない、持続可能なものにします。

バイパスできない職務分掌

支払実行における最も重要な統制は、支払を準備する人が同時に承認できないことです。ワークフローエンジンはこれを構造として強制します。準備者がバッチを提出し、承認者は別のステップにいる別の人です。一人の社員が作成と資金解放の両方をこなせる近道はありません。

より大型でリスクの高い支払では、ルートは委員会決裁を要求できます。閾値ルールにより、5人の承認者のうち少なくとも3人がクリアしなければ支払が解放されない、と設定できます。これが、大型・異常・不正のいずれであっても、単独の人物が支払を押し通すのを防ぐ統制です。J-SOXや内部統制のレビューで監査人が探すのと同じ構造であり、承認フローの中に後付けではなく最初から組み込まれています。

すべての支払がどこで止まっているかを可視化

誰かの受信箱で1週間止まった支払バッチは、早期支払割引を逃すか、支払期日を超過する可能性があります。ワークフローは、すべての申請がどこで、どのステップで、誰のところで止まっているかを正確に示します。支払が進むのを見守る必要がある関係者は、承認者でなくてもウォッチャーとして申請を追えます。

承認は担当役員の海外出張でも止まりません。ワークフローは安全な代理承認をサポートし、不在の承認者が副担当にクリアを委ねられます。ただし高リスク案件には復帰後の再承認が必須になります。営業日ベースのSLA期限が、一人の不在な決裁者の背後で支払を停滞させません。

承認内容を正確に固定したスナップショット

これが、統制を防御可能にする監査証跡です。承認者が支払バッチをクリアすると、ワークフローは何が承認されたか、すなわち請求書、金額、取引先、合計額のスナップショットを固定します。そのスナップショットは後から編集できません。承認後に誰かが請求書を変更した場合、システムはその変更を記録し、支払が動く前に改めて承認を要求できます。

将来のどんな問い合わせに対しても、社内であれ取締役会であれ外部監査人であれ、答えはすでにそこにあります。誰が、いつ、どの版の請求書に対して、どの権限で支払を承認したか。紙のハンコ台帳はこれらの問いに答えられません。メールのスレッドは一部にしか、しかも不十分に答えられます。固定された承認スナップショットは、すべての問いに即座に答えます。

-> 関連：監査に耐える承認ワークフロー

現時点での正直な境界

現金の統制を過剰に売り込むことは危険なため、この部分が最も重要です。支払実行承認ワークフロー、多段階承認、職務分掌、固定された監査証跡は、すべて構築済みで本日稼働しています。支払が解放される前にクリアしなければならない統制ゲートは本物であり、本番環境にあります。

現時点で構築されていないのは、銀行や支払システムにおける支払の自動実行です。承認が完了すると、ワークフローはその支払が動ける状態になったことを確認します。しかし、それ自体が銀行に振込ファイルを送ったり、決済ゲートウェイを叩いたりすることはありません。承認済みの支払を自動実行する書き戻しはロードマップ上にあります。本日、クリアされた承認はチームに「統制が通り、支払を解放しても安全である」ことを伝えます。実際の銀行振込は引き続き財務チームが確認します。それはまさに望むべき職務分掌です。

この境界について正確に伝えることがポイントです。重複支払や誤った支払を防ぐ統制、誰が何を承認したかを証明する監査証跡、そして単独の人物がバイパスできない職務分掌は手に入ります。一方で、完全な手放しの自動銀行実行はまだ手に入らず、それは約束されるべきものでもありません。

事例：静岡の中堅精密部品メーカー

自動車と産業機械のOEMに部品を供給する、静岡の中堅精密部品メーカーを想像してください。社員数は約280名。毎月、経理チームは約600件、合計で約3億2,000万円の仕入先請求書を処理します。基幹システム導入前、支払実行は次のように動いていました。担当者がスプレッドシートで支払一覧を作り、マネージャーが合計額をちらりと見てメールで「OK」と返し、担当者が銀行振込を一件ずつ入力する、という流れです。

失敗のパターンは予測可能でした。仕入先から電話があったとき、担当者がすでに解放したかを思い出せないと、同じ請求書が二重に支払われることがありました。古い行から銀行口座がコピー＆ペーストされると、誤った取引先に送金されることが時折ありました。そして監査の途中で、ある420万円の支払を誰が承認したのかと外部会計士に聞かれたとき、確実に答えられる人はいませんでした。承認は後から削除された1行のメールでした。

新しい流れでは、経理チームは基幹システムの中で支払バッチを組み、そのバッチは動く前に承認ワークフローに紐付けられます。閾値を超えるバッチは、異なる役職からの独立した承認を2件要求し、準備者がそのうちの1人になることは構造上許されません。承認者は請求書、取引先、金額の完全な一覧を見て、クリアした瞬間にそれをスナップショットとして固定します。システムはすでに支払済みの請求書の解放を拒否するため、重複は記憶ではなく構造として不可能です。外部会計士があの420万円の支払を誰が承認したかと尋ねるとき、答えはタイムスタンプ付きの、承認者と権限、そして承認された正確な版の請求書を含む記録になります。

実際の銀行振込は、承認がクリアされた時点で引き続き財務チームが確認します。自動支払実行はロードマップ上にあるからです。それは正しい設計です。重複支払と誤った支払を止める統制は承認ゲートであり、そのゲートは稼働しています。

時間削減を超えて、なぜこれが重要なのか

メリットは単に回避できた損失だけではありません。もっとも、その損失も実在し、1件あたり数百万円に達することもあります。2024年のTOKIUM調査では、90.4%の社員が未だ紙のレシートを提出し、経費申請の完全電子化率は7.0%にとどまっています。同様の紙への依存は、ほとんどの中堅企業の支払実行にも及んでいます。支払一覧がスプレッドシートにあり、承認がメールにあるとき、統制は直近の担当者がチェックし忘れなかったかどうかに尽きます。

監査人が特に気にする内部統制の側面もあります。支払の準備と承認の間の職務分掌は、J-SOXや内部統制のレビュー担当者が最初にテストする項目の一つです。役割ベースのルーティングと、クリアされた内容の正確な版を記録した固定承認スナップショットは、慌てることなくそのテストを通過する証拠です。監査人が来てから統制を再構築するのではなく、最初から支払フローの中に組み込んだことになります。

最後に、後継者育成の問題があります。日本の中堅製造業の多くは、支払プロセス全体を一人のベテラン経理担当者の頭の中に抱えています。どの請求書に二人目の印鑑が要るかといった暗黙のルールも含めてです。その人が定年を迎えるとき、統制も一緒に去っていきます。基幹システムはルーティング、閾値、監査証跡を記録に残すため、次の世代が受け継ぐのは習慣の集合ではなく、統制されたプロセスになります。

-> 関連：買掛金管理：支払期日を予測可能なキャッシュフローに

よくある質問

銀行振込を自動で送らないなら、承認は実際に何をするのですか？

損失防止のために最も重要な部分を担います。承認ゲートは、資金が動く前に、正しい人々が金額、取引先、支払一覧を確認したことを確定させます。職務分掌を強制し、監査証跡を固定します。自動銀行実行はキー操作を減らしますが、統制は追加しません。Kikan System はこの承認ゲートを今日提供し、最大2ユーザーまで無料、クレジットカード不要で二重支払と誤送金を提出前に止められます。統制は承認であり、それは今日構築済みです。

大型の支払にだけ二次承認を要求できますか？

はい。ここで閾値ルーティングが真価を発揮します。小口の請求書が並ぶルーティンバッチは、マネージャーの承認1回で済むかもしれません。設定額を超えるバッチや新規取引先への大型支払は、独立した承認を2件や3件、あるいは5人の承認者のうち3人以上がクリアしなければならない委員会決裁を要求できます。閾値とルーティングは、たまたまデスクにいる人ではなくワークフロールールと一緒に動きます。

同じ請求書が2回提出された場合、システムはどうやって二重支払を止めるのですか？

すでに承認され、解放されたものを追跡しているからです。請求書が支払バッチに入ると、ワークフローはそれがすでにクリアされた支払の一部だったかを知っています。担当者がもう一度追加しようとしても、バッチが提出される前にブロックされます。重複は人の記憶ではなく、システムによって防がれます。

承認後に承認者が請求書を変更したらどうなりますか？

固定スナップショットは、クリアされた瞬間に承認された内容を正確に記録します。その後に請求書が変更されると、ワークフローはその変更を記録し、支払が動く前に改めて承認を要求できます。監査証跡は常に実際に承認された版を反映するため、承認されたものと支払われたものの間にズレは生じません。

重要なポイント

二重支払を止めることは、注意力の問題ではありません。資金が動く前にクリアしなければならない統制ゲートの問題です。基幹システムはすべての支払を多段階承認の背後に置き、準備者と承認者の間の職務分掌を強制し、クリアされた内容を正確にスナップショットとして固定します。承認の統制は今日構築され稼働しています。銀行での自動支払実行はロードマップ上にあります。そしてそれこそが正しい順序です。資金を守るのは統制だからです。

Kikan System で始める

もし二重支払や誤った取引先への送金が月末のあなたを悩ませているなら、Kikan System をご覧ください。支払実行承認ワークフローは、すべての支払を多段階承認と職務分掌の背後に置き、誰が何を承認したかを固定された監査証跡として残します。2ユーザーまで無料、カード不要のフリープランですぐに始められます。/#get-startedからご開始ください。