일당 선지급 프로세스: 근태 기록부터 수령과 대사까지

일당 선지급 프로세스는 근무 시간이 기록되고 관리자가 승인하면서 시작됩니다. 시스템은 데이터를 동기화하고, 이미 발생한 급여 중 적격 부분을 산정하며, 근로자가 요청을 제출하게 하고, 지급을 실행한 뒤 급여 기간에 대사합니다. 각 거래에는 식별자, 상태, 완전한 로그가 있어야 과지급, 중복 지급, 급여 오류, 또는 근무가 조정될 때의 처리 곤란을 피할 수 있습니다.

일당 선지급은 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 · 기업용 일당 선지급