일당 선지급을 출퇴근 기록, 급여 및 ERP와 통합하려면 어떤 데이터가 필요한가요?

일당 선지급을 출퇴근 기록, 급여 및 ERP와 통합하려면 어떤 데이터가 필요한가요?

일당 선지급을 출퇴근 기록, 급여 및 ERP와 통합하려면 최소 다섯 가지 데이터 그룹이 필요합니다: 직원 프로필, 승인된 근무, 급여 기간 및 규칙, 조정 또는 공제 항목, 조기 급여 수령 거래. 모든 데이터는 통일된 직원 코드, 상태, 업데이트 시점, 데이터 버전 및 추적 로그를 사용해야 합니다. 좋은 아키텍처는 데이터를 빠르게 전송할 뿐만 아니라 중복 지급을 방지하고, 늦게 수정된 데이터를 처리하며, 각 거래를 대조할 수 있어야 합니다.

> 참고: 이 글은 일당 선지급 (Earned Wage Access – 이미 획득한 급여에 대한 접근) 시스템에 대한 참조 아키텍처를 제시합니다. 필드 이름, 상태, 승인 흐름 및 실제 회계 처리는 Nhan Kiet과 기업이 통합 조사 단계에서 확인해야 합니다.

> 용어 설명: 일당 선지급 (이미 수행한 근무에 대한 급여 수령) · HRIS/HRM (인사 정보 시스템) · ERP (기업 자원 계획 시스템) · 급여 (급여 계산) · API (소프트웨어 연결 인터페이스) · 배치 (일괄 처리) · SFTP (보안 파일 전송) · idempotency (중복 방지: 여러 번 전송해도 하나의 결과만 생성) · UAT (사용자 수용 테스트) · go-live (정식 운영 시작) · rollback (되돌리기) · webhook/callback (시스템 간 자동 알림) · token (원본 데이터 대체 코드) · data dictionary (데이터 사전) · system of record (표준 데이터 소스) · retry (재시도) · timeout (시간 초과).

왜 일당 선지급은 출퇴근 기록, 급여 및 ERP와 동시에 연결해야 하나요?

일당 선지급은 근로자가 돈을 수령하기 전에 세 가지 질문에 답해야 합니다:

1. 이 사람이 현재 근무 중이며 프로그램에 속해 있는가?

2. 현재까지 이 사람이 생성한 적격 급여는 얼마인가?

3. 이전 거래와 보류해야 할 항목 이후에 수령 가능한 금액은 얼마인가?

인사 시스템은 보통 신원과 근무 상태를 확인합니다. 출퇴근 기록 시스템은 완료된 근무 시간 또는 시간을 기록합니다. 급여 시스템은 급여 규칙, 급여 기간 및 조정 항목을 관리합니다. ERP 또는 회계 시스템은 기록, 대조 및 결산을 지원합니다. 결제 시스템은 최종 송금 상태를 제공합니다.

하나의 소스만 연결하면 일당 선지급은 근로자를 볼 수 있지만 승인된 근무 시간을 알 수 없거나, 근무 시간을 볼 수 있지만 급여 기간이 잠겼는지 알 수 없거나, 돈을 송금했지만 급여 시스템이 거래를 대조하지 못할 수 있습니다. 따라서 가장 중요한 점은 'API를 연결할 수 있는가'가 아니라, 완료된 근무에서 결산된 거래까지 일관된 데이터 체인을 설정하는 것입니다.

1. 전체 데이터 아키텍처

참조 아키텍처는 다음과 같이 구성될 수 있습니다:

flowchart TD
    A["HRIS: 직원"] --> D["통합 계층"]
    B["출퇴근 기록: 승인된 근무"] --> D
    C["급여: 급여 기간 및 규칙"] --> D
    D --> E["일당 선지급 한도 계산 엔진"]
    E --> F["일당 선지급 애플리케이션"]
    F --> G["결제 시스템"]
    G --> H["급여, ERP 및 회계 대조"]
    H --> E

각 데이터 도메인은 하나의 표준 데이터 소스(system of record)를 가져야 합니다. HRIS, 급여 및 일당 선지급이 동일한 속성을 세 가지 다른 방식으로 수정하지 않도록 해야 합니다.

2. 최소 직원 데이터 목록

'필요할 수 있다'는 이유로 전체 인사 프로필을 동기화하지 않는 것이 좋습니다. 적절한 원칙은 이미 정의된 목적을 위해 필요한 데이터를 정확히 수집하고 전송하는 것입니다.

전체 계좌 번호는 실제로 결제가 필요한 영역에서만 존재해야 하며, 적절히 권한이 부여되고 보호되어야 합니다. 테스트 환경에서는 가상 또는 마스킹된 데이터를 사용하고, 실제 데이터를 복사하지 않아야 합니다.

3. 출퇴근 기록 데이터 및 승인 상태

일당 선지급은 단순히 '월 총 근무 시간'이라는 숫자만 받지 않아야 합니다. 시스템은 어떤 데이터가 확인되었고 어떤 데이터가 변경될 수 있는지 충분히 알아야 합니다.

필요한 필드에는 다음이 포함됩니다:

• employee_id: 통일된 직원 코드;

• work_date: 근무 날짜;

• shift_id: 교대 코드, 기업이 교대 근무를 관리하는 경우;

• regularhours, overtimehours: 정규 근무 시간 및 초과 근무 시간;

• attendance_status: 출석, 휴가, 결근 또는 해당 상태;

• approval_status: 승인 대기, 승인됨, 거부됨, 조정됨 또는 잠금;

• approvedby, approvedat: 정책 요구 시 승인자 및 승인 시점;

• sourceupdatedat, record_version: 기록 시점 및 버전;

• source_system: 데이터가 생성된 시스템.

왜 '승인됨' 상태가 중요한가요?

카드 스와이프 한 번이 유효한 근무를 의미하지 않을 수 있습니다. 직원이 퇴근 체크를 잊거나, 잘못된 교대를 등록하거나, 관리자가 승인한 후 조정이 있을 수 있습니다. 기업은 어떤 상태가 일당 선지급 한도에 포함되는지 명확히 합의해야 합니다 (참조: 승인된 근무란 무엇인가요?).

예시 기록:

{
  "employee_id": "EMP-000123",
  "work_date": "2026-08-18",
  "shift_id": "SHIFT-A",
  "regular_hours": 8,
  "overtime_hours": 0,
  "approval_status": "APPROVED",
  "source_updated_at": "2026-08-19T02:15:30Z",
  "record_version": 3
}

이것은 안전한 데이터 예시일 뿐이며, 일당 선지급의 공식 API 사양이 아닙니다.

4. 급여 데이터 및 조정 항목

급여 데이터는 '승인된 근무'를 '적격 급여 부분'으로 전환하는 데 도움을 줍니다. 데이터 세트에는 보통 다음이 포함됩니다:

• 급여 기간 코드 payperiodid 및 시작, 종료 시간;

• 급여 그룹 및 급여 주기;

• 합의된 공식에 필요한 급여 계산 기준 또는 단가;

• 수입 코드 earning_code;

• 관련 조정, 보류 또는 공제 항목;

• 근무 마감일 및 급여 테이블 잠금 시점;

• 급여 기간 상태: 열림, 처리 중, 잠김 또는 결산됨;

• 통화 단위 및 반올림 규칙;

• 적용된 공식/정책 버전.

급여 명세서의 모든 구성 요소가 일당 선지급 한도에 포함되는 것은 아닙니다. 기본 급여, 수당, 초과 근무, 보너스 또는 커미션은 확실성과 승인 시점이 다릅니다. 기업은 어떤 항목이 포함되고, 어떤 상태에서 계산되며, 어떻게 제한되는지를 명확히 규정해야 합니다.

규칙 표에 포함해야 할 열은 무엇인가요?

이 표의 실제 값은 기업과 구현 단위가 확인해야 합니다. 급여 항목 이름만으로 추측해서는 안 됩니다.

5. 조기 급여 수령 거래 데이터

각 조기 급여 수령 요청은 독립적으로 추적 가능한 거래여야 합니다.

참조 거래 수명 주기는 다음과 같습니다: CREATED → VALIDATING → PROCESSING → SUCCEEDED 또는 FAILED. 결제 결과가 확인되지 않은 경우, 거래는 UNKNOWN 또는 이에 상응하는 상태에 있어야 하며, 자동으로 실패로 간주하고 다시 송금해서는 안 됩니다. 시스템은 거래 반환 및 대조가 발생할 때 필요한 상태도 필요합니다.

6. API, 파일 배치 또는 수동 동기화 선택?

모든 기업에 적합한 방법은 없습니다. 각 시스템의 성숙도에 따라 여러 방법을 결합할 수 있습니다.

HTTP API를 사용하는 경우, 기업은 OpenAPI Specification을 사용하여 통합 계약을 설명할 수 있습니다. 이는 엔드포인트, 데이터 구조 및 응답을 양측이 합의할 수 있도록 합니다. OpenAPI는 HTTP API를 설명하는 표준이며, 이는 기술적으로 유용한 선택이지, 일당 선지급 구현의 필수 조건은 아닙니다.

7. 식별 및 중복 데이터 방지

잘못된 식별은 가장 위험한 위험 중 하나입니다. 이메일, 전화번호 또는 계좌번호는 변경될 수 있으므로 주요 직원 키로 적합하지 않습니다.

권장 사항:

• employee_id를 기업 내에서 불변으로 사용;

• 여러 단위를 지원하는 플랫폼의 경우 employerid 또는 legalentity_id와 결합;

• 퇴직자의 코드를 신규 직원에게 재사용하지 않음;

• HRIS와 급여가 서로 다른 코드 세트를 사용하는 경우 매핑 테이블 유지;

• 급여 그룹, 부서 및 근무 상태 변경에 대한 유효 날짜 기록;

• 비즈니스 키에 따라 중복 검사, 동일한 내용에만 의존하지 않음.

파일 배치의 경우, 각 파일에는 배치 코드, 생성 시점, 총 기록 수 및 체크섬이 있어야 합니다. API의 경우, 각 거래 생성 요청에는 idempotency_key가 있어야 합니다.

8. Idempotency와 대조: 서로 다른 두 가지 보호 계층

Idempotency는 동일한 요청이 여러 번 전송되더라도 하나의 비즈니스 결과만 생성되도록 합니다. 예를 들어, 애플리케이션이 송금 명령을 보낸 후 시간 초과가 발생한 경우, 동일한 idempotency_key로 다시 전송하면 시스템은 이전 거래 또는 그 상태를 반환해야 하며, 추가 송금을 생성해서는 안 됩니다.

대조는 여러 시스템이 동일한 거래를 기록했는지 확인합니다 (참조: 출퇴근 기록에서 대조까지의 일당 선지급 프로세스). 적절한 모델은 삼자 대조입니다:

1. 일당 선지급 플랫폼 내 거래;

2. 은행 또는 결제 단위의 결과;

3. 승인된 급여/ERP 데이터 또는 결산 기록.

대조 보고서는 최소한 다음을 지적해야 합니다:

• 완전히 일치하는 거래;

• 일당 선지급에 있지만 결제 결과가 없는 경우;

• 결제 결과가 있지만 급여/ERP에 없는 경우;

• 금액, 수수료, 수령인 또는 급여 기간 불일치;

• 반환된 거래가 업데이트되지 않은 경우;

• 중복 기록 또는 잘못된 순서로 업데이트된 경우.

각 차이점에는 담당자, 처리 상태 및 오류 종료 증거가 필요합니다.

9. 오류 처리, 재시도 및 경고

모든 오류가 자동으로 재시도되어야 하는 것은 아닙니다.

모든 요청에는 시스템 간 추적을 위한 correlation_id가 있어야 합니다. 경고에는 거래 코드, 오류 유형, 시점, 소스 시스템 및 다음 처리 단계가 포함되어야 하며, 비밀번호, API 키 또는 민감한 데이터 전체를 로그에 포함해서는 안 됩니다.

10. API 요청 예시

{
  "idempotency_key": "ewa-demo-20260818-0001",
  "employee_id": "EMP-000123",
  "pay_period_id": "2026-08",
  "requested_amount": 1000000,
  "currency": "VND",
  "source_data_version": "attendance-v18_payroll-v6",
  "requested_at": "2026-08-18T09:20:00+07:00"
}

응답은 요청이 수락되었는지, 거부되었는지, 추가 처리가 필요한지를 알려야 하며, 동시에 transactionid, 상태, 이유 코드 및 correlationid를 반환해야 합니다. 전체 계좌 정보나 불필요한 정보를 반환해서는 안 됩니다.

API 사양은 다음을 명확히 규정해야 합니다:

• 인증 및 권한 부여 방법;

• API 버전 및 변경 정책;

• 날짜 및 시간 형식, 시간대 및 통화 단위;

• 금액의 정확도 및 반올림 규칙;

• 오류 코드 목록;

• 시간 초과 및 재시도 정책;

• 콜백 또는 웹훅 서명/검증;

• 부하 제한;

• idempotency 규칙;

• 상태 및 로그 보존 기간.

11. 설계 단계에서부터 보안 및 데이터 보호

직원 데이터, 급여, 수령 계좌 및 거래 기록은 높은 민감도를 가집니다. 통합 설계에는 다음이 포함되어야 합니다:

• 역할 기반 권한 부여 및 최소 권한 원칙;

• 데이터 전송 및 저장 시 암호화;

• 중앙 집중식 비밀 관리, 소스 코드 또는 로그에 접근 키 저장 금지;

• 개발, 테스트 및 생산 환경 분리;

• 가상 또는 마스킹된 테스트 데이터;

• 접근 및 구성 변경 로그;

• 저장 기간, 삭제 절차 및 데이터 주체 요청 처리;

• 공급업체 평가 및 데이터 공유 범위;

• 사고 대응, 알림 및 조사 계획.

베트남에서는 설계 및 운영이 2026년 1월 1일부터 시행되는 개인 데이터 보호법 제91/2025/QH15 및 시행령 356/2025/NĐ-CP에 따라 법무 부서의 검토를 받아야 합니다. 또한, 전자 거래법 2023 및 관련 전문 규정의 틀 내에서 기록, 메시지 및 전자 문서도 검토되어야 합니다.

12. 정식 운영 전 UAT 체크리스트

UAT는 '파일을 받았다'거나 'API가 200을 반환했다'는 것만 확인해서는 안 됩니다 (일당 선지급 90일 파일럿 계획에 포함). 충분한 비즈니스 시나리오와 운영 오류를 테스트해야 합니다.

직원 및 참여 조건

• [ ] 근무 중이며 자격이 있는 직원.

• [ ] 유효 날짜가 도래하지 않은 신규 직원.

• [ ] 휴직 중이거나 퇴직한 직원.

• [ ] 법인, 급여 그룹 또는 직원 코드가 변경된 직원.

• [ ] 올바른 확인 절차에 따라 수령 계좌 변경.

출퇴근 기록 및 한도

• [ ] 정책이 승인된 근무를 요구하는 경우, 승인 대기 중인 근무는 계산되지 않음.

• [ ] 승인된 근무가 한도를 정확히 변경함.

• [ ] 승인 후 수정되거나 회수된 근무가 올바르게 재계산됨.

• [ ] 최신 데이터 이후에 도착한 오래된 데이터가 잘못된 버전을 덮어쓰지 않음.

• [ ] 근무 마감일, 시간대 및 야간 교대가 올바르게 처리됨.

거래 및 결제

• [ ] 동일한 idempotency_key로 반복 전송 시 두 개의 거래가 생성되지 않음.

• [ ] 한도가 부족한 경우 정확한 이유 반환.

• [ ] 결제 시스템 시간 초과 및 결과 불확실이 두 번째 송금을 유발하지 않음.

• [ ] 실패한 거래, 반환 및 상태 전환이 올바르게 업데이트됨.

• [ ] 거래 전후 한도가 거래 기록과 일치함.

파일 배치 및 API

• [ ] 중복 파일, 잘못된 순서의 파일 및 중복 기록이 감지됨.

• [ ] 일부 기록 오류가 처리된 기록을 잃지 않음.

• [ ] API 인증 만료, 권한 부족 및 부하 제한 초과 시 올바른 오류 반환.

• [ ] 위조된 콜백 또는 잘못된 서명이 거부됨.

• [ ] 재시도가 제한을 준수하고 중복 방지 키를 유지함.

급여, ERP 및 대조

• [ ] 열림, 잠김 및 결산된 급여 기간이 올바르게 처리됨.

• [ ] 일당 선지급 거래가 승인된 절차에 따라 급여 기간 대조 기록에 포함됨.

• [ ] 일당 선지급 – 결제 – 급여/ERP의 세 가지 소스가 금액 및 상태와 일치함.

• [ ] 차이점이 경고를 생성하고 종료될 때까지 처리 흐름이 있음.

• [ ] 보고서가 회계 기록에서 거래 및 소스 데이터로 추적 가능함.

보안 및 운영

• [ ] 권한이 없는 사람이 데이터를 보거나 수정할 수 없음.

• [ ] 로그에 비밀 또는 민감한 데이터 전체가 포함되지 않음.

• [ ] 접근 키가 장기 중단 없이 교체 가능함.

• [ ] 담당자, 경고 채널 및 사고 처리 절차가 있음.

• [ ] 정식 운영 시 심각한 오류가 발생할 경우 되돌리기 계획이 있음.

13. 양측이 구현 전에 확정해야 할 기술 문서

최소한의 통합 문서에는 다음이 포함되어야 합니다:

1. 아키텍처 다이어그램 및 책임 경계;

2. 각 필드에 대한 데이터 사전;

3. 직원 코드, 급여 기간, 부서 및 항목 코드 매핑 테이블;

4. API 사양 또는 파일 사양;

5. 상태 및 오류 코드 목록;

6. 승인된 한도 계산 규칙;

7. 중복 방지, 재시도 및 늦게 도착한 데이터 처리 규칙;

8. 대조 흐름 및 차이 보고서 샘플;

9. 권한 매트릭스 및 보안 요구 사항;

10. UAT, 전환, 되돌리기 및 정식 운영 후 지원 계획.

양측은 데이터 계약 테스트도 수행해야 합니다. 시스템이 필드 이름, 데이터 유형, 상태 목록 또는 비즈니스 의미를 변경할 때, 파이프라인은 생산 환경 외부에서 한도 오류를 유발하기 전에 경고해야 합니다.

<!-- NHAN KIET 완료 대기 섹션 (게시 시 숨김) — 실제 통합 역량을 반영하기 위해 Product/IT 데이터 확인 필요; 파트너/SLA/기능 이름은 문서가 없을 때 공개하지 않음.
## 14. 공식 버전 게시 전에 Nhan Kiet이 보완해야 할 데이터

일당 선지급의 실제 역량을 반영하기 위해 Product/IT 팀은 다음을 확인해야 합니다:

• 지원 중인 출퇴근 기록, 급여 또는 ERP 시스템;

• 현재 사용 가능한 통합 방법: API, SFTP, 파일 샘플 또는 기타 방법;

• 실제 동기화 주기 및 서비스 약정;

• 공개 가능한 엔드포인트, 데이터 필드, 상태 및 오류 코드 목록;

• 사용 중인 인증, idempotency, 웹훅 및 대조 메커니즘;

• 불확실한 결과, 실패 및 반환 거래 처리 흐름;

• 한도 계산 규칙 및 적격 급여 구성 요소;

• 개인 데이터를 제거한 기술 보고서 샘플;

• Nhan Kiet, 기업 및 결제 파트너의 책임;

• 통합 문서 및 UAT 지원 접수 담당자.

파트너 이름, 처리 시간, SLA 또는 기술 기능은 문서로 확인되지 않은 경우 공개하지 않아야 합니다.

-->

자주 묻는 질문

일당 선지급은 실시간 통합이 필수인가요?

아닙니다. 기업은 실시간 API, 일정에 따른 파일 배치 또는 파일럿에서 통제된 수동 프로세스를 사용할 수 있습니다. 빈도는 한도 계산 방식, 데이터 변경 속도 및 소스 시스템의 운영 능력에 맞춰야 합니다.

출퇴근 기록 데이터만으로 일당 선지급 한도를 계산할 수 있나요?

일반적으로는 충분하지 않습니다. 직원 상태, 급여 기간, 급여 계산 규칙, 관련 조정 항목 및 일당 선지급 거래 기록이 추가로 필요합니다. 기록된 근무도 명확한 승인 상태가 필요합니다.

왜 동일한 직원 코드를 사용해야 하나요?

통일된 식별자는 한 사람의 근무, 급여 또는 거래가 다른 사람에게 연결되는 것을 방지합니다. 시스템이 서로 다른 코드를 사용하는 경우, 기업은 통제된 매핑 테이블과 유효 날짜가 필요합니다.

Idempotency는 거래 중복 검사와 같은가요?

관련이 있지만 완전히 같지는 않습니다. Idempotency는 동일한 요청을 다시 보내도 새로운 비즈니스 결과를 생성하지 않도록 보장합니다. 중복 검사는 다른 비즈니스 키를 사용하여 다른 코드지만 실제로는 동일한 거래인 두 요청을 감지할 수 있습니다.

송금 명령이 시간 초과되었을 때, 즉시 다시 보내야 하나요?

이전 명령의 결과를 확인하기 전에는 새로운 송금 명령을 보내지 않아야 합니다. 시스템은 불확실한 상태를 유지하고 참조 코드로 조회하며, 이중 지급을 방지하기 위해 미리 정의된 절차에 따라 다음 단계를 처리해야 합니다.

일당 선지급 대조는 누가 책임지나요?

책임은 운영 매트릭스에 규정되어야 합니다. 일반적으로 일당 선지급 운영 단위, 급여, 회계/재무, IT 및 결제 파트너가 참여합니다. 각 차이 유형에는 특정 소유자가 필요합니다.

결론

일당 선지급 통합은 출퇴근 기록 파일을 가져와 백분율을 계산하는 것이 아닙니다. 신뢰할 수 있는 시스템은 직원 데이터, 승인된 근무, 급여 규칙 및 거래가 통일된 식별자로 연결되어야 하며, 데이터 버전, idempotency, 결제 상태, 대조 및 오류 처리 절차가 있어야 합니다.

기업이 현재 출퇴근 기록, 급여 또는 ERP 시스템과 일당 선지급 연결 가능성을 평가하고 있다면, 시스템 다이어그램, 개인 데이터를 숨긴 데이터 사전 및 지원이 필요한 비즈니스 시나리오를 준비한 후 기업을 위한 일당 선지급을 참조하여 기술 통합 문서 및 적합한 파일럿 범위에 대해 논의하십시오.

참고 자료

• OpenAPI Initiative – OpenAPI Specification

• GitHub의 OpenAPI Specification

• 개인 데이터 보호법 제91/2025/QH15

• 개인 데이터 보호법 시행령 356/2025/NĐ-CP

• 전자 거래법 제20/2023/QH15

---
저자: Ngô Nhã Kỳ - 편집자, Nhan Kiet Manpower Supply Co., Ltd.

기업을 위한 일당 선지급 솔루션 상담: 핫라인 0937.022.655 · 이메일 info@nhankiet.vn · 기업을 위한 일당 선지급