日薪預支流程：從考勤到收款與對帳

日薪預支流程始於工作時間被記錄且由主管審核。系統同步資料、計算已發生薪資中符合條件的部分、讓員工提交申請、執行支付，再對帳進入薪資週期。每筆交易都需要識別碼、狀態與完整日誌，以避免超付、重複付款、薪資計算錯誤，或在工時被調整時難以處理。

日薪預支是 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 · 面向企業的日薪預支