이 글은 누구를 위한 것인가
마켓플레이스·오픈마켓을 운영하는 기획·운영·개발 담당자, 그리고 “정산 팀이 왜 그렇게 오래 걸리지?”라고 느낀 분을 위한 글입니다. 숫자를 모두 이해할 필요는 없지만, 한 주문이 돈·세금·수수료로 쪼개지는 흐름만 잡아 두면 CS·재무·개발이 같은 말을 하게 됩니다.
왜 ‘정산’이 따로 팀을 먹는가
마켓플레이스는 주문 한 건이 셀러·플랫폼·구매자의 세 원장에 동시에 찍히는 구조입니다. 결제가 끝났다고 끝이 아니라, 배송·클레임·부분 환불이 들어오면 정산 금액이 역으로 바뀝니다. 쇼핑몰을 직접 운영할 때와 달리, 중개자는 규칙을 코드와 계약서에 동시에 박아 두지 않으면 분기마다 스프레드시트 전쟁이 납니다.
집계 단위 고정하기
주문 기준인지 배송 완료 기준인지 먼저 정하지 않으면 OMS·WMS·정산 배치가 서로 다른 숫자를 냅니다. 정책이 바뀔 때는 effective_date로 버전을 남깁니다. “언제부터 이렇게 바뀌었나요?”라는 질문에 답하려면 날짜가 없으면 안 됩니다.
수수료와 프로모션
카테고리·셀러 등급·기간 한정 할인이 겹치면, 어떤 규칙이 먼저 적용되는지를 코드와 계약서가 같아야 합니다. 스프레드시트에만 있는 규칙은 분기마다 틀어집니다. 셀러 대시보드에 보이는 ‘예상 정산액’과 실제 이체액이 어긋나면 신뢰가 바로 깨집니다.
환불이 정산에 미치는 역류
부분 환불 한 번이 셀러 정산·플랫폼 수수료·부가세 표기를 동시에 건드립니다. 환불 접수와 이체 완료를 상태로 나누면 CS와 재무가 같은 언어를 씁니다. 사용자에게는 “환불되었습니다” 한 문장이지만, 내부적으로는 원장에 몇 줄이 더 생기는지까지 설계해야 합니다.
대사 배치
PG 일별 거래, 내부 ledger_entries, 셀러 지급 예정액을 맞출 때 불일치는 원인 코드로 분류해 큐에 넣습니다. 사람이 매번 해석하면 같은 사고가 반복됩니다. 대사는 ‘한 번 맞추고 끝’이 아니라, 다음 분기에도 같은 스크립트가 돌아가게 만드는 작업입니다.
흔한 오해
- “PG 정산서만 보면 된다” → 내부 원장·프로모션 분담·부분 환불까지 포함해야 전체가 맞습니다.
- “셀러 정산은 월 1회면 된다” → 클레임·환불이 일어나는 시점과 지급 약관이 다르면 분쟁이 납니다.
오늘부터 할 수 있는 한 가지
주문 한 건을 골라, 누가·언제·어떤 숫자를 ‘맞다’고 보는지를 표로 한 장 만들어 보세요. 그 표가 팀 회의실에 붙어 있으면 이미 절반은 성공입니다.
맺으며
정산은 ‘회계 일’이 아니라 제품 이벤트의 집합입니다. 주문·결제 글에서 다룬 멱등성·원장 개념과 이어서 읽으면 전체 그림이 선명해집니다.