EWA 中的 Settlement 與 Reconciliation 有何不同？

Settlement 與 Reconciliation 是兩個相互關聯但目的不同的層級。在 EWA 架構中，Settlement 完成並記錄一筆交易或一個結算週期的財務結果；Reconciliation 則比較獨立資料來源，以確認工時紀錄、銀行交易與薪資系統是否記錄了相同結果。

首先：兩者都與資金有關，但回答的問題不同

這兩個術語常被混用，因為它們都出現在交易建立之後。

不過，兩者可以清楚區分：

• Settlement：「這項財務義務最終如何完成並記錄？」
• Reconciliation：「各個獨立系統是否記錄了相同結果？」

如果把兩者合併，系統可能會因結果已入帳就假定其正確，即使尚未完成獨立核對。

本文中的 Settlement 應如何理解？

銀行、支付閘道與薪資系統對「settlement」的用法可能不同。

本文中，Settlement 指確定一筆交易或一個營運週期最終財務結果的步驟。

以一筆 EWA 交易為例：

• 建立申請；
• 銀行確認結果；
• 系統確定實際支付金額；
• 交易帳本記錄已收到金額；
• 更新剩餘薪資。

在薪資週期層級，Settlement 還包括：

• 彙總已確認的 EWA 付款；
• 將正確總額記入薪資系統；
• 確定本週期剩餘應付金額；
• 關閉已完成的義務。

因此，Settlement 的重點是完成財務義務。

Reconciliation 應如何理解？

Reconciliation 是比較兩個或多個獨立資料來源並判斷其是否一致的流程。

例如：

• EWA 帳本記錄支付 500,000 越南盾；
• 銀行對帳單應有對應交易；
• 週期末薪資應反映已領取金額；
• 薪資單不得重複扣除。

如果各資料來源一致，該交易或週期即視為已核對。

如果不一致，差異必須進入例外佇列。

Reconciliation 不建立交易，也不應只為了讓報表一致而修改數字。

Settlement 與 Reconciliation 比較表

標準	Settlement	Reconciliation
核心問題	財務義務如何完成？	各帳本是否一致？
時間	交易生命週期中或之後，或週期末	多個資料來源均可用之後
主要資料	交易狀態、金額、週期	EWA 帳本、銀行、薪資
結果	已付、已結算、剩餘金額	相符或例外
是否建立交易？	可能參與完成交易	否
是否找出差異？	可能，但不是主要目的	是，這是主要目的
是否關閉週期？	可協助關閉義務	關閉前確認資料
情況不明時	保留適當狀態	轉入例外調查

兩個層級必須連接，但不能互相取代。

一筆交易如何經過 Settlement？

典型流程可能是：

1. 申請符合條件；
2. Payment Orchestration 建立交易；
3. 銀行處理交易；
4. 確定最終狀態；
5. 成功交易記入「已領取」帳本；
6. 相關金額被鎖定，不能重複使用；
7. 該交易義務視為完成。

如果銀行狀態不確定，Settlement 不應自行推斷結果。

此時應採用失敗關閉原則：結果不明確時，不要將其關閉為成功或失敗。

一筆交易如何經過 Reconciliation？

當獨立資料可用後，系統比較：

1. 內部交易 ID；
2. 銀行代碼或參考編號；
3. 金額；
4. 收款人；
5. 時間；
6. 狀態；
7. 薪資週期；
8. 記入薪資系統的金額。

如果全部一致，可將交易標記為核對成功。

如果有一個欄位不同，系統就建立例外。

關鍵在於，Reconciliation 使用獨立來源驗證系統記錄的結果。

為什麼 API 回應不足以視為已對帳？

銀行 API 在處理過程中可能回傳「成功」。

這是重要訊號，但金融系統之後仍應進行獨立核對。

原因包括：

• 即時回應可能遺失或出錯；
• 內部系統可能記錄錯誤狀態；
• 一筆交易可能被記錄兩次；
• 銀行對帳單可能有內部缺少的交易；
• 薪資系統可能使用錯誤週期。

Reconciliation 提供最終驗證。

週期末 Settlement 與單筆交易 Settlement 有何不同？

Settlement 可以有兩個層級。

交易層級

確定某筆付款是否完成、金額是多少，並將其記錄於交易帳本。

薪資週期層級

彙總週期內所有交易，並確定：

• 已領取總額；
• 退款或調整；
• 應反映在薪資系統中的金額；
• 剩餘薪資。

兩個層級都需要可追溯的資料。

為什麼不應「透過改數字讓對帳一致」？

當兩個帳本不一致時，操作人員手動修改其中一邊使總額相等，是一項危險錯誤。

這會破壞有關原因的證據。

正確流程是：

1. 保留來源資料；
2. 建立例外；
3. 查明原因；
4. 確定哪個帳本有誤；
5. 進行可追溯的業務調整；
6. 取得核准；
7. 再次核對。

每項調整都必須留下稽核軌跡。

Settlement 與 Reconciliation 之間的常見例外

系統記錄成功，但銀行對帳單沒有記錄

調查該交易與銀行證據。

對帳單顯示資金已轉出，但系統仍為 pending

API 回應可能遺失。不要重新提交付款指令。

交易成功，但薪資系統未反映

週期末可能再次支付已領取金額。

薪資已扣除，但交易失敗

員工可能在未收到資金的情況下被減少薪資。

交易歸入錯誤週期

檢查截止規則及相關薪資週期。

存在重複交易

保留兩筆記錄，查明原因，並依正確流程處理。

誰應負責這兩個層級？

它們不一定由同一個團隊負責。

職責可劃分如下：

• 支付營運：監控交易層級的 Settlement；
• 會計/對帳：與銀行核對；
• 薪資：週期末 Settlement 與核對；
• 工程：確保狀態處理、冪等性與日誌；
• 產品營運：協調例外處理。

出現差異時，責任歸屬必須明確。

連接兩個層級需要哪些資料？

至少應保留：

• 交易 ID；
• 員工 ID；
• 收款帳戶；
• 金額；
• 時間；
• 客戶；
• 薪資週期；
• 交易狀態；
• 銀行參考編號；
• 記入薪資系統的金額。

Reconciliation 不應主要依賴姓名或自由格式的轉帳說明。

何時可以認為一個週期已經「關閉」？

不能只因為已執行薪資計算就關閉週期。

關閉前，雇主應確認：

• 工時記錄已有最終狀態；
• 成功交易已經彙總；
• pending 交易已有處理方案；
• 銀行帳本與內部帳本已經核對；
• 薪資系統反映正確金額；
• 尚存例外已有負責人；
• 已保存橋接報告。

並非所有例外都必須立即消失，但每個未結例外都必須被識別並受控。

Settlement 與 Reconciliation 應分別追蹤的 KPI

Settlement

• 確定最終狀態所需時間；
• pending 交易數量；
• 需要人工介入的交易比例；
• 重試交易數量；
• 重複交易數量。

Reconciliation

• 自動匹配率；
• 例外數量；
• 例外帳齡；
• 銀行差異數量；
• 薪資差異數量；
• 完成核對所需時間。

如果將這些指標合併為一個 KPI，雇主就難以判斷問題來自交易處理或帳本比較。

結論

Settlement 與 Reconciliation 是同一控制鏈中的不同環節。Settlement 完成並記錄財務義務；Reconciliation 使用獨立資料來源證明結果一致。 將兩個層級分開，有助於管理 pending 交易、差異、截止時間與薪資，同時保留從交易到薪資單的完整可追溯性。

作者： Do Huy Le — Tổng Giám Đốc，Nhan Kiet Manpower Supply Co., Ltd.

僱主隨領薪資服務諮詢： 熱線 0937.022.655 · 電郵 info@nhankiet.vn · 僱主隨領薪資服務