EWA는 왜 근태, 급여, 은행을 연결해야 할까요?

EWA는 근태, 급여, 은행을 연결해야 합니다. 각 시스템이 임금에 관한 서로 다른 사실을 보유하기 때문입니다. 근태는 수행·승인된 일을, 급여는 기간·단가·정산 규칙을, 은행은 실제 이체 결과를 알려 줍니다. 하나라도 빠지면 이용 가능 금액과 최종 급여가 일치하기 어렵습니다.

세 시스템은 서로 다른 세 질문에 답합니다

EWA는 근로 데이터를 스스로 만들거나 급여 시스템을 대체할 수 없습니다.

시스템	핵심 질문
근태	어떤 날짜·교대의 근무가 완료되고 승인되었는가?
급여	근로 가치, 급여 기간, 최종 정산은 어떻게 결정되는가?
은행	어떤 금액이 실제 이체되었고 최종 상태는 무엇인가?

EWA는 세 영역을 감사 가능한 하나의 체인으로 연결합니다.

근태는 형성된 근로를 확인합니다

근태 데이터가 없으면 실제 근로량을 알 수 없습니다.

최소 데이터는 다음과 같습니다.

• 근로자;
• 근무지;
• 날짜;
• 교대;
• 시간 또는 근무일수;
• 승인 상태;
• 수정 이력.

핵심은 기록된 근무가 곧 승인된 근무는 아니라는 점입니다.

퇴근 기록이 없거나 교대가 잘못됐거나 확인 대기 중일 수 있습니다. 적절한 승인 절차를 거친 데이터만 재무 계산에 사용해야 합니다.

급여는 근태에 없는 맥락을 제공합니다

근태가 8시간을 보여도 다음은 모를 수 있습니다.

• 적용 단가;
• 급여 기간;
• 임금 변경 효력일;
• 단가와 연결된 근무지;
• 정산 규칙;
• 이미 받은 금액의 반영 방식.

이것이 급여 시스템의 역할입니다.

EWA는 이용 가능 금액을 만들기 전에 근로가 올바른 기간과 급여 설정에 속하는지 확인해야 합니다.

EWA의 원칙은 다음과 같습니다.

이용 가능 금액 = (승인 근무일수 × 일 단가) − 기간 내 기수령액 − 회사 규정상 유보액.

근태와 급여 데이터가 같은 계산에서 만나야 합니다.

은행은 돈에 실제로 일어난 일을 확인합니다

지급 요청을 만들었다고 근로자가 돈을 받은 것은 아닙니다.

거래 상태는 다음과 같을 수 있습니다.

• 처리 중;
• 성공;
• 실패;
• 불명확;
• 조사 중.

따라서 EWA 원장은 은행 지급 증빙과 연결돼야 합니다.

요청 전송만으로 ‘수령’ 처리하면 받지 못한 돈이 급여에서 차감될 수 있습니다. 은행은 지급했지만 시스템이 누락하면 같은 금액을 다시 지급할 수 있습니다.

세 시스템은 공통 연결 키를 사용해야 합니다

통합은 단순히 “API가 있다”는 뜻이 아닙니다. 같은 대상을 일관되게 식별해야 합니다.

안정적인 키가 필요한 대상은 다음과 같습니다.

• 근로자;
• 고객 또는 근무지;
• 근태 코드;
• 급여 기간;
• 거래;
• 수취 계좌.

한 사람이 여러 곳에서 근무하면 이름만으로 매칭할 때 근무와 단가가 섞일 수 있습니다. 명확한 업무 키와 관리되는 매핑표가 필요합니다.

근태와 은행만 연결하면 어떻게 될까요?

근로 사실과 지급 가능성은 알지만 급여가 없으면 다음을 할 수 없습니다.

• 올바른 기간 식별;
• 올바른 단가 적용;
• 기수령액의 정산 위치 결정;
• 기간 말 중복 지급 방지.

돈은 이동해도 Payroll Integrity는 약합니다.

급여와 은행만 연결하면 어떻게 될까요?

급여는 주기적이지만 EWA는 진행 중인 기간에 형성된 근로를 알아야 합니다.

승인 근로 데이터가 없으면 이용 가능 금액이 실제 근로와 분리된 추정치나 한도가 되어 EWA 본질과 맞지 않습니다.

근태와 급여만 연결하면 어떻게 될까요?

금액은 계산할 수 있지만 은행이 실제 이체한 금액을 확정할 수 없습니다.

다음 작업이 어려워집니다.

• 중복 지급 방지;
• 타임아웃 처리;
• 거래 조사;
• 정확한 기수령 총액 정산.

은행은 실행된 자금 이동의 사실 원천입니다.

데이터 체인은 어떻게 폐쇄형으로 만들어야 할까요?

이상적인 흐름은 다음과 같습니다.

1. 근태 기록;
2. 권한자의 승인;
3. Earned Wage Engine의 적립 임금 계산;
4. Eligibility Engine의 조건 확인;
5. Payment Orchestration의 거래 생성;
6. 은행 처리;
7. 상태 확인;
8. Reconciliation 대조;
9. 급여 시스템의 기수령액 반영;
10. 급여명세서의 정확한 잔액 표시.

모든 지급을 수행한 근로까지 추적할 수 있습니다.

통합에 하나의 기술만 필요한 것은 아닙니다

연결 방식은 다음과 같습니다.

• 파일;
• Google Sheet;
• API;
• 여러 방식의 조합.

중요한 조건은 명확한 스키마, 안정적인 키, 정의된 사실 원천, 타임스탬프, 상태, 중복 방지, 감사 추적, 예외 처리입니다.

멱등성과 감사 기능이 없는 실시간 API가 엄격히 관리되는 배치 파일보다 반드시 낫지는 않습니다.

세 시스템의 데이터가 맞지 않으면 어떻게 해야 할까요?

“그럴듯해 보인다”는 이유로 숫자를 선택하면 안 됩니다.

예:

• 근태는 8시간;
• 급여는 6시간 수신;
• EWA는 8시간 기준 지급.

이 예외는 다음 절차가 필요합니다.

1. 원천 데이터 보존;
2. 승인 버전 확인;
3. 실제 거래 검증;
4. 영향 계산;
5. 추적 가능한 업무 조정;
6. 재대조.

최종 숫자를 수동 변경해 차이를 숨기면 안 됩니다.

각 영역은 누가 책임져야 할까요?

• 운영/고객: 근태 원천;
• HR/Payroll: 기간과 급여 규칙;
• 재무: 거래와 대조;
• IT/Engineering: 통합과 신뢰성;
• Product Operations: EWA 흐름 조정.

RACI는 기업별로 달라도 모든 데이터 원천에는 책임자가 있어야 합니다.

추적해야 할 통합 KPI

• 근태와 근로자 매칭률;
• 적시 승인률;
• 중복 기록 수;
• 동기화 오류 수;
• pending 거래 수;
• 명세서 거래 매칭률;
• 급여 차이 수;
• 예외 처리 시간;
• 매핑 수정 수;
• 완전히 종료된 대조 기간 비율.

목표는 단순히 “API가 작동”하는 것이 아니라 종단 간 데이터가 일치하는 것입니다.

결론

EWA가 근태, 급여, 은행을 연결해야 하는 이유는 어느 한 시스템도 전체 사실을 갖고 있지 않기 때문입니다. 근태는 일을 증명하고, 급여는 올바른 기간과 규칙을 적용하며, 은행은 실제 지급을 확인합니다. 공통 키, 감사 추적, 대조 통제가 있을 때 EWA는 Payroll Integrity를 유지하며 빠르게 운영될 수 있습니다.

작성자: Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

기업용 EWA 상담: Hotline 0937.022.655 · 이메일 info@nhankiet.vn · 기업용 EWA 알아보기