EWA에서 Settlement와 Reconciliation은 어떻게 다른가?

Settlement와 Reconciliation은 서로 관련되지만 목적이 다른 계층입니다. EWA 구조에서 Settlement는 거래 또는 정산 기간의 재무 결과를 완료하고 기록하며, Reconciliation은 독립된 출처를 비교해 근무 기록, 은행 거래와 급여 시스템이 같은 결과를 기록했는지 확인합니다.

먼저: 둘 다 돈과 관련되지만 서로 다른 질문에 답한다

두 용어는 거래가 생성된 뒤 등장하기 때문에 종종 같은 뜻으로 사용됩니다.

그러나 다음과 같이 분명히 나눌 수 있습니다.

• Settlement: “이 금전 의무를 최종적으로 어떻게 완료하고 기록하는가?”
• Reconciliation: “독립된 시스템들이 같은 결과를 기록하고 있는가?”

두 업무를 합치면 시스템이 독립 대사를 수행하지 않은 채 “기록이 끝났으므로 정확하다”고 간주할 수 있습니다.

이 글에서 Settlement는 무엇을 의미하는가?

“Settlement”라는 용어는 은행, 결제 게이트웨이와 급여 시스템에서 서로 다르게 쓰일 수 있습니다.

이 글에서 Settlement는 거래 또는 업무 기간의 최종 재무 결과를 확정하는 단계를 뜻합니다.

EWA 거래의 예는 다음과 같습니다.

• 신청이 생성됨
• 은행이 결과를 확인함
• 시스템이 실제 지급액을 확정함
• 거래 원장이 수령액을 기록함
• 남은 임금이 갱신됨

급여 기간 수준에서 Settlement는 다음도 포함합니다.

• 확인된 EWA 지급액 집계
• 정확한 총액을 급여 시스템에 반영
• 해당 기간에 지급할 잔액 확정
• 완료된 의무 마감

따라서 Settlement는 금전 의무의 완료에 초점을 둡니다.

Reconciliation은 무엇을 의미하는가?

Reconciliation은 두 개 이상의 독립된 데이터 출처를 비교해 일치 여부를 확인하는 과정입니다.

예를 들면:

• EWA 원장에 500,000 VND 지급으로 기록됨
• 은행 명세에도 해당 거래가 있어야 함
• 기간 말 급여에 이미 받은 금액이 정확히 반영되어야 함
• 급여명세서에서 두 번 차감하면 안 됨

출처가 일치하면 거래 또는 기간이 대사 완료로 간주됩니다.

일치하지 않으면 차이를 예외 대기열에 넣어야 합니다.

Reconciliation은 거래를 만들지 않으며 보고서를 맞추기 위해 숫자를 임의로 수정해서도 안 됩니다.

Settlement와 Reconciliation 비교표

기준	Settlement	Reconciliation
핵심 질문	금전 의무가 어떻게 완료되었는가?	원장들이 서로 일치하는가?
시점	거래 수명주기 중/후 또는 기간 말	여러 출처의 데이터가 준비된 후
주요 데이터	거래 상태, 금액, 기간	EWA 원장, 은행, 급여
결과	지급/정산/잔액	일치 또는 예외
거래 생성 여부	거래 완료에 관여할 수 있음	아니요
차이 발견 여부	가능하지만 주된 목적은 아님	예, 주된 목적임
기간 마감 여부	의무 마감에 참여할 수 있음	마감 전 데이터를 확인함
불명확한 경우	적절한 상태 유지	예외/조사로 전환

두 계층은 연결되어야 하지만 서로를 대신할 수 없습니다.

거래는 Settlement를 어떻게 거치는가?

일반적인 흐름은 다음과 같습니다.

1. 신청이 조건을 충족함
2. Payment Orchestration이 거래를 생성함
3. 은행이 처리함
4. 최종 상태를 확정함
5. 성공한 거래를 “수령” 원장에 기록함
6. 관련 가치를 재사용하지 못하도록 잠금
7. 거래 의무를 완료로 간주함

은행 상태가 불확실하면 Settlement가 임의로 결론을 내려서는 안 됩니다.

여기에는 실패 시 차단 원칙이 적용됩니다. 결과가 불명확하면 성공 또는 실패로 마감하지 않습니다.

거래는 Reconciliation을 어떻게 거치는가?

독립 데이터가 준비되면 시스템은 다음을 비교합니다.

1. 내부 거래 ID
2. 은행 코드 또는 참조번호
3. 금액
4. 수령인
5. 시간
6. 상태
7. 급여 기간
8. 급여에 반영된 금액

모두 일치하면 거래를 대사 성공으로 표시할 수 있습니다.

한 필드라도 다르면 시스템은 예외를 생성합니다.

중요한 점은 Reconciliation이 독립된 출처로 시스템에 기록된 결과를 검증한다는 것입니다.

API 응답만으로 대사라고 할 수 없는 이유는 무엇인가?

은행 API는 처리 시점에 “success”를 반환할 수 있습니다.

이는 중요한 신호지만 재무 시스템에는 이후 독립 대사 계층이 필요합니다.

그 이유는 다음과 같습니다.

• 실시간 응답이 오류이거나 유실될 수 있음
• 내부 시스템이 잘못된 상태를 기록할 수 있음
• 거래가 두 번 기록될 수 있음
• 명세에 내부 시스템이 놓친 거래가 나타날 수 있음
• 급여 시스템이 잘못된 기간을 사용할 수 있음

Reconciliation은 최종 검증을 제공합니다.

기간 말 Settlement와 개별 거래 Settlement는 어떻게 다른가?

두 수준이 있을 수 있습니다.

거래 수준

특정 지급이 이루어졌는지, 금액이 얼마인지 확정하고 거래 원장에 기록합니다.

급여 기간 수준

해당 기간의 모든 거래를 집계하고 다음을 확정합니다.

• 이미 받은 총액
• 환불 또는 조정액
• 급여에 반영할 금액
• 남은 급여

두 수준 모두 추적 가능한 데이터가 필요합니다.

“숫자를 맞도록 수정하는 대사”가 위험한 이유는 무엇인가?

두 원장이 다를 때 담당자가 총액을 맞추려고 한쪽을 수동으로 수정하는 것은 위험한 오류입니다.

이렇게 하면 원인 증거가 사라집니다.

올바른 절차는 다음과 같습니다.

1. 원천 데이터를 보존함
2. 예외를 생성함
3. 원인을 찾음
4. 어느 원장이 잘못됐는지 확인함
5. 추적 가능한 업무 조정을 수행함
6. 승인을 받음
7. 다시 대사함

모든 조정에는 감사 추적 기록이 필요합니다.

Settlement와 Reconciliation 사이의 일반적인 예외

시스템은 성공으로 기록했지만 은행 명세에 없음

거래와 은행 증빙을 조사해야 합니다.

명세에는 출금이 있지만 시스템은 pending으로 표시

API 응답이 유실되었을 수 있습니다. 새 지급 명령을 다시 보내면 안 됩니다.

거래는 성공했지만 급여에 반영되지 않음

이미 받은 금액이 기간 말에 다시 지급될 위험이 있습니다.

급여에서 차감했지만 거래는 실패함

근로자가 돈을 받지 못했는데 급여가 줄어들 수 있습니다.

거래가 잘못된 기간에 속함

마감 기준과 관련 급여 기간을 확인해야 합니다.

중복 거래가 있음

두 기록을 모두 보존하고 원인을 파악한 뒤 정해진 절차로 처리해야 합니다.

두 계층의 책임자는 누가 되어야 하는가?

같은 팀일 필요는 없습니다.

다음과 같이 나눌 수 있습니다.

• Payment Operations: 거래별 Settlement 추적
• 회계/대사: 은행과 대사
• 급여: 기간 말 Settlement와 대사
• Engineering: 상태, 멱등성, 로그 보장
• Product Operations: 예외 조정

차이가 발생할 때 책임이 명확해야 합니다.

두 계층을 연결하려면 어떤 데이터가 필요한가?

최소한 다음이 필요합니다.

• 거래 ID
• 근로자 ID
• 수령 계좌
• 금액
• 시간
• 고객사
• 급여 기간
• 거래 상태
• 은행 참조번호
• 급여에 반영한 금액

이름이나 자유 형식의 송금 내용에 주로 의존해 대사해서는 안 됩니다.

언제 기간을 “마감”한 것으로 볼 수 있는가?

급여 처리가 끝났다는 이유만으로 기간을 마감해서는 안 됩니다.

마감 전에 기업은 다음을 확인해야 합니다.

• 근무 기록이 최종 상태임
• 성공 거래가 집계됨
• pending 거래에 처리 계획이 있음
• 은행과 내부 원장이 대사됨
• 급여에 정확히 반영됨
• 남은 예외에 담당자가 있음
• 연결 보고서가 저장됨

모든 예외가 즉시 사라질 필요는 없지만 열린 예외는 식별되고 통제되어야 합니다.

Settlement와 Reconciliation의 KPI는 별도로 추적해야 한다

Settlement

• 최종 상태 확정 시간
• pending 거래 수
• 개입이 필요한 거래 비율
• 재시도 거래 수
• 중복 거래 수

Reconciliation

• 자동 일치율
• 예외 수
• 예외 경과 기간
• 은행 차이 수
• 급여 차이 수
• 대사 마감 시간

하나의 KPI로 합치면 문제가 거래 처리인지 원장 비교인지 구분하기 어렵습니다.

결론

Settlement와 Reconciliation은 동일한 통제 체인의 서로 다른 연결 고리입니다. Settlement는 금전 의무를 완료하고 기록하며, Reconciliation은 독립된 출처로 결과의 일관성을 입증합니다. 두 계층을 분리하면 pending 거래, 차이, 마감 기준과 급여를 더 쉽게 관리하고 거래부터 급여명세서까지 추적성을 유지할 수 있습니다.

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

기업용 기발생 임금 접근 상담: Hotline 0937.022.655 · Email info@nhankiet.vn · 기업용 기발생 임금 접근 서비스