先把「重複」拆成不同情境
同一張發票可能經由電子郵件、供應商入口與人工上傳重複進入系統，也可能因為 OCR 修正、附件補件或流程重送而產生多個版本。若只用檔名或檔案雜湊判斷，重新掃描的同一張發票可能無法被識別；若只用供應商、發票號碼與金額判斷，又可能誤擋合法的分批請款或供應商重複使用單號。因此，工程上應先區分「完全相同的技術重送」、「相同業務文件的不同版本」以及「欄位相似但可能合法的另一筆交易」。
入口層應建立冪等鍵，避免網路逾時、Webhook 重試或使用者連點造成同一請求被處理兩次。業務層則可使用供應商統一編號、發票號碼、發票日期、幣別、未稅金額與稅額組成比對指紋，再以採購單號、品項及附件雜湊補強可信度。不要把相似度直接等同於結論；高可信度的完全重複可以自動攔截，其餘情況應標記為疑似重複，交由人員比較版本。
- 技術重送：沿用第一次處理結果，不再次建立請款或觸發 ERP 過帳。
- 文件新版：保留版本鏈與原始附件，明確指出哪些欄位發生變更。
- 疑似重複：暫停付款相關動作，但允許審核者查看兩筆資料的差異。
- 合法重複特徵：分批交貨、定期費用、折讓或更正發票，必須有獨立的判定路徑。
用狀態機保護跨系統流程
請款通常會穿越文件辨識、採購系統、驗收資料、簽核平台、ERP 與付款排程。任何一段逾時，都可能讓呼叫端誤以為失敗並再次送件。可靠的設計不應依賴「這個 API 通常只會被呼叫一次」，而要假設訊息可能重複、延遲或順序錯置。每筆請款需要穩定的內部識別碼，以及已接收、待比對、待補件、待人工審核、核准、已過帳、作廢等明確狀態。
對 ERP 建立傳票或應付帳款時，應傳入可供查詢的外部參考碼。若回應逾時，系統要先依參考碼查詢 ERP，再決定是否重試，而不是直接新增第二筆。資料庫寫入、事件發布與下游通知也要有一致性策略，例如交易式 outbox、唯一鍵與消費端冪等處理。這些機制看似偏底層，卻直接決定財務人員是否會面對難以解釋的重複帳務。
金額差異不能只靠一條容許值
金額不同不一定代表錯誤。常見原因包括稅額四捨五入、運費另列、匯率換算、部分交貨、數量短缺、單價更新、折扣、預付款沖抵或供應商開立折讓。系統應進行採購單、收貨或驗收紀錄、發票的三方比對，並分別比較數量、單價、稅額、附加費、幣別與總額。只比較發票總額與採購單總額，會掩蓋品項層級的錯配，也會把合理的部分請款當成異常。
容許政策最好同時考慮絕對金額、相對差異與差異原因，而且依費用類型、幣別、供應商契約或採購類別配置。小額四捨五入可自動通過；價格或數量差異可能需要採購或驗收人員確認；幣別不符、採購單已關閉或累計請款超過可請金額，通常應直接停止流程。容許值必須由財務與採購共同定義，工程團隊負責讓規則可配置、可測試、可追溯，而不是把數字寫死在程式裡。
- 自動通過：差異符合明確政策，且不影響累計數量與合約上限。
- 要求補件：缺少驗收、運費依據、匯率日期或更正後的發票。
- 指定覆核：依差異類型派給採購、倉管、專案負責人或財務。
- 禁止過帳：疑似重複、關鍵欄位衝突，或已超出可請款餘額。
例外流程必須讓人快速做決定
自動化不是把所有異常丟進同一個待辦清單。審核畫面應並列採購單、驗收紀錄、發票影像、已請款累計值與本次差異，並以欄位層級顯示來源。系統還應區分 OCR 信心不足與真正的業務差異：前者需要確認文件辨識，後者需要判斷商務事實。若兩者混在一起，財務人員會花時間重新檢查大量正確資料。
人工決定應使用結構化原因，例如接受四捨五入、等待補驗收、確認分批請款、改用更正發票或拒絕重複送件，並允許附註及附件。不要只提供「核准」與「退回」兩個按鈕。結構化結果可以用來改善規則，也能在稽核時說明為何某筆差異被放行。對例外案件設定負責角色、處理期限與升級路徑，則可避免文件停在系統中卻無人處理。
上線前驗證累計、併發與稽核能力
測試案例除了正常請款，還應涵蓋同一附件重傳、不同掃描版本、同號碼不同供應商、部分請款、多張發票對一張採購單、折讓、取消後重送，以及兩個流程同時消耗最後可請款餘額。最後一種情境需要資料庫鎖定、原子條件更新或等效的併發控制；否則每個流程單獨檢查都可能通過，合計卻超出採購或驗收金額。
正式運作後，應能從任一 ERP 傳票回查原始文件、比對結果、規則版本、人工決定及所有重試紀錄。定期對帳也不可省略：系統要找出已核准但未過帳、ERP 已建立但內部狀態未更新，以及長時間停留在例外狀態的案件。好的採購自動化不追求消滅所有人工判斷，而是讓安全的案件穩定直通，讓真正需要判斷的差異帶著完整證據抵達正確的人員。若流程橫跨多套既有系統，整合團隊的價值就在於把這些控制點落實為一致、可維護的端到端設計。