人材供給・労働者派遣を行う企業向けの給与前払い：複数の顧客先での勤怠をどう管理するか？

人材供給企業や労働者派遣企業で給与前払いを導入するには、各労働者を、雇用主となる法人、顧客、就業場所、契約・業務、給与計算期間、そして承認済み勤怠データと正確に紐づける必要があります。企業は、どの顧客が勤怠を記録するのか、誰に承認権限があるのか、いつ勤怠が限度額の生成条件を満たすのか、そしてどの当事者が支払・給与計算・照合を担うのかを明確に定めなければなりません。労働者が配属変更となったり業務を終了したりする場合、給与前払いの権利は月末を待たずに効力発生日に従って変更される必要があります。

> 注: 「人材供給」「人材サービス」「アウトソーシング」「労働者派遣」は、当然に同一の法律関係を意味するわけではありません。責任範囲、雇用主となる主体、賃金の支払い方法は、契約および適用される法律に従って確定させる必要があります。本記事は一般的な業務・技術フレームワークであり、個々のモデルに対する法的助言に代わるものではありません。

> 用語解説: 給与前払い（実際に働いた日数分の賃金を受け取ること）· 給与計算（payroll）· アサインメント（顧客先での業務・配属）· SLA（サービスレベル合意）· HRIS（人事情報システム）· ERP（企業資源計画）· カットオフ（締め時点）· パイロット（試験導入）· UAT（受入テスト）· KPI（測定指標）。

なぜ複数顧客モデルは単一工場よりも複雑なのか？

一般的な製造業では、労働者、勤怠打刻機、勤怠を承認する管理者、そして給与計算は、多くの場合同一の組織システムに属します。人材供給企業や労働者派遣企業の場合、労働者は次のような状況になり得ます。

• ある法人と労働関係を結びながら、顧客の場所で働く。

• 顧客からシフトを割り当てられ、出勤を確認される。

• 供給企業側で勤怠を集計され、給与を計算・支払われる。

• 同一期間内に顧客や場所の間で配属変更となる。

• 手当、残業、確認ルールが顧客ごとに異なる複数のパターンを持つ。

• 顧客先での業務は終了したが、労働関係はまだ終了していない。

• あるいは、業務と労働関係の両方を、別々の時点で終了する。

給与前払いは、システムがこうした全体の文脈を理解して初めて正しく計算できます。従業員コードが正しくても、顧客・業務・期間の紐づけが誤っていれば、誤った限度額が生成され得ます。

1. 統合の前に業務モデルを明確に切り分ける

人材供給・人材紹介

サービス企業が候補者を紹介または提供し、顧客が直接契約を締結して労働関係を管理する場合があります。このケースでは、賃金と給与前払いの責任を負う主体は、候補者を供給した事業者ではない可能性があります。

労働者派遣

これは条件付きの活動であり、労働法によって規制されます。派遣元企業、派遣先、派遣労働者、業務の範囲、契約、そして各当事者の責任を正しく確定させる必要があります。

労働者を用いる業務のアウトソーシング

顧客はある成果物やサービスを購入し、供給側がその実施を組織します。管理・勤怠・賃金支払いの方法は、業務委託契約と実際の労働関係に依存します。

なぜ分類が給与前払いにとって重要なのか？

それは以下を決定するからです。

• 誰が雇用主か。

• 誰が賃金を確定し支払うか。

• 誰が信頼できる勤怠データを持つか。

• 誰に承認権限があるか。

• 誰が資金を供給するか。

• 取引は誰に対して決済されるか。

• 実際の役割に照らして誰がデータの管理者または処理者か。

• 誰が苦情や紛争を解決するか。

顧客先で働く労働者がいるという共通点だけを理由に、すべての契約に単一の給与前払いプロセスを適用すべきではありません。

2. 複数当事者のデータアーキテクチャ

（データおよび統合の要件については、勤怠・給与計算・ERPとの給与前払い統合を参照。）

flowchart TD
    A["人材企業のHRIS"] --> E["標準データ層"]
    B["顧客先のシフトと勤怠"] --> E
    C["監督者による確認"] --> E
    D["給与計算と契約"] --> E
    E --> F["給与前払い限度額エンジン"]
    F --> G["支払"]
    G --> H["給与計算・ERP・顧客との照合"]

各ドメインに単一の正規ソースを置く原則

3. 「人 – 業務 – 顧客 – 給与計算期間」のデータモデル

employee_id だけでは不十分です。一人が同一期間内に複数回の配属を持つことがあります。

重要なキー

• employee_id：労働者コード。

• employerid または legalentity_id：労働関係を締結する法人。

• client_id：顧客。

• site_id：就業場所。

• assignment_id：具体的な業務・配属。

• contract_id：業務委託契約または必要な参照。

• payroll_group：給与計算のルール／期間グループ。

• payperiodid：給与計算期間。

• effectivefrom、effectiveto：効力発生日。

• transaction_id：給与前払い取引。

• payment_reference：支払参照。

なぜ `assignment_id` が重要なのか？

ある従業員が顧客Aで10日、顧客Bで12日働いた場合、システムは各勤怠レコードがどの業務に属し、誰が承認し、どのルールを適用するのかを把握できなければなりません。従業員の記録に現在の顧客だけを保持し、履歴を上書きするようなことはすべきではありません。

配属データのサンプル

{
  "employee_id": "EMP-000123",
  "employer_id": "NK-DEMO",
  "client_id": "CLIENT-DEMO-B",
  "site_id": "SITE-B02",
  "assignment_id": "ASN-2026-00871",
  "payroll_group": "MONTHLY-B",
  "effective_from": "2026-08-12",
  "effective_to": null,
  "status": "ACTIVE",
  "record_version": 3
}

これは説明用の架空データであり、給与前払いの公式なAPI構造ではありません。

4. 誰が勤怠を記録し、誰が承認するのか？

（前提となる概念については、承認済み勤怠とは何か？を参照。）

三つの役割は異なり得ます。

1. 記録する者: 勤怠打刻機、アプリ、勤怠表、または現場の監督者。

2. 出勤・業務を確認する者: 顧客側のリーダーまたは管理者。

3. 給与計算のために承認する者: プロセスに従い権限を持つ人材企業の担当者。

よくある四つの承認モデル

給与前払いは、方針によって承認された正しいステータスを用いなければなりません。「顧客が閲覧済み」は、当然には「賃金支払いのために承認済みの勤怠」を意味しません。

5. 勤怠承認のSLAは顧客と一緒に設計する

顧客が勤怠を確認するのが遅れると、プラットフォームが正常に動作していても労働者は限度額を確認できません。そのため、勤怠承認のSLAは連携プロセスの一部であるべきで、人事の内部作業だけにとどめてはなりません。

推奨KPI

期限内に承認された勤怠の割合 (%) = 締め前に承認されたレコード数 ÷ 承認が必要なレコード総数 × 100%

次の軸で追跡します。

• 顧客。

• 場所。

• シフト。

• 承認者。

• 例外の種類。

• 未承認勤怠の経過日数。

• 遅延の理由。

システム全体の単一の割合だけを報告すべきではありません。承認が良好に進む複数の顧客に紛れて、遅い一顧客が隠れてしまうことがあります。

催促とエスカレーションの仕組み

• 締め前後のリマインド。

• 処理が必要な例外リスト。

• 承認者が不在の際の代理権限。

• レコードの経過日数に応じたエスカレーション。

• ある就業場所のデータが存在しない場合の警告。

• 顧客と企業の窓口への報告。

• 遅延承認の際の理由記録。

6. 顧客先の勤怠にはどのような項目が必要か？

顧客がファイルを送る場合は、batch_id、レコード件数、チェックサム、作成時刻、ファイルバージョンを追加する必要があります。

7. 同一期間内での顧客間の配属変更

これは勤怠の重複や欠落が発生しやすい状況です。

備えておくべきプロセス

1. 旧配属を効力発生の日時で終了する。

2. 新配属を開始する。

3. ルールに反する重複期間がないか確認する。

4. 旧顧客先で保留中の勤怠を確認する。

5. 新しい給与計算グループと給与前払いポリシーを確定する。

6. ルールが変わる場合は限度額を再計算する。

7. 限度額に影響がある場合は労働者に通知する。

8. 新しい場所に応じて管理・承認権限を割り当てる。

9. 発生済みの取引を正しい給与計算期間と照合する。

旧顧客を上書きしない

記録には assignmentid の履歴が必要です。現在の clientid だけを変更すると、過去のレポートがすべての勤怠と取引を新しい顧客に紐づけてしまう可能性があります。

8. 業務の終了は退職とは異なる

一人が顧客Aで業務を終え、顧客Bへの配属変更を待つ場合もあれば、完全に退職する場合もあります。

企業には少なくとも二つの独立したステータスが必要です。

• 労働関係のステータス。

• 配属・業務のステータス。

参考となる処理マトリクス

正式なルールは人事・給与計算・法務が承認しなければなりません。一つの顧客ファイルだけに基づいて自動的にロックや解除を行うべきではありません。

9. 複数顧客にわたる複数の給与計算期間とポリシー

人材企業は同一の期間で賃金を支払うとしても、顧客のデータは異なる日に締められることがあります。一部の顧客には独自の手当、残業、精勤賞与、丸めルールがあります。

バージョン管理が必要な設定表

顧客名によってポリシーをソースコードにハードコードすべきではありません。設定には効力発生日、承認者、変更履歴が必要です。

10. 残業と変動する収入項目

顧客先での残業は、申請、実施、顧客による確認、企業による承認、給与計算でのロックという複数の段階を経ることがあります。

シフト手当、精勤、出来高、賞与といった項目は、期末にしか確定しない場合があります。企業は次のように分類しなければなりません。

• すでに確定し承認された部分。

• 暫定計算だが調整の可能性がある部分。

• 期末にしか確定しない部分。

• 給与前払いに含めない部分。

変動項目を限度額に含める場合は、引当の仕組み、バージョン管理、そして労働者への説明が必要です。顧客からの想定売上を、個々人の賃金受給権の直接的な根拠にすべきではありません。

11. 顧客が勤怠を遅れて修正した場合の責任

給与前払いの取引が発生した後で勤怠が修正されることがあります。プロセスは次の点に答える必要があります。

1. 顧客はどの期間内に修正できるか。

2. 誰が変更を承認するか。

3. 修正前後の値を保存するか。

4. どの取引が旧バージョンを使ったか。

5. 現在の限度額をどう再計算するか。

6. 差額をどの期間で処理するか。

7. 誰が労働者に連絡するか。

8. 顧客と企業はどのように照合するか。

9. 繰り返し発生する誤りをどう是正するか。

旧レコードを削除すべきではありません。取引時点の限度額を再現できるよう、調整イベントまたはバージョンが必要です。

12. 複数当事者モデルにおける資金源と資金繰り

導入前に次を確定させる必要があります。

• どの当事者が労働者に送金するか。

• 資金の口座は誰に属するか。

• 取引がいつ当事者間の債務とみなされるか。

• 人材企業と顧客はいつ決済するか。

• 手数料はどの当事者が負担するか。

• 失敗・不明・返金となった取引をどう処理するか。

• 顧客の支払いが遅れた場合、労働者の権利と各当事者の義務はどうなるか。

• 債権債務と仕訳はどの契約に基づいて反映されるか。

契約や実際の資金繰りがそれを保証しないのであれば、顧客が必ず期日どおりに支払うという前提に立って給与前払いを設計すべきではありません。財務部門は資金繰りのシナリオとプログラムの上限を構築する必要があります。

13. 五方向の照合

（照合の詳細については、給与前払い取引と給与計算・会計との照合を参照。）

複数顧客モデルでは、照合が五方向にわたって必要になることがあります。

1. 確認／承認済みの勤怠。

2. 限度額と給与前払い取引。

3. 支払の結果。

4. 給与計算／ERP。

5. 関連する場合の顧客との確認／決済記録。

flowchart TD
    A["顧客先の勤怠"] --> F["照合"]
    B["給与前払い取引"] --> F
    C["支払の結果"] --> F
    D["給与計算とERP"] --> F
    E["顧客の記録"] --> F
    F --> G["一致、または差異案件"]

よくある差異

• 顧客は確認したが企業が未承認。

• 誤った assignment_id に紐づいた勤怠。

• 配属変更済みの者に旧場所での勤怠が残る。

• 給与前払いは成功したが給与計算に反映されていない。

• 支払は成功したが給与前払いがコールバックを未受信。

• 誤った法人または期間に計上された取引。

• 顧客がカットオフ後に勤怠を修正。

• 顧客別の合計は一致するが従業員別で不一致。

• 手数料や決済項目が誤った契約に紐づけられている。

14. 不要なデータを開示せずに顧客へ権限を付与する

（セキュリティのフレームワークについては、給与前払い導入時のデータセキュリティとプライバシーを参照。）

顧客側のユーザーは、確認に必要な範囲の労働者とデータだけを見られるべきです。次の情報を顧客に既定で見せるべきではありません。

• 前払い受給の全履歴。

• 個人の取引金額。

• 他の顧客先のデータ。

• 完全な銀行口座情報。

• 責任範囲外の給与記録。

• 詳細な不正検知アラート。

• 勤怠に不要な人事情報。

権限の統制

• clientid、siteid、役割に基づく権限付与。

• 権限に有効期限を設定。

• 契約や窓口が変わった際の見直し。

• 承認者へのMFA。

• 共有アカウントを使わない。

• 閲覧・修正・承認・データ出力のログ取得。

• 一括データ取得時の個別承認。

• 顧客側ユーザーの退職・異動時の即時通知と権限回収。

15. 三者間のサポート窓口

労働者が、不具合の原因が顧客・人材企業・給与前払い提供者のどこにあるのかを自分で推測しなければならない状況を作るべきではありません。

問題の種類による振り分け

チケットには一貫した番号と、労働者が追跡できるステータスが必要です。各当事者に一から連絡し直すよう求めるべきではありません。

16. 人材供給企業向けのKPI

先行KPI

• 有効な配属を持つ労働者の割合。

• 顧客が期限内に勤怠を送付した割合。

• 期限内に承認された勤怠の割合。

• 承認待ち勤怠の平均／中央値の経過日数。

• 配属変更が期限内に更新された割合。

• 限度額データの鮮度。

体験・運用のKPI

• 顧客別のアクティベーション率。

• 取引成功率。

• 入金までの時間。

• 取引1,000件あたりのチケット数。

• 自動処理率。

• 自動照合率。

• 顧客別／原因別の差異。

• カットオフ後の勤怠調整。

人事・商務のKPI

• 初期段階の入職率と出勤率。

• コホート別の離職。

• 人材充足率。

• 手動前払い申請の数。

• 認知度と満足度。

• 顧客ごとの運用負荷。

前後比較だけから給与前払いが人事上の変化を引き起こしたと結論すべきではありません。季節性、受注、賃金水準、管理、場所、その他のポリシーも考慮する必要があります。

17. パイロットではどの顧客を選ぶべきか？

（標準的なロードマップについては、企業向け給与前払い90日パイロット計画を参照。）

適したパイロット顧客には、通常次の特徴があります。

• 明確なニーズと合意がある。

• 権限を持つ窓口がいる。

• 勤怠データが比較的安定している。

• シフトと残業のプロセスが代表的である。

• 検証に十分な人数／取引数がある。

• 期限内に勤怠を承認する用意がある。

• 広報とサポートで協力してくれる。

• 大規模な勤怠システムの入れ替えを同時に行わない。

プロセスが他の大部分とあまりに異なる場合、関係が良好というだけで顧客を選ぶべきではありません。

パイロットで通過すべき範囲

• オンボーディング／アクティベーションの一巡。

• 通常シフト、残業、例外的な勤怠。

• 配属変更または配属終了。

• 成功・失敗・不明・返金の取引。

• 日次の照合。

• 一つの完全な給与計算期間。

• 該当する場合の顧客との確認／決済。

• 苦情とインシデント。

18. 複数顧客向けのUATチェックリスト

労働者と配属

• [ ] 一人が一つの稼働中の配属を持つ。

• [ ] 一人が期間内に有効な二つの配属を持つ。

• [ ] 顧客間の配属変更。

• [ ] 業務は終了したが退職はしていない。

• [ ] 退職したが顧客ファイルにまだ勤怠が残る。

• [ ] 誤った法人または顧客コード。

勤怠と承認

• [ ] 顧客が期限内に勤怠を送付。

• [ ] 確認待ちの勤怠と承認済みの勤怠。

• [ ] 却下された勤怠。

• [ ] 承認後に修正された勤怠。

• [ ] 重複・欠落・順序違いで到着したファイル。

• [ ] 承認者が不在で代理承認がある。

限度額と取引

• [ ] 条件を満たすデータだけが限度額を生成する。

• [ ] 配属変更が正しい日付で適用される。

• [ ] 同一キーの再送で重複取引が生じない。

• [ ] タイムアウトが不明ステータスを生成する。

• [ ] 返金取引が正しく処理される。

給与計算と照合

• [ ] 取引が正しい人・法人・顧客・期間に計上される。

• [ ] 給与計算が重複取引をブロックする。

• [ ] 合計だけでなく取引ごとに照合する。

• [ ] 差異が所有者付きの案件を生成する。

• [ ] 調整に修正前後の値と承認がある。

権限とセキュリティ

• [ ] 顧客側ユーザーが自身の範囲だけを見られる。

• [ ] 顧客が不要な個人の給与前払い履歴を閲覧しない。

• [ ] 権限が正しく失効・回収される。

• [ ] データ出力がログに記録される。

• [ ] ファイル漏えいやアカウント乗っ取りのシナリオを訓練する。

19. 留意すべき法的フレームワーク

労働法第45/2019/QH14号は2021年1月1日に施行されました。政令145/2020/NĐ-CPは2021年2月1日に施行され、労働条件と労働関係に関する労働法の一部条項を詳細に規定・案内しており、その中に労働者派遣に関する内容も含まれています。

企業は、法的モデル、活動条件、各当事者の権利義務、賃金支払いの責任、適用される記録を正しく確定させなければなりません。「人材供給」という用語を、実際の関係の分類に代えて用いるべきではありません。

データについては、個人データ保護法第91/2025/QH15号および政令356/2025/NĐ-CPが2026年1月1日に施行されました。人材企業、顧客、給与前払い提供者、決済パートナーの間でのデータ共有は、役割、目的、範囲、そして実際の保護措置に照らして見直す必要があります。

製品、前払い、決済、控除に関する具体的な法的結論は、契約、規程、実際の資金の流れに基づかなければならず、給与前払いという名称だけから推し量ってはなりません。

まとめ

給与前払いは、分散した労働力のニーズに応え、前払いのデジタル化を助けるため、人材供給企業や労働者派遣企業において大きな可能性を持ちます。しかし複雑さも高くなります。勤怠データは顧客先で発生し、給与計算は人材企業に属し、取引は給与前払い提供者を経由し、支払いは一貫して連携されなければなりません。

成功の条件は、人 – アサインメント – 顧客 – 給与計算期間というモデルを正しく管理し、期限内に勤怠を承認し、業務終了を退職と切り分け、権限を最小限にし、取引単位まで照合することです。複数の顧客先や場所で働く労働力に向けた給与前払いのモデルについてご相談いただくには、企業向け給与前払いをご覧ください。

参考資料

• 労働法第45/2019/QH14号

• 労働法を案内する政令145/2020/NĐ-CP

• 個人データ保護法第91/2025/QH15号

• 個人データ保護法を案内する政令356/2025/NĐ-CP

---

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

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