人力供應與勞動派遣企業的 EWA：如何管理員工在多家客戶的出勤？

若要在人力供應或勞動派遣企業導入 EWA，每一位員工都必須精確地與其僱用法人、客戶、地點、合約／任務、薪資週期以及已核准的出勤資料串接。企業需要明確界定：由哪一家客戶登錄出勤、誰有核准權、出勤何時符合資格而得以產生額度，以及由哪一方處理撥款、薪資計算與對帳。當員工調派或結束任務時，EWA 權限必須依生效日調整，而非等到月底。

> 注意：「人力供應」、「人力服務」、「外包」與「勞動派遣」並不當然屬於同一種法律關係。責任範圍、僱用主體與薪資給付機制必須依合約與所適用的法律加以認定。本文為一般性的業務與技術框架，不能取代針對個別模式的法律諮詢。

> 術語說明： EWA（依已工作天數所賺取的薪資提前支領）· payroll（薪資計算）· assignment（在客戶端的任務／指派）· SLA（服務水準承諾）· HRIS（人力資源資訊系統）· ERP（企業資源規劃）· cutoff（結帳截止點）· pilot（試辦導入）· UAT（使用者驗收測試）· KPI（衡量指標）。

為什麼多客戶模式比單一工廠更複雜？

在一般製造企業裡，員工、打卡機、核准出勤的主管與薪資計算通常隸屬於同一套組織系統。而在人力供應或勞動派遣企業，員工可能會：

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

• 由客戶排班並確認到勤；

• 由人力供應企業彙整出勤、計算薪資並發放薪資；

• 在同一週期內於不同客戶或地點之間調派；

• 適用多種津貼、加班或不同的確認規則；

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

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

唯有系統理解上述全部脈絡，EWA 才能算得正確。員工代碼正確，但綁錯客戶、綁錯任務或綁錯週期，仍可能產生錯誤的額度。

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

人力供應／人才招募

服務型企業可能只是介紹或提供人才來源，由客戶直接締結並管理勞動關係。在此情況下，對薪資與 EWA 負責的主體，可能並非提供人才的供應單位。

勞動派遣

這是一項須具備條件、並受勞動法規範的活動。必須正確認定派遣企業、要派單位、派遣勞工、工作範圍、合約以及各方責任。

使用勞動力的服務外包

客戶購買的是一項成果或服務，由供應單位組織執行。其管理、出勤與薪資給付方式，取決於服務合約與實際的勞動關係。

為什麼這樣的分類對 EWA 很重要？

它決定了：

• 誰是僱用主體；

• 誰認定並給付薪資；

• 誰握有可信的出勤資料；

• 誰擁有核准權；

• 誰提供資金來源；

• 交易與哪一方結算；

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

• 誰負責處理申訴與爭議。

不應僅因為「都有員工在客戶端工作」，就對所有合約套用同一套 EWA 流程。

2. 多方資料架構

（資料與整合需求：請參閱 EWA 與出勤、薪資及 ERP 的整合。）

flowchart TD
    A["人力企業 HRIS"] --> E["標準資料層"]
    B["客戶端班表與出勤"] --> E
    C["主管確認"] --> E
    D["薪資與合約"] --> E
    E --> F["EWA 額度引擎"]
    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：EWA 交易；

• 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. 核准以計薪者： 依流程具備權限的人力企業人員。

四種常見的核准模式

EWA 必須採用政策已核准的正確狀態。「客戶已檢視」並不當然等於「出勤已核准而得計薪」。

5. 出勤核准 SLA 必須與客戶共同設計

若客戶確認出勤過慢，即使平台運作正常，員工也看不到額度。因此出勤核准 SLA 必須是協作流程的一環，而不只是 HR 的內部事務。

建議的 KPI

準時核准出勤比率 (%) = 截止前核准的紀錄 ÷ 需核准的紀錄總數 × 100%

依下列維度追蹤：

• 客戶；

• 地點；

• 班別；

• 核准人；

• 例外類型；

• 未核准出勤的帳齡；

• 遲延原因。

不應只回報一個全系統的比率。一家遲延的客戶，可能被許多核准良好的客戶所掩蓋。

提醒與逐級呈報機制

• 截止前與截止後提醒；

• 待處理的例外清單；

• 核准人請假時的代理授權；

• 依紀錄帳齡逐級呈報；

• 某工作地點無資料時發出警示；

• 向客戶與企業的窗口回報；

• 遲延核准時記錄原因。

6. 客戶端出勤需要哪些欄位？

若客戶以檔案傳送，尚須加上 batch_id、紀錄筆數、checksum、建立時間與檔案版本。

7. 同一週期內於不同客戶間調派

這是最容易造成出勤重複或遺漏的情況。

建議的流程

1. 以生效日期／時間結束舊指派；

2. 開立新指派；

3. 檢查沒有違反規則的重疊區間；

4. 確認在舊客戶尚未結清的出勤；

5. 認定新的薪資群組與 EWA 政策；

6. 若規則變動則重算額度；

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

8. 依新地點指派管理／核准權限；

9. 將已發生的交易對帳至正確的薪資週期。

不要覆蓋舊客戶

檔案需要保留 assignmentid 的歷史。若只更改目前的 clientid，過往報表可能把所有出勤與交易都歸到新客戶。

8. 結束任務不同於離職

一個人可能在客戶 A 結束、卻正等待調派至客戶 B；也可能完全離職。

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

• 勞動關係狀態；

• 指派／任務狀態。

參考處理矩陣

正式規則須經 HR、薪資與法務核准。不應僅憑一份客戶檔案就自動鎖定或開通。

9. 多客戶下的多薪資週期與多政策

人力企業可能以同一週期發薪，但各客戶的資料卻在不同日期結帳。部分客戶另有津貼、加班、全勤獎金或各自的進位規則。

需做版本管理的設定表

不應在原始碼中依客戶名稱寫死政策。設定需具備生效日、核准人與變更歷史。

10. 加班與變動性所得

客戶端的加班可能經過多個步驟：登記、執行、客戶確認、企業核准、薪資鎖定。

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

• 已確定且已核准的部分；

• 暫估但可能調整的部分；

• 只在期末確定的部分；

• 不納入 EWA 的部分。

若要把變動性項目納入額度，需具備準備、版本管理與向員工說明的機制。不應以來自客戶的預期營收，直接作為個別員工領薪權利的依據。

11. 客戶遲改出勤時的責任

出勤可能在 EWA 已發生交易之後才被修改。流程需回答：

1. 客戶可在哪一段期間內修改；

2. 誰核准變更；

3. 是否保存修改前／後的值；

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

5. 目前的額度如何重算；

6. 差額在哪一個週期處理；

7. 由誰聯繫員工；

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

9. 重複發生的錯誤如何改善。

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

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

導入前需認定：

• 由哪一方撥款給員工；

• 資金帳戶歸屬於誰；

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

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

• 手續費由哪一方負擔；

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

• 客戶延遲付款時，員工權益與各方義務如何；

• 應收應付與分錄依哪一份合約反映。

若合約與實際現金流無法保證客戶必定準時付款，EWA 就不應建立在此假設之上。財務部門需建立現金流情境並設定方案上限。

13. 五方對帳

（對帳細節：請參閱 EWA 交易與薪資及會計的對帳。）

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

1. 已確認／已核准的出勤；

2. EWA 額度與交易；

3. 撥款結果；

4. 薪資／ERP；

5. 涉及時，與客戶的確認／結算紀錄。

flowchart TD
    A["客戶出勤"] --> F["對帳"]
    B["EWA 交易"] --> F
    C["撥款結果"] --> F
    D["薪資與 ERP"] --> F
    E["客戶紀錄"] --> F
    F --> G["相符或差異案件"]

常見差異

• 客戶已確認，但企業尚未核准；

• 出勤記在錯誤的 assignment_id；

• 已調派者在舊地點仍有出勤；

• EWA 成功但薪資漏列；

• 撥款成功但 EWA 尚未收到回呼（callback）；

• 交易入到錯誤的法人或週期；

• 客戶在截止點後修改出勤；

• 依客戶彙總相符，但依員工卻不符；

• 手續費或結算款綁錯合約。

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

（安全框架：請參閱 導入 EWA 時的資料安全與隱私。）

客戶端的使用者，只應看到其需要確認範圍內的員工與資料。不應預設讓客戶檢視：

• 全部的提前領薪歷史；

• 個人交易金額；

• 其他客戶的資料；

• 完整的銀行帳戶資訊；

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

• 詳細的詐欺警示；

• 出勤所不需要的人資資料。

權限控管

• 依 clientid、siteid 與角色授權；

• 權限具到期日；

• 合約或窗口變動時進行審視；

• 對核准人啟用 MFA；

• 不使用共用帳號；

• 記錄檢視、修改、核准與匯出的日誌；

• 大量下載資料須另行核准；

• 客戶端使用者離職／轉職時立即通知並回收權限。

15. 三方支援管道

員工不應被迫自行猜測錯誤究竟出在客戶、人力企業還是 EWA 供應商。

依問題類型分流

工單需具備貫穿的單一代碼，以及員工可追蹤的狀態。不應要求他們對每一方都從頭重新聯繫。

16. 人力供應企業的 KPI

領先型 KPI

• 具有效指派的員工比率；

• 客戶準時傳送出勤的比率；

• 準時核准出勤的比率；

• 待核准出勤的平均／中位帳齡；

• 指派變更準時更新的比率；

• 額度資料的新鮮度。

體驗與營運型 KPI

• 依客戶的啟用率；

• 交易成功率；

• 到帳時間；

• 每 1,000 筆交易的工單數；

• 自動處理比率；

• 自動對帳比率；

• 依客戶／原因的差異；

• 截止點後的出勤調整。

人資與商務型 KPI

• 初期到職與到勤比率；

• 依 cohort 的離職；

• 人力達成率；

• 手動預支申請；

• 認知度與滿意度；

• 每一客戶的營運工作量。

不應僅憑前後比較就斷定 EWA 造成人事變動。需一併考量季節、訂單、薪資水準、管理、地點與其他政策。

17. 試辦應選擇哪一家客戶？

（標準路線圖：請參閱 企業 EWA 90 天試辦計畫。）

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

• 明確的需求與共識；

• 具權限的窗口；

• 相對穩定的出勤資料；

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

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

• 願意準時核准出勤；

• 配合宣導與支援；

• 未同時更換大型打卡系統。

不應僅因關係良好就選擇某客戶，若其流程與其餘部分差異過大。

試辦範圍應涵蓋

• 一輪 onboarding／啟用；

• 正常班、加班與例外出勤；

• 調派或結束指派；

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

• 每日對帳；

• 一個完整的薪資週期；

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

• 申訴與事故。

18. 多客戶 UAT 檢核清單

員工與指派

• [ ] 一人有一個有效指派。

• [ ] 一人在週期內有兩個有效指派。

• [ ] 於不同客戶間調派。

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

• [ ] 已離職但客戶檔案仍有出勤。

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

出勤與核准

• [ ] 客戶準時傳送出勤。

• [ ] 待確認出勤與已核准出勤。

• [ ] 被退回的出勤。

• [ ] 核准後修改的出勤。

• [ ] 檔案重複、遺漏或到達順序錯誤。

• [ ] 核准人請假並有代理授權。

額度與交易

• [ ] 僅符合資格的資料產生額度。

• [ ] 指派變更依正確日期套用。

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

• [ ] Timeout 產生狀態未明。

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

薪資與對帳

• [ ] 交易入到正確的人、法人、客戶與週期。

• [ ] 薪資阻擋重複交易。

• [ ] 逐筆交易對帳，而非僅對總額。

• [ ] 差異產生具負責人的案件。

• [ ] 調整具修改前／後的值與核准。

權限與安全

• [ ] 客戶端使用者只看到自身範圍。

• [ ] 客戶不檢視不必要的個人 EWA 歷史。

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

• [ ] 資料匯出留有日誌。

• [ ] 演練檔案外洩或帳號被盜的情境。

19. 需留意的法律框架

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

企業必須正確認定其法律模式、營運條件、各方權利義務、薪資給付責任與所適用的檔案文件。不應以「人力供應」一詞取代對實際關係的分類。

在資料方面，第 91/2025/QH15 號個人資料保護法與第 356/2025/NĐ-CP 號政府法令自 2026 年 1 月 1 日起生效。人力企業、客戶、EWA 供應商與撥款夥伴之間的資料共享，需依角色、目的、範圍與實際保護措施加以審視。

有關產品、預支、結算與扣款的具體法律結論，必須依合約、規章與真實金流認定，不能僅憑 EWA 這個名稱推論。

結論

EWA 在人力供應與勞動派遣企業具有很大潛力，因為它回應了分散型勞動力的需求，並有助於將預支數位化。但其複雜度也更高：出勤資料產生於客戶端、薪資屬於人力企業、交易經由 EWA 供應商、撥款則須一致串接。

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