今年年初有个做建材批发的客户来找我诉苦，说他公司每个月收到两百多张发票，两个财务助理光录发票就要花掉三个人天。关键还容易录错，上个月一张增值税专票的税额少输了个零，进项抵扣少了三万八，月底对账才发现，差点赶上不上报税截止日。
我问他有没有试过OCR自动识别，他说试过，用了某在线工具识别了一下，发票上的数字识别率大概百分之八十五，但发票类型分不清，专票普票混在一起，发票代码和号码经常对不上。他觉得不行就放弃了，继续手动录入。
我跟他说，OCR只解决了一半的问题——把图片变成文字。另外一半得靠RPA解决——把文字变成结构化数据录入系统。两件事分开做都不行，串在一起才能跑通。后来我帮他把OCR加RPA的方案搭起来，又花了三周调准确率，最终把录发票的人工时间从三个人天压到了三个小时。这个过程中我把三种OCR引擎都跑了一遍，对比数据今天全公开。
OCR引擎怎么选，三家跑了一遍
发票OCR识别我测了三种方案：百度智能云的文字识别API、腾讯云的增值税发票识别API、以及开源的PaddleOCR。测试样本是五百张真实发票，包含增值税专用发票、普通发票、电子发票和卷式发票四种类型。测试维度有四个：字段识别准确率、识别速度、API调用成本和部署复杂度。
先说字段识别准确率。我测了九个核心字段：发票代码、发票号码、开票日期、购买方名称、销售方名称、金额、税额、价税合计、发票类型。百度智能云的准确率最高，九个字段平均百分之九十六点八，其中发票代码和号码这两个最关键的字段准确率百分之百。腾讯云紧随其后，平均百分之九十四点二，发票类型识别偶尔会混。PaddleOCR作为开源方案，平均准确率百分之八十九点五，但发票类型识别只有百分之七十八——它把不少电子普票识别成了纸质普票，因为它的模型没有针对发票类型做专门训练。
再说识别速度。百度和腾讯的云端API单张发票识别时间在八百毫秒到一点二秒之间，批量识别五百张大概七分钟。PaddleOCR本地部署，单张一点五秒左右，五百张十二分钟。速度上云端API完胜，但PaddleOCR胜在数据不出本地，对于对数据安全要求高的企业是个选择。我那个建材客户最终选了百度智能云，因为他的发票量大、对速度有要求，而且发票信息不算特别敏感。
成本方面差异也不小。百度智能云增值税发票识别API定价是每次调用零点零五元，五百张发票两十五元。腾讯云差不多，零点零六元一次，五百张三十元。PaddleOCR免费，但你需要一台有GPU的服务器来跑，AWS的T4实例每小时三元左右，一个月跑下来也得两百多。我那个客户每月两百多张发票，百度API月成本十二元，腾讯十八元，PaddleOCR服务器成本两百多元。量小的企业用云端API更划算，量大的企业如果每月超过五千张，PaddleOCR的边际成本优势就出来了。
RPA流程怎么串才不卡壳
OCR把发票图片变成文字之后，这些文字是半结构化的——你拿到了发票代码、号码、金额这些字段值，但它们还散在识别结果里，没有进入你的财务系统。这中间需要一个RPA流程把它们串起来：拿到OCR识别结果、校验字段完整性、查验发票真伪、录入财务系统、归档原始图片。
我搭的RPA流程分五步。第一步，OCR识别完成后，RPA机器人接收识别结果JSON，解析出九个核心字段值。第二步做字段校验——发票代码必须是十位或十二位数字，发票号码必须是八位数字，金额和税额加起来要等于价税合计。校验不通过的发票标记为异常，推送到财务人员的企业微信待人工处理。这一步看着简单但非常重要，OCR识别错误的第一道防线就在这里。我测试中发现，金额和税额加起来不等于价税合计的发票，百分之百是OCR识别错了数字，这种发票直接拦截不让录入系统。
第三步是发票真伪查验。我对接了国家税务总局的发票查验平台API，用OCR识别出来的发票代码、号码、日期、校验码去查验。查验通过的真票才继续往下走，假票直接拦截并通知财务。这一步是整个流程里最有价值的一环——我那个客户之前手动录入的时候，查验这一步经常被跳过，因为手动查验太慢了。上了RPA之后每张发票自动查验，上线第一个月就拦截了两张重复报销的发票，避免了重复入账。
第四步是录入财务系统。我那个客户用的是金蝶K3，RPA机器人通过金蝶的API把发票信息写入应付账款模块。写入的字段包括发票类型、发票代码、号码、开票日期、供应商名称、金额、税额。写入完成后RPA返回写入成功的记录ID。第五步是归档——把原始发票图片和OCR识别结果一起存到文件服务器上，文件名用发票号码命名，方便后续查证。五步串起来，从一张发票图片到录入系统完成，整个流程不超过五秒。
RPA流程搭建有个坑要提醒：OCR识别结果和财务系统的字段映射不是一一对应的。比如OCR识别出来的”购买方名称”在你的财务系统里对应的是”客户名称”还是”本单位名称”取决于发票类型——专票的购买方是你自己，普票的购买方也是你自己，但销售发票的购买方是客户。这种映射关系不搞清楚，RPA录入就会张冠李戴。我花了好几天才把所有发票类型和系统字段的映射关系理清楚，写了一张对照表放在RPA配置文件里，后续维护改映射不用动代码。
准确率从85%拉到98%调了什么
刚上线的时候，整个流程的端到端准确率只有百分之八十五，意味着每七张发票就有一张需要人工干预。客户不满意，觉得没省多少事。我花了两周做优化，把准确率拉到了百分之九十八，每五十张才有一张需要人工介入。这两周我调了四个东西。
第一个是OCR预处理。发票图片质量参差不齐，有的拍照歪了，有的光线暗，有的有折痕。我加了一道图像预处理：用OpenCV做倾斜校正、亮度增强和去噪。预处理之后，OCR对低质量图片的识别准确率从百分之七十五提升到了百分之九十一。这个提升最大，因为之前百分之六十的识别错误都来自图片质量太差。预处理代码不到一百行Python，但效果立竿见影。
第二个是字段后校验。前面说的金额加税额等于价税合计是一个校验规则，我又加了三条：发票代码的校验位算法、开票日期不能是未来日期、销售方纳税人识别号格式校验。这四条规则组合起来，能拦住大部分OCR识别错误。被拦截的发票进人工复核队列，人工确认后修正识别结果再重新录入。这套校验机制上线后，错误发票流入系统的概率降到百分之零点三以下。
第三个是发票类型分类器。百度和腾讯的API虽然能识别发票类型，但准确率不是百分之百，特别是对电子发票和纸质发票的区分。我训练了一个轻量级的发票类型分类模型，用ResNet18做图像分类，训练数据是两千张标注好的发票图片。这个分类器的准确率百分之九十七，比通用OCR的发票类型识别高了将近十个百分点。分类器先判断发票类型，然后根据类型选择不同的OCR识别模板——专票模板提取购买方税号，普票模板不提取。模板化识别比通用识别准确率高百分之三到五。
第四个是异常自动重试。OCR偶尔会因为网络波动或图片质量问题返回空结果，原来的处理是直接标记异常进人工队列。我改成自动重试两次，重试时切换OCR引擎——百度失败就换腾讯，腾讯失败就换PaddleOCR。三个引擎都失败才进人工队列。这个改动把因为临时网络问题导致的异常减少了百分之六十。四个优化加起来，端到端准确率从百分之八十五到百分之九十八，人工干预率从七分之一降到五十分之一。
成本和部署方案对比
说了半天技术，老板最关心的还是花多少钱。我帮客户算了一笔账。原来两个财务助理录发票，每月三个人天，按每人天四百元算，月成本一千二百元。上了OCR加RPA之后，API月成本十五元（百度），服务器成本零（RPA跑在现有服务器上），维护成本每月半天人工约两百元。总月成本二百一十五元。算下来每月省一千元左右，年省一万二。投入方面，搭建和调试费用一次性投入约一万五（含OCR调用、RPA开发、模型训练和调试），回报周期十四个月。
这个回报周期对于发票量大的企业很划算。我后来又给一个每月五百张发票的客户做了同样的方案，他的月API成本三十五元，省的人工是六个人天两千四百元，回报周期只要七个月。反过来，如果每月只有五六十张发票，就不建议上这套方案了——搭建成本收不回来，直接用在线工具手动批量识别就够了。
部署方式有两种选择。一种是全云端部署，OCR用百度API，RPA跑在云服务器上，发票图片上传到云上处理。这种方式部署快、维护省心，但发票数据要出本地。另一种是混合部署，OCR用PaddleOCR本地跑，RPA也跑在本地服务器上，数据完全不出企业。这种方式数据安全但维护成本高，PaddleOCR的模型需要定期更新，GPU服务器需要运维。我那个建材客户选了全云端，因为发票数据不算核心机密。但如果你是上市公司或者对数据合规要求高的企业，混合部署更稳。在北京，中小企业做发票自动化的需求越来越多了，方案选型上别盲目跟风，先算清楚自己的发票量和投入产出比再决定。有拿不准的可以先聊聊，帮你算笔账看看值不值得上。
需要相关服务？联系我们免费咨询
九五星球企服提供公司注册、代理记账、商标注册、财税咨询、高新申报、网站开发等一站式企业服务。可以先免费咨询看看，觉得合适再合作，不推销。
免费小工具推荐：
联系方式：
- 电话/微信：18910232032
- 扫码添加专业经营合规顾问，免费咨询 ↓
