跳至主要內容
XSIS
客戶專區索取方案

企業與整合

ERP 到銀行的付款檔案與對帳

ERP 到銀行：付款檔案發出，對帳單回傳，完成對帳

付款以 ISO 20022 pain.001 透過主機對主機（host-to-host）SFTP 或銀行 API 傳送，camt.053 與 MT940 對帳單回到總帳進行核對。

與工程師交流檢視合作模式

藍圖

ERP 到銀行：付款出，對帳單入已核准的付款以已簽章的 ISO 20022 檔案透過主機對主機（host-to-host）通道離開 ERP。狀態報告與對帳單以相同方式回傳，並與未清項核對。退件與未核對明細連同原因交予您的團隊。ERPERP付款批次、未清項、總帳XSIS整合層對映、驗證、簽章與調度閘道安全銀行通道主機對主機 SFTP、EBICS或銀行 API銀行銀行支付與資金管理服務對帳引擎比對規則與容差人員資金與財務團隊複核退件與差異1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002 RJCT910

ERP 到銀行：付款出，對帳單入

已核准的付款以已簽章的 ISO 20022 檔案透過主機對主機（host-to-host）通道離開 ERP。狀態報告與對帳單以相同方式回傳，並與未清項核對。退件與未核對明細連同原因交予您的團隊。

  • 主流程
  • 非同步
  • 異常路徑
10 步流程

流程逐步說明

  1. 從 ERP 到 整合層：已核准的付款批次，經由 REST/JSON · IDoc（主流程）。
  2. 從 整合層 到 安全銀行通道：已簽章並加密的付款檔案，經由 ISO 20022 pain.001 · OpenPGP（主流程）。
  3. 從 安全銀行通道 到 銀行：已送達銀行，經由 SFTP H2H（主流程）。
  4. 從 銀行 到 安全銀行通道：狀態報告與對帳單，經由 pain.002 · camt.053 · MT940（非同步）。
  5. 從 安全銀行通道 到 整合層：已接收並驗證，經由 SFTP H2H（非同步）。
  6. 從 整合層 到 對帳引擎：對帳單明細行，經由 camt.053（非同步）。
  7. 從 對帳引擎 到 ERP：已核對並入帳的分錄，經由 REST/JSON（主流程）。
  8. 從 整合層 到 資金與財務團隊：被拒絕的付款，附原因代碼，經由 pain.002 RJCT（異常路徑）。
  9. 從 對帳引擎 到 資金與財務團隊：未核對明細：對帳差異（異常路徑）。
  10. 從 資金與財務團隊 到 ERP：已更正並重新提交（異常路徑）。

概述

這是 ERP 與其銀行之間的流程：已核准的付款發出，狀態報告與對帳單回傳。這是大多數財務團隊仍透過銀行入口網站與試算表人工完成的連結，也是出錯就要付出金錢代價的連結。

參考設計在 ERP 與各銀行之間設定一個整合層。該層將付款轉換為銀行所用的 ISO 20022 pain.001 變體，完成簽章與加密，並透過主機對主機（host-to-host）SFTP、EBICS 或銀行 API 傳送。狀態報告與對帳單沿同一路徑回傳，並與 ERP 中的未清項核對。

失敗路徑與正常路徑一樣經過精心設計。被拒付款會帶回銀行的原因代碼。無法核對的對帳單行會成為對帳差異，由指定人員處理。不會有任何內容被丟棄，也不會有任何內容被重複入帳。

流程如何運作

  1. 核准付款批次

    您的 ERP 產生付款批次，核准人照常放行。整合層只接收已核准的批次。

  2. 轉換、簽章與加密

    整合層將每筆付款轉換為銀行的 pain.001 變體，進行驗證，並按銀行要求對檔案簽章與加密。

  3. 傳送至銀行

    檔案在銀行截止時間之前，透過約定通道傳送：主機對主機（host-to-host）SFTP、EBICS 或銀行 API。

  4. 接收狀態與對帳單

    銀行按檔案與付款回傳 pain.002 狀態報告，並在日終回傳 camt.053 或 MT940 對帳單。

  5. 蒐集並驗證

    整合層接收每份報告，對照對帳單序號檢查缺失與重複，並解析為明細行。

  6. 核對並入帳

    對帳單明細按您核准的規則與未清項核對，核對成功的項目入帳至 ERP。

出現故障時

  • 付款遭拒

    pain.002 報告帶有銀行的原因代碼。該筆付款在 ERP 中標記為已拒絕，並轉交您的資金團隊更正後重新提交。

  • 對帳單明細無法核對

    該明細成為對帳差異，並附上可能相符的項目及失敗原因。由您的團隊處理，並可據以調整規則。

  • 檔案缺失或延誤

    系統會檢查對帳單序號與預期送達時間。檔案缺失或延誤會在任何人依賴現金部位之前發出警示。

  • 金鑰或憑證即將過期

    簽章金鑰與通道憑證連同到期日一併追蹤，更新作業啟動得足夠早，以便與銀行議定新金鑰。

標準與系統

銀行標準與通道
  • ISO 20022
  • pain.001
  • pain.002
  • camt.052
  • camt.053
  • camt.054
  • MT940
  • MT942
  • SFTP (H2H)
  • EBICS
  • Swift
  • OpenPGP

問題與解答

主機對主機（host-to-host）、EBICS 或銀行 API：我們該用哪種？

通常由銀行決定。主機對主機（host-to-host）SFTP 是企業付款檔案最常見的通道。EBICS 在德國、法國及周邊國家的銀行中較為常見。銀行 API 適合銀行提供即時餘額與即時支付的情形。許多公司同時使用多種通道，整合層對 ERP 隱藏這些差異。

連結到此問題

我們應該接收 camt.053 還是 MT940 對帳單？

若銀行兩者都提供，camt.053 包含更豐富、結構化的匯款資料，使自動核對更可靠。MT940 仍被廣泛使用，在許多情境下表現良好。我們兩者都能接收，並轉換為同一內部模型；當您與銀行都方便時，再逐家銀行從 MT940 遷移到 camt.053。

連結到此問題

我們能在日間檢視現金部位嗎？

可以，前提是您的銀行提供日間報告。它們以 camt.052 或 MT942 訊息形式，或透過餘額 API 提供。我們按各銀行支援的時間表接收，並與日終對帳單並列展示，使您的資金團隊能在截止時間之前看到預期與實際部位。

連結到此問題

我們能追溯誰核准並傳送了付款嗎？

可以。核准仍留在您的 ERP 中，沿用現有控制。整合層記錄它建立、簽章、傳送和接收的每個檔案，包含時間戳記、識別碼及所用技術帳戶。該日誌將銀行狀態報告中的每筆付款關聯回 ERP 單據及其核准人。

連結到此問題

我們有多家銀行，每家都要單獨做一個專案嗎？

不需要。整合層、內部支付模型與比對規則只需建置一次。每新增一家銀行，會增加其格式變體、通道與開通步驟，這些是較小的工作量。我們通常先連結交易量最大的銀行，然後依次增加其他銀行。

連結到此問題

上線前如何測試連結？

每家銀行都提供測試環境或測試流程。我們與銀行約定一組測試案例，涵蓋每種付款類型、拒絕情形與對帳單，執行並保留證據。銀行確認後，我們先以首批付款上線，比對結果後再處理其餘部分。

連結到此問題

相關

從對話開始，而不是從合約開始。

告訴我們您需要建置、串接與防護什麼。架構師會與您逐項討論，然後建議從何處入手。

預約免費會談索取方案

後續流程

  1. 約定時間

    我們的團隊會透過電子郵件與您約定會談時間。

  2. 諮詢前會談

    一次免費 30 分鐘線上預諮詢：我們盤點您的目標、系統與限制條件。

  3. 就緒評估

    在免費 48 小時就緒評估中，首席架構師對照 6 項就緒定義檢查您的專案，並建議合適的路線。

  4. 選擇路線

    範圍就緒的專案會收到一份有約束力的方案 3–5 個工作天內。概念階段的專案從 Blueprint Studio 開始。已上線系統若出現故障、缺乏文件或需要整合，則先進行 1–2 週 的診斷。Blueprint Studio 與診斷服務各收取固定費用，費用在方案中列明。