先定義對帳單位，而不是先寫比對程式
發票與訂單看似都包含品名、數量和金額，但兩者的資料粒度經常不同。一張採購單可能分批交貨、由多張發票請款；一張發票也可能合併多筆訂單、運費或折讓。若系統一開始就假設單號必須一對一相等，正常交易也會被大量標記為異常。
工程團隊應先和採購、財務及倉儲確認真正的核對依據。常見做法是以訂單、訂單明細、收貨紀錄及發票明細組成多層次比對：先確認供應商與幣別，再尋找可對應的單號或合約，最後檢查品項、數量、單價、稅額與總額。服務費、訂閱費或里程碑請款則可能沒有收貨紀錄，需要改用驗收或付款條件作為第三份證據。
資料正規化是規則可靠度的前提。供應商代碼、全半形字元、日期格式、幣別、小數位、稅別與料號別名，都應在比對前轉成一致表示。原始值仍須保留，因為財務人員覆核時必須看到文件實際內容，而不是只看到清洗後的結果。
把規則分成硬性條件、容差與風險訊號
不是每個欄位都適合用完全相等判斷。供應商身分、公司統編、幣別與訂單狀態通常屬於硬性條件；金額、小數尾差、交貨日期和文字描述則可能需要容差。規則應明確寫出適用範圍、優先順序及失敗後的處理方式，避免把判斷散落在程式碼、試算表和人員經驗中。
- 識別規則：驗證供應商、買方、訂單號、發票號與幣別；缺少關鍵識別資訊時，不應依金額相近就自動配對。
- 數量規則：以訂購、已收貨、已請款及已退貨數量交叉檢查，並考慮分批交貨與單位換算。
- 金額規則：分開核對未稅金額、稅額、運費、折扣與含稅總額，不要只比較最終合計。
- 狀態規則：已取消、已關閉、付款凍結或尚未驗收的訂單，即使金額吻合也不應直接放行。
- 重複規則：同一供應商、發票號、日期與金額的組合需要檢查，但也要處理供應商重複使用編號或更正發票的合法情況。
容差必須有業務理由，而不是為了提高自動通過率。例如，小數計算或稅額捨入可以使用固定金額容差；依訂單金額比例放寬則可能讓高額差異被掩蓋。較穩健的方式是同時設定固定上限與相對條件，並依幣別、供應商類型、品項或採購政策套用。任何容差內放行都應留下實際差額和命中的規則版本。
人工例外應是產品流程，不是錯誤收件匣
自動化系統一定會產生例外；真正影響效率的是例外是否能被快速理解與處理。一筆任務應直接顯示原始文件、擷取欄位、候選訂單、差異項目及系統判斷理由。只顯示「比對失敗」會迫使財務人員重新查詢 ERP、郵件和共享資料夾，等於把整合成本轉嫁給使用者。
例外類型最好對應明確動作：缺少訂單號可要求供應商補件；尚未收貨可暫停並等待倉儲紀錄；價格超出容差可交由採購確認；疑似重複請款則應凍結付款並檢視歷史發票。人工處理結果不宜只有通過或拒絕，還應記錄原因碼、備註、附件、操作者及時間。若允許覆寫規則，系統必須區分單次核准與永久政策變更。
可修正的資料品質問題也應建立回饋路徑。若多筆例外都源自相同料號別名或特定供應商格式，可以更新映射或擷取模板；但不能直接把每次人工放行學成新規則。先由流程負責人檢視其風險與適用範圍，再透過版本化設定發布，才能避免錯誤經驗被自動放大。
以可追溯、可重跑的架構逐步上線
實作上可將流程拆成文件接收、欄位擷取、資料正規化、候選配對、規則判斷、例外工作流與回寫 ERP 或會計系統。每一階段都應保存輸入、輸出、時間與版本，並使用穩定的交易識別碼串連。這樣即使 OCR、主資料或規則稍後更新，也能針對指定範圍安全重跑，而不會重複建立憑證或付款。
上線初期適合採取影子比對：系統先產生判斷，但不直接改變付款狀態，由財務人員比較結果。確認規則涵蓋常見交易後，再逐步開放低風險情境自動放行。驗證時不要只看整體命中率，還要抽查自動通過是否正確、例外原因是否可理解、重跑是否具冪等性，以及 ERP 回寫失敗能否復原。
最後，規則需要明確的擁有者與變更流程。採購政策、稅務處理、供應商格式及 ERP 欄位都會改變；沒有版本、測試案例和稽核紀錄的自動化，很快就會成為新的人工負擔。若流程跨越 OCR、LINE 或電子郵件收件、ERP、CRM 與雲端服務，整合團隊的價值在於把這些邊界做成可監控、可復原的完整交易流程。