最適合處理收據與發票的 OCR 軟體
收據與發票 OCR 軟體選購指南：可驗證的準確度、明細項目、匯出、API、Webhook、稽核軌跡與透明定價——並以即時 Demo 實際驗證。
凡是要處理紙本的公司，都免不了要處理收據和發票——而這兩種文件用手一筆一筆輸入，實在折磨人。OCR 的價值不言而喻：把文件拍下來，拿到結構化資料，然後就能繼續做下一件事。問題在於，多數 OCR 工具只做到看起來像對的。它丟給你一個廠商名稱、一筆總額，剩下的就要你自己選擇相信。如果只是記個人開銷，這樣沒問題；但換成應付帳款、費用核銷，或任何會被稽核的場景，「模型說是這樣」並不是你能扛得住的答案。
這篇指南就是一份選購檢查清單。它會帶你看清楚：真正把收據與發票 OCR 軟體做到頂尖，跟一個華麗的 Demo 之間，差別到底在哪——可驗證的準確度、明細項目擷取、乾淨的匯出、附帶 Webhook 的真正 API、稽核軌跡，以及你能事先預估的定價——接著示範 space-ocr 如何逐一做到，而且是用一個可即時點選驗證的 Demo，而不是一張截圖。
先看證據：一個你可以親自驗證的真實擷取結果
在列出任何功能之前，先給你看多數廠商不會給你看的東西：一個每個值都能指回它在頁面上原始位置的擷取結果。把滑鼠移到下方任一欄位上——收據上框起來的地方，就是這個值被讀出來的位置。
Each value with a box carries a verified on-page location — in data.cells[path], that is box + 4-point quad + evidence.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 | 真正有量時靠的是自動化，不是一直點 | 只有 UI，或一個簡陋的同步端點 | 帶非同步工作與簽章 Webhook 的 REST API |
| 稽核軌跡 | 審核者需要看到改了什麼 | 默默覆蓋掉 OCR 輸出 | 把原始值保留在人工修改值旁邊 |
| 透明定價 | 編預算最怕意外 | 什麼都要「聯絡我們」 | 公開的單張價格，外加免費方案 |
本文接下來會逐列拆解。
可驗證的準確度，勝過一個信心分數
信心分數告訴你的是：模型覺得自己很確定。它並沒有告訴你 total: 2,045 到底是不是收據上實際印著的那個數字。space-ocr 回答的是一個更嚴格的問題。業務資料放在 data.values，而通往它的每一條路徑（total、line_items[0].unit_price）都對應 data.cells 裡的一筆：
box——一個軸對齊的矩形{ xmin, ymin, xmax, ymax }，建立在 0–1000 正規化的網格上（0,0 = 左上，1000,1000 = 右下）。要換算成像素，用data.image——它給的是實際讀取時的頁面寬高。quad——四個有序頂點，跟著文件的傾斜角度走，而且一定與box一起回傳。系統不做傾斜校正，所以歪斜的手機照片，框也會照著頁面原本的樣子貼上。verified——這是一個判定：儲存格帶有複查原因時為false，比對跑過而且沒有任何標記時為true，沒有可比對的對象時（例如明細列的合併框）為null。review——不是null，就是{ reasons }，說明這個儲存格為什麼值得再看一眼。evidence——判定背後的佐證：text_match是逐字元比對本身的結果，match_ratio表示這個值有多少字元在頁面上被定位到，printed_text則是那些座標上 OCR 讀到的原始字元。
待辦清單是 data.review.flagged——一個 { path, reasons } 陣列，其中 path 和 cells 的鍵用同一套寫法，可以直接取到對應的儲存格。因為位置資訊是隨值一起帶出來的，你可以直接畫出框、引用座標，或者重新檢查一個被標記的欄位，完全不必重跑一次 OCR。這正是 OCR 稽核軌跡 的基礎——也是為什麼上面那個 Demo 不是擺拍出來的假畫面。
這些座標不是聽模型一面之詞得來的。 語言模型只回傳每個欄位的文字——外加它用到了哪些 word token 的提示——但從不自己給出那些框。引擎接著拿這段文字，去跟視覺 OCR 在頁面上實際偵測到的符號做字元層級的比對，於是框會落在這些字元真正被找到的像素上，而每個值也會得到一個 match_ratio，代表它被定位到的程度。模型給的 token 提示可能有雜訊（它有時會在重複的列之間把提示張冠李戴），所以系統用欄一致性與列一致性檢查來驗證這些提示，而不是盲目相信。重點不在於 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" }
]
}
]
}只宣告你需要的欄位——還沒定案就交給 autoFields
擷取結構用 fields 陣列傳入：把真正會寫進資料庫的項目按名稱和型別列出來，明細項目則宣告成 type: "array" 欄位，用 children 描述其中一列。如果還不知道單據上有哪些項目，改傳 autoFields: true，由模型提出一份結構——把它回傳的欄位名固定成明確宣告，就是你的正式呼叫。
宣告不是一個調整準確度的旋鈕。required、pattern、min/max、enum、near、not_near 都不會傳給模型，所以宣不宣告，擷取出來的值都一樣。多出來的是兩件事：違反規則的值會連同原因（missing、pattern_mismatch、out_of_range、near_mismatch、near_conflict）進到 data.review.flagged；而宣告 number、integer、date 會在 values 旁邊多出 data.normalized 這一層——同一份讀值的確定性解析結果，同一張頁面每次跑都得到同一個數。near 和 not_near 並不能讓模型在印著兩個公司名的單據上挑對那一個，它們的作用是讓挑錯這件事現形。
整個呼叫就是一個 HTTP request——不用 SDK，也不用對 PDF 做前處理（引擎讀的是點陣影像，也就是照片和掃描檔）。
# A. 正式——只宣告你真正會寫進資料庫的項目
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",
"fields": [
{ "name": "issuer", "type": "string", "near": ["統一編號", "電話"] },
{ "name": "recipient", "type": "string", "not_near": ["統一編號", "電話"] },
{ "name": "invoice_no", "type": "string", "required": true,
"pattern": "^[A-Z0-9-]{4,}$" },
{ "name": "invoice_date", "type": "date" },
{ "name": "payment_method", "type": "string", "enum": ["現金", "轉帳", "信用卡"] },
{ "name": "total", "type": "number", "required": true, "min": 0 },
{
"name": "line_items",
"type": "array",
"children": [
{ "name": "description", "type": "string" },
{ "name": "quantity", "type": "number" },
{ "name": "unit_price", "type": "number" }
]
}
]
}'
# B. 探索——還沒有結構，讓 API 提一份
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",
"autoFields": true
}'匯出與 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 文件。
稽核軌跡：機器讀到什麼，對比人工改了什麼
最好的收據與發票 OCR，不只記錄自己的輸出——它還記錄修正。當你在 space-ocr 裡編輯一個儲存格時，你的值會跟原始 OCR 值分開儲存，而一個Original（原始）提示框永遠會顯示引擎最初讀到的內容。審核者能並排看到機器的值和人工覆蓋後的值——這正是稽核所要求的。
透明、可預估的定價
可驗證的準確度和一個誠實的價格，往往出自同一種態度。space-ocr 是每張影像 $0.05。有一個每月 100 點數、免綁信用卡的免費方案，而 Pro 方案每月 $39，含 1,100 點數、不限表格數量，以及 100 GB 儲存空間。沒有按欄位計費，沒有按頁加收，而對已儲存表格的查詢（GET /view）是免費的。
如何擷取一張收據或發票
- 送出影像把收據或發票 POST 到 /ocr/fields，imageType 用「url」或「base64」。引擎讀的是點陣影像——手機照片或掃描檔。
- 宣告欄位用 fields 陣列宣告你要寫進資料庫的項目，明細項目用帶 children 的 array 欄位描述其中一列。如果結構還沒定案，就改傳 autoFields 讓模型提一份。
- 讀取結構化結果業務資料在 data.values；每個值的 box、quad、verified、review 與 evidence 在 data.cells[path]；座標所依據的頁面尺寸在 data.image。
- 驗證並修正逐筆處理 data.review.flagged：每一筆都會給出路徑和原因（text_mismatch、missing、out_of_range 等）。點選儲存格就能高亮它被讀出來的確切區域；編輯內容會儲存在原始值旁邊。
- 匯出或查詢下載 CSV（UTF-8 BOM，明細項目已展開），或用 GET /view 搭配 where、sort 和 select 查詢已儲存的表格——不必重跑 OCR，也不另外收費。