面向劳务供应与劳务派遣企业的日薪预支：如何管理员工在多家客户的考勤？

要在劳务供应或劳务派遣企业中落地 日薪预支，每一名员工都必须与用工法人主体、客户、地点、合同/任务、薪资周期以及已审批考勤数据精确关联。企业需要明确：哪家客户记录考勤、谁有权审批、考勤在何时满足生成额度的条件，以及由哪一方处理付款、薪资核算与对账。当员工发生调动或结束任务时，日薪预支权限必须按生效日期随之变更，而不是等到月末。

> 注意： “劳务供应”“人力服务”“外包”与“劳务派遣”并不当然是同一种法律关系。责任范围、用工主体与工资支付机制必须依据合同和适用法律来确定。本文只是通用的业务—技术框架，不能替代针对具体模式的法律咨询。

> 术语说明： EWA（按已工作天数领取工资）· payroll（薪资核算）· assignment（在客户处的任务/派工）· SLA（服务水平承诺）· HRIS（人力资源信息系统）· ERP（企业资源计划）· cutoff（周期结算时点）· pilot（试点部署）· UAT（验收测试）· KPI（衡量指标）。

为什么多客户模式比单一工厂更复杂？

在普通的生产企业中，员工、考勤机、审批考勤的管理者与薪资核算通常属于同一个组织体系。而在劳务供应或劳务派遣企业中，员工可能：

• 与某一法人主体建立劳动关系，却在客户的地点工作；

• 由客户排班并确认出勤；

• 由劳务供应企业汇总考勤、核算工资并发放工资；

• 在同一周期内于不同客户或地点之间调动；

• 拥有多项津贴、加班或各不相同的确认规则；

• 在客户处结束任务，但尚未终止劳动关系；

• 或在两个不同的时间点分别结束任务与劳动关系。

只有当系统理解上述全部情境时，日薪预支才能算准。员工编码正确，但绑定了错误的客户、错误的任务或错误的周期，仍可能生成错误的额度。

1. 在集成之前先厘清各业务模式

人力供应/招聘

服务企业可以推荐或提供候选人来源，由客户直接与其订立并管理劳动关系。在这种情形下，对工资和日薪预支承担责任的主体，可能并不是提供候选人的供应单位。

劳务派遣

这是一项有条件的经营活动，受劳动法律的规范。需要正确界定劳务派遣企业、接受派遣方、被派遣劳动者、工作范围、合同以及各方的责任。

使用劳动力的服务外包

客户购买的是某项成果或服务，由供应单位组织实施。管理、考勤与工资发放的方式取决于服务合同与实际劳动关系。

为什么这种分类对日薪预支很重要？

它决定了：

• 谁是用人单位；

• 谁确定并支付工资；

• 谁掌握可信的考勤数据；

• 谁拥有审批权限；

• 谁提供资金来源；

• 交易与谁进行结算；

• 按实际角色谁是数据控制者或处理者；

• 谁处理投诉与纠纷。

不应仅因为都存在“员工在客户处工作”这一点，就对所有合同套用同一套日薪预支流程。

2. 多方数据架构

（数据与集成要求：参见 日薪预支与考勤、薪资核算及 ERP 的集成。）

flowchart TD
    A["人力企业 HRIS"] --> E["标准化数据层"]
    B["客户处的排班与考勤"] --> E
    C["主管的确认"] --> E
    D["薪资核算与合同"] --> E
    E --> F["日薪预支额度引擎"]
    F --> G["付款"]
    G --> H["薪资核算、ERP 与客户对账"]

每个数据域单一权威来源的原则

3. “人员—任务—客户—薪资周期”数据模型

仅有 employee_id 是不够的。同一个人在同一周期内可能有多次派工。

关键键

• employee_id：员工编码；

• employerid 或 legalentity_id：订立劳动关系的法人主体；

• client_id：客户；

• site_id：工作地点；

• assignment_id：具体的任务/派工；

• contract_id：服务合同或必要的参考编号；

• payroll_group：薪资规则/周期组；

• payperiodid：薪资周期；

• effectivefrom、effectiveto：生效日期；

• transaction_id：日薪预支交易；

• payment_reference：付款参考号。

为什么 `assignment_id` 很重要？

如果一名员工在客户 A 处工作 10 天、在客户 B 处工作 12 天，系统就必须知道每一条考勤记录属于哪次任务、由谁审批、适用哪套规则。不应仅在员工档案上保留当前客户，然后覆盖历史记录。

派工数据样例

{
  "employee_id": "EMP-000123",
  "employer_id": "NK-DEMO",
  "client_id": "CLIENT-DEMO-B",
  "site_id": "SITE-B02",
  "assignment_id": "ASN-2026-00871",
  "payroll_group": "MONTHLY-B",
  "effective_from": "2026-08-12",
  "effective_to": null,
  "status": "ACTIVE",
  "record_version": 3
}

这是用于演示的虚构数据，并非日薪预支的正式 API 结构。

4. 谁记录考勤、谁审批考勤？

（基础概念：参见 什么是已审批考勤？。）

三种角色可能各不相同：

1. 记录者： 考勤机、应用、考勤表或现场主管。

2. 出勤/业务确认者： 组长或客户方的管理者。

3. 计薪审批者： 依流程由人力企业有权限的人员。

常见的四种审批模式

日薪预支必须使用经政策审批的正确状态。“客户已查看”并不当然等于“已审批可发放工资的考勤”。

5. 考勤审批的 SLA 必须与客户共同设计

如果客户确认考勤迟缓，即便平台运行正常，员工也看不到额度。因此，考勤审批的 SLA 必须成为协同流程的一部分，而不仅仅是 HR 的内部事务。

建议的 KPI

考勤按时审批率 (%) = 在截止时点前完成审批的记录数 ÷ 需审批的记录总数 × 100%

按以下维度跟踪：

• 客户；

• 地点；

• 班次；

• 审批人；

• 异常类型；

• 未审批考勤的时长；

• 迟延原因。

不应只报告一个全系统的比率。一家迟缓的客户可能被众多审批良好的客户所掩盖。

提醒与升级机制

• 截止时点前后进行提醒；

• 需处理的异常清单；

• 审批人休假时的替代授权；

• 按记录时长进行升级；

• 当某工作地点没有数据时发出预警；

• 向客户与企业的对接人报告；

• 迟延审批时记录原因。

6. 客户处的考勤需要哪些字段？

如果客户以文件方式发送，还需补充 batch_id、记录数量、checksum、生成时间与文件版本。

7. 在同一周期内于客户之间调动

这是最容易产生考勤重复或缺失的情形。

应具备的流程

1. 以生效日期/时间结束旧派工；

2. 开启新派工；

3. 检查不存在违反规则的重叠区间；

4. 确认在原客户处尚未处理完的考勤；

5. 确定新的薪资组与日薪预支政策；

6. 若规则变化则重算额度；

7. 若额度受影响则通知员工；

8. 按新地点分配管理/审批权限；

9. 将已发生的交易对账到正确的薪资周期。

不要覆盖原客户

档案需要保留 assignmentid 的历史。如果只更改当前的 clientid，历史报表可能会把全部考勤与交易都归到新客户名下。

8. 结束任务不同于离职

一个人可能在客户 A 处结束、等待调往客户 B；也可能完全离职。

企业至少需要两种相互独立的状态：

• 劳动关系状态；

• 派工/任务状态。

参考处理矩阵

正式规则必须由 HR、薪资核算与法务审批。不应仅凭一份客户文件就自动锁定或开启。

9. 多客户下的多薪资周期与政策

人力企业可能按同一周期发放工资，但客户数据在不同日期结算。有些客户有自己的津贴、加班、全勤奖或取整规则。

需做版本管理的配置表

不应在源代码中按客户名称硬编码政策。配置需要有生效日期、审批人与变更历史。

10. 加班与可变收入项

客户处的加班可能经过多个步骤：登记、执行、客户确认、企业审批以及薪资锁定。

诸如班次津贴、全勤、产量或奖金等项目，可能只能在周期末确定。企业必须区分：

• 已经确定并获审批的部分；

• 暂估但可能被调整的部分；

• 只能在周期末确定的部分；

• 不纳入日薪预支的部分。

若将可变项计入额度，则需要有预留机制、版本管理以及向员工的说明。不应把客户处的预期营收直接作为个人领薪权利的依据。

11. 客户迟改考勤时的责任

考勤可能在日薪预支已发生交易之后被修改。流程需要回答：

1. 客户可在哪段时间内修改；

2. 谁审批变更；

3. 是否保存修改前/后的数值；

4. 哪些交易使用了旧版本；

5. 当前额度如何重算；

6. 差额在哪个周期处理；

7. 谁联系员工；

8. 客户与企业如何对账；

9. 反复出现的错误如何纠正。

不应删除旧记录。需要有调整事件或版本，以便能够重现交易发生时点的额度。

12. 多方模式中的资金来源与现金流

在部署前需要确定：

• 由哪一方向员工转账；

• 资金账户归属于谁；

• 交易在何时被视为各方之间的义务；

• 人力企业与客户何时结算；

• 费用由哪一方承担；

• 交易失败、状态不明或退款如何处理；

• 当客户付款迟延时，员工的权益与各方的义务如何安排；

• 应收应付与会计分录依据哪一份合同反映。

如果合同与实际现金流并不保证客户一定按时付款，就不应把日薪预支建立在“客户必然按日付款”的假设之上。财务部门需要构建现金流场景并设定项目上限。

13. 五向对账

（对账细节：参见 日薪预支交易与薪资核算及会计的对账。）

在多客户模式中，对账可能需要五个方向：

1. 已确认/已审批的考勤；

2. 日薪预支额度与交易；

3. 付款结果；

4. 薪资核算/ERP；

5. 相关时与客户的确认/结算记录。

flowchart TD
    A["客户考勤"] --> F["对账"]
    B["日薪预支交易"] --> F
    C["付款结果"] --> F
    D["薪资核算与 ERP"] --> F
    E["客户记录"] --> F
    F --> G["匹配或差异案例"]

常见差异

• 客户已确认但企业尚未审批；

• 考勤挂在错误的 assignment_id 上；

• 已调动的人在原地点仍有考勤；

• 日薪预支成功但薪资核算缺漏；

• 付款成功但日薪预支尚未收到回调；

• 交易进入错误的法人主体或周期；

• 客户在 cutoff 之后修改考勤；

• 按客户合计相符但按员工出错；

• 费用或结算款挂错合同。

14. 在不泄露多余数据的前提下给客户授权

（安全框架：参见 落地日薪预支时的数据安全与隐私保护。）

客户方用户只应看到属于其需要确认范围内的员工与数据。不应默认让客户查看：

• 全部提前领薪历史；

• 个人交易金额；

• 其他客户处的数据；

• 完整的银行账户信息；

• 超出责任范围的薪资档案；

• 详细的欺诈预警；

• 考勤并不需要的人事信息。

权限控制

• 按 clientid、siteid 与角色授权；

• 权限设有失效日期；

• 合同或对接人变更时进行复核；

• 审批人启用 MFA；

• 不使用共享账户；

• 记录查看、修改、审批与导出数据的日志；

• 批量下载数据时单独审批；

• 客户方用户离职/转岗时立即通知并回收权限。

15. 三方支持渠道

不应让员工自己去猜错误属于客户、人力企业还是日薪预支供应商。

按问题类型分流

工单需要有一个贯穿全程的编码，以及员工可跟踪的状态。不应要求他们对每一方都从头重新联系。

16. 面向劳务供应企业的 KPI

引领性 KPI

• 拥有有效 assignment 的员工比例；

• 客户按时提交考勤的比例；

• 考勤按时审批的比例；

• 待审批考勤的平均/中位时长；

• assignment 变更按时更新的比例；

• 额度数据的新鲜度。

体验与运营 KPI

• 各客户的激活率；

• 交易成功率；

• 到账时间；

• 每 1,000 笔交易的工单数；

• 自动处理率；

• 自动对账率；

• 按客户/原因的差异；

• cutoff 之后的考勤调整。

人力与商业 KPI

• 初期的入职与出勤率；

• 按队列（cohort）的离职情况；

• 人力满足率；

• 人工垫付申请；

• 认知度与满意度；

• 每家客户上的运营工作量。

不应仅凭前后对比就断定日薪预支导致了人力变动。需要考量季节性、订单、薪资水平、管理、地点及其他政策。

17. 试点应选择哪家客户？

（标准路线：参见 面向企业的 90 天日薪预支试点计划。）

合适的试点客户通常具备：

• 明确的需求与共识；

• 有权限的对接人；

• 相对稳定的考勤数据；

• 有代表性的班次与加班流程；

• 足够的人数/交易量用于测试；

• 愿意按时审批考勤；

• 配合宣传与支持；

• 不同时更换大型考勤系统。

不应仅因关系融洽就选某家客户，如果其流程与其他客户差异过大的话。

试点范围应覆盖

• 一轮入职/激活；

• 常规班、加班与异常考勤；

• 调动或结束 assignment；

• 成功、失败、状态不明与退款的交易；

• 每日对账；

• 一个完整的薪资周期；

• 属于范围时的客户确认/结算；

• 投诉与事故。

18. 多客户 UAT 检查清单

员工与 assignment

• [ ] 一个人有一个进行中的 assignment。

• [ ] 一个人在周期内有两个有效的 assignment。

• [ ] 在客户之间调动。

• [ ] 结束任务但尚未离职。

• [ ] 已离职但客户文件仍有考勤。

• [ ] 法人主体或客户编码错误。

考勤与审批

• [ ] 客户按时提交考勤。

• [ ] 待确认考勤与已审批考勤。

• [ ] 考勤被拒绝。

• [ ] 审批后修改考勤。

• [ ] 文件重复、缺失或到达顺序错误。

• [ ] 审批人休假且有替代授权。

额度与交易

• [ ] 只有符合条件的数据才生成额度。

• [ ] assignment 变更按正确日期生效。

• [ ] 以相同键重复提交不产生重复交易。

• [ ] 超时产生状态不明。

• [ ] 退款交易被正确处理。

薪资核算与对账

• [ ] 交易归入正确的人员、法人主体、客户与周期。

• [ ] 薪资核算拦截重复交易。

• [ ] 逐笔对账，而非只对总额。

• [ ] 差异生成有责任人的案例。

• [ ] 调整带有修改前/后数值与审批。

权限与安全

• [ ] 客户方用户只看到自己范围内的内容。

• [ ] 客户不查看多余的个人日薪预支历史。

• [ ] 权限按时失效与回收。

• [ ] 数据导出被记录日志。

• [ ] 演练文件泄露或账户被盗的场景。

19. 需注意的法律框架

《劳动法》第 45/2019/QH14 号 自 2021 年 1 月 1 日起生效。第 145/2020/NĐ-CP 号法令 自 2021 年 2 月 1 日起生效，就《劳动法》中关于劳动条件与劳动关系的若干条款作了详细规定与指引，其中包含与劳务派遣有关的内容。

企业必须正确界定法律模式、经营条件、各方的权利与义务、工资支付责任以及适用的档案资料。不应用“劳务供应”这一术语来替代对实际关系的分类。

在数据方面，《个人数据保护法》第 91/2025/QH15 号 与 第 356/2025/NĐ-CP 号法令 自 2026 年 1 月 1 日起生效。人力企业、客户、日薪预支供应商与付款合作方之间的数据共享，需按角色、目的、范围与实际保护措施进行复核。

关于产品、垫付、结算与扣款的具体法律结论，必须依据合同、规章与真实资金流，而不能仅凭“日薪预支”这一名称来推断。

结论

日薪预支在劳务供应与劳务派遣企业中潜力巨大，因为它满足了分散劳动力的需求，并有助于将垫付数字化。但其复杂度也更高：考勤数据在客户处产生、薪资核算归属人力企业、交易经由日薪预支供应商、付款则须被一致地关联起来。

成功的条件在于：正确管理 人员—assignment—客户—薪资周期 模型、按时审批考勤、将结束任务与离职区分开来、最小化授权，并对账到每一笔交易。欢迎了解 面向企业的日薪预支，以探讨面向在多家客户与多个地点工作的劳动力的日薪预支模式。

参考来源

• 《劳动法》第 45/2019/QH14 号

• 指引《劳动法》的第 145/2020/NĐ-CP 号法令

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

• 指引《个人数据保护法》的第 356/2025/NĐ-CP 号法令

---

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

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