티스토리 뷰

주문대조
반품 배송비를 정리할 때 저는 정산 화면의 공제액부터 보지 않고 주문번호와 반품 접수번호를 한 줄로 연결합니다. 같은 구매자가 여러 옵션을 함께 반품하거나 교환을 다시 신청하면 주문번호 하나에 회수 건이 둘 이상 생길 수 있기 때문입니다. 판매관리 화면에서 주문일, 출고 운송장, 회수 운송장, 환불 완료일을 나란히 놓고 실제로 돌아온 수량까지 확인했습니다. 반품 봉투에 붙은 라벨은 개인정보가 보이지 않게 처리하고 상품 바코드와 옵션 코드만 작업표에 남겼습니다.
제가 겪은 오류는 회수 완료와 환불 완료를 같은 시점으로 본 데서 시작했습니다. 택배 조회에는 배송 완료가 찍혔지만 물류센터 검수가 끝나지 않아 환불 상태가 그대로인 건이 있었고, 반대로 선환불 처리 뒤 상품이 늦게 입고된 건도 있었습니다. 그래서 택배 상태만으로 정산을 확정하지 않고 관리자 상태와 실물 입고 기록을 함께 대조했습니다. 세트 상품은 구성품이 모두 돌아왔는지 확인해 한 개의 반품 수량을 곧바로 정상 재고 한 개로 더하지 않았습니다.
점검표에는 원주문번호, 반품번호, 판매 옵션, 출고 수량, 회수 수량, 검수 결과, 환불 금액을 분리했습니다. 부분 반품은 남은 판매분과 섞이지 않도록 별도 행으로 만들었고, 재배송이 붙은 교환 건은 새 운송장까지 연결했습니다. 날짜 기준도 접수일과 입고일, 정산 반영일을 나눠 저장했습니다. 이렇게 해야 월이 바뀌는 시점에 전월 매출과 당월 공제를 잘못 상계하는 일을 줄일 수 있었습니다.
반품비를 무조건 비용으로만 보면 어떤 상품과 어떤 과정에서 손실이 생겼는지 놓칩니다. 저는 주문 단위 공제액보다 귀책 판단의 근거가 남아 있는지를 더 중요하게 봅니다. 고객 사유라는 표시가 있어도 상품 설명과 실제 규격이 달랐다면 판매자 쪽 개선이 먼저이고, 판매자 사유로 잡혔어도 택배 파손 증빙이 있다면 물류 사고와 구분해야 합니다. 반품률이 낮다는 이유로 한 건의 큰 공제를 넘기지 않고, 반대로 반품률이 높다고 모든 주문을 문제 상품으로 단정하지 않습니다. 금액, 사유, 입고 상태, 재판매 가능 여부를 함께 보아 다음 상세페이지 수정이나 포장 변경으로 이어질 때 기록의 가치가 생긴다고 판단했습니다.
주문번호, 회수 상태, 귀책 근거, 실제 공제액이 하나의 흐름으로 설명돼야 반품 정산을 끝냅니다.
- 원주문번호와 반품 접수번호 연결
- 출고·회수 운송장과 실물 수량 확인
- 접수일·입고일·정산 반영일 분리
- 고객 개인정보는 작업표에서 제외
회수 완료와 환불 완료는 같은 사건이 아닐 수 있습니다. 주문 자료와 물류 상태, 실물 검수 결과를 함께 맞춘 뒤 귀책을 판단합니다.

귀책구분
귀책구분은 관리자 화면의 한 단어를 그대로 복사하는 작업으로 끝내지 않았습니다. 고객 변심, 상품 불량, 오배송, 옵션 착오, 배송 파손처럼 사유를 나눈 뒤 주문 메시지와 출고 검수 사진, 회수 상품 상태를 확인했습니다. 고객 개인정보가 포함된 대화 전문은 별도 분석표에 옮기지 않고 필요한 사실과 확인 시각만 적었습니다. 증거가 부족한 건은 임의로 판매자 또는 고객 책임으로 확정하지 않고 확인 대기 상태로 남겼습니다.
오배송과 옵션 착오는 특히 상품명만 보면 구분하기 어려웠습니다. 주문 옵션 코드와 실제 회수된 바코드를 비교하고, 출고 작업표에 같은 시각 처리된 다른 주문이 있는지도 살폈습니다. 상품 불량 주장은 사진만으로 확정하기 어려운 경우가 있어 검수 기준과 플랫폼 절차를 따랐습니다. 포장 훼손이 있어도 내용물 재판매 가능 여부는 별도 기준으로 판단했고, 반품 배송비 귀책과 재고 등급을 하나의 값으로 묶지 않았습니다.
귀책이 바뀌면 고객 환급액과 판매자 부담액이 달라질 수 있으므로 수정 전후 화면을 날짜와 함께 기록했습니다. 플랫폼 정책은 바뀔 수 있어 과거 기억 대신 해당 주문 시점의 판매자 안내를 확인했습니다. 전자상거래 관련 법령의 청약철회 예외와 표시 의무도 공식 법령에서 대조하되 개별 분쟁을 제가 법률 판단으로 확정하지 않았습니다. 판단이 모호하거나 금액이 크면 판매자 고객센터의 공식 문의 기록을 남겼습니다.
- 주문과 회수 건 연결
- 옵션 코드와 실물 바코드 대조
- 사유별 증빙 확인
- 불확실한 건은 확인 대기로 분리
헷갈렸던 지점
택배 조회의 회수 완료를 환불과 정산까지 끝난 상태로 본 점입니다. 물류 이동, 검수, 환불, 공제 반영은 서로 다른 시점일 수 있었습니다.
귀책과 비용 기준은 플랫폼 정책과 주문 시점에 따라 달라질 수 있습니다. 기억이나 임의 판단 대신 해당 주문의 공식 안내와 문의 기록을 확인합니다.
공제확인
공제확인에서는 반품 배송비 한 항목만 찾지 않고 환불액, 판매수수료 조정, 쿠폰 분담, 회수비, 재배송비를 주문별로 펼쳐 보았습니다. 동일 주문에서 같은 비용이 두 번 차감된 것처럼 보여도 최초 결제 취소와 후속 정산 조정이 서로 다른 행일 수 있어 발생일과 정산 주기를 비교했습니다. 반대로 합계만 맞는다고 끝내지 않고 각 공제 행이 실제 반품번호와 연결되는지 확인했습니다.
제가 사용하는 종료 기준은 주문번호와 반품번호가 연결되고, 귀책 근거가 남아 있으며, 실물 입고 수량과 정산 공제 합계가 설명되는 상태입니다. 회수 상품이 정상 재고로 전환됐다면 재고 증가 기록까지 확인하고, 폐기나 수선으로 분류됐다면 비용 메모를 분리했습니다. 플랫폼에서 아직 확정되지 않은 금액은 예상 공제로 표시해 확정 손익에 섞지 않았습니다. 정산서 원본 파일과 확인 날짜는 보관하지만 계정 비밀번호나 고객 연락처는 기록하지 않습니다.
반품비가 반복되는 상품은 상세페이지 규격, 옵션명, 포장 방식, 출고 검수 중 어디를 고칠지 정했습니다. 한 번의 특이 사례만으로 상품을 중단하지 않고 최근 주문 수 대비 사유별 발생 건수를 보았습니다. 같은 사유가 이어지면 설명 이미지나 옵션 선택 문구를 수정하고, 파손이 집중되면 완충재와 박스 규격을 시험했습니다. 이 기록은 환불을 줄이겠다는 막연한 목표보다 실제로 바꿀 작업을 선택하는 데 사용했습니다.
자주 묻는 질문
Q. 회수 완료면 공제도 끝난 건가요?
A. 검수, 환불, 정산 반영 시점이 다를 수 있어 각 상태를 따로 확인합니다.
Q. 고객 사유 표시면 그대로 확정해도 되나요?
A. 주문 옵션과 상품 설명, 회수 상태 등 해당 건의 근거를 함께 봅니다.
Q. 공제 합계만 맞으면 충분한가요?
A. 주문별 연결이 없으면 누락과 중복을 찾기 어려우므로 반품번호까지 대조합니다.
- Total
- Today
- Yesterday
- 온라인판매
- 상품소싱
- 재고계산
- 반품정산
- 온라인판매회계
- 발급시점
- 상품별손익
- 중국발주
- 광고성과
- 재고관리
- 비용분리
- 정산차액
- 1688소싱
- 판매자쿠폰
- 광고비상품별배분
- 마진관리
- 상품손익
- 쿠팡광고
- 재고회전
- 광고비
- 귀책구분
- 상품광고
- sku관리
- 온라인판매운영
- 주문대조
- 매출연결
- 판매수수료정산
- 상품원가
- 쿠폰할인분담률
- 상품마진
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
