把 OCR + LLM
接入财务系统的八个常见坑。

把 OCR 与 LLM 接进财务系统，听起来是一件已经被做烂的事——发票识别、凭证抽取、自动录账，市面上的现成方案一抓一大把。但只要你真的把一套链路推到真实业务上跑满三个月，就会发现：演示环境里跑得漂亮的方案，和能稳定承接一家公司每月几千张票据的方案，中间隔着八个具体的、反复出现的坑。这篇文章把我们在财税与财务场景里反复踩到的八个坑列出来，每一个都附上我们现在的处理判断。

先说一个总的判断：财务场景的 AI 落地，本质不是一个识别问题，而是一个对账问题。识别只是把图片变成结构化字段，而财务真正在意的是这些字段能不能和台账、合同、银行流水三方对得平。识别错一个字段，下游可能是一笔对不平的账。所以下面八个坑，越往后越偏向工程闭环，而不是模型本身。

§ 01把识别准确率当成项目验收指标

第一个坑出现在立项阶段。很多财务团队会把「OCR 识别准确率 99%」写进验收条款，这个指标听上去严谨，实际上具有误导性。问题在于：99% 的准确率，分母是「所有字段」，而财务真正在意的是少数几个关键字段——金额、税额、开票方税号、发票代码。如果一张票上有三十个字段，错的恰好是金额，那么这一张票的业务价值就是零，哪怕另外二十九个字段全对。

我们现在的做法是把验收指标换成「关键字段全对率」——一张票上的金额、税额、税号、号码必须同时正确才算这张票通过。这个口径下，演示阶段看起来很美的 99%，往往会掉到 88% 到 92% 之间。这个落差不是模型变差了，而是你终于在用财务的标准衡量它。

§ 02忽略票据的版式离散度

第二个坑是低估了真实票据的版式数量。增值税专用发票有国家统一版式，这部分确实好做。但一家公司每月收到的票据里，专票往往只占一半不到——剩下的是各地差异巨大的电子普票、火车票、机票行程单、过路费票、定额票、餐饮小票，还有大量供应商自制的收据。

这些非标票据没有统一版式，靠纯版面规则的 OCR 几乎无法稳定抽取。这正是 LLM 真正发挥价值的地方——把 OCR 输出的全文文本丢给 LLM，让它基于语义而非坐标去理解「这一串数字是金额还是发票号」。但前提是你要在项目早期就把客户的真实票据做一次版式普查，统计出大致有多少种版式、各自占比多少，而不是拿几张专票就开工。

§ 03金额字段不做格式归一

第三个坑非常具体，但代价很高。LLM 抽出来的金额是文本，而文本形态的金额千变万化：有的带人民币符号，有的带千分位逗号，有的写成大写「壹万贰仟元整」，有的把小数点识别成了句号，还有的因为票面褶皱把「8」识别成了「3」。如果你直接把这串文本写进财务系统的金额字段，轻则报错，重则金额错位却不报错。

必须在 LLM 抽取和写库之间插一道金额归一与校验层。这一层做三件事：把所有金额形态统一成纯数字、用大小写金额互相交叉验证、用「价税合计 = 金额 + 税额」这条恒等式做一次自检。任何一项对不上，这张票就不应该自动入账，而要转人工。这道校验层的代码量不大，但它拦住的是最危险的一类错误——静默的金额错误。

§ 04没有设计异常回流的闭环

第四个坑是整个项目里最容易被跳过、却最致命的一个。团队往往把精力全花在「识别对的票怎么自动入账」，却没有认真设计「识别不了的票怎么办」。结果上线后，凡是模型没把握的票据，要么被静默丢弃，要么被强行猜一个值入账，财务在月底对账时才发现一堆问题，对系统的信任瞬间崩塌。

正确的结构是：每一张票都必须有明确的去向——要么自动入账，要么进入一个人工复核队列。模型对自己的每次抽取都要输出一个置信度，低于阈值的票自动转入复核队列，由财务人员一键确认或修正。被修正的数据再回流成为下一轮迭代的样本。没有这个回流闭环，你的系统永远停在第一版的水平。

Tab. 01 — 每张票都必须有确定去向 · 没有第六种「不知道怎么办」

§ 05把 LLM 当成确定性接口

第五个坑是认知层面的。工程师习惯了传统接口的确定性——同样的输入永远是同样的输出。但 LLM 不是这样，同一张票，两次调用可能给出略有差异的结果，尤其是在票面模糊、字段歧义的情况下。如果你的系统假设 LLM 是确定性的，就会在偶发的不一致面前措手不及。

处理方式有两个。一是在调用参数上把随机性压到最低，让输出尽可能稳定。二是更重要的——对关键字段做结构化约束，强制 LLM 按固定的字段名和数据类型返回，而不是返回一段自由文本再去解析。结构化输出能消除掉大部分「这次多了一句话、下次少了一个字段」的解析噩梦。把 LLM 当成一个有波动的概率系统来设计，而不是一个确定的函数。

§ 06政策检索和字段抽取混在一个提示词里

第六个坑出现在功能稍复杂的项目里。财务自动化常常不止要抽字段，还要判断「这张票能不能抵扣」「这笔费用该进哪个科目」——后者需要检索税收政策和企业的记账规则，也就是要接一套 RAG。常见的错误是把「抽字段」和「查政策做判断」塞进同一个提示词，让 LLM 一次性全干。

结果是两个任务互相干扰：抽字段需要的是严格、保守、不发挥；查政策做判断需要的是检索、推理、解释。混在一起，LLM 会在该保守时发挥、该推理时偷懒。正确的做法是拆成两段独立的链路——第一段只做纯抽取，输出干净的结构化字段；第二段拿着这些字段再去做政策检索和科目判断。两段各自可以独立测试、独立优化、独立设置不同的模型与参数。

§ 07重复票据和跨期票据没有去重机制

第七个坑是财务特有的。同一张发票，可能因为业务流程被扫描、上传、提交多次；也可能这个月先来了一张复印件、下个月又来了原件。如果系统只管识别不管去重，就会出现同一笔支出被重复入账，这是财务最不能接受的错误之一。

去重不能只靠发票号码，因为不同省份、不同类型的票据号码规则不一致，单独一个号码可能撞车。我们用的是发票代码加号码加金额加开票日期的组合指纹，任何一张新票入库前都先拿这个指纹去比历史记录。命中的不自动入账，而是拦下来让人确认——是真的重复，还是复印件与原件这种合理的「同票多次」。把去重做成一道独立的前置闸门，而不是事后靠对账去补。

§ 08不给财务留一个可解释的追溯入口

最后一个坑关于信任。财务是一个需要对每一个数字负责的岗位，当一笔账由 AI 自动生成，财务人员在被审计、被质疑时，必须能回答「这个金额是怎么来的」。如果你的系统只给出一个最终结果，中间过程是一个黑盒，那么财务永远不敢真正放手用它。

所以每一次自动入账，系统都应该保留一条完整的可追溯链路：原始票据图片、OCR 的全文文本、LLM 抽取的字段、校验层的判定、最终写入的凭证，全部可以一键回看。当财务点开任意一笔账，能在十秒内看清它从一张图片到一条凭证的全过程。这个追溯入口不创造识别价值，但它创造的是信任——而信任才是这类项目能不能真正被日常使用的前提。

回头看这八个坑，会发现一个清晰的规律：靠前的坑偏模型（识别、版式、格式），靠后的坑偏工程（闭环、去重、追溯）。而真正决定一个财务 AI 项目成败的，往往是靠后的那几个。模型部分今天已经有足够成熟的现成能力，把票面变成字段不再困难；困难的是把这些字段安全、可对账、可追溯地接进一个财务团队每天都要用、每月都要被审计的真实系统里。

如果你正在评估或推进一个类似的项目，建议把这八个坑当成一份立项前的检查清单。能在动手前就把异常回流、金额校验、去重、追溯这四件事想清楚，项目成功的概率会比「先把识别做出来再说」高得多。