先分清楚三種成功
EDI 交換不能只用一次 HTTP 200、SFTP 上傳成功或 AS2 MDN 判斷完成。工程上至少要區分三個層次：傳輸成功表示資料已抵達對方端點；格式與功能回執表示交換信封、欄位及標準規則可被解析，例如 X12 997、999 或 EDIFACT CONTRL；業務確認才代表訂單、出貨通知或發票已被 ERP 接受。三者可能相隔數分鐘甚至更久，也可能出現傳輸成功但業務拒絕的情況。
因此，每筆交換應有明確狀態機，而不是單一的成功旗標。常見狀態包括已建立、待傳送、已傳送、已收到傳輸回執、待功能回執、已接受、已拒絕、待重試及待人工處理。狀態只能依可驗證事件前進，並記錄事件來源、時間、原因碼與原始回執。這能避免操作人員看到已傳送就誤以為訂單已完成，也讓逾時告警針對真正缺少的回覆發生。
以冪等與可追蹤性建立交換骨架
跨公司網路無法保證真正的恰好一次。發送端可能在對方已收件後才遇到逾時，接收端也可能完成入帳卻來不及回覆。較務實的模型是至少一次傳送，加上冪等處理。每筆資料需要穩定的業務識別，以及每次交換所使用的技術識別；兩者不可混為一談。
- 業務識別：採購單號、發票號碼、供應商與公司代碼，用來辨識同一筆業務文件。
- 交換識別：interchange、group、message control number 與交易夥伴代碼，用來追蹤特定傳輸。
- 內容指紋：對正規化後的 payload 計算雜湊，協助辨識完全重複或同號異內容。
- 事件紀錄：保存每次嘗試、通道回應、回執、解析結果、狀態轉換與操作者。
接收端應以業務鍵或雙方約定的冪等鍵阻止重複入帳，但不能默默忽略同號異內容。完全相同的重送可以回傳先前結果；識別相同而內容不同時，應隔離並要求人工判斷。重送是否沿用原控制號或產生新信封編號，取決於交易夥伴規格；無論採哪一種方式，都要保留原始業務文件與所有傳輸嘗試之間的關聯。
重送策略要依錯誤類型決定
不是所有失敗都適合自動重送。DNS、暫時性連線中斷、對方端點限流或服務短暫不可用，通常屬於可重試錯誤；憑證失效、帳號被停用、格式錯誤、必填欄位缺漏及未知交易夥伴，重送相同內容通常只會製造更多噪音。解析器應將錯誤分類成暫時性、永久性與不確定，並讓各分類進入不同流程。
- 暫時性錯誤：採指數退避、隨機抖動、嘗試上限與整體時間上限，避免集中重送衝擊對方。
- 永久性錯誤：停止自動重試，附上可行動的原因與文件位置，送入修正佇列。
- 回執逾時：先視為結果未知；查詢對方狀態或以原業務識別安全重送，不能直接當作未收件。
- 大規模故障：使用斷路器、併發限制與優先佇列，避免舊訊息淹沒新交易。
重試排程必須持久化，不能只存在應用程式記憶體。每次嘗試都要保留預定時間、實際時間、錯誤分類與回應摘要。進入人工佇列後，操作介面應提供重新傳送、標記已解決或改送修正版等受控動作；人工重送同樣要走冪等檢查與稽核紀錄，不能成為繞過防重機制的捷徑。
對帳要比較技術台帳與業務台帳
回執只能證明某個交換階段完成，不能證明雙方帳務一致。可靠的對帳應同時維護技術交換台帳與業務文件台帳：前者記錄檔案、控制號、傳輸與回執；後者記錄訂單、出貨、收貨、發票及 ERP 狀態。對帳工作以穩定識別將兩者連結，並依交易夥伴、文件類型、營業日與約定等待時間產生差異清單。
- 遺失：發送端有文件，但接收端或回執台帳沒有對應紀錄。
- 重複：同一業務文件被多次接受、入帳或產生後續單據。
- 內容不一致：單號相同，但版本、數量、金額、幣別或狀態不同。
- 懸而未決：技術傳輸成功，卻在約定時間內沒有功能或業務結果。
批次對帳要明確處理時區、跨日檔案、延遲抵達、取消與修正版，否則每天都會產生假異常。關鍵交易可在日內持續掃描，完整帳務則於營業日結束後再核對。差異只有在取得回執、對方查詢結果、ERP 紀錄或經授權的人工證據後才能關閉。原始 payload 與回執應加密、限制存取並依保存政策留存；監控則聚焦於各狀態停留時間、重試積壓、拒絕原因與未結案差異，讓團隊能從單筆追查到整體通道健康度。