핵심 요약
- 이 글을 다 읽으면 사업 모델에 가장 유리하면서도 운영 리스크가 낮은 정산 주기와 유보금 정책을 직접 설계할 수 있어요.
- 정산 주기는 판매자의 서비스 유지 의지(현금 흐름)와 플랫폼의 운영 리스크(환불 대응력) 사이에서 결정돼요.
- 익일 정산은 판매자 확보에 유리하지만 환불용 유보금 정책이 필수이며, 구매확정 후 정산은 이커머스의 표준이나 정산 대사 복잡도가 높아요.
- 재무팀의 캐시플로우와 개발팀의 정산 시스템 구현 공수를 고려하여 서비스 초기에는 '주 단위' 또는 '월 2회' 정산으로 시작해 점진적으로 단축하는 것이 안전해요.
1입점사 이탈을 막고 운영 효율을 높이는 사업별 정산 주기 선택법
업종의 특성에 맞는 정산 주기를 설정해야 판매자의 만족도를 높이면서 플랫폼의 자금 회전 리스크를 관리할 수 있어요. 판매자가 기대하는 정산 속도는 업종의 마진율과 자금 회전 속도에 비례해요.
이커머스 및 마켓플레이스 (구매확정 후 N일)
가장 보편적인 모델이에요. 배송이 완료되고 고객이 구매확정을 누른 시점으로부터 1~3 영업일 이내에 정산해요.
- 특징: '구매확정'이라는 명확한 법적·운영적 기준이 있어 환불 리스크가 낮아요.
- 주의: 고객이 구매확정을 누르지 않을 경우를 대비해 '배송 완료 후 7일 뒤 자동 구매확정' 같은 정책이 반드시 선행되어야 해요.
배달 및 오프라인 연동 서비스 (익일 정산)
현금 흐름이 매우 빠른 업종이에요. 오늘 판매한 대금이 내일 바로 입금되지 않으면 소상공인 판매자분들의 운영이 어려워져요.
- 특징: 판매자 확보를 위한 핵심 경쟁력이에요.
- 주의: 카드사로부터 대금이 들어오기 전에 플랫폼이 먼저 지급하는 '선지급' 형태가 되므로 플랫폼의 자본력이 요구돼요.
SaaS 및 디지털 콘텐츠 (월 정산 또는 주 정산)
재고가 없고 환불 발생 빈도가 상대적으로 낮은 업종이에요.
- 특징: 운영 효율을 위해 월 1회 또는 2회 정산하는 경우가 많아요.
- 주의: 구독형 서비스라면 '중도 해지 시 환불' 규정에 따라 정산 대금이 차감될 수 있음을 약관에 명시해야 해요.
2자금 사고와 미회수 리스크를 방어하는 '환불 유보금' 설계
정산 주기 단축으로 인해 발생하는 '선지급 후 환불' 리스크를 방지하기 위해 유보금(Reserve) 정책을 반드시 병행해야 해요. 정산 주기가 빨라질수록 플랫폼은 '돈은 이미 줬는데 환불 요청이 들어오는' 상황에 노출돼요.
유보금이 필요한 이유
카드는 기본적으로 결제 승인 '취소' 처리가 되어 대금이 정산 전 차감되지만, 가상계좌 입금 후에는 이미 정산된 금액을 돌려받는 '환불' 처리를 해야 해요. 정산이 완료된 후 고객이 환불을 요구하면 판매자의 다음 정산 대금에서 차감하거나 판매자에게 직접 돈을 돌려받아야 해요. 판매자가 정산만 받고 잠적하거나 폐업할 경우 그 손실은 플랫폼이 고스란히 떠안게 돼요.
유보금 설정 프레임워크
- 정산 대상 금액의 일부 보관: 전체 정산 대금의 5~10%를 차기 정산 시까지 지급 유예해요.
- 보관 기간: 해당 업종의 평균 환불 발생 기간(보통 7~14일) 동안 유지해요.
- 등급별 차등: 거래 이력이 길고 신뢰도가 높은 판매자분에게는 유보율을 낮춰주는 혜택을 제공해요.
3무리한 단축이 만드는 현금 흐름과 전산 사고
기획 단계에서 정산 주기를 결정할 때 재무팀의 자금 상황과 개발팀의 시스템 안정성을 반드시 확인해야 해요.
재무팀: 캐시플로우와 세무 증빙
PG사로부터 정산 대금이 들어오는 주기는 보통 결제일로부터 2~5 영업일이에요. 플랫폼이 판매자에게 익일 정산을 해주려면 카드사 대금이 들어오기 전에 회사의 자체 자금으로 먼저 지급해야 해요. 또한 정산 주기마다 세금계산서 발행이나 지급 처리를 해야 하므로 주기와 인력 공수는 비례해요.
개발팀: 정산 대사(Reconciliation)의 복잡도
매일 정산을 하려면 '어제 결제된 건', '어제 취소된 건', '지난주에 결제됐으나 어제 구매확정된 건' 등을 매일 정확히 추출해야 해요.
- 삽질 포인트: 정산 주기를 너무 짧게 잡으면 전산 오류나 데이터 미동기화 시 수정할 시간이 부족해져요. 오지급 사고는 시스템 신뢰도에 치명적이에요.
4사업 유형별 정산 주기 및 정책 추천 기준표
이 표를 복사하여 우리 서비스의 정산 정책 의사결정 회의 초안으로 활용해요.
| 항목 | 표준 모델 (이커머스) | 공격적 모델 (플랫폼) | 안전형 모델 (SaaS/B2B) |
|---|---|---|---|
| 정산 주기 | 구매확정 후 D+2 | 결제 완료 후 D+1 (익일) | 매월 15일, 말일 (월 2회) |
| 판단 기준 | 고객의 구매확정 액션 | 플랫폼의 선지급 자본력 | 운영 효율 및 정산 대사 편의 |
| 환불 정책 | 구매확정 전까지만 취소 가능 | 정산 후 환불 시 차기 대금 차감 | 환불 발생 시 정산금에서 상계 |
| 유보금 정책 | 불필요 (구매확정 후 지급하므로) | 필수 (정산금의 10% 유보) | 선택 (판매자 신용도에 따라) |
| 추천 업종 | 종합 쇼핑몰, 의류, 잡화 | 배달, 퀵서비스, 급전이 필요한 업종 | 소프트웨어 구독, 교육 콘텐츠 |
다음 단계
정산 주기를 정했다면, 이제 어떤 정산 모델로 돈을 나눌지와 대사 자동화 시점을 함께 판단해야 해요.
추천 콘텐츠
플랫폼인데 셀러 정산을 엑셀로 하고 있다면 분리정산, 수취 후 지급, 에스크로 중 어떤 구조가 맞는지 다시 좁혀요.
월 거래 500건 넘었다면? 엑셀 대사 그만두고 자동화로 갈아탈 시점과 판단 기준 거래가 늘어날 때 엑셀 대사를 언제 자동화해야 하는지 봐요.
실제 연동할 때
주기·유보금 정책을 정했다면 코드는 다음 순서로 확인해요.
- 주문 이해하기 — 주문 상태와 정산 기준 시점 연결
- 주문 아키텍처 — OrderPre · Order · OrderPurchase 3단 흐름
- 구독 청구 주기 — 구독형 정산 주기 운영
바로 참고할 문서
- 더 복잡한 판단이 필요하다면: 부트페이 도입 문의
