# 连锁业务对账系统端到端业务流程

## 1. 文档目的

本文档定义连锁餐饮业务从基础资料准备、业务数据接入、对账核销、差异处理、结果确认、可分账输出，到分账后银行入账反馈的端到端业务流程。

本文档是 P1-04 流程设计成果，作为状态流转、产品能力地图、核销规则、权限设计、页面原型和验收场景的输入。

## 2. 流程范围

### 2.1 流程起点

满足以下任一条件时启动流程：

- 业务系统产生新增或变更的订单、支付明细、退款数据。
- 支付渠道或业务平台产生渠道账单明细、结算单、费用或调整项。
- 门店产生现金账户流水或现金汇缴记录。
- 内部权益系统产生券核销、储值扣减或权益退回流水。
- 分账系统返回分账执行和银行入账反馈。
- 财务或运营人员发起补数、重新核销、人工确认或差异复核。

### 2.2 对账主流程终点

对账主流程以以下结果之一作为终点：

- 支付明细生成可分账结果并成功交付分账系统。
- 支付明细因前置条件未满足保持不可分账。
- 支付明细因争议、退款待确认或人工控制进入暂缓分账。

### 2.3 后置反馈终点

分账系统完成分账后，向对账系统反馈分账结果及银行汇总入账结果。对账系统完成入账关联和金额验证后，形成已入账、部分入账、待入账、入账失败或退回、入账差异等结果。

银行入账状态不回写订单核销结果。

## 3. 参与系统与职责

| 参与方 | 输入或操作 | 核心职责 |
| --- | --- | --- |
| POS、收银及点餐系统 | 订单、支付构成、退款、门店信息 | 提供门店业务发生事实 |
| 外卖、团购及其他业务平台 | 平台订单、券核销、退款、账单、结算单、费用、补贴 | 提供平台业务和结算事实 |
| 支付渠道及聚合支付系统 | 支付流水、退款流水、交易账单、结算数据 | 提供外部资金交易事实 |
| 会员及权益系统 | 储值、券、积分和权益流水 | 提供内部权益变化事实 |
| 门店现金账户 | 现金收款、退款、调整和汇缴流水 | 提供现金资金变化事实 |
| 对账系统 | 标准化、归属、核销、差异、确认和输出 | 生成可信可分账结果 |
| 财务人员 | 差异处理、人工核销、结果确认和冻结 | 对金额及财务结果负责 |
| 业务运营人员 | 门店映射、平台规则、活动和业务异常确认 | 对业务归属和渠道规则负责 |
| 门店人员 | 现金、订单、退款和业务凭证确认 | 对门店业务事实负责 |
| IT 部门 | 接口、任务、补数、映射和数据质量处理 | 保证数据链路稳定 |
| 分账系统 | 接收可分账结果、执行分账、反馈入账 | 负责最终分配和资金入账 |

## 4. 流程前置条件

正式执行自动对账前，至少需要完成：

1. 客户企业、品牌、加盟商、门店和区域资料已建立。
2. 门店在业务发生自然日存在唯一有效经营主体。
3. 结算渠道、结算主体、商户号和银行账户已建立。
4. 系统门店、商户号和渠道门店映射已生效。
5. 业务类型、下单方式、订单来源、履约方式和支付方式字典已配置。
6. 渠道数据接入、字段映射、金额口径和时间口径已配置。
7. 匹配规则、D+N/T+N 结算周期、费用容差和差异阻断规则已生效。
8. 分账系统接口及可分账结果接收确认机制已启用。

前置资料缺失不应阻止原始数据接收，但相关标准数据必须进入待归属、待配置或待人工确认状态。

## 5. 端到端主流程

```mermaid
flowchart TD
    A["业务、渠道或内部账户产生数据"] --> B["接收原始数据并保留原文"]
    B --> C{"基础校验是否通过"}
    C -- 否 --> C1["记录接入失败或数据质量差异"]
    C1 --> C2["补数、修正配置或重新处理"]
    C2 --> B
    C -- 是 --> D["转换为标准业务对象"]
    D --> E["解析客户、门店、经营主体和结算主体归属"]
    E --> F{"归属是否唯一且有效"}
    F -- 否 --> F1["生成归属差异并转人工确认"]
    F1 --> F2{"人工确认完成"}
    F2 -- 否 --> Z1["保持不可核销、不可分账"]
    F2 -- 是 --> G
    F -- 是 --> G["校验订单与支付构成平衡"]
    G --> H{"支付构成是否平衡"}
    H -- 否 --> H1["生成订单支付不平差异"]
    H1 --> Z1
    H -- 是 --> I["按支付明细选择核销路径"]
    I --> J["执行支付、权益、现金或退款核销"]
    J --> K["关联渠道结算、费用和调整项"]
    K --> L["识别未核销、金额、费用、时效和重复差异"]
    L --> M{"是否存在阻断型差异"}
    M -- 是 --> M1["进入差异协同处理"]
    M1 --> M2{"差异是否关闭或解除阻断"}
    M2 -- 否 --> Z2["不可分账或暂缓分账"]
    M2 -- 是 --> N
    M -- 否 --> N["确认支付明细对账结果"]
    N --> O{"是否满足可分账条件"}
    O -- 否 --> Z2
    O -- 是 --> P["生成支付明细级可分账结果"]
    P --> Q["输出分账系统并等待接收确认"]
    Q --> R{"分账系统是否成功接收"}
    R -- 否 --> R1["记录输出失败并重试"]
    R1 --> Q
    R -- 是 --> S["标记分账系统已接收"]
    S --> T["接收分账结果和银行入账反馈"]
    T --> U["建立分账结果与入账反馈关联"]
    U --> V["验证应入账与实际入账金额"]
    V --> W{"入账是否一致"}
    W -- 否 --> W1["生成后置入账差异"]
    W -- 是 --> X["形成已入账或部分入账结果"]
```

## 6. 主流程阶段

| 阶段 | 主要输入 | 核心处理 | 主要输出 |
| --- | --- | --- | --- |
| P01 原始数据接收 | 订单、支付、退款、账单、结算、权益、现金、分账反馈 | 保存原始报文、校验文件或接口任务 | 原始数据、接入任务结果 |
| P02 标准化 | 已通过基础校验的原始数据 | 字段映射、金额转换、时间转换、业务去重 | 标准业务对象 |
| P03 业务归属 | 标准业务对象、主数据和映射关系 | 确认客户、门店、经营主体、结算主体 | 已归属数据或归属差异 |
| P04 完整性校验 | 订单、支付明细、退款和账户流水 | 校验订单有效性、支付平衡和对象关联 | 可核销数据或完整性差异 |
| P05 对账核销 | 支付明细、账单明细、权益流水、现金流水、退款流水 | 自动匹配并生成核销记录 | 已核销、部分核销或未核销结果 |
| P06 渠道结算确认 | 账单明细、结算归集明细、结算单和结算批次 | 判断未结算、部分结算、已结算 | 渠道结算状态 |
| P07 费用与调整 | 费用项、容差规则、结算调整项 | 识别正常费用、费用异常和调整归属 | 费用结果、调整项及分摊结果 |
| P08 差异协同 | 各阶段生成的差异 | 分派、处理、复核、关闭或暂缓 | 差异处理结果 |
| P09 对账确认 | 核销、退款、结算、费用和差异结果 | 确认支付明细最终对账结果 | 支付明细确认金额 |
| P10 分账准备 | 对账结果和结算主体关系 | 判断可分账、不可分账或暂缓分账 | 可分账结果 |
| P11 分账输出 | 可分账结果、调整项 | 输出、重试和接收确认 | 分账系统已接收结果 |
| P12 后置入账验证 | 分账结果、银行入账反馈 | 建立金额关联并验证 | 入账状态和入账差异 |

## 7. 数据接入与标准化流程

### 7.1 接入依赖

不同数据可以异步到达，不要求严格按顺序接收。业务处理逻辑按以下依赖推进：

```text
基础资料和映射
  ↓
订单及支付明细
  ↓
渠道账单明细、权益流水或现金账户流水
  ↓
渠道结算单及结算归集明细
  ↓
退款、费用和结算调整
  ↓
可分账结果
  ↓
分账和银行入账反馈
```

后到数据需要触发关联对象重新评估，但不得重复生成有效核销金额或可分账金额。

### 7.2 订单 D+1 同步

连锁餐饮门店的业务订单原则上支持按营业日从收银系统进行 D+1 批量同步。大部分客户和门店不以实时同步作为对账前提。

系统需要分别记录：

- 业务发生时间：订单在门店实际发生的时间。
- 营业日期：订单归属的门店营业日，可能与自然日不同。
- 来源系统更新时间：收银系统最后修改订单的时间。
- 数据同步时间：对账系统实际接收订单的时间。
- 数据完整截止时间：客户约定的 D+1 批次应完成时间。

D 日订单的标准处理节奏为：

```text
D 日门店营业并产生订单
  ↓
D 日门店日结或收银系统关账
  ↓
D+1 收银系统生成订单和支付明细批次
  ↓
D+1 对账系统接收、校验并标准化
  ↓
D+1 数据完整截止时间后执行完整性检查和自动核销
```

处理规则：

1. 订单按业务发生时间和营业日期归属，不按数据同步日期归属。
2. D+1 数据完整截止时间前，缺少订单或支付明细只标记为“等待同步”，不生成正式缺失差异。
3. 截止时间后仍未到达的数据，才生成订单同步缺失、支付明细缺失或批次不完整差异。
4. 收银系统支持实时推送时，可以提前接收和预处理，但实时数据仍需与 D+1 完整批次校验。
5. D+1 后到数据、补传数据或历史修正数据需要触发重新标准化、重新核销和差异重评。
6. 已被分账系统接收的数据发生补传或修正时，不直接覆盖历史结果，进入撤销、冲正或重新确认流程。

### 7.3 基础校验

接入时至少校验：

- 客户企业和来源系统可识别。
- 来源业务唯一键存在。
- 必填时间和金额字段格式有效。
- 金额方向和币种有效。
- 文件、批次或接口请求未重复处理。
- 数据版本不低于系统已接收版本。
- 原始记录可追溯到接入任务。
- D+1 批次对应的营业日期、门店范围、记录数量和金额汇总可校验。

### 7.4 幂等与变更

- 相同来源系统、业务对象类型和来源业务唯一键只能形成一条当前有效标准对象。
- 重复报文不重复生成订单、支付明细、账单、退款或核销金额。
- 上游数据变更需要保留版本和变更时间。
- 已参与核销或分账输出的数据发生变更时，不直接覆盖结果，应进入撤销、冲正或重新确认流程。

## 8. 订单与支付处理流程

```mermaid
flowchart TD
    A["接收订单"] --> B["识别业务分类和门店"]
    B --> C["按发生日期关联经营主体"]
    C --> D["接收或拆分支付明细"]
    D --> E["计算有效支付明细应核对金额"]
    E --> F{"合计是否等于订单应收金额"}
    F -- 否 --> G["生成订单支付不平差异"]
    F -- 是 --> H["逐条支付明细进入对应核销路径"]
    H --> I["订单状态汇总支付明细结果"]
```

处理规则：

1. 订单应收金额等于订单成交金额。
2. 每条支付明细必须明确支付方式、应核对金额和核销依据。
3. 订单支付平衡后才能进入正常自动核销。
4. 订单状态只汇总支付明细结果，不覆盖支付明细状态。
5. 组合支付中一条支付明细异常，原则上不阻断其他已确认支付明细。

## 9. 支付明细核销分支

### 9.1 外部渠道支付

适用于在线支付、外卖平台支付、团购券及其他存在外部账单的支付明细。

```text
支付明细
  → 匹配渠道账单明细
  → 生成核销记录
  → 关联渠道结算归集明细
  → 确认渠道结算单和结算批次
```

匹配结果包括已核销、部分核销、未核销和匹配冲突。

### 9.2 内部权益支付

适用于储值、私域券、积分和会员权益。

```text
支付明细
  → 匹配权益账户或核销流水
  → 确认核销金额及承担方
  → 判断是否存在外部合作方结算
```

内部权益无外部结算时，以有效权益流水作为核销依据。储值历史资金入账追溯缺失形成独立差异，不反向阻断当前储值消费核销。

### 9.3 现金支付

现金采用两阶段流程：

```mermaid
flowchart LR
    A["订单现金支付明细"] --> B["门店现金账户收款流水"]
    B --> C["形成待汇缴现金余额"]
    C --> D["门店创建现金汇缴批次"]
    D --> E["营业员或店长完成线上汇缴支付"]
    E --> F["汇缴支付渠道账单明细"]
    F --> G["完成现金汇缴核销"]
```

第一阶段确认现金已由门店收取，第二阶段确认现金已通过线上方式汇缴。现金支付是否必须完成第二阶段后才能分账，由客户现金管理规则配置。

## 10. 渠道结算确认流程

### 10.1 结算周期规则匹配

三方平台结算周期按客户企业、品牌和平台配置，支持：

- D+N：以订单所属营业日期 D 为基准。
- T+N：以平台定义的交易触发日期 T 为基准，T 可以是支付成功日、券核销日、订单完成日或平台确认日。

同一平台在不同品牌、商户号、结算主体、业务类型或支付方式下可以采用不同周期。规则需要配置自然日或工作日、日切截点、时区、节假日顺延、宽限期和有效期。

系统按业务发生时有效且范围最精确的规则计算：

```text
预期结算日
= 基准日期 D 或 T
+ N 个自然日或工作日
+ 节假日顺延
```

规则无法匹配或同优先级规则冲突时，生成结算周期配置差异并暂停超期判断，不自动选取规则。

### 10.2 结算确认

```mermaid
flowchart TD
    A["渠道账单明细"] --> A1["匹配品牌和平台结算周期规则"]
    A1 --> A2["计算预期结算日和宽限期截止日"]
    A2 --> B["等待渠道结算单"]
    B --> C["建立渠道结算归集明细"]
    C --> D{"是否全部归集"}
    D -- 否 --> E["部分结算"]
    E --> F["等待后续结算单或合法调整"]
    F --> C
    D -- 是 --> G["已结算"]
    G --> H["关联渠道结算批次"]
```

处理规则：

1. 跨日结算按 D+N 或 T+N 规则判断，不在预期结算日及宽限期前生成超期异常。
2. 同一账单明细允许通过多条归集明细进入多张结算单。
3. 累计有效归集金额不得超过账单明细可结算金额。
4. 结算单金额必须由归集明细、费用项和结算调整项解释。
5. 已核销和已结算是独立状态，是否必须结算后才能分账由支付类型和客户规则决定。
6. 渠道结算不代表银行已经入账。

## 11. 退款处理流程

```mermaid
flowchart TD
    A["接收退款单"] --> B["关联原业务订单"]
    B --> C["按原支付构成生成退款明细"]
    C --> D["每条退款明细关联原支付明细"]
    D --> E["接收渠道、权益或现金退款流水"]
    E --> F["退款明细与退款流水核销"]
    F --> G{"退款金额是否完全覆盖"}
    G -- 否 --> H["部分退款或退款失败"]
    H --> I["生成差异并等待重试或人工处理"]
    G -- 是 --> J["退款明细完成"]
    J --> K["重新计算原支付明细可分账金额"]
    K --> L{"原支付明细是否已分账"}
    L -- 否 --> M["更新分账准备结果"]
    L -- 是 --> N["输出后续冲正或资金追回处理信息"]
```

处理规则：

- 退款单金额等于退款明细业务退款金额合计。
- 退款明细必须关联原支付明细。
- 一条退款明细可以对应多条退款流水。
- 原支付明细累计退款不得超过可退金额。
- 在线支付现金退款需要同时记录现金账户退款支出。
- 原渠道后续再次退款时生成重复退款风险差异。
- 已分账后的退款不直接改写历史分账结果。

## 12. 费用与结算调整流程

### 12.1 正常费用

1. 从渠道账单明细或结算单识别费用项。
2. 按渠道实际费用金额记录。
3. 根据合同或预期规则计算费用偏差。
4. 偏差在容差内时标记正常。
5. 偏差超过容差时生成费用异常。
6. 费用异常是否阻断分账按规则配置。

### 12.2 非订单级结算调整

```mermaid
flowchart TD
    A["接收结算调整项"] --> B{"能否直接识别归属"}
    B -- 支付明细或订单 --> C["直接关联并确认"]
    B -- 门店、加盟商、经营主体或品牌 --> D["保留主体级归属"]
    B -- 涉及多个对象 --> E["按明确规则生成分摊结果"]
    B -- 无法识别 --> F["进入待归属差异"]
    E --> G{"分摊金额是否平衡"}
    G -- 否 --> H["禁止确认并生成差异"]
    G -- 是 --> I["人工或规则确认"]
    C --> J["输出已确认调整项"]
    D --> J
    I --> J
```

未确认调整项不得为了平账强制分摊，也不得影响支付明细或门店可结算金额。

## 13. 差异协同处理流程

```mermaid
flowchart TD
    A["系统生成差异"] --> B["确定差异对象、类型、金额和阻断级别"]
    B --> C["按责任规则分派部门和处理人"]
    C --> D["财务、运营、门店或 IT 调查处理"]
    D --> E{"是否需要修改基础资料或业务数据"}
    E -- 是 --> F["修正映射、配置或补充上游数据"]
    F --> G["重新标准化和核销"]
    E -- 否 --> H["提交处理结论和凭证"]
    G --> I{"差异是否消除"}
    H --> I
    I -- 否 --> J["继续处理、暂缓或升级"]
    I -- 是 --> K["复核并关闭差异"]
    K --> L["重新评估分账准备状态"]
```

### 13.1 差异责任原则

| 差异类型 | 主要责任角色 |
| --- | --- |
| 订单、支付或退款业务事实问题 | 门店人员、业务运营 |
| 门店映射、平台配置和活动归属问题 | 业务运营、IT |
| 接口失败、数据缺失、重复和延迟 | IT |
| 金额核销、费用和结算差异 | 财务 |
| 现金收款、退款和汇缴问题 | 门店人员、财务 |
| 结算调整项归属和分摊 | 财务、业务运营 |

### 13.2 门店映射冲突

门店映射缺失、多个有效映射或组合映射冲突时：

1. 生成门店映射差异。
2. 暂停相关订单、支付明细和账单明细自动核销。
3. 全部转人工确认，不自动选择优先级最高的门店。
4. 人工指定唯一门店并上传依据。
5. 按适用有效期保存确认结果。
6. 重新执行归属和核销。

## 14. 对账结果确认流程

支付明细进入结果确认时，系统依次检查：

1. 所属订单有效且支付平衡。
2. 支付明细已完成规定核销。
3. 退款状态明确且已扣除有效退款。
4. 渠道结算要求已满足。
5. 正常费用已纳入口径。
6. 结算调整项归属和分摊状态明确。
7. 门店、当日经营主体和全部结算主体已确认。
8. 不存在未关闭的阻断型差异。
9. 未被人工冻结。

系统检查通过后形成支付明细确认金额。人工确认不能绕过金额平衡、归属唯一和累计金额上限等强制约束。

## 15. 可分账结果生成与输出流程

```mermaid
flowchart TD
    A["支付明细对账确认"] --> B{"分账前置条件是否满足"}
    B -- 否，数据或差异未完成 --> C["不可分账"]
    B -- 否，人工冻结或争议 --> D["暂缓分账"]
    B -- 是 --> E["计算支付明细可分账金额"]
    E --> F["校验结算主体关系金额平衡"]
    F --> G["生成可分账结果版本"]
    G --> H["输出分账系统"]
    H --> I{"接收是否成功"}
    I -- 否 --> J["记录失败、重试并告警"]
    J --> H
    I -- 是 --> K["记录接收回执并标记已接收"]
```

输出规则：

- 可分账结果以支付明细为最小粒度。
- 支付明细可分账金额只计算一次。
- 同一支付明细可以关联多个结算主体。
- 结算主体归属金额合计等于支付明细确认金额。
- 已确认结算调整项作为独立输入输出。
- 订单级可分账金额仅汇总支付明细结果。
- 每次输出需要版本号、业务唯一键和幂等标识。
- 输出失败不得标记为已接收。
- 已接收结果发生变更时，需要使用撤销、冲正或新版本处理，不直接覆盖。
- 页面使用“已输出分账”时，其标准含义是输出状态为已接收，不是仅完成网络发送。

## 16. 分账后银行入账反馈流程

```mermaid
flowchart TD
    A["分账系统返回分账结果"] --> B["关联原可分账结果"]
    B --> C["接收银行汇总入账反馈"]
    C --> D["生成分账结果入账关联明细"]
    D --> E["累计每笔分账结果有效入账金额"]
    E --> F{"是否等于应入账金额"}
    F -- 小于 --> G["部分入账或待入账"]
    F -- 等于 --> H["已入账"]
    F -- 大于 --> I["生成超额入账关联差异"]
    C --> J{"入账是否失败或退回"}
    J -- 是 --> K["记录失败原因并生成入账差异"]
```

后置反馈规则：

- 一笔分账结果可以分多次入账。
- 一笔银行入账可以关联多笔分账结果。
- 累计有效关联金额不得超过分账结果应入账金额。
- 入账差异独立处理，不回退订单已核销状态。
- 对账系统不判断分账算法是否正确，只验证反馈数据的关联和金额一致性。

## 17. 人工操作控制

| 人工操作 | 允许条件 | 强制留痕 |
| --- | --- | --- |
| 人工确认门店 | 自动归属失败或冲突 | 确认人、时间、依据、有效期 |
| 人工核销 | 自动匹配失败但业务证据充分 | 核销对象、金额、依据、附件 |
| 核销撤销 | 原核销错误或上游数据变更 | 撤销原因、影响范围、重新核销批次 |
| 差异关闭 | 差异已解决或确认不影响结果 | 处理结论、责任人、复核人 |
| 暂缓分账 | 争议、退款调查或风险控制 | 原因、开始时间、解除条件 |
| 解除暂缓 | 解除条件已经满足 | 操作人、复核人、依据 |
| 重新输出分账 | 上次失败或经批准生成新版本 | 原输出版本、新版本、变更原因 |

人工操作不得删除原始数据、覆盖历史核销记录或修改已接收分账结果。

## 18. 任务与时点

| 任务 | 建议触发方式 | 时点要求 |
| --- | --- | --- |
| 收银订单和支付同步 | D+1 营业日批次为主，实时接口为可选补充 | 在客户约定的 D+1 数据完整截止时间前完成 |
| 外部渠道账单同步 | 渠道接口或账单文件任务 | 按渠道账单可用时间 |
| 权益和现金流水同步 | 实时或日内批次 | 在当日对账前完成 |
| 订单完整性检查 | D+1 批次完成或截止时间触发 | 截止时间前不生成正式订单缺失差异 |
| 自动核销 | D+1 订单批次到达后触发，并按后到数据周期重跑 | 支持跨日、补传和修正数据 |
| 渠道结算超期检查 | 按预期结算日和宽限期截止日调度 | 按品牌和平台对应的 D+N 或 T+N 规则 |
| 渠道结算确认 | 结算单到达触发 | 使用业务发生时有效的品牌和平台结算周期规则 |
| 差异任务生成 | 每次处理后实时生成 | 不重复生成同一有效差异 |
| 现金汇缴 | 门店日结后 | 按客户规定的营业日 |
| 可分账结果输出 | 对账确认后触发 | 支持批量和增量输出 |
| 银行入账反馈验证 | 分账反馈到达触发 | 支持多次部分入账 |

具体 D+1 截止时间、营业日切换时间、D+N/T+N 周期、工作日日历和其他时效阈值在客户实施配置中确定，不在本流程文档固化。

## 19. 流程输出

端到端流程产生以下主要结果：

- 标准订单、支付明细和退款数据。
- 标准渠道账单明细、结算单和结算归集关系。
- 权益、现金和退款核销记录。
- 支付明细及账单的核销和结算状态。
- 正常费用、费用异常和结算调整项。
- 差异任务、处理记录和审计轨迹。
- 支付明细级可分账结果。
- 分账系统接收回执。
- 分账结果和银行入账验证结果。
- 订单、门店、渠道和结算主体维度的汇总数据。

## 20. 流程边界

对账系统不负责：

- 生成业务订单或执行用户支付。
- 代替渠道出具交易账单或结算单。
- 计算品牌、加盟商、门店等参与方的最终分账比例和金额。
- 执行分账和银行转账。
- 生成企业会计凭证或总账分录。
- 无业务依据地修改渠道费用、补贴或结算金额。

对账系统负责提供可追溯、金额平衡、归属明确且状态可信的分账输入，并对分账后的银行入账反馈进行后置验证。

## 21. 评审重点

1. 主流程是否覆盖订单发生到可分账输出的完整链路。
2. 订单核销、渠道结算和银行入账是否保持独立状态。
3. 组合支付是否按支付明细分别核销和输出。
4. 现金、储值、权益和退款是否具有独立核销路径。
5. 跨日、部分和分批结算是否支持后到数据重新评估。
6. 差异处理是否能够回到归属、标准化或核销环节形成闭环。
7. 人工操作是否具备权限、复核和审计约束。
8. 分账输出和后置入账反馈是否具备幂等、版本和金额上限控制。