供應及派遣勞動力企業的日薪預支：如何管理員工在多個客戶的工時？

要在供應或派遣勞動力的企業推行日薪預支，每一位員工都必須準確連結到用工法人、客戶、地點、合約／職務、薪期以及已審批工時資料。企業要清楚界定由哪個客戶記錄工時、由誰有權審批、工時在何時符合條件而可產生額度，以及由哪一方處理付款、payroll 與對賬。當員工調配或結束職務時，日薪預支權限必須按生效日期而變更，不能等到月底。

> 注意：「勞動力供應」、「人事服務」、「外判」與「派遣勞動力」並非當然是同一種法律關係。責任範圍、用工主體與支薪機制必須按合約及適用法律界定。本文只是一般的業務—技術框架，不能取代針對個別模式的法律意見。

> 術語說明： 日薪預支（按已完成的工作日領取工資）· payroll（計算薪酬）· assignment（在客戶處的職務／派工）· SLA（服務水平承諾）· HRIS（人力資源資訊系統）· ERP（企業資源規劃）· cutoff（結期節點）· pilot（試行推行）· UAT（驗收測試）· KPI（衡量指標）。

為何多客戶模式比單一工廠複雜？

在一般製造企業裏，員工、打卡機、審批工時的主管以及 payroll 通常屬於同一套組織系統。對於供應或派遣勞動力的企業，員工可能會：

• 與某一法人建立勞動關係，卻在客戶的地點工作；

• 由客戶編排班次並確認出勤；

• 由供應企業匯總工時、計算薪酬並支付；

• 在同一薪期內於客戶或地點之間調配；

• 有多項津貼、加班或不同的確認規則；

• 結束在客戶處的職務，但尚未終止勞動關係；

• 或在兩個不同時點分別結束職務與勞動關係。

日薪預支只有在系統理解上述完整脈絡時才能計算正確。即使員工代碼正確，但掛錯客戶、錯職務或錯薪期，一樣可能產生錯誤額度。

1. 整合前先分清各種業務模式

勞動力供應／人事招聘

服務企業可以介紹或提供候選人來源，讓客戶直接訂立並管理勞動關係。在這種情況下，就工資與日薪預支負責的主體，可能並非提供候選人的單位。

派遣勞動力

這是一項有條件並受勞動法規範的活動。須準確界定派遣企業、承租方、被派遣勞動者、工作範圍、合約以及各方責任。

涉及使用勞動力的服務外判

客戶購買的是一項成果或服務；供應單位組織執行。管理、工時記錄與支薪方式取決於服務合約與實際勞動關係。

為何分類對日薪預支很重要？

它決定了：

• 誰是用工者；

• 誰界定並支付工資；

• 誰持有可靠的工時資料；

• 誰有審批權；

• 誰提供資金來源；

• 交易與誰結算；

• 按實際角色，誰是資料控制方或處理方；

• 誰處理投訴與爭議。

不應僅因為都有員工在客戶處工作，就對所有合約使用同一套日薪預支流程。

2. 多方資料架構

（資料與整合要求：見日薪預支與考勤、payroll 及 ERP 的整合。）

flowchart TD
    A["人力企業 HRIS"] --> E["標準資料層"]
    B["客戶處的班次與工時"] --> E
    C["主管確認"] --> E
    D["Payroll 與合約"] --> E
    E --> F["日薪預支額度引擎"]
    F --> G["付款"]
    G --> H["payroll、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. 界定新的 payroll 組別與日薪預支政策；

6. 若規則變更，重新計算額度；

7. 若額度受影響，通知員工；

8. 按新地點分配管理／審批權限；

9. 將已產生的交易與正確薪期對賬。

不覆蓋舊客戶

檔案需保留 assignmentid 的歷史。若只更改當前的 clientid，過往報表可能會把全部工時與交易都掛到新客戶。

8. 結束職務不等於離職

一名員工可能在客戶 A 結束、卻等待調往客戶 B；或完全離職。

企業至少需要兩個獨立狀態：

• 勞動關係狀態；

• 派工／職務狀態。

參考處理矩陣

正式規則必須由 HR、Payroll 與法務審批。不應只憑一個客戶檔案就自動鎖定或開放。

9. 多個薪期與多客戶的政策

人力企業可以按同一薪期支薪，但客戶資料卻在不同日子結期。有些客戶有津貼、加班、全勤獎或自己的進位規則。

需管理版本的配置表

不應在源碼中按客戶名稱硬編碼政策。配置需具備生效日期、審批人與變更歷史。

10. 加班與可變收入項目

客戶處的加班可能經過多個步驟：登記、執行、客戶確認、企業審批以及 payroll 鎖定。

班次津貼、全勤、產量或獎金等項目，可能只在結期才確定。企業必須分類：

• 已確定並獲審批的部分；

• 暫計但有可能調整的部分；

• 只在結期才確定的部分；

• 不納入日薪預支的部分。

若把可變項目計入額度，就需要有預留機制、版本管理，並向員工解釋。不應以客戶的預期收入直接作為個別員工領薪權利的依據。

11. 客戶逾期修改工時時的責任

工時可能在日薪預支已產生交易之後才被修改。流程需回答：

1. 客戶可在甚麼期間內修改；

2. 由誰審批變更；

3. 是否保留前／後值；

4. 哪些交易採用了舊版本；

5. 當前額度如何重新計算；

6. 差額在哪一期處理；

7. 由誰聯絡員工；

8. 客戶與企業如何對賬；

9. 如何修正重複出現的錯誤。

不應刪除舊記錄。需要調整事件或版本，以便重建交易當時的額度。

12. 多方模式下的資金來源與現金流

推行前需界定：

• 由哪一方向員工轉賬；

• 資金源賬戶屬於誰；

• 交易何時被視為各方之間的義務；

• 人力企業與客戶何時結算；

• 費用由哪一方承擔；

• 交易失敗、狀態未明或退款如何處理；

• 當客戶逾期付款時，員工權益與各方義務如何；

• 應收應付與會計分錄按哪份合約反映。

若合約與實際現金流未能保證，就不應把日薪預支建基於「客戶必定準時付款」的假設之上。Finance 部門需建立現金流情景與計劃上限。

13. 五向對賬

（對賬詳情：見日薪預支交易與 payroll 及會計的對賬。）

在多客戶模式下，對賬可能需要五個維度：

1. 已確認／審批的工時；

2. 額度與日薪預支交易；

3. 付款結果；

4. payroll／ERP；

5. 相關時與客戶的確認／結算檔案。

flowchart TD
    A["客戶工時"] --> F["對賬"]
    B["日薪預支交易"] --> F
    C["付款結果"] --> F
    D["Payroll 與 ERP"] --> F
    E["客戶檔案"] --> F
    F --> G["匹配或差額 case"]

常見差異

• 客戶已確認但企業尚未審批；

• 工時掛在錯誤的 assignment_id；

• 已調配者在舊工作點仍有工時；

• 日薪預支成功但 payroll 缺漏；

• 付款成功但日薪預支尚未收到 callback；

• 交易記入錯誤法人或薪期；

• 客戶在 cutoff 之後修改工時；

• 按客戶匯總相符，但按員工卻有誤；

• 費用或結算款項掛在錯誤合約。

14. 給客戶授權而不外洩不必要的資料

（保安框架：見推行日薪預支時的資料保安與私隱。）

客戶方使用者只應看到自己需要確認範圍內的員工與資料。不應預設讓客戶查看：

• 全部提前領薪歷史；

• 個人交易金額；

• 其他客戶的資料；

• 完整的銀行賬戶資訊；

• 超出責任範圍的薪酬檔案；

• 詳細的欺詐警示；

• 考勤以外不必要的人事資料。

權限控管

• 按 clientid、siteid 及角色授權；

• 權限設有到期日；

• 合約或對接人變更時複核；

• 審批人使用 MFA；

• 不使用共用賬戶；

• 記錄查看、修改、審批與匯出資料的 log；

• 批量下載資料時另行審批；

• 客戶方使用者離職／調職時即時通知並收回權限。

15. 三方支援渠道

員工不應要自行猜測問題出在客戶、人力企業還是日薪預支供應商。

按問題類型分流

Ticket 需有一個貫穿全程的代碼，以及員工可追蹤的狀態。不應要求他們就每一方都從頭再聯絡一次。

16. 供應勞動力企業的 KPI

領先 KPI

• 具有效 assignment 的員工比例；

• 客戶準時發送工時的比例；

• 工時準時審批的比例；

• 待審批工時的平均／中位數時齡；

• assignment 變更準時更新的比例；

• 額度資料的新鮮度。

體驗與營運 KPI

• 各客戶的啟用率；

• 交易成功率；

• 到賬時間；

• 每 1,000 宗交易的 ticket 數；

• 自動處理比例；

• 自動對賬比例；

• 按客戶／原因的差異；

• cutoff 之後的工時調整。

人事與商業 KPI

• 初期到崗與出勤比例；

• 按 cohort 的離職；

• 人力供應達成率；

• 人手墊支申請；

• 認知度與滿意度；

• 每客戶的營運工作量。

不應僅憑前後對比就斷定日薪預支導致人事變動。須一併考量季節、訂單、薪資水平、管理、地點及其他政策。

17. 試行應選哪些客戶？

（標準路線圖：見企業 90 天日薪預支試行計劃。）

合適的試行客戶通常具備：

• 明確的需求與共識；

• 有權限的對接人；

• 相對穩定的工時資料；

• 具代表性的班次與加班流程；

• 足夠的人數／交易量以供測試；

• 願意準時審批工時；

• 配合傳訊與支援；

• 不同時更換大型考勤系統。

不應僅因關係融洽就選某客戶，如果其流程與其餘部分差異太大。

試行範圍應涵蓋

• 一輪 onboarding／啟用；

• 正常班、加班與例外工時；

• assignment 的調配或結束；

• 成功、失敗、未明與退款交易；

• 每日對賬；

• 一個完整的 payroll 薪期；

• 屬於範圍內的客戶確認／結算；

• 投訴與事故。

18. 多客戶 UAT 檢查清單

員工與 assignment

• [ ] 一名員工有一個進行中的 assignment。

• [ ] 一名員工在薪期內有兩個有效 assignment。

• [ ] 在客戶之間調配。

• [ ] 結束職務但尚未離職。

• [ ] 已離職但客戶檔案仍有工時。

• [ ] 法人或客戶代碼錯誤。

工時與審批

• [ ] 客戶準時發送工時。

• [ ] 待確認工時與已審批工時。

• [ ] 工時被拒絕。

• [ ] 審批後修改工時。

• [ ] 檔案重複、缺漏或次序錯誤。

• [ ] 審批人休假並有代理授權。

額度與交易

• [ ] 只有符合條件的資料才產生額度。

• [ ] assignment 變更按正確日期生效。

• [ ] 以相同鍵重發不產生重複交易。

• [ ] Timeout 產生未明狀態。

• [ ] 退款交易獲正確處理。

Payroll 與對賬

• [ ] 交易記入正確的員工、法人、客戶與薪期。

• [ ] Payroll 攔截重複交易。

• [ ] 逐宗交易對賬，不只比對總額。

• [ ] 差異產生有負責人的 case。

• [ ] 調整具備前／後值與審批。

權限與保安

• [ ] 客戶方使用者只看到自己的範圍。

• [ ] 客戶不查看不必要的個人日薪預支歷史。

• [ ] 權限正確到期與收回。

• [ ] 匯出資料有記錄 log。

• [ ] 演練檔案外洩或賬戶被盜的情景。

19. 需要留意的法律框架

第 45/2019/QH14 號《勞動法》 自 2021 年 1 月 1 日起生效。第 145/2020/NĐ-CP 號法令 自 2021 年 2 月 1 日起生效，就《勞動法》關於勞動條件與勞動關係的若干條文作出詳細規定與指引，當中包含與派遣勞動力相關的內容。

企業必須準確界定法律模式、經營條件、各方權利與義務、支薪責任及適用檔案。不應以「勞動力供應」一詞來取代對實際關係的分類。

在資料方面，第 91/2025/QH15 號《個人資料保護法》 與 第 356/2025/NĐ-CP 號法令 自 2026 年 1 月 1 日起生效。人力企業、客戶、日薪預支供應商與付款夥伴之間的資料共享，需按角色、目的、範圍與實際保護措施加以複核。

有關產品、墊支、結算與扣減的具體法律結論，必須依據合約、規章與真實資金流，而不能僅憑「日薪預支」的名稱去推斷。

結論

日薪預支在供應及派遣勞動力企業中潛力巨大，因為它回應了分散勞動力的需求，並有助於把墊支數碼化。但複雜度也更高：工時資料在客戶處產生、payroll 屬於人力企業、交易經日薪預支供應商，而付款則必須一致地連結起來。

成功條件在於正確管理 員工—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 · 企業日薪預支