대사 결과 차액 0. 그래도 아직 하루를 마감할 이유는 아니다

500짜리 오류 두 개가 서로를 깔끔하게 상쇄할 수 있습니다. 그래서 일일 대사에서 합계가 맞았다고 해서 돈이 올바른 주문에 배분됐고 지급금이 은행에 도착했다는 증명이 되지는 않습니다. 매일의 대사는 의미 있는 금액마다 내부 기록에서 PG사 리포트, 은행 입금까지 이어지는 경로를 남겨야 합니다.

가상의 하루를 살펴보자

PG사의 기초 잔액이 10 000, 입금이 250 000, 환불이 8 000, 수수료가 4 500, 은행 지급이 232 500이라고 합시다. 그러면 계산상 기말 잔액은 10 000 + 250 000 − 8 000 − 4 500 − 232 500 = 15 000입니다. 리포트도 같은 15 000을 보여 준다면 잔액의 움직임은 설명된 것입니다. 하지만 환불이 올바른 주문에 속하는지, 수수료가 정확히 계산됐는지, 지급금이 실제로 들어왔는지는 아직 증명해야 합니다.

은행에 아직 232 500이 입금되지 않았다고 해 봅시다. 돈을 다시 보내는 대신, 배치를 참조하고 예상 일자를 적은 "이동 중인 지급" 항목을 만드세요. 두 결제의 금액이 똑같이 1 200이라면 금액 일치만으로는 둘 중 아무거나 고를 근거가 되지 않습니다. 빠진 식별자는 추가 확인이 필요합니다. 그렇지 않으면 두 오류가 서로를 가릴 수 있습니다.

차액이 0이어도 조사할 수 있다

학습용 예시에서 주문 A의 환불 500이 실수로 누락됐고, 주문 B의 환불 500은 두 번 반영됐습니다. 총액은 리포트와 일치합니다. 주문 단위로는 오류가 두 개 남아 있고, 둘 다 고객센터의 다음 판단에 영향을 줄 수 있습니다. 그래서 합계와 함께 거래의 건수, 유형, 식별자를 확인해야 합니다.

자동 매칭은 안정적인 키부터 시작하세요. 키가 없다면 결과를 추정 일치로 표시하고 수동 확인 조건을 정하세요. 자동화 비율을 높이려고 금액 허용 오차를 슬그머니 넓히지 마세요. 1센트 차이는 알려진 반올림 규칙 때문일 수도 있고, 다른 거래를 뜻할 수도 있습니다. 선택한 원인은 기록해 두어야 합니다.

입력의 완전성 점검도 유지하세요. 행 수, 양 끝 날짜, 통화, 기간의 시작과 끝, 다운로드 파일의 모든 부분이 있는지 확인합니다. 리포트가 합의한 23:59가 아니라 17:00에 끊겨 있다면 "사라진" 저녁 결제를 찾는 일은 가짜 문제의 대기열만 만들 뿐입니다. 먼저 완전한 원본을 복구하세요.

먼저 하루의 경계를 정하라

통화와 법인마다 시간대, 기간 마감 시각, 계좌 목록을 정해 두세요. 결제 생성 시각, 회계 반영 시각, 자금 사용 가능 시각은 따로 보관합니다. 늦은 저녁에 처리된 거래는 아무 오류 없이도 다른 정산 배치에 들어갈 수 있습니다. 대사를 다시 실행할 때는 같은 기간을 쓰고 원본 파일의 버전을 표시하세요.

모든 리포트가 같은 문제를 푸는 것은 아닙니다. Stripe에 따르면 Balance summary는 기간 중의 잔액 변동과 지급을 보여 주지만, 지급을 특정 결제와 연결하지는 않습니다. 따라서 이 리포트는 잔액 확인에는 적합하지만 각 지급의 구성을 복원하는 데는 적합하지 않습니다. 출처: Stripe, Balance summary report.

세 단계로 매칭하라

1. 1.주문과 거래. 내부 식별자를 PG사 식별자, 이벤트 유형, 금액, 통화와 연결하세요. 환불은 원 결제를 참조하되 별도의 거래로 남아야 합니다.
2. 2.거래와 정산 배치. 총 입금, 환불, 수수료, 기타 확인된 조정을 모으세요. 배치의 순액을 확인합니다.
3. 3.배치와 은행. 사용 가능한 식별자, 통화, 금액으로 지급과 은행 입금을 매칭하세요. 날짜의 허용 차이는 금액 허용 오차와 별도로 정합니다.

Adyen의 Settlement details report에는 거래, 수수료, 보증금 조정, 지급이 담겨 있으며, MerchantPayout 레코드는 배치를 은행 입금과 연결하는 데 도움이 됩니다. 성공한 결제 목록 하나만으로는 대사에 충분하지 않은 이유를 보여 주는 예입니다. 출처: Adyen, Settlement details report.

불일치 대기열은 원인을 설명해야 한다

항목을 정확한 일치, 예상된 시점 차이, 확인된 조정, 설명되지 않은 불일치로 나누세요. 뒤의 세 범주에는 금액, 경과 기간, 담당자, 증빙, 다음 확인 날짜를 보관합니다. 시점 차이도 확인될 때까지는 열린 상태로 남습니다. 기한 없는 "나중에 확인" 메모는 금세 영구적인 잔액이 됩니다.

Stripe의 지급 대사 리포트는 자동 지급을 기준으로 합니다. 즉시 지급의 경우 Stripe는 포함된 거래의 구성을 자동으로 판별하지 않습니다. 따라서 대사 방법은 구체적인 지급 방식을 고려해 골라야 합니다. 출처: Stripe, Payout reconciliation report.

불일치의 경과 기간은 약속된 이벤트부터 세라

5일 된 거래라도 지급이 내일 예정이라면 반드시 지연된 것은 아닙니다. 하루 된 거래라도 합의한 기한이 지났다면 이미 개입이 필요할 수 있습니다. 두 날짜를 보관하세요. 항목을 처음 발견한 시점과, 그 이후로 지연이 되는 시점입니다. 그래야 대기열이 일반적인 대기와 예상 순서의 위반을 구분할 수 있습니다.

원인은 조치가 가능할 만큼 구체적으로 지정하세요. "배치에 대한 은행 매칭 없음", "리포트 일부 미수신", "환불과 원 결제의 연결 없음"처럼요. "기타" 범주는 분석과 구체화로 이어져야지, 영구 보관 장소가 되어서는 안 됩니다. 반복되는 원인에는 해당 행을 닫는 작업만이 아니라 프로세스 개선 작업도 추가하세요.

하루를 두 숫자로 마무리하세요. 설명되지 않은 금액, 그리고 설명은 됐지만 아직 닫히지 않은 대기 금액입니다. 이 둘은 관리자와 서로 다른 대화를 필요로 합니다. 두 번째는 크더라도 기한상 정상일 수 있고, 첫 번째는 작더라도 시스템 오류를 가리킬 수 있습니다. 큰 항목은 따로 보여 주어 상계로 인해 다시 묻히지 않게 하세요.

하루를 마감한 뒤에도 열려 있는 것

일치 여부를 건수와 금액 모두로 보여 주세요. P2P 서비스라면 사용자 간 채무 배분도 대사하세요. 은행 전체 잔액이 일치한다고 해서 각 사용자의 잔액이 맞다는 증명이 되지는 않습니다.

동료에게 금액이 큰 미결 항목 하나를 골라 내부 주문부터 은행까지 따라가 보라고 부탁하세요. 경로가 끊긴다면 정확한 위치와 기대되는 문서를 표시하세요. 이런 표본 점검은 초록색 일치율 하나를 더 보는 것보다 대사의 품질을 더 잘 확인해 줍니다.