日薪预支流程：从考勤到收款与对账

日薪预支流程始于工作时间被记录且由主管审批。系统同步数据、计算已发生薪资中符合条件的部分、让员工提交申请、执行支付，再对账进入薪资周期。每笔交易都需要标识、状态与完整日志，以避免超付、重复付款、薪资计算错误，或在工时被调整时难以处理。

日薪预支是 Nhan Kiet 对其 Earned Wage Access（EWA） 解决方案的称呼，帮助员工在定期发薪日之前，支取与已完成工作相应的一部分薪资。这并非在每个工作日后支付全部薪资的方式；企业的计算周期与发薪周期仍按适用政策保持不变（更多区分见 传统薪资预支与 EWA 有何不同？）。

日薪预支流程总体示意

核心运营生命周期包含七个步骤：

1. 记录工时。

2. 主管确认工时。

3. 同步数据。

4. 计算符合条件的已发生薪资。

5. 员工提交收款申请。

6. 验证并支付。

7. 对账进入薪资周期。

若把加入阶段也计入，完整流程可描述如下：

注册/eKYC → 确认条款或电子签名 → 考勤 → 审批工时 → 计算额度 → 收款申请 → 支付 → 对账 → 薪资单。

这两层流程并不矛盾。七个步骤是每个周期重复的运营生命周期；注册与条款确认则是员工进行首笔交易前的准备步骤。

步骤0. 注册、验证与设定使用权

在使用日薪预支之前，员工档案需要与企业数据正确匹配。至少必须确定：

• 唯一的员工编号。

• 当前所在的企业或部门。

• 仍然有效的劳动关系状态。

• 已验证的电话号码或登录账号。

• 属于正确受益人的收款账户，或按已审批政策处理的账户。

• 员工已确认的条款版本。

• 启用时点与使用范围。

若存在 eKYC 或电子签名，企业需明确规定收集哪些数据、使用目的、保存期限，以及验证失败时的处理方式。《电子交易法》第20/2023/QH15号是设计交易与电子确认时法务部门应审查的依据之一。

应有的管控

• 不启用未与员工编号正确匹配的档案。

• 若离职或临时锁定状态已生效，则不允许交易。

• 变更收款账户时进行附加验证。

• 保存条款版本与同意的证据。

• 在适当情况下，将身份数据与仅用于额度运营的数据分离。

步骤1. 记录工作时间

日薪预支的第一项数据不是收款申请，而是工作时间。数据可能来自考勤机、应用、客户的工时表、HRM 系统或企业认可的其他来源。

一条工时记录通常需要以下字段：

一次打卡只证明系统收到了数据。它并不自动证明该班次符合薪资计算条件。

步骤2. 主管确认工时

这是决定额度可靠性的步骤。有权限者在把工时转为已审批状态之前，检查班次、加班、休假与例外。

为什么只应使用已审批的工时？

未审批的工时可能因以下原因发生变化：

• 漏打上班或下班卡。

• 打错班次或地点。

• 尚未确认的加班。

• 尚未更新的休假申请。

• 数据重复或员工编号录入错误。

• 客户尚未确认实际工作小时数。

若系统按待审批工时计算额度，钱可能在发现偏差之前就已支付。事后追回通常比从一开始就阻止错误交易更难。

工时审批人的责任

• 审批正确的人、正确的日期、正确的班次与正确的工时类型。

• 在规定期限内处理异常工时。

• 调整或驳回时记录原因。

• 不共享账户或进行无管控的授权。

• 在额度同步截止前完成工时。

企业应设有工时审批 SLA，以及显示未审批人数、异常记录数与积压时间的仪表盘。

步骤3. 同步与检查数据

工时审批后，数据被传送到额度计算系统。同步可采用准实时 API、按计划的批处理文件，或在试点阶段的受控操作。

系统不应只检查"是否有数据"，还应检查其质量：

• 员工编号是否存在且仍然有效？

• 薪资周期是否正确？

• 工时是否已审批且未被锁定/撤回？

• 作为依据的薪资水平或单价是否已生效？

• 同一部分工时上是否已产生某笔交易？

• 公式中是否有需要纳入的预备金或调整？

• 收款账户是否已验证？

数据缺失时的原则

不应擅自推测单价、班次类型或工时状态。若某个必填数据字段缺失或矛盾，档案应转为不符合条件状态并附具体原因，供 HR、主管或员工处理。

步骤4. 计算符合条件的已发生薪资

额度不应等于全部暂计薪资。系统需要为期末可能发生的调整保留一部分安全额。

示意公式

一般公式可表示如下：

仍可收取的额度 =（有效的已发生薪资 × 安全比例）− 已收金额 − 预备金/调整

其中：

• 有效的已发生薪资： 按企业规则从已审批工时计算出的收入。

• 安全比例： 企业允许支取的比例，默认不等于100%。

• 已收金额： 该周期内成功交易的总额。

• 预备金/调整： 为可能影响实收薪资的义务与有效变动而保留的部分。

示例

假设在计算时点：

• 从已审批工时发生的薪资：4,000,000 越南盾。

• 假定的安全比例：70%。

• 员工已提前收取：1,500,000 越南盾。

• 额外预备金：300,000 越南盾。

那么：

剩余额度 =（4,000,000 × 70%）− 1,500,000 − 300,000 = 1,000,000 越南盾。

以上所有数字仅示意公式的运作方式，并非日薪预支的政策。真实比例须基于各企业的薪资结构、工时的稳定性、扣款以及处理偏差的能力。

可能使额度为0的情形

• 尚无已审批的工时。

• 档案或收款账户尚未有效。

• 员工已收完符合条件的部分。

• 工时正在争议或等待调整。

• 薪资周期已锁定。

• 劳动状态被暂停或终止。

• 项目总额度或资金临时达到上限。

界面应说明原因，而不只是显示"无法交易"。

步骤5. 员工提交收款申请

有额度时，员工选择想要收取的金额。在确认之前，系统应显示：

• 当前额度。

• 申请金额。

• 若有，服务费与转账费。

• 实收金额。

• 该周期内已收总额。

• 交易后预计的剩余薪资。

• 已部分遮盖信息的受益账户。

• 预计处理时间。

• 重要条款与支持渠道。

记录申请前的即时检查

应重新计算或再次确认额度，以避免员工在某个时点打开界面，但在按下确认前工时或交易数据已发生变化的情形。

每笔申请都必须具有唯一交易码。若员工多次点击，或应用因断网而重新发送，系统仍只能创建一笔有效交易。

步骤6. 验证、管控与支付

在发出支付指令之前，系统需要做最后检查：

• 身份与登录会话有效。

• 受益账户未在临近时刻异常变更。

• 额度仍然充足。

• 员工仍处于可使用状态。

• 该交易从未被处理过。

• 资金与项目总上限仍然满足。

• 无欺诈告警或暂停指令。

建议的交易状态

一个危险的错误是看到支付状态缓慢，就自动重新发送新指令。正确做法是在决定如何继续处理之前，用标识查询原交易。

步骤7. 对账进入薪资周期

对账是证明系统已完成交易生命周期的步骤。提前收取的总额不可能置于薪资计算表、薪资单与会计账簿之外。

企业应执行三层：

1. 交易对账

将应用上的申请与银行或支付渠道的实际结果进行比较：

• 交易码。

• 收款人。

• 申请金额与实收金额。

• 费用。

• 时间。

• 最终状态。

2. 薪资对账

将该周期内收取的总额与每位员工的薪资计算数据进行比较。薪资单需清楚呈现已发生薪资、提前收取额、（若属于在薪资单上体现的机制）费用，以及仍需支付的薪资。

3. 会计与资金对账

将应用数据与对账单、会计分录，以及企业与运营方/资金提供方之间的结算义务进行比较。必须能够区分员工收到的钱、服务费、支付费与各项退款。

关账原则

• 仍有最终状态未确定的交易时，不关闭周期。

• 任何差异都必须有原因、处理人与证据。

• 关账后的调整必须经过审批。

• 汇总报告必须与每位员工、每笔交易的明细一致。

所需最小输入数据

原则是只使用为既定目的所必需的数据、按角色正确分配权限并留存完整痕迹。自2026年1月1日起生效的《个人数据保护法》第91/2025/QH15号，是应对整个数据生命周期进行审查的现行依据。

各方的角色与责任

企业应为常规与例外情形制定具体的 RACI。若发生事故却无法确定谁有权决定暂停、修改或退款，该流程尚不具备上线（go-live）条件。

支付前的强制管控

只有当一笔交易通过全部管控关卡时，才应被发出：

1. 员工仍然有效且符合条件。

2. 工时已由有权限者审批。

3. 该周期内的收入数据有效。

4. 在交易时点重新计算额度。

5. 申请总额不超过额度与项目上限。

6. 收款账户已验证。

7. 交易不重复。

8. 无欺诈告警或暂停状态。

9. 资金仍然可用。

10. 员工已看到费用并确认实收金额。

处理例外情形

收款后工时被修改

系统需要重新计算符合条件的部分，必要时停止新交易，并将差异转入已审批的处理流程。在员工尚未被通知时，不应自动创建流程之外的义务。

员工在周期中离职

一旦离职状态生效，创建新交易的权限必须被锁定。HR、薪资与会计按适用档案确定已审批工时、已收金额、剩余薪资与结算方案。

银行账户错误或刚变更

未支付的交易须暂停；变更账户需要附加验证。若已错误支付，立即转入查询与事故流程，不得为使报告"匹配"而手动修改状态。

失败的交易

只有在获得可信的最终结果后才恢复额度。失败交易的费用政策必须事先公布，并在应用、对账与会计上保持一致更新。

疑似重复的交易

在创建新指令前，用原交易码查询。所有创建交易的 API 都需要防止重复处理的机制。

考勤或薪资系统中断

当数据在允许期限内不再更新时，额度需要临时锁定或切换为人工管控机制。不应在没有审批的情况下继续基于旧数据支付。

SLA 与审计日志应包含什么？

运营 SLA

企业需要就以下事项约定期限：

• 工时审批。

• 数据同步。

• 处理收款申请。

• 返回交易结果。

• 查询状态不明的交易。

• 修正工时错误并重新计算额度。

• 处理投诉。

• 退款或调整费用。

SLA 需要区分系统处理时间与依赖银行、客户或人工审批的时间。

审计日志

日志需要能够回答：

• 谁或哪个系统执行了操作？

• 操作发生在何时？

• 变更前后的数据是什么？

• 应用了哪条规则或哪个公式版本？

• 谁审批了例外？

• 对应哪条支付指令？

• 交易在哪个周期被对账？

不应允许运营人员在不留痕迹的情况下直接修改交易历史。

企业连接流程前的检查清单

• [ ] 在 HR、考勤、薪资与 EWA 之间有统一的员工编号。

• [ ] 仅使用已审批工时计算额度。

• [ ] 有工时审批期限以及主管缺席时的替代人。

• [ ] 额度公式已获薪资、财务与法务审批。

• [ ] 有预备金，而非允许支取全部暂计薪资。

• [ ] 收款账户已验证并在变更时受控。

• [ ] 每笔交易有唯一码与防重复处理机制。

• [ ] 具备完整的失败、查询、退回与对账状态。

• [ ] 已测试一遍直至薪资单、会计与对账单。

• [ ] 有近实时锁定离职员工的流程。

• [ ] 有考勤、薪资或支付中断时的预案。

• [ ] 员工能清楚看到费用与预计剩余薪资。

• [ ] 有支持对接人与投诉处理 SLA。

• [ ] 个人数据经权限管控、受保护并进行生命周期管理。

• [ ] 在扩展前已运行试点并完成至少一个薪资周期。

结论

日薪预支的核心价值不只是转账速度。一个可靠的系统必须能够证明整条链条：

对的人 → 对的已审批工时 → 对的额度 → 对的账户 → 恰好一次 → 对的状态 → 对的薪资周期 → 对的对账账簿。

若有一步无法追溯，企业尚不能确定该交易是否正确。因此，试点需要经过至少一个完整的薪资周期，充分处理例外，并在扩展前关闭所有重大偏差（另见 实施 EWA 的风险）。

希望评估数据与实施准备度的企业，可在 面向企业的日薪预支 申请从考勤到对账的日薪预支流程演示。

> 注意： 本文提供一般性信息，不能替代针对具体企业的法律、财务、会计、安全或系统设计咨询。

参考来源

• 劳动法 第45/2019/QH14号

• 电子交易法 第20/2023/QH15号

• 个人数据保护法 第91/2025/QH15号

• 关于非现金支付的第52/2024/NĐ-CP号法令

• 银行评论：已产生薪资取得服务的法律性质与越南法律调整建议

---

作者： Nguyen Minh Khang — 战略部专员，Nhan Kiet Manpower Supply Co., Ltd.

面向企业的日薪预支解决方案咨询： 热线 0937.022.655 · 邮箱 info@nhankiet.vn · 面向企业的日薪预支