报销要手工录入？用OCR把发票整理成结构化台账

一、痛点：报销录入为何成为“隐形工时”

每次出差归来，行李可以慢慢收拾，发票却躲不过要一张张处理。打开相册、放大看金额、切到表格、再回头核对日期——单个动作都不难，重复上百次之后，时间成本与出错率会持续累积。这类工作的本质，是把“非结构化的图片”转换为“结构化的数据”，而这恰好是OCR（Optical Character Recognition，光学字符识别）最擅长的场景。

手工录入通常带来三类成本：

• 时间成本：每张发票需要在多个应用之间反复切换，平均耗时数分钟，一次报销整理动辄占用整个下午；
• 错误成本：金额看错一位、日期录错一天、销方名称漏一个字，都可能在审核环节被打回重来；
• 追溯成本：录入完成后原图散落在相册各处，一旦被质询“这笔金额对应哪张票”，翻找凭证的时间往往超过录入本身。

把这三项叠加，就能解释为什么“整理发票”常年位居职场人最厌烦事务的前列，而OCR要解决的，正是其中最机械的部分。

二、技术原理：OCR如何把图片变成数据

一句话概括：OCR就是把图片中的文字识别成机器可处理的文本信息。一套典型的识别流程包含四个环节：

1. 图像预处理：灰度化、二值化、透视矫正与去噪，提升文字区域的清晰度；
2. 文本检测：定位图中所有包含文字的区域，输出坐标框；
3. 文本识别：对每个区域做字符序列识别，得到文字内容；
4. 后处理：结合置信度、字典约束与版式规则修正识别结果。

发票对OCR相当“友好”：文字以印刷体为主、版式相对固定，关键字段（号码、日期、金额）出现在可预期的位置。目前主流云服务商（如百度智能云等）普遍提供通用文字识别与票据类识别能力，可以直接返回结构化字段；也可以先获取全文，再按关键词自行抽取字段，两条路线都可行。

三、方案设计：五个步骤的完整流程

整体链路可以概括为：

发票图片集 → 质量检查 → OCR识别 → 字段抽取与清洗 → 台账生成 → 异常复核 → 人工抽查 → 报销材料准备

下面逐步展开。

3.1 第一步：把图片质量控制在源头

“垃圾进，垃圾出”同样适用于OCR——识别准确率的上限由图片质量决定。拍摄与整理时注意四点：

• 保留完整票面：四个角都在画面内、边缘不被裁掉，否则票头的发票号码可能缺失；
• 避免反光与阴影：发票纸面常带油墨光泽，应寻找光线均匀的位置或调整拍摄角度；
• 保持对焦清晰：金额区域是后续核对的重点，宁可多拍一张，也不要接受虚焦；
• 集中存放、规范命名：将本次要处理的图片统一放入同一目录，按“日期_序号”等规则命名，从源头减少遗漏。

一个实用技巧：拍摄前把发票平铺在深色背景上，与浅色票面形成对比，能明显降低边缘识别失败的概率。

3.2 第二步：定义字段与输出格式

不要笼统地说“整理发票”，明确的字段规范是后续核对效率的基础。一份实用的台账字段设计如下：

字段	作用	核对要点
发票号码	唯一标识	用于查重
开票日期	报销周期归属	与行程日期比对
销方名称	供应商信息	名称完整性
价税合计	报销金额	与报销单加总比对
来源文件名	溯源凭证	每行都能回到原图

其中“来源文件名”最容易被忽略，却最有价值：它让台账的每一行都能反查原始凭证，是后续审计、质询与补录时的底气。

对应的记录结构可以用一段JSON描述：

{
  "invoice_no": "发票号码（字符串）",
  "issue_date": "开票日期，统一为 YYYY-MM-DD",
  "seller_name": "销方名称",
  "total_amount": "价税合计（数值类型）",
  "source_file": "来源图片文件名"
}

如果使用支持自然语言指令的智能办公工具，同样建议在指令中明确列出上述字段并要求输出电子表格。字段统一之后，无论多少人经手，台账口径都保持一致，核对成本会大幅下降。

3.3 第三步：识别与结构化

选择自建脚本的话，核心逻辑并不复杂，以下为示意代码：

import csv, glob
from collections import Counter
FIELDS = ["发票号码", "开票日期", "销方名称", "价税合计", "来源文件名"]
# 1. 批量识别：ocr_recognize 为所用OCR服务的调用封装（示意）
records = []
for img in sorted(glob.glob("invoices/*.jpg")):
    raw = ocr_recognize(img)      # 返回全文或结构化字段
    rec = extract_fields(raw)     # 按"发票号码""开票日期"等关键词定位抽取
    rec["来源文件名"] = img
    records.append(rec)
# 2. 查重：发票号码出现多次的记录需人工复核
counter = Counter(r["发票号码"] for r in records if r["发票号码"])
duplicated = {no for no, cnt in counter.items() if cnt > 1}
# 3. 输出台账：CSV格式，可用任意表格软件打开
with open("发票台账.csv", "w", newline="", encoding="utf-8-sig") as f:
    writer = csv.DictWriter(f, fieldnames=FIELDS)
    writer.writeheader()
    for r in records:
        writer.writerow(r)

三个实现细节值得强调：

• 日期统一格式：一律转为 YYYY-MM-DD，避免“2024年3月1日”与“2024-03-01”混杂，影响后续排序与筛选；
• 金额统一为数值类型：去掉货币符号与千分位分隔符，方便加总校验；
• 低置信度不填值：识别置信度不足的字段置空并标记“待复核”，宁可留空，也不要让机器“猜”一个看起来合理的结果。

3.4 第四步：异常单独处理

自动化的价值，不仅在于把确定的部分交给机器，更在于把不确定的部分明确“抛”给人工：

• 模糊数字绝不靠猜：金额、号码等关键字段置信度偏低时，先打上标记，回到原图放大确认后再回填；
• 发票号码重复单独列出：可能是同一张票被拍了两次，也可能是真的重复开票，两种情况的处理方式完全不同，必须由人工判断；
• 异常行回溯原图：借助来源文件名，所有待复核的行都能一键定位到原始图片，不必在相册里“大海捞针”。

3.5 第五步：校验与交付

台账生成后不要直接提交，先完成三项检查：

1. 数量核对：图片张数应与台账行数一致，防止漏识别或漏文件；
2. 抽查金额与日期：随机抽取一定比例的行，与原图逐项比对；
3. 汇总校验：价税合计加总应与报销申请金额一致，确认无误后再按公司实际要求准备报销材料。

四、边界与合规：OCR不等于报销闭环

需要划清能力边界：OCR解决的是“录入”环节的自动化，发票验真与报销审批是另外两道独立流程——发票真伪需通过税务部门提供的官方查验渠道验证，结构化数据本身不构成凭证有效的证明。此外还有两点提醒：

• 数据安全：发票上包含个人姓名、单位抬头等敏感信息，批量处理时注意文件存放位置与访问权限，避免随手共享或上传到不可控的环境；
• 服务与计费：使用云端OCR能力前，需要开通对应服务并了解权限与计费规则，具体以云服务官方页面与文档说明为准。

五、从三五张票据开始试点

与其一次性搭建完整系统，不如先拿三五张清晰票据做试点：手动走一遍“拍摄→识别→核对”的流程，验证字段抽取的准确率与耗时，再逐步扩大批量。当单张处理时间从几分钟降到几十秒，从试点走向常态化使用就是水到渠成的事。