最好用的票据与发票 OCR 识别软件
票据与发票 OCR 软件选购指南：可验证的准确度、明细提取、导出、API 与 webhook、审计追踪，以及透明的定价——并用实时演示逐一印证。
凡是要跟纸打交道的企业，都绕不开票据和发票——而这两样东西手动录入起来都让人头疼。OCR 的卖点很直白：把单据拍下来，得到结构化数据，然后继续干别的。问题在于，大多数 OCR 工具只做到了看起来像那么回事。它们给你一个供应商名称和一个合计金额，剩下的就要你自己去信。记一笔个人开销，这没问题。但放到应付账款、费用对账，或者任何会被审计的场景里，“模型说是这样”可不是你敢拍胸脯担保的答案。
本文就是一份选购清单。它会带你梳理：到底是什么把真正好用的票据与发票 OCR 软件和一个华而不实的演示区分开来——可验证的准确度、明细行提取、干净的导出、带 Webhook 的真正 API、审计记录，以及你能预估的定价——然后展示 space-ocr 如何逐一做到，用一个实时、可核对的演示，而不是一张截图。
先看证据：一次你可以亲自核对的真实提取
在罗列任何功能之前，先看一样多数厂商不会给你看的东西：一次提取里，每一个数值都能指回它在页面上原本所在的确切位置。把鼠标悬停在下方任意字段上——票据上高亮的那个框，就是这个数值被读取的地方。
Each value with a box carries a verified on-page location — bbox + 4-point vertices + match_ratio — on a 0–1000 normalized grid (0,0 top-left → 1000,1000 bottom-right), the same shape the live API returns. Hover a field to trace it back to the pixels it came from.
票据与发票 OCR 该看哪些点
票据和发票是最难啃的“简单”单据。版式因供应商而异，合计金额藏在小计和税额之间，明细行会换行折行，而一张手机拍的照片往往是歪的、还带着反光。一个能搞定干净 PDF 的工具，下一张皱巴巴的热敏小票就可能崩盘。用下面这些标准，帮你穿过营销话术看清本质。
| 关键点 | 为什么重要 | 弱工具 | 强工具 |
|---|---|---|---|
| 可验证的准确度 | 一个无法追溯的数字，反正你还得重新录入一遍 | 给出一个值，也许再加个置信度分数 | 给出每个值连同它在页面上的位置，可一键跳转 |
| 明细行 | 发票和票据是表格，不是一组扁平字段 | 抓到合计，丢掉行 | 提取可重复的明细行，每个单元格都带位置 |
| 导出 | 数据得能离开工具才有用 | 复制粘贴或锁死在查看器里 | 通过 API 提供 CSV（Excel／中日韩文本安全）和 JSON |
| API + Webhook | 真有量就意味着自动化，而不是点鼠标 | 只有界面，或一个单薄的同步接口 | 带异步任务和签名 Webhook 的 REST API |
| 审计记录 | 审核者需要看到改了什么 | 悄悄覆盖 OCR 输出 | 把原始值保留在人工修改旁边 |
| 透明定价 | 做预算最怕意外 | 凡事“请联系我们” | 公开的单图价格加免费额度 |
本文余下部分会逐行展开。
可验证的准确度，胜过一个置信度分数
置信度分数告诉你模型自我感觉很有把握。它并不告诉你 total: 2,045 到底是不是票据上实际印着的那个数字。space-ocr 回答的是一个更严苛的问题，它在每个值旁边一并返回：
bbox——一个轴对齐矩形{ xmin, ymin, xmax, ymax }，位于一个 0–1000 normalized（归一化）网格上（0,0 = 左上角，1000,1000 = 右下角），与图片的像素尺寸无关。vertices——四个有序顶点，构成一个带方向的框，会跟随单据的倾斜角度，所以哪怕手机拍歪了也能干净地框住。match_ratio——该值的字符中，实际在页面上被定位到的比例（0–1）。当达到 ≥ 0.85 时，该字段被视为可信匹配；1.0表示每一个字符都被找到了。
因为位置是跟着值一起走的，你可以渲染出这个框、引用这些坐标，或者重新核对一个被标记的字段，而无需重跑 OCR。这正是 OCR 审计记录 的基础——也是上面那个演示不是摆拍的原因。
这些坐标并不是听模型一面之词得来的。 语言模型会返回每个字段的文本——以及它用到了哪些词元（word token）的提示——但从不返回框本身。引擎随后把这段文本与视觉 OCR 在页面上实际检测到的符号逐字符匹配，于是框落在这些字符被找到的真实像素上，每个值也据此得到一个 match_ratio，表示它有多大比例被定位到了。模型给的词元提示可能有噪声（在重复出现的行之间它有时会张冠李戴），所以系统用列一致性和行一致性检查来验证这些提示，而不是盲目相信它们。重点不在于 AI 不会出错——而在于每个值都会回过头来与票据本身核对，并附上一个分数说明它匹配得有多好。
要的是明细行，不只是合计
廉价票据 OCR 最大的缺口就在表格。谁都能抓到一个总计；真正的价值在行里——每一项商品、数量、单价和折扣。space-ocr 把这些提取为可重复的行，而且每个单元格都保留自己的位置，所以一条换行或合并的明细行依然可追溯。
你通过一个 type: "array" 的字段来请求它们，其 children 描述一行的结构。关于行模型更深入的讲解，参见 从发票中提取明细行。
{
"fields": [
{ "name": "vendor", "type": "string" },
{ "name": "invoice_date", "type": "string" },
{ "name": "total", "type": "string" },
{
"name": "line_items",
"type": "array",
"children": [
{ "name": "description", "type": "string" },
{ "name": "quantity", "type": "number" },
{ "name": "unit_price", "type": "number" }
]
}
]
}内置模板：省去写 schema 的功夫
常见场景下，你不必手写字段定义。space-ocr 自带预设模板，只需一个 templateId 即可套用——包括 receipt（票据）和 invoice（发票），还有名片、报价单、采购订单、送货单以及多种证件文档。模板会替你提供字段集合和提示词；如果你同时传入了自己的 fields，则以你的为准。
整个调用就是一次 HTTP 请求——不用 SDK，也不用对 PDF 做预处理（引擎接收栅格图像：JPEG、PNG、GIF、BMP、TIFF、WebP）。
curl -s https://api.space-ocr.com/ocr/fields \
-H "Authorization: Bearer $SPACE_OCR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"image": "https://example.com/invoice.jpg",
"imageType": "url",
"templateId": "invoice"
}'导出与 API：数据去往何处
如果数据被困在工具里，提取就毫无价值。space-ocr 给你两条干净的出口：
- CSV——表格导出时带 UTF-8 BOM，这样 Excel 才能正确打开日文、韩文和中文文本。数组（明细行）会展开成子行，而任何人工修正都会在输出中覆盖 OCR 原值。
- 基于 REST 的 JSON——
POST /ocr/fields处理单份单据，POST /upload把图片直接推入一张表，GET /view在服务端查询已存储的表（where、sort、select、limit），无需重跑 OCR，也不必再付一次费。
面向大批量的自动化，/upload 默认是异步的：它为每个文件返回一个任务，并在完成时通过 Webhook 通知你——每个空间一个签名（HMAC-SHA256）端点，事件如 ocr.completed 和 ocr.failed。这就是“你点鼠标的工具”和“自己跑起来的流水线”之间的区别。完整的接口面收录在 发票数据提取 API 指南 和 API 文档 里。
审计记录：机器读到了什么 vs. 人改了什么
最好的票据与发票 OCR，不只是记录它自己的输出——它还会记录修正。当你在 space-ocr 里编辑一个单元格时，你的值会与 OCR 原值分开存储，而一个 Original（原值）提示框始终显示引擎最初读到的内容。审核者可以并排看到机器值和人工覆盖值——这恰恰是审计所要的。
透明、可预估的定价
可验证的准确度和一个实诚的价格，往往出自同一种态度。space-ocr 为每张图 ¥10。有每月 100 次扫描的免费额度，无需信用卡；Pro 套餐 ¥7,980/月，含 1,100 次扫描、团队共享和 100 GB 存储。更大的用量由 Business 套餐通过联系洽谈承接。没有按字段计费，没有按页加价，针对已存储表的查询（GET /view）也是免费的。
如何提取一张票据或发票
- 发送图像把票据或发票 POST 到 /ocr/fields，imageType 取 'url' 或 'base64'。引擎接收栅格图像（JPEG、PNG、GIF、BMP、TIFF、WebP）。
- 套用模板或字段传入 templateId 'receipt' 或 'invoice' 以使用内置 schema，或者提供你自己的 fields——包括一个带 children 的 array 字段用于明细行。
- 读取结构化结果每个值返回时都带着它的 bbox、vertices、match_ratio 和 bbox_source，外加一个 field_bboxes 映射，定位页面上的每个字段。
- 核对与修正点击任意单元格即可高亮它被读取的确切区域；match_ratio 低于 0.85 会标记出一个值得再看一眼的值。修改会保存在原值旁边。
- 导出或查询下载 CSV（UTF-8 BOM，明细行已展开），或用 GET /view 配合 where、sort 和 select 查询已存储的表——无需重跑 OCR，也不额外收费。