一、先想清楚台账要有什么列

一份能直接拿去报销、对账的发票台账，列的构成基本是固定的：

少了"识别状态"这一列，台账就只能靠人一行行回看原件，批量处理的意义就没了。

二、坑一：不是所有发票都能识别

能读的范围：新版数电票（电子发票（普通发票）、电子发票（增值税专用发票）），以及旧版增值税电子普通发票、电子专用发票。

读不了的范围要记清：成品油、通行费、旅客运输、二手车、代开发票等特定业务版式；以及扫描件、手机拍的图片版——这类没有文字层，本质上需要 OCR，而多数批量工具只读 PDF 里的文字层。遇到这两类，工具应在台账里写明原因，而不是给一个猜出来的号码。

三、坑二：金额校验，交叉核对那一步不能省

可靠的取数逻辑是三条：金额与税额取发票"合计"行；价税合计取"价税合计（小写）"；然后交叉校验：

金额合计 + 税额合计 = 价税合计

对不上时，正确做法不是硬改，而是照旧给出识别到的值，同时在"识别状态"里标注需核对。金额类数据最怕"看起来对"，一旦被自动修正成看似合理的数，人工就再也发现不了问题。

四、坑三：认不出来的发票，金额必须留空

这条听起来反直觉，但很关键：识别失败的发票照样要占一行，写明文件名、页码与原因，金额列留空，绝不填 0。

原因很直接——0 会被当成真实金额参与求和。一张本该 5000 元的发票被记成 0，合计金额就少 5000，而且从表面完全看不出来。留空至少会让求和结果异常，逼你去核对。同理，同一批里识别成功的其它发票不受影响，不该因为一张失败就整批作废。

五、坑四：一个 PDF 里塞了多张发票

这种情况很常见——把整个月的发票合并成一个长 PDF。处理原则是按页拆：一页算一张发票，页码列标出是第几页，15 页的 PDF 生成 15 行，不需要你手动拆文件。

但要留意两件事：一是单文件通常有大小上限（常见 20MB），超了应在上传前拦下，别等传完才报错；二是一次能传的文件数量也有限制（常见一次最多 20 个），批量任务要分批跑。

六、操作顺序建议

1. 先把发票按"同一供应商 / 同一月份"归成几个批次，便于出错时定位；
2. 每批导出后，先看"识别状态"列，把标注需核对的行挑出来人工过一遍；
3. 用"金额合计 + 税额合计 = 价税合计"整批再验一次；
4. 台账存档时保留来源文件名与页码，等于留了一条回到原件的路。

至于发票文件本身，处理完就该删——只在这一次识别中使用、不存储，是目前同类工具的常规做法。涉及公司税号与金额的文件，能不留在第三方就尽量不留。