跳至主要内容
XSIS
客户专区索取方案

企业与集成

ERP 到银行的付款文件与对账

ERP 到银行：付款文件发出，对账单返回，完成对账

付款以 ISO 20022 pain.001 通过 host-to-host SFTP 或银行 API 发送，camt.053 与 MT940 对账单回到总账进行匹配。

与工程师交流查看合作方式

蓝图

ERP 到银行：付款出，对账单入已批准的付款以签名 ISO 20022 文件通过 host-to-host 通道离开 ERP。状态报告与对账单以相同方式返回，并与未清项匹配。拒绝与未匹配行连同原因交予您的团队。ERPERP付款批次、未清项、总账XSIS集成层映射、校验、签名与调度网关安全银行通道host-to-hostSFTP、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 与诊断服务各收取固定费用，费用在方案中列明。