주문액·PG 내역·입금액이 다를 때 무엇을 기준으로 대사할까

문제와 판단 기준

주문 화면에는 19만 원이 잡혔는데 통장에는 13만 5,800원이 들어왔습니다. 차액을 찾으려고 같은 날짜의 주문 파일과 PG 정산 파일을 나란히 놓아도 합계가 맞지 않습니다. 취소가 섞였는지, 수수료가 더 빠졌는지, 아직 들어오지 않은 돈인지부터 구분해야 합니다. 뒤에서 이 숫자를 가상 데이터로 풀어보겠습니다.

대사의 기준은 어느 한 화면의 총액이 아니라, 같은 거래를 연결한 기록입니다. 주문과 승인·취소를 연결하고 그 거래 중 이번 정산에 포함된 내역을 고른 뒤, 지급 명세와 은행 입금을 대조해야 합니다. 주문액과 입금액의 차이가 모두 오류인 것도 아니고, 두 합계가 같다고 모든 거래가 올바르게 반영된 것도 아닙니다.

실무에서는 질문을 나누는 편이 좋습니다. 주문 시스템은 ‘얼마를 받아야 했는가’, PG 거래 기록은 ‘얼마가 승인·취소되었는가’, 정산 명세는 ‘어떤 내역을 반영해 얼마를 지급하는가’, 은행 기록은 ‘실제로 얼마가 들어왔는가’를 확인하는 자료로 둡니다. 서로 다른 질문의 답을 한 열에 넣지 않는 것이 출발점입니다.

이 글은 2026년 9월 26일 확인한 공식 문서를 바탕으로, 토스페이먼츠를 국내 PG의 구체적인 예로 사용합니다. 아래 연결 구조와 예외 처리 방식은 구현을 위한 설계 제안입니다. 회계상 매출 인식이나 세무 처리 기준을 정하는 글은 아닙니다.

같은 날짜의 파일부터 맞추면 범위가 어긋난다

먼저 비교표의 ‘날짜’ 열을 풀어 써야 합니다.

정산 주기와 수수료 조건은 계약에 따라 확인해야 합니다. 토스페이먼츠의 설명에서도 정산 매출일은 결제일과 항상 같지 않습니다. 따라서 주문 기간을 선택한 결과와 입금 기간을 선택한 결과를 바로 빼면, 애초에 서로 다른 거래 집합을 비교할 수 있습니다. 정산 개념·주기 안내.

토스페이먼츠 거래 조회는 transactionAt을 기준으로 당일 기록을 조회합니다. 정산 조회는 다음 날부터 가능하고 dateType은 기본 soldDate, 지급일 기준 조회는 paidOutDate입니다. 정산 기록이 아직 조회되지 않는 상태와 실제 누락을 구분해야 합니다. 코어 API — 거래·정산 조회.

조회 조건과 함께 ‘어느 시각까지 수집을 마쳤는지’도 남기십시오. 종료 날짜를 오늘로 입력했더라도 수집이 오전에 끝났다면 오늘 전체를 확인한 것이 아닙니다. 조회 구간의 경계, 시간대, 페이지 수집 완료 여부를 정하지 않은 채 미일치를 경보로 보내면 데이터 수집 문제와 거래 문제를 구분하기 어렵습니다.

주문 하나를 거래 한 줄로 줄이지 않는다

한 주문을 두 번 나누어 결제하거나 한 결제를 여러 번 부분 취소하는 상황을 담을 수 있어야 합니다. 토스페이먼츠도 승인과 각각의 취소·부분 취소를 별도 거래로 설명합니다. 주문의 현재 잔액만 보관하면 어떤 취소가 어느 정산에 들어갔는지 거슬러 올라가기 어렵습니다. 거래의 정의와 거래 기록.

권장하는 연결표는 다음과 같습니다. 오른쪽의 자체 식별자는 PG가 자동 발급하는 필드가 아니라 내부에서 관리할 값입니다.

토스페이먼츠에서는 paymentKey가 결제를, transactionKey가 승인·취소 거래를 식별합니다. 취소 배열에도 개별 거래 키가 있습니다. 코어 API, 결제 취소하기.

실제 저장 키에는 공급자와 상점 ID, 테스트·운영 환경도 포함하도록 설계하십시오. 내부 주문 번호가 같다는 이유로 다른 상점이나 환경의 거래를 연결해서는 안 됩니다. 한 업무 주문을 여러 결제 요청으로 나누는 서비스라면, 업무 주문 ID와 PG에 전달하는 요청별 주문 ID도 분리해서 관리하는 편이 안전합니다.

정산 묶음 ID가 명시적으로 제공되지 않을 수도 있습니다. 토스페이먼츠의 공개 Settlement 스키마에서는 공통 지급 묶음 ID나 은행 입금 참조를 확인할 수 없습니다. Settlement 객체. 이때 같은 지급일의 행을 모았다는 이유만으로 그것을 은행 입금 한 건의 확정 구성원으로 취급하지 마십시오. 상점·통화·지급 명세와 입금 통지를 확인한 뒤 대응표를 확정하고 근거가 모자라면 후보 묶음으로 남깁니다.

해외 결제를 함께 운영한다면 공급자별 차이도 남겨야 합니다. Stripe의 Payout reconciliation report는 자동 지급을 중심으로 거래 묶음을 설명하며 수동 지급에는 별도의 Balance 보고서를 안내합니다. 국내 PG에 그 묶음 구조를 그대로 적용하는 근거는 아닙니다. Stripe 지급 대사 보고서.

연결하기 전에 금액과 상태의 뜻부터 맞춘다

원본 CSV를 한 시트에 합치는 작업과 대사할 수 있는 데이터를 만드는 작업은 다릅니다. 다음은 수집 규칙에 먼저 넣을 항목입니다.

금액·통화·부호. 공급자가 제공하는 단위와 통화를 확인하고 원래 값을 함께 보존합니다. 이 글의 예시는 KRW 원 단위 정수입니다. 다른 통화나 보고서에 같은 단위를 강제하지 마십시오. 정확한 금액 연산이 필요할 때 PostgreSQL 문서도 부동소수점 대신 정확한 수치형을 안내합니다. 구현에서는 허용 범위가 충분한 정수 또는 명시적인 소수 정밀도를 선택하고 반올림은 공급자의 실제 규칙에 맞춰 별도로 정합니다. PostgreSQL 수치형 문서.

취소 금액이 원본에서 양수인지 음수인지 확인한 뒤 내부 부호로 변환합니다. 이미 음수인 취소를 다시 빼거나, 취소 후 잔액에서 취소액을 한 번 더 빼지 않도록 해야 합니다. 환산이 필요한 거래라면 결제 통화와 정산 통화, 적용 환율·시점, 환전 관련 항목을 구분합니다. 환산 근거가 없는 원화와 달러는 합계 자체를 분리합니다.

거래 상태·정산 상태·입금 상태. 세 상태를 하나의 ‘완료’로 합치지 않습니다. 토스페이먼츠의 Payment.status에서 DONE은 결제 승인 상태이며 카드 acquireStatus는 매입 상태입니다. paidOutDate도 은행 입금 증빙을 대신하지 않습니다. 코어 API 상태·정산 필드.

내부에서는 아래처럼 별도 열을 두는 방법을 제안합니다. 이 명칭은 PG의 공식 상태 코드가 아닙니다.

수수료·중복·정정. 정산의 총 차감액과 그 구성 항목을 나눕니다. 토스페이먼츠 문서에는 fees, supplyAmount, vat, payOutAmount가 구분되어 있습니다. Settlement 객체. 필드가 여러 개라고 모두 독립 비용으로 더하지 말고, 합계와 구성 항목의 포함 관계를 확인하십시오. 이 글은 부가세율이나 분개 방법을 정하지 않습니다.

거래를 연결하는 키와 원본 행의 중복을 검사하는 키도 구분합니다. 거래 파일과 정산 파일은 분리해서 관리하고 한 거래가 수수료·조정 등 여러 정산 행으로 나뉘는 형식이라면 공급자가 정의한 행 ID나 항목·순번을 함께 보존합니다. 거래 키가 같다는 이유만으로 서로 다른 정산 행을 지우거나, 결제 원금을 연결된 행 수만큼 반복 합산해서는 안 됩니다.

파일 이름이 바뀌었다고 새로운 거래가 되는 것은 아닙니다. 원본 파일의 해시와 수집 이력을 남기고, 해당 자료 형식의 행 식별 기준으로 중복을 검사합니다. 같은 키의 내용이 같으면 재수집으로 처리하되, 같은 키의 금액이나 상태가 달라졌다면 정정 후보로 기록합니다. ‘마지막 파일이 정답’이라는 규칙으로 과거 값을 덮어쓰지는 않습니다.

19만 원이 13만 5,800원이 되는 과정을 검산해 보자

설계 예시입니다. 실제 고객 데이터, 특정 PG의 응답, 계약 수수료나 정산 일정이 아닙니다. 하나의 가상 상점, KRW 원 단위, 2026년 9월 21일 23:59:59 한국시간까지 수집한 자료를 가정합니다. 최초 주문액에는 최종 청구할 금액이 반영되어 있고, 모든 주문은 승인되었습니다. 사례에는 아래의 취소와 수수료 외에 세금 추가 공제·보류·환전·조정·차지백이 없습니다.

O-A는 10만 원 결제 후 2만 원이 취소되었습니다. O-B는 6만 원을 두 결제로 나누었습니다. O-C의 3만 원은 이번 지급 묶음 밖에 있으며, 이후 정산으로 확인할 대상입니다.

다음은 같은 주문을 개별 거래 사건으로 펼친 표입니다. 수수료 차감은 지급액에서 빼는 값을 양수로 표시하고 되돌리는 값을 음수로 표시했습니다. 취소 시 600원이 되돌아온다는 것 역시 이 예시만의 가정입니다.

B-01은 정산 원본의 네 거래 행을 확인한 뒤 붙인 내부 묶음 ID입니다. 정산 기준일은 9월 14일·15일, 지급 예정일은 9월 21일로 정해진 가상 명세를 가정합니다. 서로 다른 기준일의 내역도 지급 명세에서 같은 묶음임이 확인되면 함께 대사합니다.

은행 기록은 입금 거래 D-01, 입금일 9월 21일, 금액 135,800원입니다. 이 예시에서는 PG 입금 통지와 은행 내역에 대응 가능한 참조 REF-01이 있고, 담당자가 REF-01과 B-01의 연결을 확인했다고 가정합니다.

따라서 검산은 다음과 같습니다.

전체 주문 190,000원 − 확인된 취소 20,000원 = 순결제 170,000원
순결제 170,000원 − 이번 묶음 밖 거래 30,000원 = 묶음 거래 증감 140,000원
묶음 거래 증감 140,000원 − 순수수료 차감 4,200원 = 지급액 135,800원
지급액 135,800원 − 대응하는 은행 입금 135,800원 = 대사 차액 0원

순결제와 은행 입금의 차이 34,200원은 수수료 4,200원과 이번 묶음 밖의 원금 30,000원으로 설명됩니다. 30,000원은 다음 입금액 자체가 아니라 아직 이번 지급에 포함되지 않은 거래 원금입니다. 이후 수수료와 정산 내역을 다시 확인해야 합니다. 이 식을 모든 기간·PG에 적용하는 만능 정산 공식으로 사용해서는 안 됩니다.

여기에는 한 가지 함정이 더 있습니다. T-A2의 −19,400원과 T-B2의 +19,400원이 동시에 빠져도 지급 합계는 135,800원으로 같습니다. 합계 일치만 검사하면 취소 한 건과 승인 한 건의 누락을 놓칩니다. B-01의 구성원이 T-A1·T-A2·T-B1·T-B2 네 건인지, 각 키와 금액이 원본에 대응하는지도 검사해야 합니다.

자동으로 연결할 건과 사람이 확인할 건을 나눈다

자동 일치는 식별 근거와 금액 검산을 모두 통과한 경우로 제한하는 편이 좋습니다. 공급자·상점·통화가 같고, 거래 키로 연결되며 승인·취소의 뜻이 맞고, 동일 행이 다른 묶음에 중복 배정되지 않았는지 확인합니다. 은행 단계에서도 지급 참조와 구성원이 확인되어야 합니다.

입금자가 같고 금액도 같지만 대응 가능한 지급 명세가 두 개라면 ‘일치 후보 두 건’입니다. 먼저 발견한 행에 연결하거나, 합계가 맞는 거래 조합을 찾아 확정하지 않습니다. 금액과 날짜는 후보를 좁히는 조건이지 신원을 입증하는 키가 아닙니다. 사람이 연결을 확정할 때에도 선택한 원본, 근거, 확인자와 시각을 남깁니다.

허용 오차 역시 모든 차이를 없애는 장치로 쓰지 마십시오. 적용할 항목·통화·반올림 근거·한도를 정하고 허용 범위로 처리한 차액을 별도 집계합니다. 설명되지 않은 차이는 1원이어도 설명되지 않은 상태로 남기는 편이 낫습니다.

이미 정산된 결제를 나중에 취소하는 경우도 별도로 다뤄야 합니다. 토스페이먼츠 취소 가이드는 다음 정산금에서 상계하는 방식을 안내합니다. 과거 입금액을 취소 후 숫자로 덮어쓰기보다, 원결제와 취소 및 이후 반영 내역을 연결해 과거 기록과 이후 변화를 함께 설명하십시오. 결제 취소하기.

위 표의 보류·조정·차지백은 모든 PG에 같은 필드가 있다는 뜻이 아닙니다. 예를 들어 Stripe는 잔액 거래의 분쟁·분쟁 환원과 유보금 관련 분류를 따로 설명합니다. 국내 PG에서는 실제 계약·명세·통지에서 확인한 항목만 대응시키고, 모르는 코드는 ‘기타 수수료’가 아니라 미분류 예외로 남겨야 합니다. Stripe 보고 분류.

파일을 다시 받아도 이전 판단을 설명할 수 있어야 한다

대사 결과만 보관하면 원본 파일이 정정되었을 때 지난 마감이 왜 달랐는지 설명하기 어렵습니다. 수집 원본과 계산 결과, 사람이 내린 예외 판단을 분리해서 관리하는 방식을 권합니다.

수집 기록에는 출처·상점·기간·조회 조건·수집 시각·파일 해시·수집 완료 여부를 남깁니다. 계산 기록에는 사용한 원본 버전, 변환 규칙 버전, 대사 규칙 버전, 처리 실행 ID를 묶습니다. 예외 기록에는 담당자·확인 기한·처리 근거·재처리 이력과 재개 여부를 남깁니다. 같은 원본과 같은 규칙으로 다시 계산한 결과가 달라지면, 거래 차이보다 처리 과정부터 조사합니다.

정정본은 새 원본 버전으로 보존하되, 어떤 기존 행을 대체하거나 조정하는지 공급자의 문서와 확인 결과에 따라 연결합니다. 과거 확정 결과를 남긴 채 영향받은 묶음만 재계산하고 이미 닫힌 예외가 다시 열리는 조건도 정해 둡니다. 전체 정정 파일을 과거 파일에 그대로 더하는 방식은 재수집과 신규 거래를 혼동합니다.

‘원본 보존’이 인증정보와 개인정보까지 무제한 보관하라는 뜻은 아닙니다. 수집 범위를 줄이고 접근 권한·보관 기간을 정하십시오. 대사 확인 업무에는 조회 권한을 우선 사용하고 환불 실행·지급 요청·회계 전표 확정 권한은 분리하는 설계가 적절합니다. 대사 프로그램은 차이를 찾는 역할이며 차이가 발견되었다고 자동으로 돈을 움직여서는 안 됩니다.

작은 팀이라면 엑셀에서 시작해도 된다

자료 출처가 적고 키가 안정적이며 담당자가 예외를 처리할 수 있다면, 새 시스템을 구매하기 전에 원본 보관·연결표·차이 분류부터 정리해도 됩니다. 먼저 한 상점, 한 통화, 한 지급 묶음으로 계산을 설명해 보십시오. 설명이 안 되는 상태에서 연결 규칙만 자동화하면 잘못된 매칭도 빠르게 반복됩니다.

반대로 여러 상점과 채널에서 정정 파일이 반복되고 과거 결과를 재현하기 어렵거나, 예외가 담당자 없이 쌓인다면 수집과 이력 관리의 자동화를 검토할 시점입니다. 이때 판단 기준은 ‘자동 일치율이 높아졌는가’만이 아닙니다. 미분류 차액, 지급 기한을 넘긴 항목, 키가 없는 기록, 중복 배정, 처리 기한이 지난 예외가 보이는지도 함께 봐야 합니다.

기존 결제 정산 대사 규칙·운영 런북 양식에는 공통 키와 불일치 처리, 런북을 정리하는 구조가 마련되어 있습니다. 이 글의 예시로 연결 방식을 이해한 뒤 실제 업무 규칙은 해당 자료에 정리하면 됩니다.

정리할 대상은 결국 네 가지입니다. 무슨 거래인지, 어느 정산에 들어갔는지, 실제로 입금됐는지, 남은 차이는 누가 확인하는지. 이 네 질문에 답할 수 있어야 차액 0원이 의미를 갖습니다. 정산액은 회계상 매출이나 이익과 같은 값이 아니며, 대사 기록은 회계 원장을 대신하지 않습니다.

데이터 출처와 연결 키, 예외 처리 범위를 함께 설계해야 한다면 IXC 정산 자동화 서비스의 제공 범위를 확인하십시오.