銀行連携の要件定義は、決まって同じ議題から始まる。従来の全銀協規定形式の固定長データで送るか、XML電文に切り替えるか。接続はファイル伝送か、それともAPIか。ホスト側の対応状況はどうか。この議論に二回か三回の会議を使い、方式が決まると要件定義は終わったことになる。そして稼働から数か月後、経理から同じ報告が上がってくる。入金明細は自動で取り込まれているが、消し込めない入金が積み上がって手作業が増えた、と。銀行とつないでも消込は速くならない。自動消込が使える手がかりは金額と振込依頼人名の二つしかなく、連携は手がかりの本数を増やさないからだ。 増えたのは経理の手元に届くデータ量だけで、判定できない入金は場所を変えて滞留する。
「銀行連携」は4本の別々の要件で、難易度も効果も違う
要件定義の初回で、まずこの一語を割る。割らないまま進めると、支払側の設計が終わった時点でプロジェクトが「銀行連携は完了」と認識し、入金側の消込ルールが誰の担当でもないまま結合テストに入る。
| 連携の本数 | 中身 | 難しさの中身 | 効果の出方 |
|---|---|---|---|
| 支払データの送信 | 総合振込・給与振込などのデータを銀行へ渡す | 技術より権限。誰が作成し誰が承認し誰が送信するか | 振込依頼書の手作業がなくなる。効果は明確で読みやすい |
| 支払結果の受領 | 組戻し・不能・エラーの結果を取り込む | 例外の戻し方。失敗した明細をどの状態に戻すか | 件数は少ないが、放置すると支払残が実態と合わなくなる |
| 入金明細の受領 | 入出金明細・振込入金通知を取り込む | 手がかりの情報量。金額と依頼人名しか載っていない | 最も効果が大きく、最も設計を誤りやすい |
| 残高照会 | 各口座の残高を日次で取り込む | ほぼない。口座数と接続方式の問題 | 資金繰り表の作成工数が消える。副次効果として口座の棚卸しが進む |
四本目の残高照会は、実は最も費用対効果が読みやすい。日次の残高集計はほとんどの会社で誰かがネットバンキングの画面を見て転記しており、その作業が丸ごと消える。にもかかわらず後回しにされるのは、経理の中でも資金担当という少人数の作業だからだ。要件の優先順位を「困っている人の声の大きさ」で決めると、この本数は落ちる。作業時間で測れば上位に来る。
三本目に工程の重心を置く。ここだけは、連携の設計より前にやるべき工程がある。
フォーマットの議論を先にやっても、照合率は1ポイントも上がらない
方式選定の会議で語られる論点は、たいていデータの器の話だ。固定長かXMLか、伝送かAPIか、暗号化と証明書の管理をどうするか。どれも必要な検討で、実際に決めなければ動かない。しかしこの議論は、消込がどれだけ自動で当たるかにほとんど影響しない。
自動消込のロジックが判定に使えるのは、入金明細に実際に載っている情報だけである。載っているのは、入金日、金額、振込依頼人名、それに銀行が付ける取引区分やコード。このうち請求側の債権と紐づけられるのは、金額と振込依頼人名の二つしかない。器を固定長からXMLに変えても、この二つが三つになるわけではない。
情報量を増やす手段は制度として用意されている。全国銀行資金決済ネットワークの全銀EDIシステム（ZEDI）が2018年12月に稼働し、総合振込をXML形式の電文で行えるようになった。この電文には支払通知番号や請求書番号といった金融EDI情報を添付でき、受け取る側は振込データそのものに請求書番号が乗った状態で消し込める。XML電文は金融通信メッセージの国際規格であるISO 20022に準拠した形式で、簡易にXMLファイルを作成する機能（S-ZEDI）も用意されているため、支払う側の負担も以前ほど重くない（全国銀行協会 ZEDI、全銀EDIシステム接続のためのガイダンス）。
ただし、ここが実装側にとって決定的に重要な点になる。EDI情報を載せるのは支払う側の作業であって、受け取る側のシステム設計では動かせない。つまりこれはプロジェクトの要件でなく、顧客の支払部門との交渉事項である。交渉を動かせるのは営業であり、情シスでも経理でもない。要件定義で「ZEDIを使う」と書いても、相手が載せてくれなければ電文の項目は空のまま届く。だから連携の要件定義と並行して、入金件数の上位数社に絞った交渉を営業側のタスクとして起票しておく。全社展開を前提にすると、一社も動かないまま稼働する（入金消込と滞留売掛金｜消込できない入金が月次決算を止める構造を直す）。
消込ルールを直す工程は、連携の設計より前に置く
順序を入れ替える。銀行から何をどう受け取るかを決める前に、いま消し込めていない入金がなぜ消し込めないのかを型で数える。材料は既にある。直近三か月の入金明細と、そのとき経理が手で何をしたかの記録だ。
実務で出る差異は、たいてい五つの型に収まる。複数の請求書に対する一括入金。買掛金との相殺後の差額入金。振込手数料を差し引いた入金。支払サイトの解釈違いによる一部入金や前払。振込依頼人名が請求先の名義と違うもの。この五つを三か月分数えると、件数の分布が出る。分布が出た時点で、どこに手を打てば照合率が上がるかは自明になる。
そして重要なのは、五つのうち四つは発生源が経理の外にあることだ。一括入金と手数料控除は取引条件の問題で、営業と法務が動かないと解けない。相殺は販売企画の判断が絡む。支払サイトの解釈違いは契約文言の問題である。経理側のシステム設計で解けるのは、振込依頼人名の相違だけで、これは得意先マスタに振込依頼人名を登録すれば当たるようになる。
この四手を工程表に載せるかどうかが、実装側にとっての勝負どころになる。並行作業として扱うと、インターフェース仕様の確定期日が先に来て、消込ルールは「現行踏襲」で押し切られる。押し切られた瞬間に、この連携は自動化ではなく転送になる。
自動化しないと決めた型には、必ず出口を付けて閉じる
自動で当てないと決めた入金を、そのまま未消込のまま残すと、月次決算のクリティカルパスに乗る。締めの最終日に「消し込めていない入金が四十件あります」と報告が上がり、締めが止まる。これを避ける設計は決まっていて、仮勘定で受けて残高を確定させ、消込作業を締めの外側へ出す。
- ① 受け皿の勘定（仮受金など。どの型をどの勘定で受けるかを型ごとに決め、混ぜない）
- ② 滞留の判定日数と、その日にトリガーされるアクション（照会・営業への差し戻し・回収担当への引き継ぎ）
- ③ エスカレーション先（部署名でなく役割名。担当者の異動で運用が切れないようにする）
滞留の管理では、入金済みで消込未済のものと、真の未入金を必ず分けておく。エイジング表にこの二つが混在していると、滞留額が実態より大きく見え、督促のリソースが作業残に吸われる。分けたうえで、真の未入金には日数をトリガーとする督促・出荷停止・引当・法的手続を先に紐づける。取引先の信用悪化は決算書より入金の挙動に先に出るため、この滞留データは与信の一次情報としても効く（取引先の倒産をどう防ぐか：決算書の与信では、貸し倒れの前に間に合わない）。
振込手数料の差異については、作業でなく会計処理の設計で消せる。手数料相当額を売上値引きとして処理する場合、売上に係る対価の返還等のうち税込1万円未満のものは返還インボイスの交付義務が免除されており、これは適用期限も規模要件もない恒久的な措置である（消費税法第57条の4第3項）。この前提が使えるなら、手数料控除入金は差異として残さず、自動で吸収する設計に寄せられる。制度の細部を前提に設計を組む場合は、他の日本固有要件と同じく受け皿と根拠を割り付け表に残しておく（SAPで日本固有の要件をどこまで作り込むか｜インボイス・電子帳簿・消費税区分の落とし所）。
支払側で詰まるのは技術ではなく、誰が送信ボタンを押すかである
支払側のインターフェースは、入金側に比べて設計が素直だ。支払対象を抽出し、支払方法と銀行を決め、データを作り、送る。仕様は明快で、テストも通しやすい。それでもカットオーバー直前に必ず揉めるのが、承認と送信の権限である。
いままでは、経理が振込依頼書を紙で作り、部長が押印し、銀行の窓口かネットバンキングで担当者が送信していた。この動線には、システムの外側で複数の目が入っていた。SAPから直接データを送る設計にすると、その目が消える。だから設計工程で、支払データの作成者、承認者、送信実行者を分ける。同一人物が三役を兼ねられる権限構成のまま稼働すると、内部統制の評価で必ず指摘される。権限とSoDの設計は支払の要件と同時に詰める（SAPの権限設計とSoD（職務分掌）｜内部統制を仕組みで担保する）。
支払結果の戻しも設計に入れる。組戻しや振込不能が発生したとき、その明細をどの状態に戻すか。支払済みのフラグを落とすのか、逆仕訳を立てるのか、未払に戻すのか。件数は月に数件でも、決めていなければ発生した日に人が判断することになり、判断が人によって割れる。割れた処理は残高のずれとして翌月以降に効いてくる。債権債務の残高が意思決定に使える状態を保つには、この例外の戻し方まで含めて設計する（SAPの債権・債務管理（AR/AP）を回収と支払の意思決定に効かせる）。
グループ全体で口座を集約している場合は、支払の実行主体そのものが論点になる。子会社の支払を親会社が代行する構成なら、SAP側の支払プログラムと資金管理の設計は連動して決めなければならない。導入プロジェクトの中で片方だけ動かすと、稼働後にグループ間の債権債務が合わなくなる（グループ資金管理（CMS・キャッシュプーリング）の導入判断｜効く会社と効かない会社）。
作り切る順番は、型を数える・行き先を配る・器を選ぶである
銀行連携で期待外れになるプロジェクトは、順番を間違えている。器を先に決め、来たデータをどう配るかを後回しにする。順番を戻せばよい。三か月分の入金明細から差異の型を数え、型ごとに自動・仮勘定・差し戻しの行き先を配り、そこで初めて必要な器を選ぶ。器の選定は最後で構わない。
そして、自動化しないと決めた範囲を明示的に閉じる。仮勘定で受け、滞留の判定日数を決め、エスカレーション先を役割名で書く。この三点が付いていない未消込は、締めのクリティカルパスに戻ってくる。支払側は権限を分けることに集中し、例外の戻し方を先に決める。この順で作れば、稼働後に増えるのはデータ量でなく、経理が使える時間になる。
