银行来款与应收单匹配，应先确认流水唯一性和可分配金额，再依据付款说明寻找应收对象，生成逐单分配建议。Agent 可以整理付款备注、关联沟通和解释冲突；金额分配由固定规则核对。没有足够依据的部分保留未认领，不能为了清空列表把来款随意挂到金额接近的订单。
流水与应收分别保留身份
流水至少记录收款账户、银行交易标识、交易日期、币种、到账金额、付款户名、付款账号及附言。来自不同批次导出的同一流水，需要识别为同一笔到账；不能用文件行号作为长期身份，也不能仅按日期和金额去重，因为当天可能有两笔相同金额的真实付款。
应收明细保留单号、买方主体、对应订单、应收节点、币种、当前未分配余额和已有认领记录。认领前重新读取余额，提交时由业务系统将余额校验与分配记录写入一并完成；多人同时认领时，只接受不超出剩余金额的分配，冲突建议重新计算后再确认。这里讨论业务数据对应，不改变企业既有的记账和审批规则。
匹配依据的优先顺序
| 依据 | 可以支持的判断 | 仍需检查的内容 |
|---|---|---|
| 明确付款清单 | 指定应收单及分配金额 | 清单版本、主体和余额 |
| 附言中的订单号 | 缩小候选订单范围 | 是否存在多个付款节点 |
| 已确认付款关系 | 识别同一主体或代付关系 | 本次付款是否适用该关系 |
| 金额组合 | 提出一款多单候选 | 是否有多组组合及付款依据 |
| 日期与历史习惯 | 提供辅助检索线索 | 不能单独认定资金用途 |
名称匹配时保留原户名和标准主体，别名需要有确认依据。同一个集团的几家公司也应分别识别，不能看到共同字号就合并应收。付款账号变化时重新核对，不沿用上一次付款的对应关系。
示例：部分付款与余额保留
以下为示例。某主体到账五万元，有三张未完成应收，余额分别为两万元、三万元和五万元。只看金额，前两张之和与第三张都能匹配。Agent 应列出两组候选，并请求付款清单或经办人说明，不能把最先搜到的一组当成事实。
随后付款说明明确：两万元用于第一张，另三万元是第三张的部分付款。分配结果应是第一张余额归零，第三张剩余两万元，第二张仍有三万元。若说明只解释其中两万元，则剩余三万元保持未认领，不能自动按到期顺序分掉。
多对多分配与金额约束
分配表需要独立记录流水编号、应收编号、分配金额和依据。这样一笔来款可以分到多张应收，一张应收也可以接收多笔来款。每条关系可单独撤销或更正，不必把整笔流水删除后重建。
固定计算检查三项约束：同一流水本次新增分配额不超过其当前未分配余额；同一应收本次新增分配额不超过其当前可认领余额；币种及金额口径一致。分配后，还应核对每笔流水的有效分配累计额加剩余未分配额，等于该流水可用于认领的总金额。跨币种不能直接按数字相等匹配，需要另有经确认的换算和结算依据。金额有尾差时保留差额原因，不由模型自行抹平。
若到账金额小于付款说明中的金额，先把差异列出。手续费、扣款、分次付款都只是可能解释，需要对应证据。把少收部分直接写成“银行手续费”，会把猜测固化进后续报表。
代付、退款与更正
第三方代付需要记录实际付款方、对应买方、适用应收与确认材料。不能因历史上出现过一次代付，就默认以后该账户所有来款都属于同一主体。关联关系应有适用范围，过期或有冲突时重新核对。
退款、撤回和误认领通过原流水关联处理，保留原分配与更正记录。报表读取当前有效分配，同时能解释历史变化。否则销售昨天看到已收，今天看到未收，却找不到变化原因，仍然会反复向不同人员询问。
认领清单的交付标准
分配确认前可展示一张前后对照表：流水原未认领额、本次分配额、剩余未认领额，以及每张应收分配前后的余额。确认期间若有人已处理同一对象，应重新生成对照，保留此前的建议作为历史记录，不能继续使用过期余额完成分配。
每天的清单可分成有充分依据的待确认分配、存在冲突的候选、缺少说明的未认领来款。每条应直接展示原流水、付款材料、应收余额和分配后的变化，经办人无需再次从聊天里找依据。
验收重点覆盖重复导入、同额多组候选、部分付款、代付及并发认领，检查错配和余额重复占用。催收前的业务核对可阅读应收回款持续跟进；跨系统对应关系见企业业务事实源建设。需要打通流水与应收明细，可了解定制开发。
