已審核工時是什麼,為什麼決定能領取的金額?
已審核工時是關於工作日、班別或工作時間的資料,由有權限者依企業流程檢查並確認。在 日薪預支 系統中,只有這部分足夠可靠的工時才應被用來計算已發生薪資與提前領取額度。打卡成功但仍在等待審核,並不代表該工時已符合領取條件。
員工需要牢記的最重要一點是:
> 已打卡代表系統已記錄資料;已審核工時代表該資料已被確認,可以進入額度計算這一步。
「已審核工時」是法律術語嗎?
「已審核工時」主要是工作時間管理、薪資計算與日薪預支系統中的營運術語。每家企業對這一狀態的命名可能不同,如「已確認」「有效」「approved」「已鎖定」或「符合薪資計算條件」(不要與這個詞組的其他含義混淆——見 日薪有幾種含義?)。
《勞動法》規定了與薪資、工作時間、加班和薪資支付相關的原則。然而,由誰審核工時、在什麼時點審核、在軟體中使用哪種狀態,這些流程通常需要各企業在規章、權限分配與適當的內部流程中加以具體化。
因此,員工不應預設某個應用上的狀態在每家公司都具有完全相同的含義。
五種常見的工時狀態
狀態 | 含義 | 是否應用於計算日薪預支額度? |
|---|---|---|
未記錄 | 系統尚無關於班別/工作日的資料 | 否 |
已記錄 – 待審核 | 有打卡資料但尚未確認 | 暫不宜 |
已審核 | 資料已由有權限者確認 | 若其他條件也齊備,可以 |
駁回/無效 | 資料未被接受或需要說明 | 否 |
調整 | 發現偏差後工時已被或正在被修改 | 依新狀態重新計算 |
週期鎖定 | 資料已為薪資週期鎖定,僅透過例外流程修改 | 依適用規則用於結算 |
一些系統將「已審核」與「週期鎖定」分開。已審核工時可在週期內用於計算額度,但在薪資鎖定資料之前仍可能被有效調整。因此,已審核工時並不等於期末薪資已結算完畢。
為什麼不應從未審核工時計算額度?
初始打卡資料可能因多種原因缺失或錯誤:
忘記打上班或下班卡。
打錯班別、地點或日期。
考勤機失去連線。
客戶發來的資料滯後。
加班未經管理者確認。
休假或無薪休假尚未更新。
一次打卡被重複記錄。
各系統間員工編號不一致。
若系統直接按未審核工時允許領取,企業可能超出實際薪資支付。當工時被修改時,員工可能被降低額度、期末薪資不足,或引發差額處理流程。
從一開始就防止錯誤,總是比在支付後追回或調整更易理解、也更少引發爭議(另見 實施 EWA 的風險)。
已審核工時如何決定能領取的金額?
日薪預支不應把整月薪資平均分攤後允許提前領取。系統需要從有效工時確定已發生的收入,然後套用安全規則。
示意公式
仍可領取的額度 =(已審核工時薪資 × 安全比例)− 已領金額 − 預備金/調整
其中:
已審核工時薪資: 從已確認的日期/時間/班別暫計的金額。
安全比例: 企業允許支取的比例,可能低於100%。
已領金額: 該週期內成功交易的總額。
預備金/調整: 為可能影響實收薪資的變動而保留的部分。
已審核工時是重要的輸入,但並非唯一輸入。額度還取決於企業規則、用工狀態、薪資週期、已完成的交易、資金以及其他管控條件。
工時審核前後的範例
假設某員工的示意基本薪資為 9,000,000 越南盾/月,企業為簡化範例約定標準工作日為 26 天。
一天單價示意:
9,000,000 ÷ 26 ≈ 346,154 越南盾/天。
在月中某一時點:
系統已記錄 10 個工作日。
其中 8 天已審核。
2 天仍待管理者檢查。
假定安全比例為 70%。
尚無提前領取交易,也未計算額外預備金。
審核剩餘兩天之前
已審核工時薪資 ≈ 8 × 346,154 = 2,769,232 越南盾。
額度示意 ≈ 2,769,232 × 70% = 1,938,462 越南盾。
兩天獲審核之後
已審核工時薪資 ≈ 10 × 346,154 = 3,461,540 越南盾。
額度示意 ≈ 3,461,540 × 70% = 2,423,078 越南盾。
如此,兩天獲審核後額度約增加 484,616 越南盾。若這兩天被駁回或調整,額度不會像上例那樣增加。
> 注意: 範例中對工作日的換算、薪資構成與安全比例的處理,僅為解釋機制。企業必須套用自己已審核的薪資公式與日薪預支政策。
誰有權審核工時?
工時審核人由企業授權,通常可以是:
組長或班別負責人。
直屬主管。
部門管理者。
確認工作時間的客戶代表。
例外情形下的人資/營運部門。
檢查或週期鎖定環節的薪資部門。
不應讓一個人同時自行建立資料、自行審核工時、自行修改額度並自行處理付款。分離職責有助於減少差錯與舞弊。
工時審核人需承擔什麼責任?
檢查正確的人、正確的日期、正確的班別。
依據有效資料確認正常工時與加班。
在規定期限內處理缺失或異常的工時。
在駁回或調整時清楚說明理由。
不共用審核帳戶。
確保已離職或調職的人被更新為正確狀態。
工時審核期限如何影響員工?
若工時審核滯後,日薪預支額度也可能滯後更新。員工已經工作,卻因系統尚無足夠可靠的資料而無法取得相應的錢。
企業應規定:
管理者必須完成工時審核的時間節點。
管理者休假或缺席時的替代人。
對逾時未審核工時的告警。
因審核滯後而受影響人數的報告。
員工反映未處理工時的管道。
工時審核後額度更新的時間。
對多用工模型而言,「按時被審核工時的人數」應成為一個重要的營運指標,因為它是直接決定能否使用日薪預支的先決條件。
六種常見打卡錯誤及處理方法
錯誤 | 跡象 | 員工應怎麼做? | 主要處理部門 |
|---|---|---|---|
忘記打卡 | 沒有上班或下班時間 | 依流程提交說明與證據 | 直屬管理者 |
班別錯誤 | 時間與排班不符 | 申請修改班別 | 管理/營運 |
加班未審核 | 有加班工時但未計入 | 核對單據/申請加班 | 管理 + 人資 |
休假未更新 | 系統顯示缺勤或缺工時 | 重新提交已審核的休假資訊 | 人資/營運 |
資料重複 | 一個班別出現多次 | 回報重複的編號/日期,不要自行再建立 | IT/營運 |
員工編號錯誤 | 有到職但資料在另一份檔案 | 核實編號與單位 | 人資 + IT |
員工不應為「快速修正」而請他人代為登入或代打卡,因為這一行為可能造成更多偏差並違反企業規定。
說明與工時調整流程
一個清晰的流程可包含六步:
發現偏差: 員工或系統發現工時缺失/錯誤。
提交申請: 選擇日期、班別、錯誤類型、說明內容以及必要時的證據。
管理者核驗: 比對排班、班別分配、裝置資料或客戶確認。
審核或駁回: 清楚記錄結果與理由。
重新同步: 系統更新工時並重新計算額度。
通知: 員工獲知新狀態、額度變化以及若已領取時的處理方式。
每筆調整申請需記錄什麼?
申請人。
需修改的日期/班別。
修改前後的資料。
理由與證據。
審核人。
審核日期時間。
對額度與薪資的影響。
是否已同步。
不應在不留歷史的情況下直接修改已審核資料。
若工時在領取後被調整怎麼辦?
這是需要在日薪預支政策中預先規定的情形。
當交易後工時減少時,系統應:
重新計算符合條件的已發生薪資。
與員工已領取的總額比較。
若已領金額超過新額度,暫停新申請。
清楚通知原因與差額。
轉入已審核的結算/調整流程。
保存全部處理痕跡。
若檔案、約定與交易性質尚未如此界定,則不應自動將一切差額視為員工的「負債」。處理方式必須符合適用的法律模型與規章。
為什麼已審核工時但額度仍未增加?
已審核工時是最重要的條件,但並非在所有情形下都充分。額度可能尚未變化,原因包括:
資料尚未到同步週期。
員工檔案尚未完成驗證。
收款帳戶尚未有效。
單價或薪資資料尚未生效。
薪資週期正在鎖定或換期。
員工已用完符合條件的部分。
有調整/預備金使剩餘額度為 0。
專案總上限或資金臨時達到限制。
上一筆交易正等待結果或查詢。
帳戶因安全告警被臨時鎖定。
系統應顯示具體原因並指引下一步,而不是只提示「額度不足」。
已審核工時與已鎖定薪資表有何不同?
標準 | 已審核工時 | 已鎖定薪資表 |
|---|---|---|
目的 | 確認工作資料 | 結算整個週期的收入 |
時點 | 可在月內每日/定期進行 | 通常在工時週期結束後 |
資料 | 日期、時間、班別、加班、休假 | 工時、收入、津貼、義務與調整 |
可變性 | 鎖定前可依流程調整 | 有限;須經鎖定後的修改流程 |
在日薪預支中的作用 | 計算已發生薪資的輸入 | 期末對帳的依據 |
因此,月內「預計剩餘薪資」在薪資表鎖定之前可能變化。
企業應如何設計工時狀態介面?
員工應能看到:
已記錄的總天數/小時數。
已審核工時總計。
待審核的工時。
被駁回或需補充的工時。
最近一次同步日期。
目前額度。
額度未更新的原因。
提交說明或聯繫支援的按鈕。
顏色只是輔助。每種狀態仍需要文字名稱與描述,以免使用者猜測其含義。
面向監督與人資的儀表板
一個營運儀表板至少應有:
今天需審核工時的人數。
工時待審核超過 SLA 的人數。
缺上班/下班時間的記錄數。
未確認的加班班別數。
交易發生後的調整數。
因缺少已審核工時而無額度的人數。
依管理者/單位的平均審核時間。
同步成功率。
與工時相關的申訴數。
儀表板的目的不是以數量施壓,而是精準找出正讓員工無法使用其權益的瓶頸。
員工未獲額度時的檢查清單
[ ] 檢查工作日是否已出現在系統上。
[ ] 查看狀態是待審核、已審核還是被駁回。
[ ] 檢查班別、上班時間、下班時間與加班。
[ ] 查看休假/換班申請是否已更新。
[ ] 檢查檔案與收款帳戶。
[ ] 查看上一筆交易是否正在等待處理。
[ ] 閱讀系統顯示的原因。
[ ] 就正確的日期/班別提交說明,若流程要求則附證據。
[ ] 聯繫正確的管理者或支援管道;提供員工編號,不提供密碼/OTP。
企業按時審核工時的檢查清單
[ ] 各工時狀態有統一定義。
[ ] 各系統貫穿使用同一個員工編號。
[ ] 依單位/班別/部門分配審核人。
[ ] 主審核人缺席時有替代人。
[ ] 有 SLA 與積壓工時告警。
[ ] 將建立/修改資料的權限與例外審核權限分離。
[ ] 每次調整都有理由與歷史。
[ ] 已審核工時以正確版本同步。
[ ] 每次相關變更後都重新計算額度。
[ ] 員工收到易懂的通知。
[ ] 有因審核滯後而受影響人數的報告。
[ ] 已測試付款後工時被修改的情形。
結論
已審核工時是已做的工作與符合條件可提前領取的金額之間的橋樑。若工時資料未被確認,系統就還沒有足夠可靠的依據來計算額度。
對員工而言,需要清楚區分「已打卡」與「已審核」,並在出現偏差時使用正確的說明管道。對企業而言,按時審核工時不只是行政事務;它是決定日薪預支體驗、財務安全與可擴展性的關鍵環節。
員工請在系統上查看工時狀態與工時錯誤處理指引。希望把工時審核流程與日薪預支結合起來設計的企業,可了解 面向企業的日薪預支。
> 注意: 本文提供一般性資訊,不能替代企業的規章或針對具體情形的法律諮詢。
參考來源
---
作者: Nguyen Minh Khang — 戰略部專員,Nhan Kiet Manpower Supply Co., Ltd.
面向企業的日薪預支解決方案諮詢: 熱線 0937.022.655 · 信箱 info@nhankiet.vn · 面向企業的日薪預支
常見問題
我已打卡,為什麼還沒領到提前薪資?
工時可能仍處於待審核狀態,資料尚未同步,或檔案仍缺少其他條件。請檢查每個工作日的狀態與系統顯示的原因。
誰為我審核工時?
視企業結構而定,可能是組長、主管、管理者、客戶代表或人資/營運。員工應依內部指引聯繫正確的對接人。
工時審核後,額度多久更新?
取決於系統的同步頻率。企業需公布具體 SLA。若超過這一時間,員工應提供員工編號、工作日與狀態以便查核。
未審核的加班會計入額度嗎?
在加班未經有權限者確認前不應計入。經審核並同步後,符合條件的部分可依企業政策納入公式。
已審核工時可以被修改嗎?
若發現偏差且企業有有效的調整流程,則可以。每次修改都須保存理由、審核人以及對額度/薪資的影響。
已審核工時是否代表一定能領到那筆全部金額?
不是。已審核工時是一個輸入。額度還取決於安全比例、已領金額、預備金、檔案狀態、薪資週期以及其他限制。
為什麼預計剩餘薪資會變化?
當工時、加班、休假、無薪休假、調整或交易在週期鎖定前被更新時,該數字可能變化。
提交工時錯誤說明需要提供什麼?
通常需要員工編號、日期/班別、偏差類型、說明內容以及依流程要求的證據。不要透過非正式管道傳送密碼、OTP 或帳戶資料。
Read more articles
- 日薪預支(EWA)風險治理與詐欺防範 · Doanh nghiệp
- EWA 適合哪些企業?自評指標體系 · Doanh nghiệp
- 企業導入日薪預支(EWA)時如何計算投資報酬率 · Doanh nghiệp
- 日薪預支流程:從考勤到收款與對帳 · Doanh nghiệp
- 部署 EWA 時的資料安全與隱私保護 · Doanh nghiệp
- 企業90天EWA試點計畫 · Doanh nghiệp
- 已打卡但尚未顯示出勤天數或額度未增加:原因與處理方式 · 勞工
- 什麼是日薪預支(EWA)?越南全面指南 · Kiến thức
- 多班次製造企業的EWA:如何導入才能算準工時? · Doanh nghiệp
- 日薪預支(EWA)試辦計畫範本與擴大決策準則 · Doanh nghiệp