쿠팡 매출은 보이는데 실제로 얼마 남았는지는 모른다

매출이 늘었다고 그 금액이 그대로 들어오지는 않는다

판매자 화면에서 매출을 보는 일과 이번에 들어올 돈을 계산하는 일은 다르다. 수수료가 빠지고 광고비와 물류비가 연결되며, 정산 시점에 따라 일부 금액은 나중에 지급된다. 화면의 매출 합계를 엑셀에 옮겼는데 통장에 들어온 금액과 다른 것은 서로 다른 항목을 보고 있기 때문이다.

쿠팡 공식 로켓그로스 안내는 상품 최종 판매가격에서 판매수수료, 광고비 등 추가 비용, 로켓그로스 서비스 이용비를 정산한 뒤 지급한다고 설명한다. 마켓플레이스 판매 준비 안내에서는 주정산 금액의 70%를 먼저 지급하고, 환불 등에 대비해 보관한 나머지 30%를 월 단위로 합산해 지급한다고 설명한다.

셀러가 보려는 숫자도 먼저 나눠야 한다. 어느 기간에 얼마나 팔았는지는 매출 자료에서, 정산에서 얼마를 공제했는지는 비용과 지급 자료에서, 실제 들어온 돈은 통장 내역에서 확인한다. 얼마 남았는지를 보려면 여기에 상품원가와 쿠팡 정산 밖에서 지출한 비용을 추가한다. 최종지급액을 그대로 이익으로 표시하면 정산표는 맞아도 수익 판단은 달라진다.

AI에게 “이번 달 얼마 남았는지 알려 달라”고만 요청하면 필요한 원본의 범위가 흐려진다. 먼저 쿠팡 지급액의 구조를 맞추고, 실제 입금을 대조하고, 마지막에 원가와 외부 지출을 연결하도록 결과를 나누는 편이 좋다. 어느 단계에서 차이가 나는지 보여야 누락된 파일과 잘못 적용한 계산을 찾을 수 있다.

국내 작성자는 일반 정산 지급행 429건의 계산 차이가 0건이었다고 밝혔다

지피터스의 나병우 작성자는 Aside에 로켓그로스 최종지급액 구조를 파악해 달라고 요청했다. 작성자가 밝힌 작업에는 로그인된 Wing의 자료 수집, 파일 다운로드, 중복 제거, 계산 대조, Excel 통합과 원본 정리가 포함됐다. 결과물을 확인한 뒤 일반 Wing 정산으로 범위를 넓혔다고 설명한다.

작성자는 2018년부터 2026년까지 일반 정산 지급행 429건을 모았으며, 계산 결과와 Wing 최종지급액 사이의 차이가 0건이었다고 밝혔다. 이 숫자는 작성자가 공개한 실행 기록의 결과다. 자동화가 만든 엑셀에 원본 지급액과 계산값을 나란히 둬 같은 기준으로 대조한 점이 핵심이다.

정산 업무에서 필요한 결과물도 이처럼 나뉜다. 원본을 모은 폴더, 누적한 지급행, 연결한 상세 파일, 계산식, 차이가 나는 행을 볼 수 있는 검증표가 있어야 한다. 예쁜 대시보드만 있으면 특정 금액이 어디서 왔는지 다시 찾아야 한다. 요약 숫자에서 원본 파일과 지급행으로 돌아갈 수 있어야 다음 달에도 사용할 수 있다.

지급 계산, 실제 입금, 영업이익은 서로 다른 확인 단계다. 지급 계산을 맞추는 일이 독립된 업무이며, 그 단계가 끝나야 실제 입금과 원가를 연결할 기준이 생긴다. 판매자가 원하는 최종 결과는 자신이 확인할 숫자와 AI가 계산할 숫자가 같은 이름과 기간을 갖는 것이다.

수수료와 광고비와 물류비는 원본을 따로 연결해야 한다

매출 상세를 모두 받아도 비용 원본이 빠지면 최종지급액이 맞지 않는다. 판매수수료, 광고비, 입출고와 배송, 보관, 반품 관련 비용은 지급 자료에 어떤 형태로 반영됐는지 확인해야 한다. 같은 비용을 판매 자료에서도 빼고 지급 자료에서도 다시 빼면 실제 비용보다 크게 계산된다.

셀러용 수집표에는 숫자뿐 아니라 어떤 원본을 어디에 연결할지 적는다. 월별 비용과 지급행이 같은 기간 단위를 쓰는지, 이미 지급액에 반영된 항목인지, 별도 공제할 항목인지를 확인한다. 다음 표는 쿠팡의 공식 공제 구조와 국내 사례의 원본 분류를 업무에 적용한 것이다.

쿠팡 개발자센터 지급내역조회는 매출인식월을 기준으로 지급 확정·예정 내역을 제공한다. 응답 항목에는 지급액, 유보 성격의 최종액, 보류 해제 금액, 정산차감 등이 구분돼 있다. 판매자가 같은 달의 숫자를 볼 때에도 매출인식월과 지급일, 실제 입금일을 하나로 합치지 않아야 하는 이유다.

70%와 30% 지급행을 합치는 기준은 판매상세와 다르다

주정산과 최종액정산은 지급 단계가 나뉜 행이다. 두 지급행이 같은 매출기간의 판매상세를 가리킨다면 지급행은 각각 보존하되 판매상세는 중복 여부를 판단해야 한다. 지급액을 합산할 때 필요한 행과 판매액을 합산할 때 필요한 행의 수가 같을 필요는 없다.

국내 사례 작성자는 로켓그로스 지급행 27건에 고유 매출기간은 15개였다고 밝혔다. 70%와 30% 지급행에서 내려받는 판매상세가 같아 고유 매출기간별로 수집했다고 설명했다. 같은 상세를 두 번 합치면 매출과 수수료가 함께 부풀 수 있으므로, 지급행 번호와 판매 상세의 중복 기준을 나눈 것이다.

업무에 적용할 때는 지급행의 고유키, 정산 유형, 계정, 매출기간, 지급 구분을 보존한다. 판매상세는 원본이 제공하는 식별 항목과 기간으로 비교하고, 비용은 비용 유형과 비용 발생 기간을 따로 연결한다. 파일 이름이나 금액이 같다는 이유만으로 서로 다른 지급행을 지우는 방식은 피해야 한다.

Microsoft Power Query 문서는 선택한 열을 기준으로 중복 행을 제거하며, 중복 묶음에서 첫 번째 행을 보존하는 것을 보장하지 않는다고 설명한다. 같은 고유키에 다른 금액이 들어왔다면 한 행을 바로 삭제하지 않고 변경 또는 충돌로 표시하는 편이 좋다. 중복 제거가 과거 값을 바꾸는 작업이 되지 않도록 원본과 이전 값을 남긴다.

구화면과 신규화면은 같은 표 모양으로 보여도 계산 열이 다를 수 있다

오랜 기간의 정산자료를 모으면 조회 화면과 다운로드 형식이 바뀐 구간을 만나게 된다. 국내 작성자는 일반 정산에서 구화면과 신규화면의 조회 방식과 최종지급액 필드가 달랐다고 설명했다. 같은 이름의 파일을 하나로 합치기 전에 어느 화면에서 내려받았는지 기록할 필요가 있다.

셀러가 AI에게 자료 수집을 맡길 때에는 수집 성공을 파일 개수로만 판단하지 않는다. 요청한 기간이 파일 안에 실제로 들어 있는지, 헤더가 예상대로인지, 빈 파일이 없는지, 같은 기간을 여러 번 받은 것은 아닌지 확인한다. 조회 기간을 넓게 입력했다고 파일 내용까지 모두 들어갔다고 가정하지 않아야 한다.

폴더 결합 자체는 기존 기능으로도 처리할 수 있다. Excel Power Query의 폴더 가져오기는 같은 구조의 여러 파일을 한 표로 합치고 새로고침할 수 있다. 공식 안내는 열 이름과 데이터 형식이 일관돼야 하며, 결합 대상 폴더에 관련 없는 파일을 넣지 않도록 설명한다. CSV 결합 문서도 파일을 결합한 뒤 변환하는 흐름을 제공한다.

이를 정산에 적용하면 구화면 파일은 구화면의 열을 표준 열에 맞추고, 신규화면 파일은 신규화면의 열을 표준 열에 맞춘 뒤 합친다. 누적관리 결과 파일을 원본 수집 폴더에 넣으면 다음 갱신에서 결과 파일을 다시 읽을 수 있으므로 저장 위치도 구분한다. 형식이 바뀐 파일은 평소처럼 합산하지 않고 확인할 대상으로 남긴다.

합계가 맞는지보다 어떤 행에서 차이가 나는지 보여야 한다

검산표의 기준은 원본 최종지급액과 같은 지급행에서 다시 계산한 금액이다. 국내 작성자가 적용한 계산식은 일반 정산에서 지급액에서 총차감액을 빼고 기타지급조정을 더하는 방식이었다. 로켓그로스에서는 지급액에서 추가상계와 CFS 최종비용을 빼고 재고 손실 보상을 더하는 구조를 사용했다. 정산 유형이 달라 기준 파일도 따로 유지했다.

이 계산식을 판매자의 모든 기간과 화면에 그대로 붙이기 전에 실제 다운로드 자료의 항목을 맞춰야 한다. 비용이 이미 포함된 지급액인지, 추가로 공제할 금액인지에 따라 이중 차감이 생길 수 있다. 엑셀에서 한 번 맞춘 식이 다음 형식에서도 같은 뜻인지는 항목 단위로 확인한다.

Excel의 SUMIFS처럼 여러 조건을 지정하는 합계 기능을 쓰면 계정·정산 유형·기간별 합계를 따로 만들 수 있다. 총합 하나만 맞추면 한 기간의 누락과 다른 기간의 중복이 서로 상쇄될 수 있다. 행별 차이와 기간별 합계를 함께 봐야 원본으로 돌아가 확인할 위치가 남는다.

해외 인보이스 처리 사례의 작성자도 번호 중복 확인, 누락 자료 표시, 검토와 지급 대조를 별도 과정으로 설명했다. 해외 청구서와 쿠팡 정산의 계산 항목은 다르지만, 추출된 숫자를 바로 합계로 보내기 전에 중복과 누락을 검사하는 순서는 정산 업무에서도 사용할 수 있다.

다음 달에는 신규 자료와 수정된 자료를 함께 확인한다

한 번 만든 정산 파일은 다음 달에 새 자료를 더할 때 가치가 생긴다. 국내 작성자의 현재 결과물은 과거 자료를 모은 기준 파일이다. 정기 실행으로 신규 지급행을 추가하고 차이가 있으면 알리는 흐름은 앞으로의 계획으로 제시됐다. 최초 정리와 반복 운영을 같은 완료 상태로 두지 않아야 한다.

판매자가 반복 갱신에 적용할 흐름은 기존 고유키와 신규 자료를 비교하는 데서 시작한다. 처음 보는 키는 추가하고, 이미 있는 키의 금액이나 상태가 바뀌면 이전 값을 남긴 채 비교한다. 확인 범위를 마지막 수집일 이후로만 제한할지, 조정이 발생할 수 있는 이전 기간도 다시 볼지 업무 기준을 정한다.

월별 청구서를 모으던 Reddit 작성자는 이메일 PDF를 내려받고 보관하고 시트에 기록하는 반복을 자동화했다고 설명했다. 정산에서도 수집한 파일의 위치와 처리 상태를 남기면 다음에 같은 작업을 다시 시작하기 쉽다. 자료가 없었던 것인지, 조회가 실패한 것인지, 갱신이 끝났는지가 구분돼야 한다.

원본자료와 누적관리 파일과 검산 결과는 서로 연결하되 저장 위치를 나눈다. 새로고침 뒤에는 추가 행 수, 변경 행 수, 계산 차이, 마지막 확인 시각을 남긴다. 검산 차이가 생기면 원본 링크와 해당 지급행을 보여주고, 누적 결과를 통째로 덮어쓰기 전에 차이를 확인한다.

쿠팡 정산 자동화의 목적은 숫자를 빨리 채우는 데서 끝나지 않는다. 어떤 매출기간에 어떤 비용이 적용돼 얼마가 지급되는지 설명할 수 있어야 한다. 그 기준을 맞춘 뒤 실제 입금과 원가를 연결하면 매출 화면과 판매자의 수익 사이에 남아 있던 계산을 이어갈 수 있다.

자주 묻는 질문