4. ACH文件结构
ACH批量支付清算的核心载体是NACHA（National Automated Clearing House Association）定义的文件格式。无论是发起工资代发、供应商付款，还是处理退票（Return）与更正（NOC），系统解析和生成的都是同一套结构化文本文件。理解NACHA文件结构，是排查“文件被拒”“批次不平衡”“退票定位不到原交易”等问题的前提。本节从记录类型、层级关系、字段含义三个维度拆解NACHA文件，并给出实战中的解析要点。
一、核心原理：四层记录与“头—明细—控制”闭环
NACHA文件是典型的行式定长记录结构，每行固定94个字符，以换行符分隔。文件由四种记录类型构成，形成“文件—批次—明细”的三级嵌套，每级都由“头记录”和“控制记录”包裹，构成完整性校验闭环。
- 文件头记录（File Header，记录类型1）：标识发起方、接收方、文件创建时间与文件ID，是整个文件的入口。
- 批头记录（Batch Header，记录类型5）：标识一个批次的服务类别码（SEC）、公司名称、公司标识、生效日期等，决定该批次的业务规则。
- 明细记录（Entry Detail，记录类型6）：承载具体交易，包含交易码、收款方路由号、账号、金额、个人标识号等。
- 批控制记录（Batch Control，记录类型8）：汇总本批次的明细笔数、借记总额、贷记总额、哈希值。
- 文件控制记录（File Control，记录类型9）：汇总整个文件的批次数量、明细块数、借记总额、贷记总额、哈希值。
其中“块（Block）”指每10行记录构成一个块，文件控制记录中的“块数”按10行向上取整计算。这是很多自研系统首次对接ACH时最容易算错的字段。
二、记录类型与字段含义速查
下表列出四类核心记录的定位与关键字段，便于开发与运维对照解析。
| 记录类型 | 位置 | 关键字段 | 实战关注点 |
|---|---|---|---|
| 1 文件头 | 文件第1行 | 立即目的地、立即发起方、文件创建日期、文件ID | 发起方ID需与ACH运营方备案一致 |
| 5 批头 | 每批首行 | 服务类别码、公司名称、公司标识、生效日期 | SEC决定退票时限与NOC规则 |
| 6 明细 | 批头之后 | 交易码、RDFI路由号、账号、金额、个人标识号 | 交易码区分借记/贷记与账户类型 |
| 8 批控制 | 每批末行 | 明细笔数、借记总额、贷记总额、哈希值 | 哈希值按路由号前8位累加取模 |
| 9 文件控制 | 文件末行 | 批次数量、块数、借记总额、贷记总额、哈希值 | 块数按10行向上取整 |
三、方法流程：从原始数据到合规文件
生成一个合规NACHA文件，通常遵循以下步骤：
- 确定SEC与交易码：根据业务场景选择PPD（个人）、CCD（企业）、WEB（网络发起）等，并匹配对应交易码，如22（活期贷记）、27（活期借记）。
- 组装批头：填写公司名称、公司标识、生效日期，确保生效日期符合ACH运营方的提前提交要求。
- 写入明细：逐笔填充路由号、账号、金额，金额以“分”为单位右对齐补零，共10位。
- 计算批控制：统计笔数、借记总额、贷记总额，并按路由号前8位计算哈希值。
- 组装文件头与文件控制：汇总批次数量、块数、总额与哈希值。
- 填充块：若文件总行数不是10的倍数，用记录类型9的填充行补齐至整块。
101 021000021 1234567890 2504010000A094101BANK OF TEST ORIGINATOR CO
5200ORIGINATOR CO 1234567890PPDPAYROLL 250401 1021000020000001
6220210000211234567890 0000010000 JOHN DOE 0
822000000100000000100000000000000000000000001234567890
9000001000001000000010000000000000000000000
9999999999999999999999999999999999999999999999999999999999999999999999999999
上面示例中，第1行是文件头，第2行是批头，第3行是明细，第4行是批控制，第5行是文件控制，第6行是填充行。注意金额字段“0000010000”表示100.00元，单位为分。
四、案例与复盘：退票定位为何失败
某财务系统发起工资代发后收到一笔R01（账户不存在）退票。运维人员尝试用退票文件中的“原始交易标识”回查，却无法定位到原明细。复盘发现：退票文件中的原始条目追踪号（Original Entry Trace Number）由原批头中的“生效日期+发起方路由号+序列号”组成，而该系统在生成原文件时序列号未按批次重置，导致追踪号重复，回查时命中多条记录。
- 把“块数”按实际行数除以10直接取整，忽略向上取整规则。
- 哈希值计算时误用完整路由号，正确做法是取路由号前8位数字累加后对10取模。
- 退票处理时只看金额和账号，忽略原始条目追踪号，导致无法关联原交易。
- 批控制中的借记/贷记总额与明细不符，文件被整批拒绝。
正确的做法是：在生成文件时即建立“追踪号—业务单号”映射表，退票文件到达后先解析原始条目追踪号，再通过映射表定位原交易，最后根据退票码（R01、R02、R03等）决定是重发、更正还是转人工。