EWAでの誤った計算や誤送金、誤った口座に対する責任は誰にあるのか？

EWAでの誤った計算や誤送金、誤った口座に対する責任は誰にあるのか？

EWAトランザクションでエラーが発生した場合、労働者は通常、金額が正しくないか、まだ受け取っていないという問題しか見えません。しかし、原因は人事記録、タイムカードコード、承認者、計算式、銀行口座、決済システム、照合、または給与計算にある可能性があります。迅速に対応するためには、企業は問題解決の主催者と最終的な法的または財務的責任を負う者を区別する必要があります。

> 要約: すべての問題に対して「プロバイダーに連絡してください」と答えるべきではありません。各状況において真実の源、調査の主催者、修正の承認者、修正期限、事件の終了証拠を特定する必要があります。

> 警告: 本記事のマトリックスは運用の参考フレームワークであり、法的責任、補償、または控除権を自動的に決定するものではありません。最終的な責任は、労働契約、サービス契約、銀行との合意、規則、および適用される法律に依存します。

1. EWAトランザクションにはどのような関係者がいるのか？

モデルによっては、トランザクションには以下が関与する可能性があります：

• 労働者；
• 雇用主または労働力供給ユニット；
• 顧客/労働者が働く場所；
• 監督者またはタイムカード承認者；
• EWAプラットフォームプロバイダー；
• 銀行/決済機関；
• 人事および給与計算；
• 財務–会計；
• カスタマーサポートと情報セキュリティ。

一つの関係者が複数の役割を果たすことがあります。そのため、法的名称だけでなく、活動に基づいてRACIを作成する必要があります。

2. 分けるべき4つの責任

運用責任

誰が受け取り、調査し、更新し、事件を終了まで持っていくのか？

データ責任

誰がデータソースを作成、確認、修正し、その品質に責任を持つのか？

財務責任

誰が差額、返金、回収不能額、または発生した費用を負担するのか？

法的/契約責任

誰が労働者、顧客、銀行、国家機関に対して義務を負うのか？

カスタマーサポート担当者は運用を主催することができますが、補償責任を自ら決定することはできません。

3. 「ワンストップ、複数チーム処理」の原則

労働者は、エラーが人事、銀行、またはソフトウェアにあるかを自分で探す必要はありません。サポートチャネルは以下を行う必要があります：

1. 事件コードを作成する；
2. 安全にリクエスト者を確認する；
3. 最小限のデータを収集する；
4. ケースオーナーを指定する；
5. 背後のチームを調整する；
6. 定期的にステータスを更新する；
7. 結果と証拠をわかりやすく返す；
8. 金銭/給与計算の影響が処理されるまで閉じない。

4. 総合責任マトリックス

(詳細は、EWA契約で確認すべき20の条項と企業における給与前払い（EWA）の規則サンプルを参照。)

エラーポイント	最初の確認ソース	適切な主催者	協力すべき関係者
記録/CCCD	ERP、労働者記録	人事/ニャンキエット	CSKH、技術
タイムカードコード	ソースタイムカード	監督者/顧客	人事、統合
未承認の勤務	承認ポータル/監査ログ	承認者	CSKH、労働者
計算式/制限	設定、計算ログ	プロダクトオーナー/運用	人事、財務
誤った口座	確認証拠	口座運用	労働者、銀行、情報セキュリティ
保留中の取引	コマンドコード、調査	銀行運用	VPBank、技術、CSKH
重複/誤送金	ログ + 明細書	インシデントコマンダー	銀行、法務、財務
給与計算のズレ	ブリッジレポート	給与計算	会計、EWA、人事
データ漏洩	アクセスログ/インシデント	情報セキュリティ/DPO/法務	関係者

公式マトリックスは、ニャンキエットと各顧客の契約に基づいて調整される必要があります。

5. シナリオ1 — 労働者の記録が誤っているまたは不足している

例

CCCDが誤っている、名前が異なる、退職者がまだアクティブ、または新しい従業員が同期されていない。

提案される主催者

人事記録を管理するユニット。給与前払いでは、ERPとCCCDが重要な接続ポイントであるため、修正は権限のあるソースから始める必要があります。

必要な証拠

• ソース記録；
• 同期履歴；
• 識別キー；
• 有効時点；
• 修正ログ；
• 承認者。

複数のシステムで直接修正することなく、再同期メカニズムが欠けている。

6. シナリオ2 — タイムカードが記録されているが勤務が表示されない

考えられる原因

• 同期ジョブが実行されていない；
• タイムカードコードが誤っている；
• レコードがフォーマットエラー；
• 深夜をまたぐシフトが誤ってマッピングされている；
• 別の勤務ソースが真実のソースとして選ばれている；
• 労働者が誤った顧客に紐付けられている。

提案される主催者

最初の確認ステップの結果に応じて、勤務ソースまたは統合のオーナー。ケースオーナーは労働者への更新責任を保持します。

7. シナリオ3 — 勤務が承認されていない

給与前払いは承認された勤務のみを使用して利用可能額を生成します。レコードが保留中の場合、初期責任は通常、顧客/監督者の承認プロセスにあり、銀行ではありません。

確認すべきこと

• 勤務がいつ承認可能になったか；
• 誰が承認権を持っているか；
• 承認者が通知を受け取ったか；
• 代替者がいるか；
• 承認のSLA/OLA；
• 承認後に修正されたか。

データが未承認のまま、単に金銭を得るために「承認を強制」しない。

8. シナリオ4 — 承認された勤務だが利用可能額が誤っている

確認ソース

計算式で再計算：

承認された勤務 × 単価/日 − 期間中に受け取った額 − 予約

その後、丸めと制限を確認します。

提案される主催者

プロダクトオーナー/運用ポリシー、HRと単価管理者と協力します。入力データが誤っている場合、修正アクションを正しいソースに移しますが、ケースオーナーを保持します。

9. シナリオ5 — 銀行口座が確認されない

原因

番号の入力ミス、存在しない口座、名前の不一致、クエリサービスの中断、または人事記録の誤り。

提案される主催者

口座運用チームが受け取り、労働者が情報を確認し、銀行がクエリ状態をサポートし、人事がソースが誤っている場合に記録を修正します。

確認とログがないまま、担当者が受取口座を勝手に変更することを許可しない。

10. シナリオ6 — 金銭がまだ届かず、状態が保留中

(詳細は、給与前払いを引き出したが金銭がまだ届かないを参照。)

保留中の状態は失敗を意味しません。システムはコマンドを送信したが、確実な結果をまだ受け取っていない可能性があります。

提案される主催者

銀行/照合運用。トランザクションコードを保持し、調査し、新しいコードで再送信しない。

事件終了の証拠

• 有効なフィードバックまたは調査結果；
• 明細行；
• 最終状態；
• 利用可能額の処理；
• 労働者への通知。

11. シナリオ7 — システムが成功と報告したが労働者が受け取っていない

手順

1. マスクされた正しい口座を確認する；
2. トランザクションコードとフィードバックを確認する；
3. ソース明細を照合する；
4. 銀行に公式チャネルを通じて調査を依頼する；
5. 労働者に個人チャットで全明細を送信させない；
6. 処理期限を更新する。

「成功」画面だけでチケットを閉じない。

12. シナリオ8 — 重複送金

これは金銭と給与計算に影響を与える可能性があるため、重大なインシデントです。

提案される主催者

指定されたインシデントコマンダー；技術、銀行、財務、給与計算、法務、CSKHと協力します。

アクション

• さらなる発生を防ぐ；
• ログを保護する；
• 範囲を特定する；
• 各コード/金銭行を照合する；
• 合法的な修正方法を統一する；
• 制御された通知を行う；
• RCAと冪等性/ロックの再テスト。

証拠と承認されたプロセスがないまま、重複送金を給与から自動的に控除しない。

13. シナリオ9 — 誤った人または誤った口座への送金

これは記録、口座変更操作、結合エラー、詐欺、またはアクセス制御の問題から発生する可能性があります。

優先アクション

1. 必要に応じて関連フローを停止する；
2. 確認証拠を保護する；
3. 公式チャネルを通じて銀行に連絡する；
4. 各関係者のデータを保護する；
5. エラーのソースを特定する；
6. 契約および法律に基づいて修正/補償計画を立てる；
7. 類似のトランザクションを確認する。

14. シナリオ10 — 支払い後に勤務が減少

(詳細は、企業が給与前払いを返済する方法を参照。)

給与前払いには、既に認識されているリスクのための「回収不能額」帳簿があります。ただし、誰が負担するか、どのように控除されるかはコードでは決定されません。

確認すべきこと

• 勤務修正の理由；
• 誰が前/後に承認したか；
• 支払われた額；
• 最終的な収入；
• 契約/規則；
• 顧客、ニャンキエット、または他の関係者の責任；
• 法務が承認した労働者への対応策。

15. シナリオ11 — 労働者が金銭を受け取った後に退職

人事は新しいリクエストの権限をロックする必要がありますが、保留中のトランザクションは結論を必要とします。給与計算/財務は受け取った額、最終収入、義務、例外を確定します。

アカウントのロックがトランザクションの追跡を失わせたり、正当な調査/苦情の権利を妨げたりしないようにする。

16. シナリオ12 — 明細がシステムと一致しない

確認すべき2つの側面

• システムにあるが明細にない；
• 明細にあるがシステムにない。

提案される主催者

財務/銀行の照合チーム。技術がログをサポートし、銀行が行を確認し、会計が証拠を得た後に記録を決定します。

「一致」報告を作成するために差異を削除しない。

17. シナリオ13 — EWA額が給与計算で誤って計算される

原因

誤った期間、保留中のトランザクションを給与計算に含める、2回控除、返金の見落とし、誤った人または勤務日が重複して計算される。

提案される主催者

給与計算、EWAと会計と協力します。ブリッジレポートは総収入、義務、受け取った額、残額を追跡する必要があります。

18. シナリオ14 — 個人データが不正にアクセスされる

(セキュリティフレームワーク：詳細は、EWA導入時のデータセキュリティとプライバシーを参照。)

情報セキュリティ/データ責任者と法務が対応を主催し、システムチームがログを保護し、権限を回収し、影響を受けたデータ/人を特定します。

違反アカウントを処理して閉じるだけでなく、通知義務、労働者への影響、予防措置を評価する必要があります。

19. 標準フローのRACIサンプル

活動	R	A	C	I
記録更新	人事	HRオーナー	IT	労働者
勤務承認	監督者/顧客	勤務ソースオーナー	人事	労働者
制限設定	運用	サービスオーナー	財務/法務	CSKH
口座確認	運用	サービスオーナー	銀行/情報セキュリティ	労働者
支払い処理	システム/運用	サービスオーナー	VPBank	CSKH
照合	財務	会計責任者	銀行/IT	人事
給与計算	給与計算	給与計算オーナー	EWA/会計	労働者
P1インシデント	インシデントチーム	インシデントコマンダー	法務/銀行	リーダーシップ/顧客

これはサンプルです。「A」は明確な主体である必要があり、複数の人が最終責任を負うことを避けるべきです。

20. 事件の記録に必要なもの

• 事件コードと重大度；
• 適切にマスクされた人/顧客/トランザクション；
• 発見時点；
• 影響の説明；
• データとソース証拠；
• 処理タイムライン；
• 決定と承認者；
• 調整された金額/証憑；
• 送信された通知；
• 終了確認；
• 根本原因；
• 予防措置と期限。

21. よくある質問

金銭がまだ届かない場合、銀行の責任か給与前払いの責任か？

表面的な現象だけでは結論を出せません。コマンドが作成/送信されたか、口座、フィードバック、調査、明細を確認する必要があります。ケースオーナーが結果に向けて調整責任を負います。

勤務が承認されていないのはシステムのエラーか？

必ずしもそうではありません。承認者のプロセスに起因する可能性があります。システムは正しい状態を表示し、OLAに従って通知/エスカレーションする必要があります。

重複送金は給与から控除されるのか？

自動的に行うべきではありません。法務、契約、合意されたプロセス、および具体的な記録が必要です。

労働者が口座番号を誤入力した場合、誰が責任を負うのか？

責任は確認プロセス、表示情報、契約に依存します。給与前払いの標準フローは、このリスクを軽減するために正しい名前を確認します。

最終的な窓口は誰か？

企業はプログラムのサービスオーナーと各事件のケースオーナーを指定するべきです。労働者は1つの受け入れチャネルだけを必要とします。

---

Minh Khang Nguyễn著者: [Do Huy Le] — [Chức vụ], Nhan Kiet Manpower Supply Co., Ltd.

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