支払業務の集約における実務上の検討ポイント

近年、口座振込や電子手形をはじめとした「支払業務」を1つの拠点へ集約する企業が増えています。例えば、人員不足、拠点の統廃合、基幹システムの刷新を背景に、各拠点の支払処理を本社やセンターに集約する企業も少なくありません。

このような取り組みにより、業務の効率化や振込手数料の削減が期待されます。しかしながら、期待どおりの成果を上げるためには、業務要件やシステム要件の検討の際に生じ得る以下のような実務的な課題が解消されている必要があります。

• 業務：集約先が各拠点の支払の締めの完了を把握できなければ、支払処理を開始できない
• システム：支払金額の合算により、支払通知書と実際の振込金額が一致しなくなる

そこで今回は、支払業務を集約するメリットを明確化するとともに、そのメリットを享受するために必要な実務上の検討ポイントを整理します。

前述のとおり、支払業務を1つの拠点に集約する取り組みは、主に業務の効率化とコスト削減を目的として検討されます。例えば、各拠点の支払処理を本社に集中させることで、各拠点の担当者間の作業の重複を解消（効率化）し、各拠点担当者の負担を軽減することができます。また、集約先が振込をまとめて実行することから、振込手数料の削減（コスト削減）につながる点もメリットの一つです。

施策のメリットを十分に享受するためには、本社担当者や各拠点担当者が実際に動ける粒度にまで業務の詳細を詰めていくことが不可欠です。しかしながら、業務のあるべき姿を定義することは容易ではありません。定義にあたっては、対象業務の全体像を整理したうえで検討課題の優先順位を定め、めざすべき業務の解像度を段階的に高めていくことが重要です。
本稿では実務上の主な検討ポイントを以下の3つのステップで解説します。

1. 集約対象となる“業務”の検討
2. 集約対象となる“支払”の検討
3. 支払の“集約方法”の検討

まずは、どこまでを本社の業務として集約するかによって、めざすべき業務の姿が変わることを認識しておきましょう。例えば、支払予定の変更や支払の締めを従来どおり各拠点で行う場合、当然、本社は各拠点の締め作業の完了を把握できなければ支払処理を開始できません。つまり、各拠点担当者からの報告義務の徹底、または、本社担当者が能動的に締め作業の完了を確認できる仕組みの構築など、各拠点の締め作業が完了したことを把握する方法をあらかじめ決めておく必要があります。

• 支払予定の変更（支払日の変更、支払控除、支払方法の変更）
• 支払の締め
• 支払通知書の作成・送付
• 振込の支払処理
• 電子手形の支払処理

前述の検討を網羅的に行うためには、支払に至るまでの業務フローを作成することがポイントです。業務フローにより業務の流れを可視化すれば、役割分担や本社の関与するタイミングが見えてきます。この時、作成した業務フローに流れが途切れる箇所があれば、何が不足しているかを整理し、当該の不足を担当者による運用で補うのか、仕組みで補うのかを検討すると良いでしょう。

次に、どの支払を集約の対象とするのかを検討しなければいけません。すべての支払を無条件に集約してしまうと、業務負荷が本社に集中し支払処理自体が滞るおそれがあります。そのため、件数の多い支払を中心に効果と負担のバランスがとれる範囲を見極めることが求められます。例えば、月末の国内振込だけを本社に集約するということが考えられます。

集約の対象範囲が曖昧なままでは、本社と各拠点の運用ミスによって二重支払が発生するおそれがあります。これを回避するためには、システム上で判定できる条件を切り口に集約対象の整理を行うことが有効な場合があります。
主な切り口は次のようなものです。

• A　画面やインターフェイスの入力経路による区別
  例：非定時払いの専用画面から入力されたものは対象外
• B　支払先マスタの“項目値”による区別
  例：支払方法が電子手形の支払先は対象外

• 支払日（翌月15日、翌月25日、翌月末、翌々月末）
• 手数料負担区分（当社負担、相手負担）
• 支払方法（現金、FB、電子手形）
• 決済通貨（JPY、USD、GBP）
• 全銀協銀行コード
• 全銀協銀行支店コード
• 口座種類（普通、当座）
• 口座番号

集約対象を決めた後は、支払データをどの単位で集約するかを検討しましょう。
振込データについては、振込手数料の削減を図るためにも口座番号単位で集約する方法が考えられます。一方、支払通知書は口座番号のほかに宛先住所にも影響を受けるため、振込データと支払通知書が同じ単位で集約できるとは限りません。
例えば、次のケースでは、同一口座への支払であっても支払通知書は口座番号単位で集約せず、各支払通知書に合算後の金額（300円）を併記する対応が考えられます。

帳票出力を前提とした場合、集約条件の項目を検討する必要があります。
これにより必要なシステム要件が見えてきます。
集約条件となる主な項目は次のとおりです。

• A　振込データや支払通知書に出力される項目を基準とした集約
  例：口座番号で集約、支払先の電子手形の識別番号で集約
• B　支払先マスタの項目を基準とした集約
  例：手数料負担区分で集約し、当社負担と相手負担の支払は口座番号が同じでもまとめない

とくにBは帳票には表示されない情報であり、検討から漏れやすいため注意が必要です。

支払業務を集約すれば業務効率化や振込手数料の削減が期待できます。しかし、一見単純な施策でも、実際に業務を組み立てていくと想定外の課題が浮上する可能性があることを理解しておかなければいけません。
とくに落とし穴になりやすいのは、業務担当者が必要と考える情報と、システムが保持しているデータの項目や粒度がかみ合っていないケースです。業務とシステムの両方を理解したうえで要件を整理できるかどうかが、その後の安定した運用やトラブルの発生可能性を大きく左右します。