如何把发票数据提取到 Excel——无论版式如何

如果你的收件箱每个月都被供应商发票塞满，那你早就熟悉这套流程了：打开每一份 PDF，找到发票号、日期、合计金额，把每一行明细都抄下来，再一项项敲进表格。然后换下一家供应商重来一遍——而它的发票跟上一份长得毫无相似之处。

最后这一点才是真正的麻烦。问题不在于发票的数量，而在于没有两家供应商用一样的格式。合计金额放在不同的位置，日期用不同的写法，明细表的列也各不相同。人能毫不费力地适应每一种版式，但大多数软件做不到——这也是为什么那么多团队干脆放弃，全部靠手工重新录入。

本文将带你走一遍，如何把发票数据提取成干净的 Excel、CSV 或 JSON——适配任意版式——而且无需为每家供应商单独搭建并维护一套模板。

为什么发票比看上去更难提取

如果只有一种固定的发票模板，那很简单。麻烦在于，你几乎永远不会只有一种。发票之所以难以被干净提取，有几个原因：

• 每家供应商的版式都不一样。 发票号、账单地址、合计金额放在哪里，根本没有行业标准。你为某家供应商设好的模板，一旦新供应商寄来第一张发票，就立刻失效。
• “金额”本身就有歧义。 一张发票上有小计、税额、运费、折扣前总额，还有最终应付金额——它们往往就紧挨着堆在一起。如果你只说”提取金额”却不说清是哪一个，那提取引擎猜到哪个就给你哪个。
• 明细行是一个列表，而不是一个值。 每张发票只有一个发票号，但有许多明细行，每行都有自己的描述、数量、单价和行小计。一旦把这些拍扁拍错，本想要的整齐行就变成了一团乱麻。
• PDF、扫描件，还是照片。 以 PDF 形式邮件发来的发票是干净的文本。同一张发票在前台扫描，或者用手机拍下来，就成了图片——这时你得先做 OCR 才能提取任何内容，而 OCR 又会带来它自己的误差。

任何号称能”直接提取发票”的工具，都必须对以上每一点都有应对之策。手工录入的痛苦，正源于这种千差万别，而不是某一张单独的发票。

几种常见做法，以及各自的失效边界

并不存在唯一正确的工具——关键取决于你要应对多少家供应商，以及他们的版式有多一致。

手工录入。 零搭建成本，只要细心就准确，但完全无法规模化。每月处理几张还行；一旦要在众多供应商之间处理几十张，就根本撑不住了。

基于模板的解析器。 你只需定义一次每个字段在页面上的位置。如果每张发票长得一模一样，那它又快又省。但既然每家供应商都不同，你最终还是得为每家供应商搭建并维护一套模板——而且某家供应商一改版式，你当天就得重建模板。如果你有三四家长期稳定的供应商，这没问题；可一旦面对一长串还在不断变动的供应商名单，搭建成本就把省下的时间全吃掉了。

自然语言提取。 你不再去标注位置，而是用日常语言描述你想要的字段，由引擎去适配每一种版式。这直接解决了”每家供应商都不一样”的难题，而且对扫描件和奇怪的格式宽容得多。代价是，你会希望工具能让你核对输出结果——因为你信任的是一个模型在读取页面，而不是一个固定的坐标。

最后这一类正是 Ztract 所处的位置，所以我们来具体走一遍。

实操演示：在 Ztract 里把发票变成 Excel

下面是完整流程——无论你是处理一张发票，还是来自十几家不同供应商的五十张发票，流程都一样。

1. 创建项目并描述你想要的内容

项目只是一个容器，用来装相关的文档以及你要应用到它们身上的 Schema。对于发票，你有三种方式来定义这个 Schema：

• 从现成的发票 Schema 开始再做调整。这是最快的起步方式——它已经认识发票号、日期、供应商信息、合计金额和明细行。

• 用日常语言描述字段。 例如：

  “对于每一张发票，提取发票号、开票日期、供应商名称，以及应付总金额（含税并扣除折扣后）。然后对每一条明细行，提取描述、数量、单价和行小计。如果某个字段不存在，就留空，不要猜测。”

  注意这里有两点。“应付总金额（含税并扣除折扣后）” 明确告诉引擎，在那几个金额里你指的究竟是哪一个。而 “对每一条明细行” 把明细行标记为一个可重复的列表，于是你拿回来的是整齐的行，而不是全部挤进一个单元格。这两个习惯，几乎就是可信赖的发票输出与一团乱麻之间的全部区别。

• 从样本推断。 放入一张有代表性的发票，让 Ztract 据此为你提出一份 Schema。当某家新供应商的发票上出现了你没料到的字段时，这一招很有用。

关键优势在于：同一份 Schema 在不同供应商之间都通用。你描述的是你想要的数据，而不是它所在的位置——所以一种你从未见过的版式，会和你见过的版式得到完全一样的处理。无需为每家供应商单独建模板。

2. 上传发票

把文件拖进来——PDF、Word、Excel、扫描件，或者手机照片，单文件最大 500 MB。基于文本的 PDF 和基于图片的扫描件都行；扫描件只是会先经过 OCR。如果一个月的发票是来自不同供应商的一堆独立文件，全部一起上传即可，同一份 Schema 会应用到每一张上。

3. 审阅与修正——真正省时间的环节

人们常常低估这一点：对于发票来说，提取本身不是时间黑洞——核对才是。如果你无法信任输出结果，最后还是得拿着发票逐张去比对表格，那就等于一点没省下。

Ztract 正是围绕这一点打造的。每一个提取出来的值都锚定在它在源文档上的精确位置：点击结果里的一个数字，它就会高亮出这个值在发票上的来源处。正是这种左右并排的视图，让审阅变得很快。你不必逐个字段重新核对，只需扫一眼那些看起来不对劲的——比如某个合计错抓成了小计，某条明细行把两行合并到了一起——然后一键改好。

而且因为我们只对提取计费，所以修正一个值不花你一分钱。 之后的编辑是免费的；只有你提取的页面才会从你的页面包里扣除，整理修正不计入。

4. 导出

确认无误后，导出为 Excel、CSV 或 JSON——可以单张发票导出，也可以整个项目一次性导出。从那里，它就能直接接入你的应付账款流程、你财务软件的导入功能，或者这些数字接下来需要去的任何地方。

那些仍然需要人眼把关的情况

与其假装不存在，我们更愿意如实告诉你哪里会变得棘手。有几种情况需要留意：

• 贷项通知单与退款。 贷项通知单看起来像发票，但金额的方向是相反的。在 Schema 里要明确说明如何处理负数金额，并在审阅环节再三核对正负号。
• 多币种供应商。 如果你向不同币种的供应商采购，要把币种作为每张发票自己的一个字段来捕获，而不要假定整批都用同一种货币——否则一个写着”1,000”的合计什么也说明不了。
• 严重劣化的扫描件。 一张先传真、再重新扫描、字迹模糊的发票，对任何人来说都难以辨认，OCR 也一样。如果源件连你自己都看不清，那就要做好更仔细核对的准备——一份更清晰的扫描件，胜过事后再多的修正。

如果一种我们本应处理好的版式却返回了错误结果，我们是真心想看看——发一份样本（需要的话可先做匿名化处理）到 support@ztract.com，我们会深入排查。大家发给我们的文档，正是引擎不断变好的来源。

关于供应商数据的说明

发票携带着敏感的商业信息——你向谁采购、你支付多少、你的账号——所以有必要把话说清楚：我们不会用你上传的文档来训练模型。 既不用于训练我们自己的引擎，也不用于训练我们所对接的第三方 LLM；我们使用的商业 API 都禁止用提交的数据进行训练，而我们正是依托这些承诺。当你删除一张发票时，它会立即从活跃存储中消失，并在 14 天内从备份中清除。完整说明请见我们的隐私政策和数据处理协议。

拿你自己的发票试一试

要判断这是否契合你的工作流，最快的办法就是拿几张你原本要手工录入的真实发票来跑一遍——最好来自几家不同的供应商，这样你就能亲眼看到同一份 Schema 如何应对不同的版式。新账户可获得 30 页免费额度，无需信用卡——足够你从头到尾提取一批，并亲自核对那些合计金额。

如果你需要大批量处理发票，并且愿意就哪些好用、哪些不好用给出真诚的反馈，欢迎联系我们——我们正在邀请早期用户加入，并围绕大家真正头疼的那些文档来规划接下来要做什么。发票正好就排在那张清单的最前面。

想了解更多关于发票数据提取的内容，欢迎查看我们的使用场景页面。