每日还款收款与用户入账对账
1. 背景与目标
当前还款链路中，支付通道确认收款与 FCS 完成用户还款入账属于两个连续但独立的业务事实。回调延迟、主动查询失败、重复通知、金额或币种异常、内部补偿失败等情况，可能造成“通道已收到钱但用户未入账”或“用户已入账但通道侧缺少有效收款事实”。
本需求建设每日自动对账与财务核对明细能力，目标是：
- 每日按业务日核对支付通道收款与用户入账结果。
- 逐笔识别未入账、无通道收款、金额不一致、状态冲突和重复匹配等差异。
- 为财务提供可查询、可筛选、可导出、可追溯的对账明细。
- 对差异建立认领、复核、处理和关闭闭环，同时保留原始资金事实与处理证据。
- 通过对账结果观察重复收款、迟延入账和补偿失效情况，为后续 34-统一还款防重复治理 —— 暂hold、35-还款H5支付会话时效与代扣在途拦截 —— 暂hold 是否启动提供事实依据。
- 通过系统设置内统一配置的 Webhook，将每日总体结论播报给财务和运营协作群；发送、失败和重试均纳入审计，不单独建设播报记录菜单。
2. 适用范围
2.1 首期范围
- 业务范围：现金贷还款。
- 收款侧：Paystack、Monnify 及已接入的其他还款支付通道，包括银行卡还款、Web H5、自动代扣和虚拟账号到账。
- 入账侧：FCS 中由对应收款资金产生的用户还款入账结果。
- 使用角色：财务运营、支付运营、具备授权的系统支持人员和审计人员。
- 使用能力：每日总体概览、对账批次、逐笔明细、退款影响核对、差异处理、重新核对、导出、系统设置内的 Webhook 配置和审计。
2.2 首期不包含
- 放款出账、佣金付款和其他付款方向对账。
- 退款申请、审批、执行和收款账户选择；但退款形成后的通道反向资金事实及其对原收款、用户入账的影响纳入本对账。
- 支付通道结算到公司银行账户的结算款、手续费和银行流水对账。
- 直接在对账页面修改用户余额、还款计划、通道状态或历史资金流水。
- 根据人工判断直接补记用户入账、退款或冲正；此类资金动作须走独立且已授权的处理流程。
- 将通道手续费或结算净额与用户应入账金额直接比较。
- 面向用户展示财务对账状态或内部差异原因。
3. 角色与责任边界
| 角色 / 系统 | 责任 |
|---|---|
| 支付通道 | 提供收款交易的权威状态、实收金额、币种、交易时间和通道参考号 |
| PMT / 支付域 | 保存支付订单、通道参考关系、回调与主动查询结果，形成可核对的通道收款事实 |
| FCS / 账务域 | 负责还款分配和用户入账，是用户已还金额、余额及入账结果的权威来源 |
| 对账任务 | 按统一口径采集双方事实、匹配、分类、汇总、重跑并保留版本 |
| 财务运营 | 查看汇总和明细，认领差异，核验证据，推动责任系统处理并完成财务复核 |
| 支付运营 / 系统支持 | 排查通道未知、参考关系缺失、回调或补偿异常，提交处理结论和证据 |
| 审计人员 | 只读查看批次、差异处理和导出审计记录 |
财务在本功能中负责核对和处理闭环，不成为通道状态或用户账务状态的数据所有者。前端不得根据金额相等自行覆盖权威状态。
4. 核心口径
4.1 业务日
- 对账按
App / 国家 / 币种 / 支付通道 / 业务日分组。 - 业务日以对应 App 所属国家的配置时区计算，不统一使用服务器时区。
- 通道收款以通道确认的成功时间归属业务日；仅有内部入账而无通道成功记录时，暂以内部入账时间归属待核对业务日。
- 跨日回调或延迟入账仍按同一笔资金参考关系匹配，不因日期不同拆成两笔差异。
- 页面必须展示业务时区、数据截止时间和最近核对时间，避免财务将未到截止时间的数据当成最终结果。
4.2 对账金额
- 通道侧金额取该笔成功收款的实际支付金额，不取扣除手续费后的结算净额。
- 入账侧金额取该笔资金在 FCS 已成功入账的合计金额。
- 一笔通道收款被 FCS 分配到多个期次或多个账务组件时，应先按同一资金事实汇总，再与通道收款金额比较；不得把每个分配明细分别与通道总额比较。
- 金额比较必须在同一币种和该币种精度下进行。首期不做跨币种换算。
- 通道收款金额为用户实际支付的全额；通道费、税费和结算净额单独展示。通道未返回某项时标记为“未返回”，不得虚构为 0。
- 通道费不等同于向用户收取的费用，也不计入用户入账差额；用户入账差额仍以通道收款金额与 FCS 入账合计比较。
4.3 对账对象
每个对账对象代表一笔真实收款资金及其对应的用户入账结果，至少关联：
- App、国家、币种和业务日。
- 还款方式和支付通道。
- 内部还款订单 / 支付订单。
- 通道交易参考号。
- 客户和借据。
- 通道实收金额与状态。
- FCS 入账金额与状态。
- 首次收款、首次入账及最近状态更新时间。
客户、账户和卡信息默认脱敏。财务对账不依赖客户姓名或完整账号完成匹配。
4.4 通道收款明细获取与权威性
对账任务须从通道商户侧获取全量收款明细，而不是只依赖本系统回调记录。通道商户后台导出的文件可作为财务复核证据和应急补数来源，但自动对账以已授权的通道交易明细拉取结果为准；WebHook 仅用于及时发现和触发补查，不单独构成收款成功基准。
| 通道 | 日常全量收款来源 | 单笔补查来源 | 手续费 / 结算核验来源 | 不可作为唯一基准 |
|---|---|---|---|---|
| Paystack | 商户集成下按时间范围、成功状态全量获取交易明细；也可生成通道交易导出文件用于财务留档 | 以支付参考号获取单笔交易结果，核实状态、实收金额、币种和成功时间 | 单笔交易返回的实际费用；结算清单及其交易组成用于复核已结算金额、费用合计和结算归属 | 前端跳转结果、仅有的内部回调、按费率公式推算的手续费 |
| Monnify | 商户集成下按时间范围、支付状态全量获取交易明细；虚拟账户收款纳入对应的保留账户交易明细 | 以支付参考号或通道交易参考号查询交易状态，核实实收金额、支付时间和支付状态 | 通道返回的结算金额及结算归属；按结算参考号取得的交易组成用于复核 | 前端回跳、仅有的通知消息、将实收金额与结算金额差额直接当作确定手续费 |
通道数据采集的共同规则：
- 每次采集按
业务日开始时间 - 数据截止时间取数并完成全部分页；保存来源、拉取时间、原始文件或结果版本、记录数和截止位置。 - Paystack 仅以交易状态为
success的交易形成成功收款事实；Monnify 仅以支付状态为PAID的交易形成全额成功收款事实。OVERPAID、PARTIALLY_PAID、PENDING、REVERSED等须分别保留并按差异规则处理，不能混入全额已收款。 - 通道返回的金额统一按币种精度还原后入库；Paystack 的金额和费用须按其币种最小单位处理，不能把最小单位直接作为页面金额。
- 通道交易明细、单笔补查结果和商户后台导出发生不一致时，批次标记“通道数据冲突”，不自动覆盖历史版本；由支付运营复核通道侧证据。
- 通道手续费优先使用交易明细直接提供的费用。只有通道明确提供结算金额而未提供费用时，才可在“结算扣减（待确认）”中展示
实收金额 - 结算金额；该值不得写入“通道费”、不得参与用户入账差额，也不得按费率反推替代。
4.5 对账基准与判断流程
对账基准：一笔已被通道确认成功的收款资金事实，按唯一通道参考关系关联到内部订单，再与该资金事实对应的 FCS 成功入账合计比较。
flowchart LR A[Paystack / Monnify 全量交易明细] --> B{通道最终成功?} W[通道 Webhook] --> C[按参考号单笔补查] C --> B B -- 否 / 未知 --> D[待确认或通道侧异常] B -- 是 --> E[通道收款事实\n实收金额、币种、成功时间、参考号] E --> F{唯一关联内部订单?} F -- 否 --> G[参考关系缺失或多重匹配] F -- 是 --> H[FCS 成功入账分项汇总] H --> I{金额与币种一致?} I -- 是 --> J[已匹配] I -- 否 --> K[金额 / 币种差异]
| 判断层级 | 对账事实 | 基准字段 | 结论规则 |
|---|---|---|---|
| ① 通道收款成立 | Paystack 成功交易 / Monnify 已支付交易 | 通道状态、实收金额、币种、成功时间、通道参考号 | 未达到最终成功状态时，不产生“已收款”结论，只进入待确认或通道异常 |
| ② 订单关联成立 | PMT 保存的内部订单与通道参考关系 | 内部订单号、内部还款订单号、支付订单号、通道参考号 | 只能唯一关联；无关联或一对多 / 多对一均不得自动匹配 |
| ③ 用户入账成立 | FCS 成功还款入账及收费科目分项 | 入账状态、入账金额、币种、入账时间 | 同一资金事实对应的全部成功分项先汇总；失败、撤销、处理中分项不计入成功入账 |
| ④ 逐笔对账结论 | 通道收款事实与 FCS 入账汇总 | 币种、通道收款金额、FCS 入账合计 | 币种和金额均一致才为已匹配；其余进入明确差异类型 |
| ⑤ 结算 / 手续费复核 | 通道结算清单 | 结算批次、通道费、结算净额 | 仅用于验证通道费与结算归属，不能替代 ①—④ 的用户收款与入账对账 |
通道实际收款、用户入账和结算款是三层不同事实：
用户支付全额（通道收款基准） ──逐笔匹配──> FCS 用户入账合计
│
└──通道费 / 税费 / 结算扣减──> 通道结算净额（财务结算复核，不参与用户入账差额）外部能力依据：Paystack 的交易明细、单笔核验和交易导出及结算与结算交易明细；Monnify 的交易状态与全量交易查询及交易核验说明。上线前应以生产商户已开通能力再次确认。
4.6 后续退款的对账口径
退款不得覆盖或删除原收款事实。系统为同一笔交易保留两条独立对账轴：
flowchart LR P[原通道成功收款 P] --> A[收款轴] B[FCS 原成功入账 B] --> A R[通道累计成功退款 Rp] --> C[退款轴] F[FCS 累计退款冲正 Rf] --> C A --> D{P = B?} C --> E{Rp = Rf?} D --> G[原收款结论] E --> H[退款影响结论] G --> I[综合展示] H --> I
| 指标 | 计算口径 | 用途 |
|---|---|---|
原通道收款 P | 原交易的通道实收金额 | 与 FCS 原入账合计比较，退款后仍不改写 |
FCS 原入账 B | 原资金事实对应的成功入账分项合计 | 与 P 比较 |
通道累计成功退款 Rp | 同一原交易下所有最终成功退款去重后的金额合计 | 与 FCS 退款冲正比较；处理中和失败退款不计入 |
FCS 累计退款冲正 Rf | 与退款事实关联的成功冲正 / 退款入账金额合计 | 与 Rp 比较 |
| 通道净保留金额 | P - Rp | 汇总辅助，不可替代两条逐笔对账轴 |
| FCS 净入账金额 | B - Rf | 汇总辅助；净额相等也不能掩盖原收款或退款轴上的差异 |
退款事实来源：Paystack 支持部分或全额退款，退款具有 pending、processing、needs-attention、failed、processed 等状态；仅 processed 计入成功退款。Monnify 通过退款列表 / 单笔退款状态及成功、失败退款通知提供退款事实；仅通道最终成功状态计入成功退款。Webhook 到达后仍需按退款参考号补查权威状态并去重。参考：Paystack Refunds、Monnify Transaction Refunds。
4.6.1 退款状态处理
| 退款状态 / 场景 | 是否计入 Rp | 原收款处理 | FCS 处理要求 | 对账结论 |
|---|---|---|---|---|
| 已发起、待处理、处理中 | 否 | 原成功收款保持不变 | 不得因退款申请提前冲正已入账金额 | 退款待确认；超过时效进入账龄关注 |
| 需要补充资料 | 否 | 原成功收款保持不变 | 不得提前冲正 | 退款待处理，提示责任团队补充资料 |
| 退款失败 | 否 | 原成功收款保持不变 | 已入账金额应继续有效；若已提前冲正则形成差异 | 退款失败，或“退款失败但账务已冲正” |
| 部分退款成功 | 是，按实际成功金额 | 原收款仍保留全额 | 仅冲正对应退款金额及实际收费科目 | 比较累计成功退款与累计冲正 |
| 全额退款成功 | 是，累计至原收款金额 | 原收款仍保留全额并关联反向资金事实 | 已入账时应完成等额冲正；未入账时按退款先于入账规则处理 | 已退款匹配或退款差异 |
| 多次部分退款 | 是，逐笔去重后累计 | 每笔退款均关联同一原收款 | 每次冲正保留独立参考，累计不得超过原入账可冲正金额 | 按单笔退款核对，并展示累计结果 |
| 退款成功后又发生退款冲回 / 撤销 | 按通道最终反向结果恢复对应额度 | 保留退款及退款冲回两条事实 | FCS 同步恢复相应账务影响 | 单独形成“退款冲回”核对，不删除成功退款历史 |
| 非系统发起的通道退款 | 是 | 通过通道全量退款明细发现 | 必须关联内部订单和原因；无法关联时不得自动冲正 | 通道有退款、内部无退款记录 |
| 内部记录已发起但通道无退款 | 否 | 不产生通道反向事实 | 不得视为已退款或完成冲正 | 内部退款无通道记录 |
4.6.2 退款与入账先后顺序
| 顺序 | 核对规则 |
|---|---|
| 先入账、后退款 | 默认路径。先保持 P = B 的原收款结论，再要求成功退款 Rp = Rf；退款处理中不得提前冲正 |
| 全额退款成功、原收款尚未入账 | 若原收款与全额退款均为通道终态、退款关系唯一、FCS 从未入账且业务明确不再入账，可标记“全额退款完成—未入账”，不要求先做一正一反；仍保留两笔通道资金事实 |
| 部分退款成功、原收款尚未入账 | 默认仍应先按原收款入账、再按成功退款冲正。只有 FCS 明确支持退款先于入账的净额入账，并保存退款参考和收费科目依据时，才允许比较 P - Rp 与后续 FCS 入账；该记录单列为“退款先于入账—净额核对” |
| 退款处理中、原收款尚未入账 | 不得用“可能退款”抵消通道已收款未入账差异；原收款仍按未入账处理，退款单独显示待确认 |
| 退款失败、FCS 已提前冲正 | 形成高优先级差异，要求恢复账务或重新执行有效退款；不能因两边净额暂时接近而关闭 |
4.6.3 退款匹配与金额规则
- 退款首先按通道退款参考号去重，再通过原通道交易参考号关联原收款，最后关联内部退款记录和 FCS 冲正记录。
- 同一原收款可对应多笔部分退款；累计成功退款不得超过原通道实收金额。超额、币种不同或关联多个原交易时标记“退款数据冲突”。
- 退款手续费、不可退的原交易手续费和汇兑差额单独展示，不计入用户退款金额，也不得通过修改
Rp或Rf消除差异。 - 原收款日和退款成功日分别归属各自业务日。退款日批次记录反向资金事实，并关联原收款业务日；已确认的原批次显示“确认后发生退款”，保留原版本，不静默改写。
- 退款通知重复、状态反复或主动查询与通知不一致时，以通道单笔退款最终查询为准；每次变化保留版本轨迹。
- 争议扣款、拒付、通道自动冲正与商户主动退款来源不同，须分别标识，但均按独立反向资金事实处理；首期不得把拒付自动伪装成普通退款。
5. 每日对账批次
5.1 生成规则
- 每个业务日结束后自动生成该业务日的对账批次，默认在次日 02:00 首次执行，具体时间可按国家和通道配置。
- 生成前分别确认通道侧和 FCS 侧的数据截止位置；任一侧数据缺失、获取失败或不完整时，批次标记为“数据不完整”或“生成失败”，不得显示为“无差异”。
- 同一业务日、App、币种和通道重复执行时更新同一批次版本，不新增互相冲突的正式批次。
- 对迟到回调、主动查单和延迟入账进行自动复核。默认在次日 10:00 和第二日 02:00 再次核对，时间支持配置。
- 已被财务复核的批次再次执行时，保留原复核记录，并清楚标识新增、已消除和仍存在的差异。
- 所有批次均记录生成时间、双方数据截止时间、数据完整性、规则版本、最近核对时间和结果版本。
5.2 批次状态
| 批次状态 | 含义 | 可用操作 |
|---|---|---|
| 生成中 | 正在采集和匹配双方数据 | 查看进度，不可确认 |
| 数据不完整 | 至少一侧数据未达到截止位置或部分获取失败 | 查看缺失来源、重新核对 |
| 待复核—无差异 | 当前版本逐笔匹配且数据完整 | 查看明细、导出、财务确认 |
| 待复核—有差异 | 当前版本存在待确认或已确认差异 | 查看差异、认领、导出、重新核对 |
| 已复核 | 财务已完成当前版本复核 | 查看、导出；新数据到达后提示重新复核 |
| 生成失败 | 未形成可用批次 | 查看失败分类、重新生成 |
“无差异”只代表当前完整数据范围内逐笔核对通过，不等于支付通道结算款已到账公司银行账户。
6. 自动匹配与差异分类
6.1 匹配优先级
- 通道交易参考号与内部保存的通道参考关系唯一一致。
- 内部支付订单与 FCS 入账记录的原始还款参考关系唯一一致。
- 同一真实资金下的多个 FCS 分配明细汇总后进行比较。
- 仅金额、客户和时间相近但缺少稳定参考关系时，只能作为人工排查候选，不得自动判定匹配。
- 一个通道交易匹配多个互不相同的内部资金对象，或一个内部对象匹配多个通道交易时，判定为重复 / 多重匹配异常。
6.2 对账结果
| 对账结果 | 判定口径 | 是否计入差异 |
|---|---|---|
| 已匹配 | 通道成功、FCS 已入账，币种与金额一致，参考关系唯一 | 否 |
| 通道已收款、用户未入账 | 通道已确认成功，但 FCS 无对应成功入账或仍在入账中 | 是 |
| 用户已入账、通道无有效收款 | FCS 已入账，但通道无对应记录或权威状态不是成功 | 是 |
| 金额不一致 | 参考关系一致，但通道实收与 FCS 入账合计不一致 | 是 |
| 币种不一致 | 关联记录币种不同 | 是 |
| 状态冲突 | 通道失败、自动冲正、拒付或其他非退款终态与 FCS 入账结果冲突 | 是 |
| 退款待确认 | 退款处于待处理、处理中或需补资料状态 | 单列待确认，不计入成功退款金额 |
| 退款已匹配 | 通道累计成功退款与 FCS 累计成功冲正金额、币种及参考关系一致 | 否 |
| 通道退款成功、FCS 未冲正 | 原收款已入账，通道退款最终成功，但无对应成功冲正或冲正金额不足 | 是 |
| FCS 已冲正、通道退款未成功 | FCS 已冲正，但退款仍在处理、失败或通道无有效退款记录 | 是，高优先级 |
| 退款金额不一致 | 通道累计成功退款与 FCS 累计成功冲正金额不同 | 是 |
| 退款参考缺失 / 重复退款 | 退款无法唯一关联原收款，或同一退款被重复累计 | 是 |
| 重复 / 多重匹配 | 一笔资金被重复消费、重复入账或存在多个无法唯一确定的匹配对象 | 是 |
| 通道处理中 / 结果未知 | 通道尚无权威终态，暂不能判断是否真实收款 | 单列待确认，不并入已确认差异金额 |
| 参考关系缺失 | 存在单侧记录，但缺少稳定参考号，无法自动匹配 | 是 |
对账结果表示双方当前资金事实；处理状态表示人员是否已跟进。人工关闭差异不得把“通道已收款、用户未入账”等事实改写为“已匹配”。
7. 财务对账页面
后台增加一级菜单 Finance，其下增加 Daily Reconciliation。功能级配置不得各自增加配置菜单；所有跨功能 Webhook 配置统一进入 System Management > System Settings，仅系统管理员可见和维护。首期不设置播报记录菜单。
页面结构如下：
| 页面 | 菜单 / 入口 | 核心用途 | 默认角色 |
|---|---|---|---|
| 每日总体概览 | Finance > Daily Reconciliation > Overview | 查看所选业务日的总体结论、双方汇总、差异分布和处理进度 | 财务运营、支付运营、审计只读 |
| 对账批次 | Finance > Daily Reconciliation > Batches | 按 App、国家、币种和通道查询批次并进入明细 | 财务运营、支付运营、审计只读 |
| 差异处理 | 从概览、批次或差异列表进入 | 核对单笔双方事实，认领、转派、重新核对和关闭处理 | 财务运营、支付运营、系统支持 |
| 系统设置—每日对账播报 | System Management > System Settings > Daily Reconciliation Webhook | 在统一系统设置内配置总体结论播报范围、触发时机、接收地址和启停状态 | 系统管理员 |
7.1 每日总体概览
总体概览默认展示最近一个已生成业务日，并支持切换业务日、App、国家、币种和支付通道。页面必须先展示明确的总体结论：
| 总体结论 | 判定口径 |
|---|---|
| 对账完成—无差异 | 所选范围数据完整，所有终态交易逐笔匹配，不存在待确认或已确认差异 |
| 对账完成—有差异 | 所选范围数据完整，但存在至少一笔已确认差异 |
| 对账待确认 | 所选范围数据完整，不存在已确认差异，但仍有通道处理中或结果未知记录 |
| 数据不完整 | 至少一个应纳入批次的数据源未达到截止位置或部分获取失败 |
| 对账失败 | 至少一个必要批次未能生成可用结果 |
| 尚未生成 | 业务日未结束或尚未到对账执行时间 |
总体概览展示：
- 业务日、业务时区、数据截止时间、当前结果版本和最近核对时间。
- 覆盖的 App、国家、币种、支付通道及批次数量。
- 通道收款笔数 / 金额、FCS 入账笔数 / 金额、已匹配笔数 / 金额。
- 当日成功退款笔数 / 金额、退款待确认笔数 / 金额、退款冲正匹配及退款差异笔数 / 金额；不得与原收款净额相抵后只展示净结果。
- 待确认、已确认差异及各差异类型的笔数 / 金额。
- 未处理、处理中、已关闭差异数量和最长未关闭账龄。
若筛选范围包含多个币种，各币种金额必须分组展示，只允许汇总笔数，禁止形成跨币种总金额。
7.2 批次列表
查询条件：
- 业务日期范围。
- App、国家、币种。
- 支付通道、还款方式。
- 批次状态、是否有差异。
- 数据完整性。
列表字段：
- 业务日和业务时区。
- App、国家、币种、支付通道。
- 批次状态、数据截止时间、最近核对时间。
- 通道收款笔数 / 金额。
- FCS 入账笔数 / 金额。
- 已匹配笔数 / 金额。
- 待确认笔数 / 金额。
- 差异笔数、通道侧未入账金额、内部单边入账金额和绝对差额。
- 未处理、处理中、已关闭差异数量。
净差额只能作为汇总辅助，不能代替逐笔核对。两笔方向相反的差异不得相互抵消后显示为无差异。
7.3 批次详情
批次详情顶部展示双方汇总、各差异类型分布、账龄分布和处理进度。明细支持按以下条件筛选：
- 对账结果、处理状态、账龄。
- App、通道、还款方式、币种。
- 内部还款订单号、支付订单号、通道交易参考号。
- 客户 ID、借据 ID。
- 收款时间、入账时间。
- 金额范围。
逐笔明细至少展示：
| 分组 | 字段 |
|---|---|
| 归属 | 业务日、App、国家、币种、通道、还款方式 |
| 关联标识 | 内部订单号、内部还款订单号、支付订单号、通道交易参考号、客户 ID、借据 ID |
| 通道侧 | 通道状态、收款金额、通道费、结算净额（通道返回时）、收款时间、最近确认时间 |
| 退款侧 | 原交易参考号、退款参考号、退款类型、退款状态、退款金额、累计成功退款、退款发起 / 完成时间、退款来源 |
| 入账侧 | FCS 入账状态、入账合计、收费科目及分项金额、累计成功退款冲正、冲正科目、入账 / 冲正时间、分配期次数、最近更新时间 |
| 对账结论 | 对账结果、差额、首次发现时间、账龄、最近核对时间、数据版本 |
| 处理信息 | 处理状态、负责人、原因分类、处理结论、关联工单 / 异常单、最后处理时间 |
点击明细可查看双方状态轨迹、FCS 分配明细、收费科目分项、自动核对记录和人工处理记录。收费科目按 FCS 实际记账归属展示，例如本金、利息、服务费、管理费、罚息 / 逾期利息、保险 / 担保费和其他费用；不适用的科目不展示，不以占位金额补齐。普通财务页面不展示通道原始报文、密钥、完整卡号、完整银行账号、BVN、手机号或原始错误堆栈。
7.4 差异处理详情
具备处理权限的人员可以：
- 认领、转派或解除认领差异。
- 选择标准原因分类并填写处理说明。
- 关联已有工单 / 异常单，或记录需由哪个责任系统继续处理。
- 上传或引用必要的核对证据；证据遵守访问权限和保存期限。
- 发起“重新核对”，读取双方最新权威结果。
- 在事实已匹配后关闭；或在差异已移交到独立资金处理流程后，以“差异保留、处理闭环”方式关闭。
关闭差异必须填写处理结论；涉及资金修正时必须关联实际处理记录。仅填写备注、口头确认或金额看似相等不能关闭为“已匹配”。
7.5 系统设置中的每日对账 Webhook 配置
Webhook 配置用于将每日总体结论播报到财务或运营协作群，不发送逐笔交易明细。配置作为 System Management > System Settings 中的“每日对账 Webhook”设置项呈现，包含配置列表、新建 / 编辑抽屉和消息预览；不得因每日对账或任何其他业务功能新增独立配置菜单。
每条配置至少包含：
| 配置项 | 规则 |
|---|---|
| 配置名称 | 在后台唯一且可识别，不使用接收地址作为名称 |
| 启用状态 | 草稿、已启用、已停用；新建默认草稿，测试成功不自动启用 |
| 数据范围 | 选择 App、国家、币种和支付通道；只能选择配置人有管理权限的范围 |
| 播报时机 | 首次总体结论生成后、财务确认后；至少选择一种 |
| 结论类型 | 可选择全部、无差异、有差异、待确认、数据不完整或对账失败 |
| 变更播报 | 可选择总体结论或关键汇总发生变化时发送更正播报 |
| 播报时间 | 按配置范围的业务时区设置；早于数据截止时间时不得执行正式播报 |
| Webhook 地址 | 仅在有配置权限的页面录入，保存后脱敏展示；列表、日志和导出不得展示完整值 |
| 签名密钥 | 可选；仅支持设置或更换，保存后不可回显明文 |
| 备注 | 记录群组用途、责任团队等非敏感说明，不进入播报正文 |
配置规则：
- Webhook 地址必须使用安全地址；禁止指向本地、内网管理地址或其他不允许访问的目标。
- 保存前展示固定模板预览。首期不开放任意消息模板和自由变量，避免把敏感字段或逐笔信息拼入群消息。
- “测试发送”只发送明确标识为测试的模拟结论，不使用真实金额、客户或交易数据。
- 测试成功仅证明当次地址可达，不代表每日正式播报已启用。
- 修改数据范围、Webhook 地址、签名密钥、播报时机或结论类型后，下一次正式播报使用新版本；发送事实与配置版本通过审计记录追溯。
- 停用配置只停止后续播报，不影响每日对账任务和页面结论。
- 同一范围可配置多个接收目标，但保存时提示可能重复播报，由管理员确认。
8. 差异处理流程
每日生成批次
-> 数据完整性校验
-> 自动逐笔匹配
-> 无差异：财务复核并确认
-> 有差异 / 待确认：进入差异队列
-> 认领并核查双方事实
-> 可自动收敛：重新核对后更新结果
-> 需业务处理：关联工单或独立资金处理记录
-> 处理完成后再次核对
-> 事实一致则关闭为已匹配
-> 合法差异仍需保留则记录结论并关闭处理状态
-> 批次达到复核条件后财务确认当前版本批次财务确认条件：
- 双方数据完整。
- 所有已确认差异均已认领并具有处理状态。
- 未关闭差异数量和金额已被财务明确知悉。
- 批次确认记录包含确认人、确认时间、数据版本和未关闭差异摘要。
批次确认不冻结后续真实资金数据。迟到数据改变结果时，系统将批次标记为“确认后有变化”，要求财务复核新版本。
9. 异常与边界场景
| 场景 | 处理规则 |
|---|---|
| 通道数据获取失败 | 批次标记数据不完整或生成失败，告警并允许重试；不得生成无差异结论 |
| FCS 数据获取失败 | 同上，保留已采集的通道数据但不形成最终结果 |
| 通道回调迟到 | 接收后更新原资金事实，重新核对原批次，不新建重复收款 |
| FCS 延迟入账 | 初始显示通道已收款、用户未入账；入账完成后重新核对并保留状态变化轨迹 |
| 同一参考号重复通知 | 合并为同一通道资金事实，标记重复来源，不重复累计金额 |
| 同金额、同客户、相近时间存在多笔 | 不做模糊自动匹配，进入重复 / 多重匹配或参考关系缺失差异 |
| 通道成功金额大于用户应还 | 仍按实际收款核对；超额部分须进入溢缴款 / 退款流程，不得从对账中隐藏 |
| 通道退款或撤销晚于原收款 | 原收款和后续反向资金事实均保留，若 FCS 未同步则产生状态冲突差异 |
| 退款通知重复 | 按退款参考号幂等合并，不重复累计退款金额；状态变化保留轨迹 |
| 多次部分退款 | 逐笔核对并累计，累计成功退款超过原实收金额时标记数据冲突 |
| 退款处理中超过时效 | 保持退款待确认并累计账龄，不提前冲正、不视为失败，也不关闭原收款差异 |
| 退款失败但 FCS 已冲正 | 形成高优先级差异，要求恢复账务或取得新的最终成功退款证据 |
| 通道退款成功但内部无申请 | 保留通道退款事实，标记来源未知并由支付运营核实，不因缺少内部记录而忽略 |
| 原交易发生拒付 / 争议扣款 | 单列为拒付反向资金事实，不混为普通退款；FCS 影响按独立账务处理结果核对 |
| 一笔收款分配多个期次 | 汇总入账金额核对，详情展开各期次分配，不产生伪重复 |
| 人工处理期间数据变化 | 提示当前页面版本已过期，刷新后基于新版本提交，避免覆盖最新结论 |
| 已复核批次出现迟到数据 | 标记确认后有变化，保留原确认记录并要求重新复核 |
10. 权限、脱敏与审计
权限至少拆分为：查看总体概览、查看批次、查看明细、处理差异、重新核对、确认批次、导出、管理系统设置中的 Webhook、测试发送、人工重试 / 重播、查看敏感字段和查看审计。菜单可见不代表自动获得全部 App 数据范围、Webhook 管理权限或导出权限。
规则：
- 所有查询、详情、处理、确认和导出均受角色与 App 数据范围控制。
- 列表和导出默认不提供客户姓名、手机号、完整卡号、完整银行账号或身份信息。
- 如确需查看敏感字段，必须独立授权、按次操作并记录原因和审计。
- 对账记录、原始结果版本和审计记录不得由普通业务人员删除或覆盖。
- Webhook 地址和签名密钥属于敏感配置，前端、日志、导出和审计展示不得回显明文；只有实际发送能力可以使用保存后的有效配置。
- 认领、转派、原因修改、重新核对、关闭、批次确认、导出、Webhook 新建 / 编辑 / 启停、测试发送、人工重试 / 重播和敏感查看均记录操作人、时间、前后状态、结果和追踪标识。
11. 财务明细导出
- 支持按当前筛选条件导出批次汇总或每日逐笔明细；每日逐笔明细按业务日导出，不受页面分页影响。
- 每日逐笔明细至少提供三张工作表：
- “每日对账明细”：一笔对账资金事实一行，包含业务日、App、国家、币种、通道、内部订单号、内部还款订单号、支付订单号、通道交易参考号、通道收款金额、通道费、结算净额（如有）、FCS 入账合计、收费科目汇总、对账结果、差额、收款 / 入账时间和处理状态。
- “收费科目分项”：一笔内部订单的一个实际收费科目一行，包含业务日、内部订单号、内部还款订单号、支付订单号、收费科目、分项入账金额、FCS 入账状态、对账结果及关联对账记录号；该表不重复填写通道收款金额和通道费，避免按科目汇总时重复计算通道金额。
- “退款影响明细”：一笔通道退款一行，包含退款业务日、原收款业务日、App、通道、币种、内部订单号、原通道交易参考号、退款参考号、退款类型、退款来源、退款状态、退款金额、累计成功退款、FCS 累计成功冲正、退款差额、退款发起 / 完成时间和退款对账结论。
- 通道费未返回时导出为空并在文件说明中标记“未返回”；不得用 0 替代。收费科目以 FCS 实际记账归属为准，不得由前端推算或改写。
- 导出基于提交时固定数据版本，文件内展示业务时区、数据截止时间、生成时间、筛选条件和行数。
- 大数据量异步生成，不允许前端翻页拼接全量数据。
- 文件默认脱敏，并记录申请人、App 范围、筛选条件摘要、数据版本、文件摘要、生成结果、过期时间和下载记录。
- 新数据到达不会静默改写已生成文件；需要最新结果时重新发起导出。
- 导出失败、部分数据源不可用或结果超出允许范围时必须明确提示，不生成看似完整的文件。
12. 通知与运营指标
12.1 每日总体结论 Webhook 播报
12.1.1 播报触发
- 达到配置的播报时间且所选范围已形成总体结论后，按启用配置发送一次正式播报。
- 所选范围在数据截止时间仍为数据不完整或对账失败时，按对应结论播报，不等待到次日静默跳过。
- 配置选择“财务确认后”时，仅在当前数据版本完成财务确认后发送。
- 已播报结论因迟到回调、延迟入账或重新核对发生变化时，只有开启“变更播报”才发送更正消息；更正消息必须同时展示原结论、新结论和新数据版本。
- 同一配置、业务日、播报范围、触发场景和数据版本只允许有一次成功正式播报。失败重试复用原审计追踪标识，不生成多个看似独立的结论。
12.1.2 播报内容
每日总体结论消息使用固定结构，至少包含：
- 标题：每日还款对账结论，并标识正式、测试、更正或人工重播。
- 业务日、业务时区、覆盖范围、数据截止时间和结果版本。
- 总体结论及数据完整性。
- 按币种分别展示通道收款、FCS 入账、已匹配、待确认和差异的笔数 / 金额。
- 各差异类型数量、未关闭差异数量和最长账龄。
- 生成时间及后台总体概览 / 批次详情入口。
播报内容不得包含客户姓名、手机号、卡号、银行账号、BVN、客户 ID、借据 ID、订单号、通道参考号、逐笔金额、处理备注、原始错误或 Webhook 配置值。后台入口必须在登录和权限校验后才能查看数据。
12.1.3 失败与重试
- 发送失败不改变总体结论、批次状态或财务确认状态。
- 系统进行有界自动重试，默认在失败后 1、5、15 分钟重试，最多 3 次；重复尝试不得产生重复成功播报。
- 地址无效、权限拒绝、签名失败等不可恢复错误可提前停止自动重试，并在审计记录中保留稳定失败分类。
- 自动重试耗尽后通知系统支持，并允许具备权限的人员在修正配置后人工重试。
- 人工重试使用当前有效配置，但消息仍关联原业务日和原数据版本；若数据版本已变化，应提示改为发送更正播报。
12.2 运营通知
- 批次生成失败或数据不完整：通知支付运营和系统支持。
- 通道已收款、用户未入账超过业务时限：按金额和账龄升级通知财务与账务责任人。
- 状态冲突、重复 / 多重匹配、币种不一致：作为高优先级差异通知。
- 批次确认后出现新差异：通知原确认人和当班财务。
- 通知失败不改变批次或差异事实，也不能自动关闭异常。
12.3 核心指标
- 每日通道收款笔数 / 金额、FCS 入账笔数 / 金额。
- 逐笔匹配率和金额匹配率。
- 通道已收款未入账笔数 / 金额及 15 分钟、30 分钟、2 小时、24 小时账龄分布。
- 内部单边入账、金额不一致、状态冲突、重复 / 多重匹配数量。
- 各 App、通道、还款方式的差异率。
- 差异首次响应时长、平均关闭时长、超时未关闭数。
- 自动复核后消除的差异数与长期未收敛差异数。
- 每日总体结论播报应发数、成功数、失败数、重试成功率、平均送达时长和重复成功数；重复成功目标为 0。
13. 非功能要求
- 金额计算使用币种对应精度，不使用展示格式后的数值参与比较。
- 同一批次重复生成、重复核对和重复回调不得重复累计资金。
- 批次汇总必须能够回溯到逐笔明细，逐笔明细能够回溯到双方来源和结果版本。
- 页面展示的是哪一个数据版本必须明确；处理提交时发现版本变化应阻止覆盖并提示刷新。
- 对账任务故障不得影响支付回调接收、主动查询、FCS 正常入账和既有补偿任务。
- Webhook 发送和重试异步执行，不阻塞对账批次生成、总体结论展示或财务确认；单一接收目标故障不得影响其他配置。
- 对账明细、处理记录、确认记录和导出审计按财务及审计制度保存；未确认制度前不得设置短于现有资金流水保存期限的清理策略。
14. 验收标准
- 每个业务日能按 App、国家、币种和支付通道生成唯一可追溯的对账批次，并展示双方数据截止时间。
- 任一数据源缺失或获取不完整时，批次明确显示“数据不完整 / 生成失败”，不会显示为无差异。
- 通道成功且 FCS 入账金额、币种和参考关系一致的交易逐笔标记为已匹配。
- 能准确分类通道已收款未入账、内部单边入账、金额不一致、币种不一致、状态冲突、重复 / 多重匹配和参考关系缺失。
- 通道处理中或结果未知的交易单列待确认，不混入已确认差异金额，也不当作失败释放。
- 一笔收款分配到多个 FCS 期次时按资金事实汇总核对，详情可展开分配明细且不产生重复金额。
- 跨日回调或延迟入账能更新原批次；已复核批次发生变化时保留原记录并提示重新复核。
- 财务能按日期、App、通道、状态、差异类型、处理状态、订单参考和金额范围查询逐笔明细。
- 批次汇总分别展示通道收款、FCS 入账、匹配、待确认和各方向差异，不以净额相抵掩盖逐笔差异。
- 财务可认领、转派、备注、关联处理记录、重新核对和关闭处理；人工动作不能直接修改通道或 FCS 权威事实。
- 差异关闭必须有标准原因和结论；资金修正类差异必须关联实际处理记录。
- 支持按固定数据版本异步导出财务汇总和每日逐笔明细；每日逐笔明细同时提供对账明细和收费科目分项，包含通道收款金额、通道费、内部订单号和实际收费科目，且不因收费科目拆分重复累计通道金额。文件展示截止时间、筛选条件、生成时间和行数，且默认脱敏。
- 查询、敏感查看、认领、转派、重新核对、关闭、批次确认、导出和下载均受权限与 App 数据范围控制并完整审计。
- 通道参考号重复通知不会重复累计；一对多或多对一无法唯一匹配时不会自动判定已匹配。
- 对账任务失败不会阻断正常收款、回调、查单、FCS 入账和既有补偿任务。
- 后台提供总体概览、对账批次和差异处理页面；每日对账 Webhook 统一置于系统设置，各页面受角色与 App 数据范围控制，且不提供播报记录菜单。
- 总体概览能按业务日展示唯一明确的总体结论；多币种范围按币种分别展示金额，不生成跨币种总金额。
- 管理员可按 App、国家、币种和支付通道配置总体结论的播报时机、结论类型、变更播报、Webhook 地址及启停状态。
- Webhook 测试只发送标识清楚的模拟结论，不使用真实交易数据；测试成功不会自动启用正式播报。
- 正式播报包含业务日、时区、范围、数据截止时间、总体结论、按币种汇总、差异摘要、数据版本和受权限保护的后台入口，不包含逐笔或敏感信息。
- 同一配置、业务日、范围、触发场景和数据版本只成功播报一次；自动重试或人工重试不会产生未标识的重复消息。
- 播报失败不改变对账结论和财务确认状态；自动重试耗尽后可查询稳定失败分类并由有权限人员人工恢复。
- 结论播报后因迟到数据发生变化时，开启变更播报的配置能发送带原结论、新结论和新版本的更正消息。
- Webhook 地址和签名密钥加密保存并在页面、日志、导出和审计展示中脱敏；配置、测试、启停、重试和重播完整审计。
- 原收款和后续退款作为独立资金事实保留；退款不会覆盖原交易成功状态、原金额或原批次快照。
- 退款待处理、处理中、需补资料和失败状态不计入成功退款金额，也不会触发 FCS 提前冲正；退款最终成功后才核对退款与账务冲正。
- 支持全额退款、部分退款、多次部分退款、跨日退款、退款失败、退款冲回、非系统发起退款及拒付场景，并能形成明确结论。
- 原收款轴与退款轴分别核对；即使通道净保留金额与 FCS 净入账金额相等，也不会用净额抵消两条轴上的逐笔差异。
- 已确认批次后发生退款时保留原确认版本，在退款业务日记录反向资金事实，并在原批次标识“确认后发生退款”。
- 导出包含退款影响明细，能按退款参考号追溯原收款、内部订单、通道成功退款和 FCS 冲正结果，重复通知不会重复累计。
15. 上线建议
- 影子期：连续运行至少 7 个业务日，只生成结果，不开放批次确认；由财务抽样核对通道后台和 FCS 明细。
- 校准期：确认各通道成功状态、时间口径、金额口径、迟到数据窗口和唯一参考关系，修正误差后再开放正式确认。
- 正式期：开放财务认领、导出和批次确认，保留影子期数据但明确标识不可作为正式财务结论。
- 运行观察：按差异类型、App、通道和账龄持续观察重复与迟延情况，再决定是否启动 34、35 号需求及其优先级。