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 · 面向雇主的随用随付工资服务