企業應根據哪些標準評估日薪預支供應商？簽約前的審核問題集
企業應根據哪些標準評估日薪預支供應商？簽約前的審核問題集
簡短回答： 企業應根據八個標準組評估日薪預支供應商：產品本質、工時數據、計算規則、資金流和成本、轉賬、對賬薪資、保密–合規和實施能力。一個快速轉賬的解決方案如果無法證明已完成的工時、無法控制重複支付或無法與薪資表對接，則尚未是一個完整的日薪預支系統。
為避免決策基於口號，企業應要求供應商通過數據、文件和例外情況演示，而不僅僅是展示順利的流程。
首先，企業購買的是什麼？
(標準集和其他20個問題：參見選擇日薪預支供應商的清單。)
“提前支付工資”、“提前領取工資”或“靈活工資”這些名稱可能用於非常不同的模型。在比較功能之前，需要確定本質：
- 勞工是領取已完成的工資還是基於未來收入借款？
- 領取的金額是否來自工時？
- 已領取的金額如何在薪資中扣除？
- 是否產生債務、利息、費用或對金融機構的義務？
- 如果工時在支付後被修改，誰承擔風險？
在日薪預支中，源代碼顯示只有已完成並已批准的工時才會生成符合條件的金額；已領取的部分會在期末工資中扣除；當前流程不收取利息，也不向勞工收取費用。關於在越南的法律結論仍需由 Nhân Kiệt 和法律顧問確認。
建議的評估得分表
企業可以評分100分，以避免一個吸引人的標準掩蓋其他風險：
| 標準組 | 建議權重 | 核心問題 |
|---|---|---|
| 產品本質 | 15 | 是已完成的工資還是貸款？ |
| 工時數據和控制權 | 15 | 誰確認工時，修改工時有痕跡嗎？ |
| 計算方式和限額 | 10 | 計算公式是否可解釋和配置？ |
| 資金流、費用和合同 | 15 | 誰提供資金，誰支付費用，何時償還？ |
| 轉賬和交易安全 | 15 | 如何防止重複支付和處理不明狀態？ |
| 薪資和對賬 | 15 | 是否正確扣除一次並與銀行對賬？ |
| 保密和合規 | 10 | 數據、權限、銀行密鑰如何保護？ |
| 實施和支持 | 5 | 是否有試點、KPI、SLA和處理聯絡人？ |
權重需根據行業、勞工規模和整合程度調整。這是一個參考框架，不是強制標準。
標準1：日薪預支的本質是否清晰？
(更多信息：參見日薪預支是否為貸款？。)
供應商需證明勞工領取的金額與已發生的勞動價值之間的關聯。
審核問題
- 金額是從已完成的工時計算還是信用限額？
- 是否允許領取尚未結束的當日或未來日期的工資？
- 是否產生貸款合同或勞工債務？
- 是否有利息、交易費、會員費或隱藏費用？
- 已領取的金額如何在工資單上顯示？
- 如果勞工不使用，是否收取費用？
- 市場營銷信息是否與合同一致？
應要求的證據
- 計算領取金額的公式；
- 應用上的承諾樣本；
- 使用後的工資單樣本；
- 費用條款；
- 已批准的法律描述；
- 工時被調整時的處理流程。
日薪預支目前具備什麼？
系統阻止尚未結算的當日/未來工時，只使用已批准的工時，並要求勞工確認這是根據臨時工時的預支，將在工資中扣除。當前流程中不向勞工收取利息/費用。長期費用政策和法律結論需 Nhân Kiệt 確認。
標準2：工時數據是否可靠？
只有當領取的金額來自可驗證的勞動數據時，日薪預支才是安全的。
審核問題
- 解決方案從哪裡獲取工時？
- 是否整合現有的工時來源？
- 勞工的識別鍵是什麼？
- 如何處理跨午夜的夜班？
- 是否支持一個人在多個工作地點工作？
- 誰有權批准或拒絕工時？
- 修改已批准的工時是否保存歷史記錄？
- 是否防止虛假GPS和代打卡？
- 工時更新的延遲是多少？
- 如果數據源出錯，系統會自動生成金額嗎？
日薪預支目前具備什麼？
日薪預支從客戶的Google Sheet、Nhân Kiệt的ERP和應用中的六種打卡方式獲取數據：自拍+GPS、地理圍欄、動態QR、藍牙信標、WiFi BSSID和進出時間記錄。
勞工的識別鍵是CCCD；客戶使用company_id和專用打卡碼。修改後的工時自動返回待批狀態，並附有前後日誌。系統還有防止虛假GPS、一人一機和代打卡的機制。
標準3：公式和限額是否可解釋？
勞工和企業必須理解為什麼系統顯示特定的數字。
審核問題
- 公式使用基本工資、日單價還是預期收入？
- 誰輸入和批准單價？
- 已領取的金額如何在期內扣除？
- 是否有預留金，為什麼保留？
- 限額是按次、日、月計算的？
- 是否可根據客戶配置？
- 配置更改是否有日誌？
- 勞工是否能查看每一天的詳細工時？
日薪預支目前具備什麼？
公式：
> 領取金額 = 已批准的工時 × 客戶的日單價 - 期內已領取金額 - 預留金
結果向下取整到1000越南盾的倍數。默認代碼： Do Huy Le — Tổng Giám Đốc,000越南盾。可配置保留最近N天的工時和/或達到門檻時的10.5%。這些限額需 Nhân Kiệt 批准後才能納入報價或合同。
標準4：資金流和成本是否透明？
這是產品演示中最容易被忽略的部分。
審核問題
- 在勞工領取之前，誰預先存款？
- 供應商自行提供資金還是有金融合作夥伴？
- 企業按日、週還是薪資期償還？
- 是否有客戶的基金限額？
- 誰承擔轉賬費用、運營費用和資金成本？
- 是否有押金或保證金？
- 哪些憑證確認債務？
- 如果勞工離職，風險如何分配？
- 如果工時在支付後減少，誰承擔差額？
- 是否有單方面更改費用的權利？
日薪預支目前具備什麼？
源代碼證明資金來自 Nhân Kiệt 在 VPBank 的專用賬戶。代碼未顯示背後資金來源是 Nhân Kiệt 自行提供、客戶預存還是金融合作夥伴。因此，這是必須通過政策和合同確認的內容，不能從技術架構推斷。
標準5：轉賬是否有足夠的安全層？
速度只有在準確性和可追溯性並存時才有意義。
審核問題
- 收款賬戶是否必須是本人？
- 系統如何檢查賬戶名稱？
- 是否有防重複的交易碼？
- 是否有並發處理鎖？
- 當銀行未返回明確結果時，系統如何處理？
- 是否自動重新支付？
- 是否有懸掛款項的查詢機制？
- 是否有緊急停止開關？
- 銀行密鑰存儲在哪裡？
- 誰有權更改交易狀態？
日薪預支目前具備什麼？
標準流程將資金轉至已通過 VietQR 驗證名稱的 VPBank 本人賬戶。賬戶號在驗證後被鎖定。系統使用固定交易碼，支付時鎖定行，僅在收到有效回應後記錄“已支付”，在狀態不明時保持懸掛，每五分鐘查詢一次，並有緊急停止開關。銀行密鑰存儲在獨立的內部服務中。
自動支付已集成，但默認標誌關閉，並根據客戶逐步開放。
標準6：對賬和薪資是否閉環？
(詳情：參見日薪預支與薪資和會計的對賬。)
當資金進入賬戶時，日薪預支解決方案尚未完成。該款項還需正確返回到薪資表中。
審核問題
- 與銀行對賬的週期是什麼？
- 哪些狀態被納入扣除項？
- 如何防止雙重扣除？
- 如何防止期末重複支付？
- 是否鎖定已使用的工時部分？
- 一個人在多個客戶工作如何分開處理？
- 鎖定薪資時的待處理交易如何處理？
- 是否有無法收回的款項記錄？
- 工資單是否允許勞工對賬？
- 是否有調整歷史記錄？
日薪預支目前具備什麼？
系統在T+1的08:00通過sFTP上的VPBank對賬文件進行對賬，每五分鐘查詢懸掛款項，並在不明確時保持懸掛。已支付的金額在當期工資中扣除；已使用的工時部分通過advancecovereddays鎖定；有無法收回的款項跟蹤。
某些對賬狀態的結算仍需superadmin手動執行以確保資金安全。
標準7：保密、隱私和權限是否可驗證？
(完整框架：參見日薪預支的數據保密和隱私。)
供應商將處理身份數據、工作、收入和銀行賬戶信息。企業不應止步於“系統已加密”的回答。
審核問題
- 收集哪些數據，目的為何？
- 誰可以查看CCCD、賬戶號和工資？
- 是否在界面/報告中隱藏敏感數據？
- 管理賬戶如何分配角色？
- 是否有登錄、審批和數據修改日誌？
- 員工離職後何時撤銷權限？
- 手機丟失或更換設備如何處理？
- 是否有安全測試和事件應對？
- 數據保存多久，如何刪除？
- 事件通知責任歸誰？
應要求的證據
- 數據流圖；
- 權限矩陣；
- 保密/隱私政策；
- 日誌樣本；
- 事件管理流程；
- 測試報告或獨立評估（如有）；
- 數據處理協議。
從源代碼可以驗證日薪預支的一些技術控制，但不能從中自行得出系統已達到特定安全認證的結論。Nhân Kiệt 必須提供正式證據以公佈認證。
標準8：供應商是否能夠實施和支持？
產品再好，如果現場無人運營，仍可能失敗。
審核問題
- 誰是項目經理？
- 數據清理和整合需要多長時間？
- 是否有無預付款的試運行？
- 試點多少人，持續多久？
- 誰培訓管理工時審批？
- 勞工通過哪些渠道獲得指導？
- 各級事件的SLA是什麼？
- 是否有工廠支持聯絡人？
- 暫停和重新開放的標準是什麼？
- 哪些KPI決定擴展？
日薪預支系統具備從工時到支付和對賬的技術能力，但實施時間、試點規模、SLA和正式支持團隊仍需 Nhân Kiệt 確認。
35個RFP或審核會議中可用的問題
產品和勞工
- 勞工領取的金額來自哪些數據？
- 是否允許領取未完成的工時？
- 勞工簽署/確認什麼？
- 是否產生債務或影響信用記錄？
- 勞工需支付哪些費用？
工時和計算方式
- 系統能連接哪些打卡來源？
- 更新頻率是多少？
- 誰有權批准、拒絕和修改工時？
- 修改後的工時是否保存歷史記錄？
- 一個人在多個地點工作如何處理？
- 領取金額的公式是什麼？
- 是否有預留金和限額？
資金和銀行
- 資金從哪個賬戶支付？
- 誰提供資金？
- 收款賬戶如何驗證？
- 系統如何防止重複支付？
- 當銀行狀態不明時如何處理？
- 查詢多久進行一次？
- 是否有緊急停止開關？
薪資和會計
- 已支付的數據如何納入薪資？
- 哪些狀態被扣除？
- 如何防止雙重支付或扣除？
- 與銀行對賬的週期是什麼？
- 供應商的債務由哪些憑證確認？
- 勞工領取後離職如何處理？
保密和運營
- 個人數據如何存儲和分配權限？
- 銀行密鑰是否與應用分離？
- 是否有管理操作日誌？
- 事件處理和通知流程是什麼？
- 回應和修復的SLA是多久？
- 是否有無預付款的試運行？
- 試點的KPI是什麼？
- 每方的責任是什麼？
- 有哪些法律、保密和數據處理文件？
- 合同中明確記錄了哪些承諾？
選擇供應商時的警示信號
- 無法解釋勞工看到的金額；
- 使用未來收入但仍稱為已完成的工資；
- 未明確區分勞工費用和企業費用；
- 未明確說明誰提供資金；
- 無工時審批機制；
- 修改工時或交易無日誌；
- 銀行狀態不明但自動重新支付；
- 無法與薪資對賬；
- 無勞工離職處理流程；
- 宣稱認證或規模但無證據；
- 承諾立即實施但未檢查數據；
- 無人負責事件直至結案。
如何組織有價值的演示會
企業應提出六種情況，而不僅要求演示成功流程：
- 勞工有工時但未批准；
- 已批准的工時被減少；
- 銀行賬戶名稱與CCCD不符；
- 銀行未返回明確結果；
- 勞工在期中離職；
- 薪資表中重複一筆交易。
供應商需指出系統狀態、允許處理的人、日誌和薪資表上的結果。
供應商評分模板
對於每個問題，可以使用0–3的評分標準：
- 0分： 無或未回答；
- 1分： 有描述但無證據；
- 2分： 有功能和文件；
- 3分： 有功能、運營證據和例外控制。
高分不能自動替代法律和財務審核。企業也應設置一些“未達標即停止”的標準，如無法證明工時來源、無重複支付防控或無法與薪資對賬。
日薪預支的技術優勢是什麼？
從實際系統中可以驗證：
- 從人事、打卡、工時審批、計算、銀行支付到對賬和工資單的閉環鏈；
- 六種打卡方式和多Google Sheet格式的讀取能力；
- 客戶有專用門戶控制工時；
- 一個人可以在多個客戶工作；
- VPBank本人的賬戶經過名稱驗證並在驗證後鎖定；
- 多層重複支付防控和fail-closed機制；
- 懸掛款項查詢和T+1對賬；
- 分離的銀行密鑰服務；
- 跟蹤已使用的工時部分和無法收回的款項；
- 系統正在實際運行，自動支付根據客戶逐步開放。
不應從上述點推斷“第一”、“絕對安全”、客戶規模或減少離職率的效果，除非有經批准的數據。
常見問題
是否應選擇功能最多的解決方案？
不一定。應選擇與工時數據、薪資、勞動模型和企業風險水平匹配的解決方案。處理例外的能力通常比展示的功能數量更重要。
資金到賬速度是最重要的標準嗎？
速度對勞工體驗很重要，但必須與正確的人、正確的金額、防止重複支付和期末對賬能力相結合。
不向勞工收費的解決方案是否意味著完全免費？
不一定。可能仍有企業費用、銀行費用、運營成本或資金成本。需要查看價格表和合同。對於日薪預支，當前流程不向勞工收費；正式的費用承擔方需 Nhân Kiệt 確認。
是否應要求法律證明？
應該。企業應要求合同模型、資金流、數據處理機制和相關法律意見。不應僅依賴產品名稱。
是否需要一開始就與ERP深度整合？
不一定。可以先試點可控的數據來源，但識別鍵、交易狀態和進入薪資的流程必須一開始就清晰。
為什麼要演示錯誤情況？
順利的流程只顯示產品可以運行。錯誤情況顯示供應商是否能保護資金、數據和勞工權益。
可以使用這個評分表進行招標嗎？
可以用作初步框架，然後補充企業的法律、安全信息、財務和採購要求。
結論
選擇日薪預支供應商就是選擇一個參與工時、收入、資金轉賬和薪資表的敏感鏈條的合作夥伴。因此，決策不應僅基於漂亮的界面、資金轉賬速度或吸引人的費用。
好的供應商需要通過證據回答五個問題：金額來自哪些工時，誰控制工時，資金如何流動，差異如何處理，期末如何與薪資對賬。
日薪預支具備多項技術能力，適合參與審核過程。商業、法律、規模和SLA部分需由 Nhân Kiệt 完善成正式文件，以將技術優勢轉化為客戶信任。
來源參考
---
作者： Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.
企業日薪預支解決方案諮詢： 熱線 0937.022.655 · 電子郵件 info@nhankiet.vn · 企業日薪預支