用OCR與ChatGPT自動化發票處理

簡而言之： 用一個具備版面感知能力的OCR步驟，加上一個把擷取文字轉成結構化發票欄位的語言模型，然後把所有低於信心門檻的項目——以及每一次供應商銀行帳號變更，無一例外——交給人處理。技術能很好地解決鍵入和勾稽。它解決不了發票詐騙，而那才是真正讓你損失金錢的部分。

應付帳款是一個整體已高度自動化的財務職能裡，最後幾個真正靠人工完成的流程之一。發票以PDF寄過來，有人從上面讀出幾個數字，鍵進會計系統，追著主管要簽核，之後再回覆供應商那封問「什麼時候付款」的信。一個月兩百次。

這恰恰是現在的AI真正擅長的工作形態。多數文章略過的，是決定這個專案究竟是淨收益還是一項新負債的那一部分：一條自動化的應付帳款管線，同時也是一條從信箱直通銀行付款檔的自動化通路。查證做錯了，你就為「誰把你的供應商仿冒得最像就把錢匯給誰」這件事，建成了一套又快、文件又齊全的流程。

應付帳款的時間到底花在哪裡？

在自動化之前先量測，因為這裡的假設通常是錯的。

鍵入發票資料。 從文件上讀出供應商、發票號碼、日期、幣別、明細、稅額和總額，再鍵進系統。枯燥、易錯，也正是AI擷取能幾乎完全拿掉的那一塊。

勾稽。 確認這張發票對應著你確實訂過、確實收到的東西，價格是談定的那個。部分可自動化，且完全依賴於你有沒有採購單和收貨紀錄可供比對。

追簽核。 通常是整個時鐘上最大的一塊。一張發票躺九天，不是因為有人在打字，而是因為它排在預算負責人信箱裡另外四百封信的後面。只自動化擷取、不動簽核，你的應付帳款週轉天數幾乎不會變化。

處理例外。 缺採購單號、數量不符、折讓單、部分交貨、幣別搞錯。佔用的時間不成比例，而且是自動化幫助最小的情境。

上面只有第一項是AI擷取能完整解決的。這依然值得做，但在有人拿它去寫商業論證之前，先把預期設定對。

搭建這條管線：先OCR，再AI擷取

為什麼OCR和語言模型是兩件不同的事？

把這兩步當成一件事，正是多數自建管線出問題的地方。

OCR把像素轉成字元，同時給出它們在頁面上的位置。成熟的文件AI服務——Google Document AI、AWS Textract、Azure AI Document Intelligence、ABBYY——回傳的是帶版面資訊的結果：帶邊界框的字詞、被辨識出的表格結構，以及往往已初步標出的鍵值對。這層幾何資訊比人們以為的更重要。一個數字之所以能被認成「合計」，一部分原因是它在頁面上的位置和它旁邊的東西，而不只是因為附近出現了「Total」這個字。

模型的工作從這之後才開始：把標籤不統一的雜亂文字，變成一筆乾淨的結構化紀錄。「Inv. No.」、「Invoice #」和「Ref」說的是同一件事；03/04/26有三種互不相容的讀法；一筆明細可能跨兩列換行。這種正規化的判斷，正是模型存在的意義。

多模態模型可以直接讀發票影像、省掉OCR這一步，在乾淨的數位PDF上通常做得不錯——對一天只有幾張發票的公司是合理的。但在有量的情境下，兩段式管線通常更好：單份文件更便宜；可以存下OCR結果，改提示詞後重跑擷取而不必重新處理原始檔；以及能指出某個數值來自頁面上的哪一塊區域。最後這一條，在稽核人員第一次問「這個數字哪來的」時就顯出價值。

無論走哪條路，都要求模型依固定schema輸出嚴格的JSON，並明確指示：找不到的欄位回傳null，而不是推斷出一個看起來合理的值。缺漏的欄位會被路由給人，而一個自信捏造出來的欄位不會。

信心門檻和簽核關卡該怎麼設？

三方勾稽是傳統的控制手段：發票必須與採購單、以及與「實際收到了什麼」的紀錄一致，逐行比對，落在你設定的容差內。沒有採購單紀律，這個控制根本不存在，再多AI也替代不了。

信心度有兩種，只有一種可靠。模型對自己的評分是個弱訊號——模型完全有能力「很有把握地錯」。內部一致性有用得多：明細加總等於小計嗎？小計加稅等於總額嗎？供應商在主檔裡存在嗎？發票號碼是不是重複項？稅率對那個法域合理嗎？這些算術和交叉引用檢查，抓到的真實錯誤比任何自評分都多，而且實作成本很低。

然後按風險路由，而不是只按信心度。以下一律交給人：超過你設定金額門檻的、第一次出現的供應商、付款資訊與留檔不一致的，以及疑似重複的。

有一條規則值得當作絕對律：擷取可以產生一張應付單據，但絕不能放款。「直通到已簽核的應付款」是合理目標；「直通到錢離開帳戶」不是，無論信心度多高。

一個完整例子：從信箱裡的PDF到一張已簽核的應付款

供應商把發票寄到專用的應付帳款信箱。管線對附件計算雜湊，立即丟掉與已處理檔案完全相同的重複件——這一步值得放在最前面，因為供應商是會重寄的。

OCR回傳帶版面的文字。擷取步驟把它連同你的schema交給模型，拿回一筆結構化紀錄：供應商、稅籍編號、發票號碼與日期、幣別、明細、稅額、總額、付款條件，以及文件上印著的銀行帳戶資訊。

接下來是驗證，由一般程式碼完成，不交給模型。算術必須對得上，供應商必須能解析到主檔，發票號碼在該供應商名下不能已存在，幣別必須是你真在用的。然後是勾稽：找到採購單，逐行比對數量與價格，核對收貨紀錄。一次乾淨的比對會產生一張應付草稿，原始PDF作為附件，OCR座標一併存下，這樣任何數字都能追回到頁面上的那個位置。

現在才是那個真正值回票價的檢查。把這張發票上的銀行資訊與該供應商留檔的資訊比對。完全一致，照常進入簽核佇列。任何一處不同——帳號、開戶行、收款人名稱，哪怕只是SWIFT碼變了——就地停下，轉給一位具名的人做線下查證。不是回覆那封信，而是打電話，打給這張發票到達之前你就已留檔的那個號碼。

之後簽核照舊，這張應付款進入一個由人放行的付款批次。AI拿掉了打字和大部分勾稽工作，而它一步也沒靠近「要不要把錢發出去」這個決定。

AI發票擷取 vs 專用應付帳款軟體 vs 人工鍵入

建置成本與時間 — 人工鍵入勝出，沒有任何東西需要建。自建AI管線是數週工作量。打包的應付帳款軟體介於兩者之間，如果你的帳務系統在它已支援的名單上，通常幾天設定完成。
每張發票的運行成本 — 有量的情況下AI管線最便宜。打包軟體按單據數或使用者數收費，量一上來可能變成最大一筆支出。人工鍵入看起來免費，其實只是以薪資形式支付。
在糟糕文件上的準確率 — 打包軟體勝出，差距不小。廠商在數以百萬計的真實發票上訓練過，包括拍糊的照片。通用模型在乾淨PDF上表現可敬，在折過又斜拍的掃描件上明顯更弱。
簽核流程與稽核軌跡 — 打包軟體明顯勝出。簽核路由、代理、金額門檻和不可竄改的稽核日誌本身就是產品，而不是附加功能，把它們好好重建一遍是自建管線裡的大部分工作量。
對接冷門帳務系統 — 自建管線勝出。如果你的會計系統是區域性的、比較舊的，或被大幅客製過，打包連接器往往根本不存在。
開箱即用的反詐騙控制 — 多數情況下打包軟體勝出，但差異大到不該假設，應在選型時點名去問。「供應商銀行資訊變更告警」是要指名問的那個功能。

一個誠實的建議：每月發票量在一百張以下，先去修簽核流程，暫時別自動化擷取。超過這個量，先評估打包的應付帳款軟體，只有在打包方案確實搆不到你的帳務系統時才自建——因為你要重建的大部分是流程與稽核的機器，而不是那個聰明的部分。

沒人能自動化掉的詐騙這一面

改掉的銀行帳號就是全部的攻擊。 成熟版本的發票詐騙不是一家假公司。它是一張真實的發票，對應你真的訂過的貨物，只有一個欄位被改了。其他一切都完美對得上，這正是它能躲過每一項「檢查算術是否正確」的控制的原因。

仿冒網域與被劫持的回信串。 那封信可能來自一個與供應商只差一個字元的網域，也可能真的來自供應商自己的信箱——在其帳號被攻陷之後。後一種情況下，攻擊者是在一條真實會話裡回覆你，他那段話的上方是真實的往來歷史。

急迫感是破綻。 催你在截止日前付款、警告供貨可能中斷、為「新的銀行安排」通知得太倉促而道歉。急迫感存在的目的就是讓人跳過查證。

模型讀的是文件，不是處境。 擷取模型會準確回報頁面上印著的那個帳號。那就是你交給它的活。它對「這個帳號是不是屬於你的供應商」沒有任何判斷。

用線下方式查證，比對你原本就持有的資訊。 任何付款資訊變更都觸發一通電話，打給在變更被提出之前就已在檔的號碼，並且由處理這張發票的人以外的另一個人來打。讓它在流程裡無法被跳過，並讓所有人知道：在這一步慢下來，永遠不算做錯。

把這件事做對：付款資料治理、郵件安全，以及何時該讓IT介入

發票不是中性文件：它們帶著供應商的銀行資訊、你談下來的價格、合約編號，以及真實個人的姓名。請刻意地決定你用哪家服務商、哪個層級，並去讀真正適用於它的資料處理與訓練條款——商業版和API層級通常與消費級聊天產品不同，而且條款會變，所以請以服務商當前的文件為準。讓文件透過你自己應用裡的API走，而不是讓員工把附件貼進聊天視窗。

這條管線需要一支API金鑰、一個信箱連線，以及對會計系統的寫入權限——這個組合值得當作敏感資產對待。金鑰應放進金鑰管理服務；信箱連線應僅限於應付帳款那一個信箱；會計系統整合應拿到能建立應付草稿、且僅此而已的最小權限集。我們的AI+支援服務負責把這類管線從一開始就建成「被治理的」，而託管IT支援則在依賴它的人不只一個之後，接手身分、權限和生命週期這一側。

信箱本身現在是你付款流程的一個生產輸入，這改變了它需要什麼：網域上的驗證控制、能辨識仿冒寄件網域的過濾，以及供應商會話出現異常時的告警。這正是託管郵件安全存在的意義，也是做應付帳款自動化專案時槓桿率最高的一件事——因為它針對的是那個會讓你損失六位數的失效模式，而不是那個只浪費一個下午的。如果你關心的是員工報帳那一側而不是供應商發票，我們的姊妹篇用ChatGPT與QuickBooks/Xero自動化費用歸類講的就是那條流程。Brocent自2007年在北京創立以來一直在亞洲提供託管IT服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

AI能可靠地讀掃描件或拍照的發票嗎？

可靠到有用，但沒可靠到可以不看著。乾淨的數位PDF擷取效果很好，平整的掃描件通常也沒問題。而一張在光線不好的環境裡斜著拍的照片、一份折過的傳真件，或者列印文字上有手寫註記的文件，就是準確率下降的地方——而且是無聲地下降，因為輸出看起來照樣很篤定。

AI擷取出來的發票，可以自動付款嗎？

不可以。自動化擷取和入帳是合理的；自動化放款不是，無論信心度多高。在付款關卡保留一個人幾乎不花時間——付款本來就是批次跑的——而它正是橫在「一次擷取錯誤」與「錢真的離開帳戶」之間的那道控制。

現實中能做到多高的準確率？

去量你自己的，而不是相信某個宣傳數字，因為準確率幾乎完全取決於你的文件組成。拿幾百張真實發票跑一遍，逐欄位與人工擷取的結果比對，並按欄位而不是按單據統計錯誤——98%的欄位準確率，仍可能意味著相當比例的發票裡至少有一個欄位是錯的。把總額、銀行資訊和發票號碼分開統計。

怎麼才能抓住被改掉的銀行帳號？

為每個供應商存下留檔的付款資訊，讓每張進來的發票自動比對，並把任何差異變成一次無條件的中止。查證的方式是打電話給你原本就持有的號碼，並且由處理這張發票的人之外的另一個人來打。不要用回信的方式查證，也不要接受在提出變更的那同一封信裡給出的新號碼。

把供應商發票送給AI服務商安全嗎？

這是一個需要刻意做的決定。發票包含第三方銀行資訊和個人資料，所以請查清：你所在的那個具體層級，服務商當前條款關於保存和訓練是怎麼說的；處理所在的區域是否符合你的義務；以及你與供應商的合約就其資訊作了什麼承諾。很多組織的結論是：商業版或企業版API層級可以接受，消費級聊天產品不可以。

如果自動化了擷取，還需要採購單嗎？

需要，而且比以前更需要。三方勾稽才是讓自動處理變安全的東西，而它需要有採購單和收貨紀錄可以比對。沒有採購單，管線只能確認一張發票在算術上正確、內部一致，這與「確認你訂過這批貨、收到了它、並同意了那個價格」完全不是一回事。

從哪裡開始

在動手建任何東西之前先花一週量測：數發票、給各環節計時，弄清楚延遲裡有多少是鍵入、有多少是簽核躺在信箱裡。如果是簽核，先修那個——更便宜的專案，更大的效果。如果鍵入確實是限制，就挑一個PDF乾淨的供應商類別做試點，第一個月讓人複核每一次擷取，並在建其他任何東西之前先把銀行資訊比對做出來。如果你更希望由做過這件事的人，把管線、信箱控制和權限模型一起建起來，歡迎與我們聯絡。