帮财务做的发票识别录入工具：每月省 20 小时手工录入，我是这么拆的

从 47 张发票照片说起

10 月 8 号早上八点半，微信里一次性弹进来 47 张发票照片。发照片的是一家代账公司的王会计，第一句话是：「月底了，我们三个人对着一沓发票敲一下午，你看看这个能不能做成工具——拍照或者扫描进去，出来就是 Excel。」

我先让她把账算给我看。每张发票要录的字段：发票代码、发票号码、开票日期、购买方名称和税号、销售方名称和税号、品名、金额、税率、税额、价税合计，十三个字段，一个熟手敲一张平均 40 秒。她们手上每月大概 900 张，摊下来就是每人每月 10 小时纯录入，三个人轮着干。这不是效率问题，是月月底气问题——录错一个税号，比对账的时候就得多花半小时找。

她们不是没试过现成方案。买过某 OCR 会员，识别是能识别，但导出的 Excel 列序和她们代账软件的导入模板对不上，每次还得人工对列、挪列，等于省了敲字的时间又还回去了。这就是定制工具的真实立足点：不是「别人做不到」，是「别人的最后一公里不通」。

三层结构，OCR 只是最薄的一层

我报了 2.8 万、三周工期，方案拆成三层：

第一层：图像预处理。 客户的发票来源很杂——手机拍照、扫描仪、PDF 电子发票。扫描仪进纸歪 3 到 5 度，识别率就肉眼可见地往下掉，所以先做倾斜矫正和裁边。PDF 电子发票直接按页转图片。这层没什么高深技术，但决定了后面 OCR 的下限。

第二层：云 OCR 识别接口。 发票识别没有自己训模型，直接调云厂商的发票识别接口，按次计费。900 张的量，一个月的成本不到一杯奶茶钱，自己造轮子反而不划算。接口返回的是结构化字段，这一层基本是调通、重试、计费监控三件事。

第三层：校验与导出——我写代码最多的地方。 这层的坑，文档里一个都不会写：

1. 金额字段带「¥」和千分位逗号。直接 decimal.Parse 会炸，得先洗掉符号和逗号。听起来小儿科？上线前内部测试就靠这个抓出一批。
2. 价税合计的尾差。金额 + 税额 ≠ 价税合计，差 1 分钱——开票系统四舍五入的锅。校验规则如果写成严格相等，满屏都是红。最后放宽到 ±0.02，超过才进异常队列。
3. 全电发票没有「发票代码」字段，发票号码从 8 位变成 20 位。老解析逻辑在这里直接 KeyError，把发票号码兜底赋给代码字段就乱套了。字段解析必须按票种分支。
4. 去重。发票号码做唯一键，SQLite 存历史导入记录，重复导入当场提示，这是代账场景的刚需——同一个客户把同一张发票发两遍太常见了。
5. 置信度兜底。OCR 返回置信度低的字段不直接落库，进人工复核队列：界面左边原图、右边字段表单，复核员改完回车跳下一个字段。王会计的原话：「这个页面比我们自己敲快多了，因为不用抬头低头对。」

界面与交付

WPF 单机版，不上云——财务数据客户死活不肯出内网。左边文件列表、中间发票大图、右边字段表单，底部一个复核队列计数。导出用 NPOI 直接生成代账软件导入模板的列序，一个列都不用挪——这一条才是她们付钱的理由。

三周交付，含一个月试用期。验收那天王会计拿当月的 200 多张真发票跑了一遍，复核队列里剩 11 张，其余全过。她算的账：每月 20 小时的录入工时砍到 2 小时复核，工具半年回本。

这类活给我的感受一直没变：甲方搜「发票识别」搜到的都是 OCR 接口广告，但真正让项目成立的，是那 1 分钱尾差、20 位发票号码和导出列序这些没人写进文档的细节。

---

有定制软件需求（.NET 桌面端 / 小程序 / APP），直接联系：微信/手机 17788568694

（转载请注明作者与出处）

手机 17788568694 ｜ 微信 17788568694（与手机同号）｜ QQ 76656825