承認済み勤務とは何か、そしてなぜ受け取れる金額を決めるのか?
承認済み勤務とは、働いた日・シフト・時間に関するデータで、権限者が企業の手続きに沿って点検し確認したものです。給与前払い システムでは、この十分に信頼できる勤務部分だけが、すでに発生した給与と早期受取の限度額を算定するのに使われるべきです。打刻が成功しても、まだ承認待ちであれば、その勤務が受取に適格だという意味にはまだなりません。
労働者が覚えておくべき最も重要な点は次のとおりです。
> 打刻したというのはシステムがデータを記録したという意味であり、承認済み勤務とはそのデータが限度額算定のステップへ進むよう確認されたという意味です。
「承認済み勤務」は法律用語か?
「承認済み勤務」は主に、勤務時間管理、給与計算、給与前払いシステムで使われる運用用語です。企業ごとにこの状態を「確認済み」「有効」「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)を導入する際のROIの計算方法 · Doanh nghiệp
- EWAはCICに影響するのか? 正確で条件付きの答え · Pháp lý
- 給与前払いのプロセス:勤怠記録から受取・照合まで · Doanh nghiệp
- EWA導入時のデータセキュリティとプライバシー保護 · Doanh nghiệp
- 企業向け90日間EWAパイロット計画 · 企業
- 勤怠打刻済みなのに出勤日数が表示されない、または利用可能額が増えない:原因と対処方法 · 従業員
- 複数シフト制の製造企業向けEWA: 正確な勤怠計算のためにどう導入するか? · Doanh nghiệp
- 給与前払い(EWA)パイロット計画テンプレートと拡大可否の判断基準 · Doanh nghiệp