FBデータは支払予定の「入力成果物」。会社が承認し、銀行結果まで照合する

支払母集団・検収

FBデータ作成と振込の責任分離を安定させるには、支払母集団・検収の正本が必要です。「請求書受領だけで振込対象にする」が起きる場面を先に示し、契約、注文、検収、請求、支払条件、保留、相殺、源泉の参照先を一つに定めます。対応策は「会社承認済み支払予定を正本にする」です。処理済みの内容と確認待ちを支払予定・検収・承認表の同じ行で管理します。会社が取引事実と支払可否を承認する。

完了条件は、支払母集団・検収の結果と未完了を説明できることです。支払母集団・検収の作成者とは別の確認者が証拠を見て判定します。支払母集団・検収は、決めた手順で進む項目と判断が必要な項目に分離します。支払母集団・検収で判断が必要な項目には、処理を止める条件と質問先を付けます。支払予定・検収・承認表は請求受領時とFB締め前に確認する。

支払母集団・検収の条件を変更した場合は適用開始日と確認証拠を残し、過去の条件と区別します。

新規・変更口座

FBデータ作成と振込の責任分離では、新規・変更口座を作業、確認、承認に分けます。取引先、旧口座、新口座、名義、適用日、別経路確認、承認の回答者を先に決めることで、「請求書の口座をそのまま使う」を避けます。最初に「通常支払から隔離して別経路確認する」を行い、判断が必要な点だけを振込先マスタ変更台帳へ切り出します。会社の別担当が口座変更を二者承認する。

完了時は「新規・変更口座の結果と未完了を説明できる」を証拠で確かめます。新規・変更口座は金額や件数に加え、扱う権限と判断待ちの長さも確認します。新規・変更口座で影響の大きい例外ほど、停止条件を具体的にします。振込先マスタ変更台帳は変更時とFB作成前に確認する。新規・変更口座の担当、代理承認、期限が変わった項目を先頭に出し、引継ぎ後も同じ結果になるか試します。

FB仕様・銀行テスト

FB仕様・銀行テストはFBデータ作成と振込の責任分離の前提になります。全銀、銀行独自、文字、桁、レコード、日付、依頼人、合計を確定済みと確認待ちに分ければ、「前回ファイルを無条件で流用する」を早い段階で防げます。実務では「銀行仕様の版とテスト結果を固定する」を行います。結果をFB仕様・テスト台帳へ戻し、口頭の補足も判断材料として残します。会社管理者が仕様と適用日を承認する。

作業終了時は「FB仕様・銀行テストの結果と未完了を説明できる」まで到達したかを承認者が確認します。FB仕様・銀行テストの負荷は、対象量だけでなく例外数、回答待ち、締切までの余裕を含めて見積もります。FB仕様・テスト台帳は導入、銀行変更、仕様変更時に確認する。FB仕様・銀行テストの引継ぎでは、前回から変わった条件と残っている確認事項を先に共有します。

FB作成・差分

FB作成・差分の日程は、FBデータ作成と振込の責任分離の後工程から逆算します。バッチ、請求ID、受取人、口座、金額、手数料、摘要、重複の期限と利用目的を並べ、「承認前の資料を推測で補う」を防ぎます。運用開始後は「承認済み一覧から自動・手動差分を出す」を実施し、FB作成・差分表に提出、確認、差戻し、完了の時刻を残します。作成者以外が件数・合計・例外を確認する。

そのうえで、「FB作成・差分の結果と未完了を説明できる」を月次の判定基準にします。FB作成・差分を改善する際は、実際の処理時間と資料・承認を待った時間を分けます。FB作成・差分で発生する待ち時間の元が、直すべき工程です。FB作成・差分表は各バッチ作成時に確認する。FB作成・差分の期限を越えた項目には影響先と業務を再開する条件を記載します。

受渡・改ざん検知

FBデータ作成と振込の責任分離では、まず受渡・改ざん検知を確認します。「メール添付を正本にする」を避けるため、ファイル名、バッチID、版、作成日時、件数、合計、ハッシュ、権限を対象、確認待ち、対象外に分けます。着手時は「期限付き共有と照合値を使う」を行い、FB受渡・ハッシュ台帳に根拠、担当、期限を記録します。会社が受領ファイルの版と照合値を確認する。

この方針どおりに処理し、最後に「受渡・改ざん検知の結果と未完了を説明できる」を確かめます。受渡・改ざん検知は件数だけで評価せず、処理待ちと判断待ちを分けて測ります。受渡・改ざん検知で人手や承認時間が必要な箇所を見極めるためです。FB受渡・ハッシュ台帳は受渡時とアップロード前に確認する。変更理由と承認者を残し、次回は「受渡・改ざん検知の結果と未完了を説明できる」を同じ証拠から再現できるか確認します。

IBアップロード

FBデータ作成と振込の責任分離を安定させるには、IBアップロードの正本が必要です。「代行先へ共用管理者IDを渡す」が起きる場面を先に示し、契約者、管理者、申請、承認、実行、ID、端末、MFA、ログの参照先を一つに定めます。対応策は「会社IDで申請し最小権限を使う」です。処理済みの内容と確認待ちをIB権限・アップロード記録の同じ行で管理します。会社管理者が利用者と端末を承認する。

完了条件は、IBアップロードの結果と未完了を説明できることです。IBアップロードの作成者とは別の確認者が証拠を見て判定します。IBアップロードは、決めた手順で進む項目と判断が必要な項目に分離します。IBアップロードで判断が必要な項目には、処理を止める条件と質問先を付けます。IB権限・アップロード記録はアップロード時と権限変更時に確認する。

IBアップロードの条件を変更した場合は適用開始日と確認証拠を残し、過去の条件と区別します。

銀行承認・実行

FBデータ作成と振込の責任分離では、銀行承認・実行を作業、確認、承認に分けます。件数、合計、高額、新規、変更、指定日、残高、限度額の回答者を先に決めることで、「作成者が同じIDで最終承認する」を避けます。最初に「別担当が銀行画面で再確認する」を行い、判断が必要な点だけを銀行承認・実行ログへ切り出します。代表者等が資金移動を最終承認する。完了時は「銀行承認・実行の結果と未完了を説明できる」を証拠で確かめます。

銀行承認・実行は金額や件数に加え、扱う権限と判断待ちの長さも確認します。銀行承認・実行で影響の大きい例外ほど、停止条件を具体的にします。銀行承認・実行ログは実行前と指定日に確認する。銀行承認・実行の担当、代理承認、期限が変わった項目を先頭に出し、引継ぎ後も同じ結果になるか試します。

再作成・版管理

再作成・版管理はFBデータ作成と振込の責任分離の前提になります。修正理由、旧版、新版、差分、取消、再承認、配布先、削除を確定済みと確認待ちに分ければ、「修正後も旧承認を流用する」を早い段階で防げます。実務では「再作成ごとに新しいバッチIDを付ける」を行います。結果をFB版・再作成履歴へ戻し、口頭の補足も判断材料として残します。会社が旧版無効と新版を再承認する。

作業終了時は「再作成・版管理の結果と未完了を説明できる」まで到達したかを承認者が確認します。再作成・版管理の負荷は、対象量だけでなく例外数、回答待ち、締切までの余裕を含めて見積もります。FB版・再作成履歴は修正ごとに閉じる。再作成・版管理の引継ぎでは、前回から変わった条件と残っている確認事項を先に共有します。

銀行結果・エラー

銀行結果・エラーの日程は、FBデータ作成と振込の責任分離の後工程から逆算します。受付、実行、エラー、残高、名義、口座、取消、組戻し、受領の期限と利用目的を並べ、「受付済みを実行済みとみなす」を防ぎます。運用開始後は「銀行結果をバッチと請求IDへ戻す」を実施し、銀行結果・エラー対応表に提出、確認、差戻し、完了の時刻を残します。会社が失敗・組戻しの再対応を承認する。

そのうえで、「銀行結果・エラーの結果と未完了を説明できる」を月次の判定基準にします。銀行結果・エラーを改善する際は、実際の処理時間と資料・承認を待った時間を分けます。銀行結果・エラーで発生する待ち時間の元が、直すべき工程です。銀行結果・エラー対応表は実行日と翌営業日に確認する。銀行結果・エラーの期限を越えた項目には影響先と業務を再開する条件を記載します。

会計消込・保管・終了

FBデータ作成と振込の責任分離では、まず会計消込・保管・終了を確認します。「FB作成時に支払済み計上する」を避けるため、銀行結果、未払、預金、手数料、証憑、ログ、保存、返却、削除を対象、確認待ち、対象外に分けます。着手時は「実行済みだけ消込し会社へデータを戻す」を行い、FB・銀行・会計照合表に根拠、担当、期限を記録します。会社・税理士等が会計処理と保管を確認する。

この方針どおりに処理し、最後に「会計消込・保管・終了の結果と未完了を説明できる」を確かめます。会計消込・保管・終了は件数だけで評価せず、処理待ちと判断待ちを分けて測ります。会計消込・保管・終了で人手や承認時間が必要な箇所を見極めるためです。FB・銀行・会計照合表は月次締めと契約終了時に確認する。変更理由と承認者を残し、次回は「会計消込・保管・終了の結果と未完了を説明できる」を同じ証拠から再現できるか確認します。