給与前払いのプロセス：勤怠記録から受取・照合まで

給与前払いのプロセスは、勤務時間が記録され、管理者が承認したときに始まります。システムはデータを同期し、すでに発生した給与のうち適格な部分を算定し、労働者に申請させ、支払いを実行したうえで給与期間に照合します。各取引には識別子、ステータス、完全なログが必要で、それにより過払い、二重払い、給与計算の誤り、または勤務が調整されたときの処理困難を防ぎます。

給与前払いは、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

• Banking Review：すでに発生した賃金へのアクセスサービスの法的性質とベトナムにおける法整備の提案

---

著者： Nguyen Minh Khang — 戦略部門スペシャリスト、Nhan Kiet Manpower Supply Co., Ltd.

企業向け給与前払いソリューションのご相談： ホットライン 0937.022.655 · メール info@nhankiet.vn · 企業向け給与前払い