# 结算类凭证要素核验需求规格说明书

> 结算业务申请书与「转账支票+进账单」两场景的要素核验需求规格，含规则映射、印章混合识别与自修复链，附三张交互式图表。

---

LLMS 索引： [llms.txt](/llms.txt)

---

依据《AI 审核规则》及 vlagent 项目已实现的核验能力编制。本说明书覆盖**结算业务申请书**（单张/批量）与**「转账支票+进账单」联合核验**两个场景，规则与需求文档逐条对应（申请书 1.1–1.8、支票 2.1–2.12），并纳入实现过程中经业务确认的判定口径。

## 一、引言 {#intro}

### 1.1 目的与范围

为银行柜面结算凭证的人工审核提供 AI 辅助要素核验：识别凭证影像上的要素，按规则逐条给出结论与证据，供柜员快速定位问题。本说明书界定两个核验场景的功能与非功能需求；**特种转账借方传票**等票种为规划范围（规则文档 §3 占位），不在本期。

### 1.2 术语

| 术语 | 含义 |
|---|---|
| 要素 | 凭证上需校验的具体字段（户名、账号、金额、日期、签章、用途…） |
| 抽取-校验分离 | 第一阶段只收集并修复证据，第二阶段规则引擎确定性判定 |
| 五态 | 通过 / 不通过 / 警告 / 不适用 / 待人工复核 |
| 联合核验 | 转账支票正面、背面与进账单三件配套、跨单比对 |
| 印章解剖学 | 单位章（圆，单位名称+类型词+3 开头数字码）与个人名章（方，姓名+1 开头数字码）的结构口径 |
| 透印 | 另一面印章透过纸张在本面形成的淡红镜像影，非本面印章 |

### 1.3 参考文档

《AI 审核规则》（结算业务申请书 §1、转账支票+进账单 §2）；项目 CONTEXT.md 词汇表与 ADR-0001～0004。

## 二、总体描述 {#overall}

### 2.1 系统定位与流程

系统采用**抽取-校验分离**的两阶段架构：第一阶段完成要素收集与自修复（VLM 整图抽取 → PaddleOCR 印章增强 → 金额/账号复核 → 文本兜底），产出一册完整的要素总集；第二阶段由规则引擎对同一册证据逐条判定，输出五态结论。所有模型不确定性被限制在第一阶段，判定层完全确定、可单测、可审计。

<iframe src="/ai/xingchen/01-verification-pipeline.html" title="结算凭证要素核验总流程" loading="lazy" style="width:100%;height:700px;border:1px solid #e5e7eb;border-radius:8px;"></iframe>

<a href="/ai/xingchen/01-verification-pipeline.html" target="_blank">全屏打开 ↗</a>

> [!NOTE]
> 图内支持缩放、语义视图、关系追踪与 PNG/SVG 导出。

### 2.2 系统架构

前端为核验工作台（上传、轮询、报告呈现）；FastAPI 后端编排两阶段管线；AI 服务包括 Qwen-VL 多模态（整图抽取与裁片精读）与内网 PaddleOCR（版面解析与印章定位）；证据（裁片文件、PaddleOCR 输出、校验明细）随记录落库可追溯。

<iframe src="/ai/xingchen/03-system-architecture.html" title="结算类凭证要素核验系统架构" loading="lazy" style="width:100%;height:700px;border:1px solid #e5e7eb;border-radius:8px;"></iframe>

<a href="/ai/xingchen/03-system-architecture.html" target="_blank">全屏打开 ↗</a>

### 2.3 结论体系（五态）

| 状态 | 语义 | 典型场景 |
|---|---|---|
| 通过 | 要素合规 | 大小写金额一致、印鉴齐全 |
| 不通过 | 存在阻断性缺陷 | 日期涂改、跨单账号不一致、支票逾期 |
| 警告 | 可受理的规范性问题 | 应加零未加零、缺「圆」字 |
| 不适用 | 规则对该票不适用 | 非密码交易的支付密码规则 |
| 待人工复核 | 证据不足或需主观判断 | 印鉴加盖不完整、印章重叠不清 |

总体结论取全部规则的最严重态。

### 2.4 凭证上传要求

- **结算业务申请书**：单面凭证，支持**单张与批量上传（一次最多 5 张，逐张独立识别）**；批量时逐张展示状态与结论，支持汇总（N 通过 / M 不通过 / K 待复核）与单张钻取。
- **转账支票+进账单**：三件配套必传——支票正面、支票背面、进账单，缺一拒绝受理（无背面则背书核对无从做起，无进账单则跨单比对无从做起）；可选输入交易码（票号位数模式用）。

## 三、功能需求——结算业务申请书 {#application}

规则与需求文档 §1.1–§1.8 一一对应；申请日期与进账单日期共用公共日期口径。

| 编号 | 规则 | 需求要点 | 判定口径（业务确认版） |
|---|---|---|---|
| R1.1 | 申请日期 | 阿拉伯小写；当日或上一工作日 | 大写日期识别书写规范性；非当日/上一工作日 → 不通过 |
| R1.2 | 金额（公共） | 大小写一致、规范、顶头、¥ 符号 | 大写转数值与小写比对；合规变体（零可省、角后整可省、繁体受理、缺「圆」字数值一致）按宽容口径分级；>50 万且收款户名 ≤3 字（个人）→ 警告「应出具付款依据」 |
| R1.3 | 收付款信息 | 六要素完整、无涂改；括号全角 | 户名/账号/开户行两侧齐全性检查；涂改 → 不通过 |
| R1.4 | 票号 | 仅识别数字部分 | 剥离行别前缀（如「青：」） |
| R1.5 | 支付密码 | 非必输 | 填写且有涂改 → 不通过；未填 → 不适用 |
| R1.6 | 出票人签章 | 形式审核：完整、清晰、无重叠 | 单位口径（有单位章即按单位）：财务专用章/公章 + 个人名章，加盖不全 → 待复核「印章加盖不完整」；**不做名称内容核验**（业务确认：与 2.12 口径统一）；个人口径：签字或名章，全无 → 不通过 |
| R1.7 | 用途及附加信息 | 必填；非同户名禁用词 | 非同户名不得「转账/转款/汇款」→ 不通过；名章姓名与收款人一致时不得「劳务费」→ 警告 |
| R1.8 | 业务类型 | 交易类型与勾选一致 | 单位转账应勾「其他」、人民币对公汇款应勾「电汇」 |

**印章分类按证据判定**：类型词/形状会被识别错（如方形名章被读作「圆形+测试专用章」），分类依「章文结构 + person_name/unit_name 互斥字段 + 形状」综合反推；票面有单位章时按单位口径（户名启发式可被章型证据纠正）。

## 四、功能需求——转账支票+进账单 {#transfer}

三件联合核验，规则与 §2.1–§2.12 一一对应。支票正面/背面字段平铺合并，进账单整体挂 `slip` 命名空间。

| 编号 | 规则 | 需求要点 | 判定口径（业务确认版） |
|---|---|---|---|
| R2.1 | 日期 | 出票日中文大写 + 逾期规范；进账单日期小写口径 | 出票日小写 → 不予受理；应加壹未加 → 不通过，应加零未加 → 警告；**到期日 = 签发日 +10 自然日**，第 10 天为非工作日顺延至下一工作日（第 11 天逾期）；远期票据不通过；进账单日期当日或上一工作日 |
| R2.2 | 金额 | 两单各按公共规则 + **四个金额比对一致** | 单内大小写一致 + 跨单小写数值相等；矛盾触发复核重读与 PaddleOCR 仲裁 |
| R2.3 | 票号 | 16 位票号 | 默认识别上下两行（各行 8 位）；交易码映射其他位数模式 |
| R2.4 | 付款人账号 | 支票右上角出票人账号 vs 进账单出票人账号 | 跨单不一致 → 不通过；说明打印两侧账号 |
| R2.5 | 密码 | 仅数字，非必输 | 未填 → 不适用 |
| R2.6 | 行号及付款行名称 | 无核验规则 | 两单识别值仅抽取展示 |
| R2.7 | 用途 | 仅「用途」栏内容 | 排除栏下方预印字样 |
| R2.8 | 出票人全称 | 支票正面签章单位名称 vs 进账单「出票人全称」 | 圆章只取单位名称（剥类型词与小数码）；不一致 → 「付款人名称跨单比对不一致」 |
| R2.9 | 收款人账号 | 仅抽取展示进账单值 | 无核验规则 |
| R2.10 | 收款人户名 | 票面收款人 / 背书链 / 进账单三方核验 | 无背书：票面 vs 第一手背书人 vs 进账单，不一致 → 「收款人名称比对不一致」；有转让背书：位置 1–4 比对（票面=位置1、位置2=位置3=进账单），断链 → 「背书不连续」，跨单不一致 → 「收款人跨单比对不一致」；第 2 被背书人「委托收款」→ 链终止；≥3 手 → 待复核 |
| R2.11 | 收款人开户银行 | 仅抽取展示进账单值 | 无核验规则 |
| R2.12 | 印章加盖规范性审核 | 只核个数与重叠/不清，不做内容核验 | 分组分别审核（支票正面·出票人签章 / 支票背面·第 N 手背书人签章），说明逐组列出；仅 1 枚 → 待复核「印鉴加盖不完整」；重叠/不清 → 待复核「印章加盖不规范」；手写背书不做个数审核 |

**说明文案要求**（业务确认）：无论结论如何，说明中固定罗列检核用到的各要素（票面收款人、每手背书人（标注形式）与被背书人（含委托收款标记）、进账单收款人全称），未识别项标注「未识别」。

## 五、印章识别混合方案 {#seal}

整图 VLM 识别印章不可靠（计数幻觉、锚点挪用、示例污染），采用 **PaddleOCR 定位裁片 + VLM 裁片精读**：

- PaddleOCR 只负责检测印章位置并输出裁片；章文内容由 VLM 按统一印章解剖学口径精读单枚特写；其余字段维持整图抽取。
- 归属用表格结构与 bbox 几何（背面 x 向三区：附加信息 / 第 1 手 / 第 2 手），VLM 不参与。
- **三重透印过滤**（两面通用）：低饱和淡红（颜色）、裁片框红墨覆盖率过低（稀疏透痕）、镜像反字（方向）任一命中即剔除。
- **章证优先**：检出单位章即以其单位名称重推锚点并覆盖手写标志；**手写保护**——该手未检出裁片时整图结果原样保留（手写第一行锚点不清空）。
- PaddleOCR 失败优雅降级退回整图值；被剔除裁片仍落盘留证。

<iframe src="/ai/xingchen/02-seal-recognition-pipeline.html" title="印章识别混合管线" loading="lazy" style="width:100%;height:700px;border:1px solid #e5e7eb;border-radius:8px;"></iframe>

<a href="/ai/xingchen/02-seal-recognition-pipeline.html" target="_blank">全屏打开 ↗</a>

## 六、抽取自修复链（第一阶段） {#repair}

所有修复仅发生在证据层，「发现缺口/矛盾 → 定向重读 → 能消解才采纳」：

| 机制 | 触发 | 动作 |
|---|---|---|
| 金额复核与 Paddle 仲裁 | 单内不一致或跨单矛盾 | 裁带重读；进账单侧取 PaddleOCR 位值表格读数仲裁（小写取位值格，大写按数值最近候选） |
| 付款人账号复核 | 跨单不一致或单侧为空 | 裁带逐位重读，消解矛盾才采纳 |
| 被背书人兜底 | endorsee 为空 | 从 PaddleOCR markdown 表格同位置文本补（只补空不覆盖） |
| 手写背书人纠偏 | 手写锚点截短/黏连 | 取签章框格首行 + 剥黏连数字串 |
| 印章章型纠偏 | VLM 形状误读 | 鲜红墨迹径向分布几何判定（方/圆）覆盖 |

## 七、接口需求 {#api}

| 接口 | 说明 |
|---|---|
| `POST /settlement-check/check` | 上传凭证（申请书 file；支票另传 file_back/file_slip，可选 transaction_code），异步校验 |
| `GET /settlement-check/records` | 记录列表（含状态与总体结论） |
| `GET /settlement-check/records/{id}` | 详情：逐条规则结果 + 提取要素总集 + PaddleOCR 输出目录 |
| `GET /settlement-check/records/{id}/file?side=` | 原件影像（front/back/slip） |

## 八、非功能需求 {#nfr}

- **确定性**：同一输入必出同一结论；规则层不调用任何模型。
- **可追溯**：每条结论附说明与证据；印章证据附裁片文件地址；PaddleOCR 输出目录随记录落库。
- **降级**：任一外部服务（VLM/PaddleOCR）失败不影响主流程出报告（退回可用证据，标注待复核）。
- **性能**：单张凭证端到端（含两次 VLM 抽取 + 印章增强）目标 ≤60s；批量 5 张并行处理。
- **安全**：全接口 JWT 鉴权；影像与输出文件按用户目录隔离。

## 九、附录 {#appendix}

### 9.1 规划范围

- 结算业务申请书批量上传（≤5 张）前端交互与汇总展示（增量需求）。
- 特种转账借方传票（规则文档 §3 占位）、电汇凭证等新票种。
- PaddleOCR 能力服务化（ADR-0004：独立 OCR 标准化服务，方案已定案）。

### 9.2 版式先验

背面背书栏位三区/手间分界等几何先验按样本标定，换版式样本须复标；进账单金额位值表格解析依赖表格结构识别质量。

---

反链：

- [星辰智能](/docs/ai/xingchen-intelligence/)