银行流水 OCR 识别后怎么做结构化？字段映射、余额校验与来源追溯
将银行流水从 PDF、图片或扫描件转成文本，只解决了输入可读取的问题。对于企业已授权的尽调、审计、风控和财务核查项目，后续真正要使用的是交易级结构化明细：字段能对齐、金额方向可判断、余额关系可检查、每条记录能够回到原始文件。
这条链路通常包括文件归类、版面解析、字段映射、交易行重建、数据校验、实体归一化和来源追溯。OCR 是入口，但不等于流水结构化完成。
不同文件类型需要不同的解析路径
原生 PDF 往往保留文本对象和坐标信息，扫描 PDF 或图片则需要先经过版面识别与文字识别。两类输入混在一起时，不能使用同一套假设。
原生 PDF 的主要问题是阅读顺序、表格边界和跨页内容。扫描件的主要问题则包括倾斜、模糊、背景线、印章遮挡、折行文字和低清数字。进入抽取前，可以按银行、账户、文件类型、期间和页数建立文件清单，并保留文件哈希或版本标识，减少重复文件和版本混用。
对于流水页，还应识别页首的账户信息、期间范围和表头结构。交易明细行没有与所属账户、页码和表头关联，后续即使抽取出了金额，也很难判断它属于哪一份流水。
用 Canonical Schema 统一字段口径
不同银行的列名和顺序常有差异：收入、支出可能写作贷方、借方，也可能只用正负号表达；对方信息可能放在摘要列、附言列或单独列中。要让多来源文件进入同一张明细表，需先定义统一 Schema。
常见的交易级字段包括：
account_owner、account_number和账户币种。transaction_date、transaction_time和交易流水号。description、counterparty_name和对方账户信息。credit_amount、debit_amount、balance与金额方向。source_file、source_page、row_index与原文坐标。
Schema 的关键不只是字段名称，还包括方向规则和空值规则。例如，某家银行把支出写成负数，另一家银行在借方列填写正数。映射时需要把原始列名、原始值和规范化值同时保留，避免后续无法解释金额方向的转换过程。
交易行重建要处理折行与跨页
银行流水中的一笔交易不一定占一行。摘要、对方户名或备注较长时，内容可能折到下一行；跨页时，表头重复出现，上一页最后一笔交易与下一页第一行也可能需要重新判断边界。
交易行重建可以综合使用版面坐标、列边界、日期模式、金额模式和余额序列。处理时不应只根据换行符切分文本，而应判断一行是否具备交易记录的必要特征，以及后续行是否更像前一条记录的续写。
对于无法明确归属的内容，建议保留为待复核片段，而不是强行填入某个字段。错误的行合并会在汇总阶段放大，且很难再回溯到问题来源。
用余额关系发现列错位和金额方向问题
结构化后，余额字段可以提供基础一致性检查。对同一账户、连续期间的相邻记录，可以比较期初余额、本笔借贷变化和期末余额之间的关系。不同银行的记账规则存在差异，校验公式需要结合该行的方向规则和账户币种处理，但余额序列仍可用于发现明显异常。
例如，以下情况通常值得回看原页：
- 交易日期顺序异常，且无法由补记或冲正说明。
- 金额被解析为文本，或收入、支出同时为空。
- 前后余额变化与本笔金额方向明显不匹配。
- 同一页中金额小数位或千分位格式出现异常。
- 账户、币种或期间信息在交易中断处发生变化。
这些校验结果只是数据质量线索，不应直接代替业务判断。其价值在于把版面识别、字段映射和行重建中的问题集中暴露出来。
对交易对手和摘要做可回查的归一化
交易对手名称常受简称、空格、符号和 OCR 误识别影响。用于汇总前，可以保留原始字段，并另建规范化字段处理字符清洗、别名映射和重复值聚合。任何归一化规则都应可以回看原始值，避免汇总后丢失证据。
摘要也是同样的处理方式。它可以用于后续筛选和分类，但原文、来源页和对应交易行应始终保留。对批量项目而言，结构化明细和文件索引能够关联，复核成本会明显下降。
Grater 的处理定位
庖丁科技银行流水识别神器Grater面向企业已授权的银行流水整理场景，适合将 PDF、图片和扫描件处理为结构化交易明细，并辅助进行交易对手汇总、收支分析和重点线索整理。技术评估时，建议混合原生 PDF、低清扫描件和跨月多账户样本，重点检查 Schema 映射、折行处理、余额校验和来源回查是否满足项目要求。
银行流水结构化的核心，不是导出一张表，而是让字段映射、交易行、校验规则与原文件证据形成可复核的数据链路。
