本文从工程视角拆解一套凭证识别即核销的实现路径OCR 把图变成字段规则引擎把字段变成校验结论异常再回流人工。以下是我落地这类系统时的做法与踩坑。为什么要把识别接到核销里我之前对接快消费用场景时发现凭证核销核心的成本不是识别不出字而是识别出来了却没人去比规则。财务月底集中收到几百张发票和快递单手工敲金额、税号、日期再凭经验判断该不该报——慢、易错、还拦不住假票。所以核心思路是OCR 只负责把非结构化凭证变成结构化字段真正的价值在后面那道规则校验。识别率再高字段不进业务规则依然是把纸变成电子版而已。一、OCR 识别流程怎么搭我把它拆成四步图像预处理纠偏、去噪、二值化、透视校正。手机翻拍的发票常有阴影和倾斜这一步直接决定后续上限。版面分析与字段定位增值税发票有相对固定的版式可用模板 关键字段锚点如发票号码价税合计做定位快递单版式更杂我更倾向用检测模型直接框出字段区域而不是死守模板。识别数字和金额用 CRNN / Transformer 类模型关键值税号、发票码要带校验逻辑。发票号码、税号有校验位识别完用算法复核一遍能拦掉一批错识。后处理金额做千分位/小数位正则校验日期统一成YYYY-MM-DD税号按长度与校验规则兜底。二、字段抽取映射表以增值税发票为例我会抽这些字段并建映射字段类别字段基础发票代码、发票号码、开票日期、校验码主体销售方税号、购买方税号、双方名称金额不含税金额、税额、价税合计业务货物或应税劳务名称、规格、数量快递单侧则抽订单编号、日期、金额、寄收地址。这些字段不是存着看而是马上送进规则引擎。三、规则引擎是核心我设计校验时主要挂四类规则税号库校验销售方税号是否在合作方白名单。不在库的直接标红。预算窗口校验价税合计是否落在当前活动预算与执行日期内。超预算或日期越界标异常。查重规则用发票号码做全局哈希查重同一号码在不同活动里出现即拦截并回显历史报销记录。地址 / 排班比对快递单寄收地址与系统开班地址、配送门店模糊匹配日期与排班范围比对不符标红。规则做成可配置业务侧改预算、加税号不用动代码。这点很关键——否则每条费用线都要研发介入落地成本会很高。四、异常处理与人工研判闭环不是所有异常都拒绝。我把结论分三档通过全部规则命中直接进入核销。标红转人工某一字段不符附上哪条规则没过业务员或财务当场补正或说明。拦截查重命中、税号不在库等硬规则直接挡下并留痕。每笔核销都记来源图片、抽取结果、命中规则、操作人。事后稽查不用翻文件夹直接按规则追溯。五、踩过的坑翻拍与反光业务员在仓库拍发票阴影重。后来强制要求正面平铺、加框引导识别稳定性明显提升。手写与涂改部分费用单含手填项模型不稳。做法是手填项单独标需人工确认不强行自动过。地址模糊匹配快递单地址写法不一XX路vsXX道路直接相等比对会漏。我加了标准化分词 相似度阈值。查重误判同一张通用发票如油费可能合法出现在不同费用线。查重要带业务单号 发票号码复合键而不是单看号码。跨票种增值税专票、普票、电子票字段位置不同模板要分族管理别用一套锚点通吃。六、和 DMS / TPM 的联动识别结果不是孤岛。核销结论回流到 TPM 做费用结算同时和 DMS 的进销存 / 对账数据互证——票上的金额能不能和经销商对账对上是另一道隐性校验。我在 eBest TPM 这类费用系统里把这套能力嵌进核销闭环体会是规则建得好识别才真的可用规则没建好就上识别往往录得快、核不准。七、落地建议四步规范移动端凭证采集入口统一拍照上传保图片质量与归属。先把活动预算、合作方税号、执行日期窗口结构化形成规则库。选一条费用线小范围试点拍照—识别—校验—标记闭环看准确率。再把核销结果和 DMS 对账联动让费用与进销存互证。如果你在搭类似系统可参考 eBest 官网www.ebestmobile.cn的 TPM 与数据中台资料里面有一体化费用核销的架构说明。