日薪預支流程：由考勤到收款與對數

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

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