ERPと銀行の支払ファイルと照合
ERPと銀行：支払ファイルを送り、明細を受け取り、照合する
支払いはISO 20022 pain.001としてホスト間SFTPまたは銀行APIで送信し、camt.053とMT940の明細を台帳へ突合します。
ブループリント
横にスクロールすると図全体を確認できます。
ERPから銀行へ：支払いを送り、明細を受け取る
承認済みの支払いは、署名付きISO 20022ファイルとしてホスト間チャネルでERPを離れます。ステータスレポートと明細は同じ経路で戻り、未決済項目と照合されます。却下や未照合の明細は、理由を付けてお客様のチームに届きます。
- 主要フロー
- 非同期
- 例外経路
10ステップのフロー
フローを順に示す
- ERPから連携レイヤーへ：承認済み支払いバッチ、REST/JSON · IDoc経由（主要フロー）。
- 連携レイヤーから安全な銀行チャネルへ：署名・暗号化された支払いファイル、ISO 20022 pain.001 · OpenPGP経由（主要フロー）。
- 安全な銀行チャネルから銀行へ：銀行へ送信、SFTP H2H経由（主要フロー）。
- 銀行から安全な銀行チャネルへ：ステータスレポートと明細、pain.002 · camt.053 · MT940経由（非同期）。
- 安全な銀行チャネルから連携レイヤーへ：受信して検証、SFTP H2H経由（非同期）。
- 連携レイヤーから照合エンジンへ：明細行、camt.053経由（非同期）。
- 照合エンジンからERPへ：照合済みの仕訳を計上、REST/JSON経由（主要フロー）。
- 連携レイヤーから財務・経理チームへ：却下された支払い。理由コード付き、pain.002 RJCT経由（例外経路）。
- 照合エンジンから財務・経理チームへ：未照合の明細：照合の不一致（例外経路）。
- 財務・経理チームからERPへ：修正して再送信（例外経路）。
概要
これはERPと取引銀行の間のフローです。承認済みの支払いが出て行き、ステータスレポートと明細が戻ってきます。多くの財務チームが今も銀行ポータルと表計算で手作業にしている接続であり、誤りが金銭的な損失につながる接続でもあります。
参照設計では、ERPと各銀行の間に統合レイヤーを置きます。レイヤーは支払いを各銀行のISO 20022 pain.001の派生形式にマッピングし、署名と暗号化を行い、ホスト間SFTP、EBICS、または銀行APIで送信します。ステータスレポートと明細は同じ経路で戻り、ERPの未照合項目と突合されます。
障害経路も正常経路と同じくらい入念に設計します。拒否された支払いは銀行の理由コードとともに戻ります。一致しない明細行は、担当者が処理する照合差異になります。取りこぼしも二重計上もありません。
フローの仕組み
支払バッチの承認
ERPが支払バッチを作成し、承認者が従来どおり放出します。統合レイヤーは承認済みのバッチだけを取り込みます。
マッピング、署名、暗号化
レイヤーは各支払いを銀行のpain.001派生形式にマッピングし、検証し、銀行の要件に従ってファイルに署名と暗号化を行います。
銀行への送信
ファイルは合意した経路、すなわちホスト間SFTP、EBICS、または銀行APIで、銀行の締め切り時刻までに送信されます。
ステータスと明細の受信
銀行はファイルと支払いごとのpain.002ステータスレポートと、日終了時のcamt.053またはMT940明細を返します。
収集と検証
レイヤーは各レポートを収集し、明細の連番に対して欠落や重複がないか確認し、明細行に解析します。
突合と転記
明細行を承認済みのルールで未照合項目と突合し、一致した仕訳をERPへ転記します。
障害が起きたとき
支払いが拒否された場合
pain.002レポートに銀行の理由コードが含まれます。ERPで支払いを拒否済みとし、トレジャリーチームが修正して再送できるようにします。
明細行が一致しない場合
その行は、候補と考えられる項目と失敗理由を添えた照合差異になります。お客様のチームが処理し、ルールはそこから学習できます。
ファイルの欠落や遅延
明細の連番と想定される配信時刻を確認します。欠落や遅延があれば、誰かが資金ポジションに依拠する前にアラートを発します。
鍵や証明書の期限が近い場合
署名鍵とチャネル証明書を有効期限とともに管理し、銀行と新しい鍵を合意するのに十分早く更新を開始します。
標準とシステム
- 銀行の標準とチャネル
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- SFTP (H2H)
- EBICS
- Swift
- OpenPGP
よくある質問
ホスト間通信、EBICS、銀行APIのどれを使うべきですか。
通常は銀行が決めます。ホスト間SFTPは、企業の支払ファイル向けに最も広く提供される経路です。EBICSはドイツ、フランスと近隣諸国の銀行で一般的です。銀行APIは、銀行が提供している場合、リアルタイム残高や即時決済に適しています。複数の経路を使う企業も多く、統合レイヤーがその違いをERPから隠します。
camt.053とMT940のどちらの明細を受けるべきですか。
銀行が両方を提供する場合、camt.053は振込内容の構造化データが豊富で、自動突合の信頼性が高まります。MT940も広く使われ、多くのケースで十分機能します。当社は両方を受け取り、同じ内部モデルに変換し、お客様と銀行にとって都合のよい時期に各行をMT940からcamt.053へ移行できます。
日中に資金ポジションを確認できますか。
銀行が日中レポートを提供していれば可能です。camt.052やMT942のメッセージ、または残高APIで届きます。各行が対応するスケジュールで収集し、日終了の明細と並べて表示するため、トレジャリーチームは締め切り前に見込みと実際のポジションを確認できます。
誰が支払いを承認し送信したかを追跡できますか。
はい。承認は既存の統制とともにERP内に残ります。統合レイヤーは、作成、署名、送信、受信したすべてのファイルを、タイムスタンプ、識別子、使用した技術アカウントとともに記録します。その記録により、銀行のステータスレポートの各支払いをERPの伝票と承認者までたどれます。
取引銀行が複数あります。それぞれ別プロジェクトになりますか。
いいえ。統合レイヤー、内部の支払モデル、突合ルールは一度だけ構築します。追加の銀行ごとに、独自の形式派生、チャネル、接続時の手順が加わりますが、これはより小さな作業です。通常は取引量の最も多い銀行から接続し、他行を順に追加します。
本番前に接続をどう試験しますか。
各行がテスト環境またはテスト手順を提供します。支払種別、拒否、明細を網羅するテストケースを銀行と合意して実行し、証拠を保管します。銀行の承認を得たら、小さな初回の支払バッチで本番に移り、結果を比較してから残りを移します。
契約ではなく、対話から始めましょう
構築、接続、保護のどれが必要かを教えてください。アーキテクトが内容を一緒に整理し、どこから始めるべきかを提案します。
今後の流れ
日程の調整
セッションの日程を調整するため、当社チームからメールをお送りします。
事前コンサルティングセッション
無料の30分オンライン事前相談です。目標、システム、制約を伺います。
準備状況レビュー
無料の48時間準備状況レビューで、プリンシパルアーキテクトがプロジェクトを6項目のDefinition of Readyに照らして確認し、適切なトラックを提案します。
トラックの選択
スコープが確定したプロジェクトには、拘束力のある提案書を3–5営業日以内にお渡しします。構想段階のプロジェクトはBlueprint Studioから始まります。稼働中のシステムに障害がある場合、文書化されていない場合、連携が必要な場合は、1–2週間の診断から始まります。Blueprint Studioと診断はそれぞれ固定料金で、提案書に記載します。