自动清算所 (ACH) 支付是在美国的银行账户之间转移资金的电子交易。它们通常用于直接存款、账单支付、企业对企业 (B2B) 交易和个人对个人支付。

ACH 支付通过 ACH 网络进行处理，这是一个由美国国家自动清算所协会 (Nacha) 运营的安全可靠的系统。2023 年，ACH 网络转移的资金超过 80 万亿美元。尽管 ACH 支付很常见，但有时也会失败。当发生 ACH 退回时，了解其发生的原因并做出相应的回应非常重要。本指南解释了 ACH 退回的常见原因，提供了 ACH 退回码的完整列表，并介绍了企业应如何减少 ACH 支付失败的情况。

本文内容

• ACH 支付被退回时会发生什么？
  
• 为什么 ACH 支付会被退回
  
• ACH 退回码完整列表
  
• 如何减少 ACH 退回
  

ACH 支付被退回时会发生什么？

当 ACH 交易无法成功完成时，支付就会被退回。支付退回与支付被拒略有不同，支付被拒是指某条交易记录从未被 ACH 网络接受处理。ACH 支付被退回或拒绝的原因有多种，包括汇款人账户资金不足、账户已关闭或账户信息不正确。以下是 ACH 支付被退回时会发生的情况。

• 银行通知： 收款银行会通知发起银行（付款方的银行）该笔 ACH 支付已被退回。它为退回提供原因代码或描述，指示交易无法完成的原因。

• 付款方通知： 发起银行会通知付款方（通常是企业或个人）该 ACH 支付已被退回，并附上收款银行提供的原因。

• 重新提交或更正： 根据退回的原因，付款方可能需要在重新提交交易之前更正支付信息（例如更新账户详细信息）。

• 对账： 付款方会核对自己的记录以反映已退回的支付，并采取必要措施解决问题，例如联系收款方安排替代支付方式。

被退回的 ACH 支付可能会产生费用，通常由付款方的银行向付款方收取。这些费用因银行政策和退回的性质而异。

为什么 ACH 支付会被退回

ACH 支付可能因多种原因被退回。以下是一些最常见的原因。

资金不足

示例代码： R01（资金不足）

当用于支付的账户在处理交易时没有足够的资金覆盖交易时，会发生这种情况。

账户问题

示例代码： R02（账户已关闭）、R03（无账户/无法找到账户）、R04（无效账户号码）

如果提供的账户号码不存在、对应的账户已关闭或无效，支付就会被退回。这可能是由于输入错误、账户关闭或其他管理方面的差异造成的。

授权问题

示例代码： R07（客户撤销授权）、R10（客户表示未经授权）

当发起方没有从账户持有人处获得发起借记的适当授权，或者在最初获得授权后授权被撤销时，就会出现这种支付退回情况。

停止支付

示例代码： R08（支付已停止）

如果账户持有人对某笔特定支付下达了停止支付指令，该 ACH 借记将被退回。

管理错误

示例代码： R05（使用企业 SEC 代码对消费者账户进行未经授权的借记）、R17（文件记录编辑标准）

如果交易格式不正确，就可能会出现此错误。这可能意味着支付代码不匹配（例如，将企业交易代码应用于消费者账户）或其他违反 ACH 规则的技术错误。

银行错误

示例代码： R13（无效的 ACH 路由号码）、R26（必填字段错误）

这些支付退回与收款银行的问题有关，例如没有资格参与 ACH 网络，或在处理交易中的必填字段时出现错误。

争议和欺诈

示例代码： R29（企业客户表示未经授权）、R51（与 RCK 条目[重新提交的支票]相关的项目不合格或 RCK 条目不正确）

如果账户持有人认为某笔交易未经授权，可能表明存在欺诈或条目处理方式存在差异，则该交易可能会使用这些代码返回。

技术或程序故障

示例代码： R20（非交易账户）、R24（重复条目）

支付指向非交易账户（不允许处理自动借记或贷记的账户）或重复交易（同一条目被多次发送）也是 ACH 退回的常见原因。

监管合规和法律问题

示例代码： R16（账户被冻结）

此错误代码可能意味着账户因法律行动被冻结，或交易因违规被暂停。

ACH 返回代码的完整列表

ACH 拒绝和退回码涵盖了从简单的管理错误到与国际交易和合规性相关的更复杂问题等各种情况。在讨论具体代码之前，了解一些关键术语会有所帮助：

• 条目： 任何 ACH 交易提交
  
• IAT： 国际 ACH 交易
  
• ODFI： 发送 ACH 交易的原始存款金融机构
  
• RDFI： 接收 ACH 交易的存款金融机构
  

每个代码都提供了有关交易失败或需要关注原因的具体信息。以下是所有 ACH 拒绝和返回代码的列表。

常用代码

R01 - 资金不足
R02 - 账户已关闭
R03 - 无账户/无法找到账户
R04 - 帐号无效
R05 - 使用企业 SEC 代码对消费者账户进行未经授权的借记
R06 - 根据 ODFI 的请求返回
R07 - 客户撤销授权
R08 - 支付已停止
R09 - 未收妥资金
R10 - 客户表示未授权

较少见代码

R11 - 支票截断条目返回
R12 - 分行出售给另一家 DFI
R13 - 无效的 ACH 路由号码
R14 - 受益人或账户持有人（非代表收款人）已故
R15 - 受益人或账户持有人（非受委托人）已故
R16 - 账户被冻结
R17 - 文件记录编辑标准
R18 - 生效入账日期不正确
R19 - 金额字段错误
R20 - 非交易账户
R21 - 无效的公司标识
R22 - 个人身份证号码无效
R23 - 接收方拒绝贷记条目
R24 - 重复条目
R25 - 附录错误
R26 - 必填字段错误
R27 - 追踪号码错误
R28 - 路由号码校验位错误
R29 - 企业客户表示未经授权
R30 - RDFI 未参与支票截断计划
R31 - 允许的退回交易条目（仅适用于 CCD 和 CTX 交易）
R32 - RDFI 未进行结算
R33 - XCK 条目退回
R34 - 有限参与 DFI
R35 - 不当借记条目退回
R36 - 不当贷记条目退回
R37 - 提交源文件以进行支付
R38 - 对源文件进行停止支付
R39 - 源文档不正确
R40 - 联邦政府机关退回的 ENR 交易条目
R41 - 无效的交易代码
R42 - 路由号码/校验位错误
R43 - 无效的 DFI 帐号
R44 - 无效的个人身份证号码
R45 - 无效的个人姓名
R46 - 无效的代表收款人指示符
R47 - 重复注册
R50 - 影响 RCK 接受的州法律
R51 - 与 RCK 条目相关的项目不符合条件或 RCK 条目不正确
R52 - 对与 RCK 条目相关的项目进行止付
R53 - 用于支付的项目和 RCK 条目
R61 - 错误路由的退回
R62 - 错误或反向借记退回
R63 - 美元金额不正确
R64 - 个人身份识别不正确
R65 - 交易代码不正确
R66 - 公司标识不正确
R67 - 重复退回
R68 - 逾期退回
R69 - 字段错误
R70 - 允许退回条目未被接受/ODFI 未请求退回
R71 - 错误路由的拒付退回
R72 - 不及时的拒付退回
R73 - 及时的原始退回
R74 - 更正后的退回
R75 - 非重复退回
R76 - 未发现错误
R77 - 不接受 R62 拒付退回

国际交易代码

R80 - IAT 条目编码错误
R81 - 非 IAT 计划参与者
R82 - 无效外国接收 DFI 标识
R83 - 外国接收 DFI 无法结算
R84 - 网关未处理条目
R85 - 出境国际支付编码错误

如何减少 ACH 退回

减少 ACH 退回可以为您节省资金，减轻员工的管理负担，并通过尽量减少支付延迟和解决支付过程中的不满情绪来改善客户体验。将您的 ACH 退回率与行业基准进行对比，并与您所在行业的其他企业合作，分享减少支付退回的最佳实践，这是个不错的主意。当 ACH 退回确实发生时，请确保及时处理，并考虑实施自动化工作流程，以便实时对退回情况进行分类和处理。

以下是一些有助于减少 ACH 退回的建议。仔细评估这些防止支付退回策略的成本效益，以确保您在投资成本与潜在节省之间取得平衡。

• 账户验证： 使用 Financial Connections 进行实时用户验证，以确认买家身份并尽量减少 ACH 错误。通过分析数百万笔 Stripe 交易的数据，它它能有效筛选出不符合 ACH 支付条件的账户，确保更高的交易成功率。

• 客户教育： 清晰地传达 ACH 授权流程以及与资金不足或未经授权的交易相关的潜在费用。

• 风险模型： 分析历史支付退回数据，找出规律，并为新交易创建风险评分。考虑客户历史记录、交易规模和行业趋势。

• 实时监控： 实施能够监控 ACH 交易中可疑活动的工具，例如来自新账户的高价值借记交易。

• 交易说明： 使用易于理解、简洁的交易描述，准确反映支付的目的。模糊的描述可能会引起客户的警觉，并导致支付退回。

• 预先通知： 可能向客户发送预先通知，告知他们即将进行的 ACH 交易，特别是对于首次借记或定期支付。

• 客户支持： 为客户提供多种途径，以便他们就不认识的交易或更新账户信息联系支持人员。

• 批处理策略： 使用批处理策略一起提交低风险交易。

• ACH 网络优化： 与您的支付处理商合作，探索高级 ACH 网络优化策略。这些策略可能包括选择最合适的路由选项，或使用当日 ACH 功能来加快结算速度并降低资金不足的风险。

• 第三方合作： 考虑与专门提供先进数据清理和验证功能的 ACH 退回预防服务提供商合作。

• 遵守 Nacha 准则： 及时了解最新的 Nacha 运营规则以及 ACH 交易的最佳实践。

• 安全措施： 在整个 ACH 处理系统中保持强大的安全协议，以尽量降低欺诈性交易和支付退回的风险。