EWA 오류 시 책임은 누구에게 있는가?

EWA 오류 시 책임은 누구에게 있는가?

EWA 거래에 오류가 발생하면 근로자는 보통 돈이 맞지 않거나 아직 입금되지 않았다는 문제만 인식합니다. 그러나 원인은 인사 기록, 출근 코드, 승인자, 공식, 은행 계좌, 결제 시스템, 대조 또는 급여에 있을 수 있습니다. 신속한 처리를 위해 기업은 문제 해결 주체와 최종 법적 또는 재정적 책임자를 구분해야 합니다.

> 간단히 말해: 모든 문제를 "공급업체에 문의하세요"라는 답변으로 해결하지 마십시오. 각 상황에 대해 사실의 출처, 조사 주체, 수정 승인자, 해결 기한 및 사건 종료 증거를 명확히 해야 합니다.

> 경고: 이 글의 매트릭스는 운영 참고용이며, 법적 책임, 보상 또는 공제 권한을 결정하지 않습니다. 최종 책임은 근로 계약, 서비스 계약, 은행과의 합의, 규정 및 적용 법률에 따라 다릅니다.

1. EWA 거래에 참여하는 주체는 누구인가?

모델에 따라 거래에는 다음이 포함될 수 있습니다:

• 근로자;
• 고용주 또는 인력 공급업체;
• 고객/근로자가 일하는 장소;
• 감독자 또는 출근 승인자;
• EWA 플랫폼 공급업체;
• 은행/결제 기관;
• HR 및 급여;
• 재무–회계;
• 고객 서비스 및 정보 보안.

한 주체가 여러 역할을 수행할 수 있습니다. 따라서 법인 이름뿐만 아니라 활동에 따라 RACI를 설정해야 합니다.

2. 네 가지 책임 유형

운영 책임

누가 사건을 접수하고 조사하며 업데이트하고 종료까지 이끄는가?

데이터 책임

누가 데이터를 생성, 확인, 수정하며 데이터 출처의 품질에 책임을 지는가?

재정 책임

누가 차액, 환불, 회수 불가 금액 또는 발생 비용을 부담하는가?

법적/계약 책임

누가 근로자, 고객, 은행 및 국가 기관에 대한 의무를 지는가?

고객 서비스 담당자는 운영을 주도할 수 있지만 보상 책임을 독자적으로 결정할 수 없습니다.

3. "원스톱, 다중 팀 처리" 원칙

근로자가 HR, 은행 또는 소프트웨어의 오류를 직접 찾아야 할 필요는 없습니다. 지원 채널은 다음을 수행해야 합니다:

1. 사건 번호 생성;
2. 요청자의 안전한 신원 확인;
3. 최소 데이터 수집;
4. 사건 소유자 지정;
5. 후속 팀과의 협력;
6. 주기적인 상태 업데이트;
7. 이해하기 쉬운 결과 및 증거 제공;
8. 금전/급여 영향이 처리될 때까지 사건을 종료하지 않음.

4. 일반적인 책임 매트릭스

(더 보기: EWA 계약에서 확인해야 할 20가지 조항 및 기업의 일당 선지급(EWA) 규정 샘플.)

오류 지점	첫 번째 검사 출처	적합한 주체	협력해야 할 주체
인사 기록/주민등록증	ERP, 근로자 기록	HR/인력 공급업체	고객 서비스, 기술
출근 코드	원본 출근표	감독자/고객	HR, 통합
승인되지 않은 출근	승인 포털/감사 로그	승인자	고객 서비스, 근로자
공식/한도	설정, 계산 로그	제품/운영 책임자	HR, 재무
잘못된 계좌	확인 증거	계좌 운영	근로자, 은행, 정보 보안
보류 중인 거래	명령 코드, 조사	은행 운영	VPBank, 기술, 고객 서비스
중복/잘못된 사람에게 지급	로그 + 명세서	사건 지휘관	은행, 법무, 재무
급여 불일치	연결 보고서	급여	회계, EWA, HR
데이터 유출	접근/사고 로그	정보 보안/DPO/법무	관련 주체

공식 매트릭스는 인력 공급업체와 각 고객의 계약에 따라 조정되어야 합니다.

5. 상황 1 — 근로자 기록 오류 또는 누락

예시

잘못된 주민등록증, 다른 이름, 퇴사자가 여전히 활동 중이거나 신규 근로자가 동기화되지 않음.

제안된 주체

인사 기록 관리 부서. 일당 선지급에서는 ERP와 주민등록증이 중요한 연결 지점이므로 수리는 권한 있는 출처에서 시작해야 합니다.

필요한 증거

• 원본 기록;
• 동기화 이력;
• 식별 키;
• 유효 시점;
• 수정 로그;
• 승인자.

여러 시스템에서 직접 수정하지 말고 동기화 메커니즘을 유지해야 합니다.

6. 상황 2 — 출근 기록이 있지만 출근이 보이지 않음

가능한 원인

• 동기화 작업이 실행되지 않음;
• 잘못된 출근 코드;
• 형식 오류가 있는 기록;
• 자정 이후 교대가 잘못 매핑됨;
• 다른 출근 출처가 사실의 출처로 선택됨;
• 근로자가 잘못된 고객에 연결됨.

제안된 주체

출근 출처 소유자 또는 통합 담당자, 첫 번째 검사 결과에 따라 다름. 사건 소유자는 여전히 근로자에게 업데이트할 책임이 있습니다.

7. 상황 3 — 출근이 승인되지 않음

일당 선지급은 승인된 출근만을 사용하여 가용 금액을 생성합니다. 기록이 대기 중인 경우 초기 책임은 보통 고객/감독자의 승인 절차에 있으며, 은행이 아닙니다.

확인해야 할 사항

• 출근이 언제 승인 준비가 되었는가;
• 누가 승인 권한을 가지고 있는가;
• 승인자가 알림을 받았는가;
• 대체자가 있는가;
• 출근 승인 SLA/OLA;
• 승인 후 수정되었는가.

데이터가 준비되지 않은 상태에서 단지 돈을 위해 "승인 강요"하지 마십시오.

8. 상황 4 — 승인된 출근이 있지만 가용 금액이 잘못됨

검사 출처

공식을 사용하여 다시 계산:

승인된 출근 × 일일 단가 − 기간 내 수령 금액 − 예약

그런 다음 반올림 및 한도를 확인합니다.

제안된 주체

제품/운영 정책 책임자, HR 및 단가 관리자와 협력. 입력 데이터가 잘못된 경우, 수정 작업을 올바른 출처로 전환하지만 여전히 사건 소유자를 유지합니다.

9. 상황 5 — 은행 계좌가 인증되지 않음

원인

잘못된 번호 입력, 존재하지 않는 계좌, 이름 불일치, 조회 서비스 중단 또는 잘못된 인사 기록.

제안된 주체

계좌 운영 팀이 접수; 근로자가 정보를 확인; 은행이 조회 상태 지원; HR이 출처가 잘못된 경우 기록 수정.

직원이 확인 및 로그 없이 수령 계좌를 임의로 변경하지 않도록 합니다.

10. 상황 6 — 돈이 아직 입금되지 않고 대기 중 상태

(더 보기: 일당 선지급을 요청했지만 돈이 아직 입금되지 않음.)

대기 상태는 실패를 의미하지 않습니다. 시스템이 명령을 보냈지만 아직 확실한 결과를 받지 못했을 수 있습니다.

제안된 주체

은행/대조 운영. 거래 코드를 유지하고 조사하며 새로운 코드로 다시 보내지 마십시오.

사건 종료 증거

• 유효한 응답 또는 조회 결과;
• 명세서 라인;
• 최종 상태;
• 가용 금액 처리;
• 근로자에게 알림.

11. 상황 7 — 시스템은 성공을 보고하지만 근로자는 수령하지 않았다고 주장

단계

1. 올바른 계좌가 가려졌는지 확인;
2. 거래 코드 및 응답 확인;
3. 출처 명세서 대조;
4. 공식 채널을 통해 은행에 조사 요청;
5. 근로자에게 개인 채팅으로 전체 명세서를 보내도록 요구하지 않음;
6. 처리 기한 업데이트.

"성공" 화면만으로 티켓을 종료하지 마십시오.

12. 상황 8 — 중복 지급

이는 돈과 급여에 영향을 미칠 수 있는 심각한 문제입니다.

제안된 주체

지정된 사건 지휘관; 기술, 은행, 재무, 급여, 법무 및 고객 서비스와 협력.

조치

• 추가 발생 방지;
• 로그 보존;
• 범위 확인;
• 각 코드/금액 대조;
• 합법적인 해결 방법 합의;
• 통제된 알림;
• RCA 및 idempotency/locking 재검토.

근거와 승인된 절차 없이 중복 지급 금액을 급여에서 자동으로 공제하지 마십시오.

13. 상황 9 — 잘못된 사람 또는 잘못된 계좌로 이체

이는 기록, 계좌 변경 작업, 결합 오류, 사기 또는 접근 제어 문제에서 발생할 수 있습니다.

우선 조치

1. 필요한 경우 관련 흐름 중지;
2. 확인 증거 보존;
3. 공식 채널을 통해 은행에 연락;
4. 각 주체의 데이터 보호;
5. 오류 출처 확인;
6. 계약 및 법률에 따른 해결/보상 계획 수립;
7. 유사 거래 점검.

14. 상황 10 — 지급 후 출근이 감소

(더 보기: 기업이 일당 선지급을 반환하는 방법.)

일당 선지급에는 이미 인식된 위험 사례에 대한 "회수 불가 금액" 기록이 있습니다. 그러나 누가 부담하고 어떻게 공제할지는 코드로 결정되지 않습니다.

확인해야 할 사항

• 출근 수정 이유;
• 승인자 전/후;
• 지급된 금액;
• 최종 소득;
• 계약/규정;
• 고객, 인력 공급업체 또는 다른 주체의 책임;
• 법무 승인된 근로자 대책.

15. 상황 11 — 근로자가 돈을 받은 후 퇴사

HR은 새로운 요청 권한을 차단해야 하지만 대기 중인 거래는 여전히 결론이 필요합니다. 급여/재무는 수령 금액, 최종 소득, 의무 및 예외를 확정합니다.

계좌 차단이 거래 추적을 방해하거나 합리적인 조회/불만 권리를 방해하지 않도록 합니다.

16. 상황 12 — 명세서가 시스템과 일치하지 않음

두 가지 방향으로 확인해야 함

• 시스템에 있지만 명세서에 없음;
• 명세서에 있지만 시스템에 없음.

제안된 주체

재무/은행 대조 팀. 기술은 로그 지원; 은행은 라인 확인; 회계는 증거 확보 후 기록 결정.

차이를 삭제하여 "일치" 보고서를 만들지 마십시오.

17. 상황 13 — 급여에서 EWA 금액이 잘못 계산됨

원인

잘못된 기간, 대기 중인 거래를 급여에 포함, 두 번 공제, 환불 누락, 잘못된 사람 또는 이미 포함된 출근일이 다시 추가됨.

제안된 주체

급여, EWA 및 회계와 협력. 연결 보고서는 총 소득, 의무, 수령 금액 및 남은 금액을 추적할 수 있어야 합니다.

18. 상황 14 — 개인 데이터가 잘못된 범위로 접근됨

(보안 프레임워크: EWA 도입 시 데이터 보안 및 개인정보 보호 참조.)

정보 보안/데이터 책임자 및 법무가 대응을 주도; 시스템 팀은 로그 보존, 권한 회수 및 영향을 받은 데이터/사람 식별.

위반 계정을 처리하고 종료하는 것만으로는 충분하지 않으며, 근로자에게 알림 의무, 영향 및 예방 조치를 평가해야 합니다.

19. 표준 흐름에 대한 RACI 샘플

활동	R	A	C	I
기록 업데이트	HR	HR 소유자	IT	근로자
출근 승인	감독자/고객	출근 출처 소유자	HR	근로자
한도 설정	운영	서비스 소유자	재무/법무	고객 서비스
계좌 확인	운영	서비스 소유자	은행/정보 보안	근로자
지급 명령 처리	시스템/운영	서비스 소유자	VPBank	고객 서비스
대조	재무	회계 책임자	은행/IT	HR
급여	급여	급여 소유자	EWA/회계	근로자
P1 사고	사건 팀	사건 지휘관	법무/은행	리더십/고객

이것은 샘플일 뿐입니다. "A"는 명확한 주체여야 하며, 여러 사람이 최종 책임을 지지 않도록 해야 합니다.

20. 사건 기록에 포함되어야 할 사항

• 사건 번호 및 심각도;
• 적절히 가려진 사람/고객/거래;
• 발견 시점;
• 영향 설명;
• 데이터 및 출처 증거;
• 처리 타임라인;
• 결정 및 승인자;
• 조정된 금액/증빙;
• 발송된 알림;
• 종료 확인;
• 근본 원인;
• 예방 조치 및 기한.

21. 자주 묻는 질문

돈이 아직 입금되지 않았다면 은행의 잘못인가, 일당 선지급의 잘못인가?

표현만으로는 결론을 내릴 수 없습니다. 명령이 생성/전송되었는지, 계좌, 응답, 조사 및 명세서를 확인해야 합니다. 사건 소유자가 결과까지 조정을 책임집니다.

출근이 승인되지 않은 것은 시스템 오류인가?

반드시 그렇지는 않습니다. 승인자의 절차에 속할 수 있으며, 시스템은 올바른 상태를 표시하고 OLA에 따라 알림/에스컬레이션해야 합니다.

중복 지급은 급여에서 공제될 수 있는가?

자동으로 하지 않는 것이 좋습니다. 법무, 계약, 합법적인 동의/절차 및 구체적인 기록이 필요합니다.

근로자가 잘못된 계좌 번호를 입력했다면 누구의 책임인가?

책임은 확인 절차, 표시 정보 및 계약에 따라 다릅니다. 일당 선지급의 표준 흐름은 이 위험을 줄이기 위해 실제 이름을 조회합니다.

최종 책임자는 누구인가?

기업은 프로그램에 대한 서비스 소유자와 각 사건에 대한 사건 소유자를 지정해야 하며, 근로자는 단일 접수 채널만 필요합니다.

---

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 · 기업을 위한 일당 선지급