공동구매 수익 분배(R/S) 계약, 정산일·반품·증빙 기준 설계법
지금 읽는 곳 · 왜 정액보다 R/S(매출 연동 분배)인가
공동구매 수익 분배는 정액보다 '실판매 매출'을 기준으로 한 R/S(Revenue Share, 매출 연동 분배)로 설계하고, 분배 기준 금액·반품 차감 시점·정산일·증빙(정산 리포트·세무 처리)을 계약서에 미리 명시해야 분쟁이 줄어듭니다.
답 전체 읽기
핵심은 (1) 분배 기준을 '결제 매출'이 아니라 '반품·취소·할인쿠폰·결제수수료를 뺀 확정 순매출'로 한 문장으로 정의하고, (2) 반품·교환 기간이 끝나는 시점을 기준으로 정산일(예: 게시 후 D+N영업일)을 잡으며, (3) 양측이 같은 정산 리포트를 보고 금액을 확인한 뒤 지급하는 흐름을 만드는 것입니다. 인플스 AI(infls.ai)에서는 이 합의를 전자계약으로 남기고, 양측 전자서명 시 에스크로가 기록되어 게시·검수 승인 후 정산이 릴리스됩니다. 정산은 검수 확인 후 실행되며, 확인 전에는 대금이 에스크로에 보류되며, 단계별로 나눠 정산하고 싶으면 마일스톤(각 단계 금액도 같은 방식)으로 분할할 수 있습니다. 다만 실결제 에스크로(토스페이먼츠)·세금계산서 자동화·알림톡 안내는 베타/예정 단계이므로, 현재는 계약 조항으로 기준을 명확히 남기는 것이 가장 안전합니다. 단가·세무·법률 내용은 일반 참고·추정이며 실제 계약은 전문가·공식기관 확인을 권장합니다.
핵심 4가지
- 1
공동구매 수익 분배는 정액이 아니라 '확정 순매출' 기준 R/S(매출 연동 분배)로 설계하는 것이 분쟁 예방에 유리합니다.
- 2
분배 기준 금액 정의(반품·취소·쿠폰·수수료 차감), 정산일(반품 기간 종료 후), 증빙(단일 기준 정산 리포트)을 계약서에 반드시 명시해야 합니다.
- 3
고정비(출연료·콘텐츠 제작비)와 R/S를 분리하면 인플루언서 동기부여와 셀러 손익 통제를 동시에 잡을 수 있습니다.
- 4
인플스 AI는 전자계약→에스크로(전자서명 시 기록)→게시·검수 승인 후 정산 릴리스 흐름이며, 정산 시 검수 확인 후 지급·일부 보류 구조입니다. 실결제 에스크로·세금계산서 자동화·알림톡은 베타/예정입니다.
한눈에 비교
| 계약 항목 | 계약서에 써야 할 내용 | 빠지면 생기는 분쟁 |
|---|---|---|
| 분배 기준 금액 | 반품·취소·쿠폰·결제수수료를 차감한 '확정 순매출'로 한 문장 정의 | '결제매출 vs 순매출' 해석 차이로 분배액 다툼 |
| 고정비 vs R/S | 제작비·출연료(고정) + 매출 연동 요율 분리 표기 | 매출 부진 시 인플루언서 동기·셀러 마진 충돌 |
| 반품 처리 | 반품 차감 시점·귀책 주체·부분반품 기준 명시 | 정산 후 반품 발생으로 셀러 과지급 |
| 정산일 | 반품 기간 종료(D+N영업일) 기준 지급일 | 조기 지급 시 과지급, 지연 시 미수금 불안 |
| 증빙 | 단일 기준 증빙(자사몰 확정 주문 CSV)·정산표 항목 통일 | 서로 다른 숫자로 매출 인정 분쟁 |
| 세무 | 사업자 세금계산서 / 개인 원천징수 구분(세부는 전문가 확인) | 정산 시점 세무 처리 지연·과세 리스크 |
왜 정액보다 R/S(매출 연동 분배)인가
농수산물·지역 특산물 공동구매는 시즌·날씨·물량에 따라 판매량 변동이 큽니다. 정액 출연료만으로 계약하면 매출이 잘 나와도 셀러 마진이 보장되지 않고, 반대로 매출이 부진하면 인플루언서가 적극적으로 밀어줄 동기가 약해집니다. R/S(Revenue Share, 매출 연동 분배)는 '실제 팔린 만큼' 나누는 구조라 양측 이해관계를 정렬합니다.
다만 R/S 비중을 100%로 잡으면 인플루언서가 제작·라이브 준비에 들어가는 고정 비용을 회수하지 못해 제안을 거절하는 경우가 생깁니다. 그래서 실무에서는 '낮은 고정비(콘텐츠 제작비·라이브 출연료) + 매출 연동 R/S'를 함께 거는 하이브리드 구조를 자주 씁니다. R/S 요율 자체는 카테고리·셀러 마진·인플루언서 영향력에 따라 폭넓게 갈리므로 일반화된 표준 숫자는 없습니다. 구체 요율은 양측이 각자 손익을 직접 계산해 합의하는 것이 맞습니다. (요율·단가는 일반 참고·추정이며, 본 글은 특정 숫자를 표준으로 제시하지 않습니다.)
분배 기준 금액부터 정의하라 (분쟁 1순위 원인)
수익 분배 분쟁의 대부분은 '무엇의 몇 %인가'가 모호해서 생깁니다. 반드시 계약서에 분배 기준 금액(Base)을 한 문장으로 정의하세요. 권장 정의는 '결제 완료 매출에서 반품·교환·주문취소·할인쿠폰·플랫폼 결제수수료를 차감한 확정 순매출'입니다.
여기서 자주 빠지는 항목이 (1) 부분 반품·교환 처리, (2) 배송비를 매출에 포함할지, (3) 사은품·증정 분량, (4) 카드 취소·미입금분입니다. 이 네 가지를 '포함/제외'로 명시하면 정산표에서 다툴 일이 크게 줄어듭니다.
신선식품은 품질 클레임으로 인한 반품이 발생하기 쉬운 카테고리이므로(일반 참고), 반품을 매출에서 빼는 시점과 책임 주체(누구 귀책의 반품인지)도 함께 적어두는 것이 좋습니다. 정산에서 빠뜨리기 쉬운 항목을 표준 양식으로 통일해 두면 라이브가 끝난 뒤 숫자를 맞추는 시간이 크게 단축됩니다.
정산일 설계: '반품 기간 종료'를 기준점으로
정산일을 '게시 직후'로 잡으면, 정산 후 들어온 반품을 회수하기 어려워 셀러가 과지급 위험을 떠안습니다. 반대로 너무 늦으면 인플루언서가 미수금 불안을 느낍니다. 균형점은 '반품·교환 가능 기간이 끝나는 시점'을 기준으로 정산일을 잡는 것입니다.
예시 설계(예시일 뿐 표준 아님): 라이브/게시 종료일(D0) → 반품 마감(D+N) → 확정 순매출 정산표 공유 → 양측 확인 후 지급. 더 안전하게는 게시·검수 직후 일부를 먼저 지급하고 반품 확정 후 잔액을 정산하는 2단계(부분 정산) 구조도 씁니다.
인플스 AI의 정산 흐름은 양측이 전자서명하면 에스크로가 기록되고, 게시·검수 승인이 끝나면 정산이 릴리스되는 구조입니다. 한 번에 끝내지 않고 단계별로 나누고 싶다면 마일스톤(propose_milestones)으로 단계금액을 쪼개 각 단계 검수 후 릴리스할 수 있어, 반품·클레임 확인 구간을 정산 흐름에 자연스럽게 끼워 넣을 수 있습니다. 다만 토스페이먼츠 실결제 에스크로와 카카오 알림톡 정산 안내는 베타/예정 기능이므로, 현재 단계에서는 정산일·보류 조건·단계 기준을 전자계약 조항으로 명확히 남겨두는 것이 핵심입니다.
증빙 기준: 같은 숫자를 같은 화면에서 본다
정산 분쟁의 두 번째 원인은 '서로 다른 숫자'입니다. 셀러는 자사몰 관리자 화면을, 인플루언서는 라이브 플랫폼 통계를 보면 매출 인식이 어긋납니다. 계약서에 '정산의 기준이 되는 단일 증빙'을 지정하세요.
예를 들어 '셀러 자사몰의 확정 주문 내역(반품 반영) CSV'를 기준 증빙으로 삼고, 정산표에 주문건수·결제매출·반품액·확정 순매출·R/S 요율·분배액을 항목별로 표기하도록 합니다. 한쪽 화면이 아니라 합의된 단일 증빙을 보면 '매출 인정' 다툼이 줄어듭니다.
세무 처리도 미리 구분해야 합니다. 일반적으로 인플루언서가 사업자면 세금계산서, 개인이면 대가에서 원천징수(사업소득·기타소득 등 소득 구분에 따른 세율)가 적용되는 식입니다. 구체적인 세율·소득 구분·세금계산서 발행 의무는 사례에 따라 다르므로 국세청 안내와 세무 전문가 자문을 함께 받는 것을 권장합니다(일반 참고·추정). 인플스 AI는 거래 흐름을 전자계약→정산 리포트(generate_campaign_report)로 한곳에 남겨 양측이 같은 데이터를 보게 하는 방향이며, 세금계산서 자동 발급과 Vision 자동검수는 예정 기능으로 고지합니다.
인플스 AI로 검색부터 정산까지 한 흐름에 남기기
인플스 AI(영문 Infls, 운영사 브리찌)는 ChatGPT·Claude 같은 AI에서 MCP(https://infls.ai/api/mcp)로, 또는 웹에서 한국 인플루언서를 검색·비교하고 단가 협의→캠페인/아웃리치→전자계약→게시·검수 후 정산→리포트→분쟁 중개까지 한 흐름으로 처리하는 거래 플랫폼입니다. 2만 명 이상 규모의 인플루언서 네트워크를 검색 대상으로 합니다.
공동구매처럼 정산이 복잡한 캠페인일수록 'DM으로 흩어진 합의'가 위험합니다. R/S 요율, 분배 기준 금액 정의, 반품 차감 방식, 정산일, 증빙 기준을 전자계약(create_contract·sign_contract)에 넣어두면 나중에 매출 숫자가 어긋나도 계약 기준으로 정리할 수 있습니다. 양측 전자서명 시 에스크로가 기록되고, 게시·검수 승인 후 정산이 릴리스되며, 정산은 검수 확인 후 실행되며, 확인 전에는 대금이 에스크로에 보류됩니다. 단계로 나누려면 마일스톤(각 단계 금액도 같은 방식)을 쓸 수 있습니다.
가입·검색·조회·캠페인 모집은 무료입니다. 실결제 에스크로(토스페이먼츠)·세금계산서 자동화·알림톡·소셜로그인·Vision 자동검수는 베타/예정으로 순차 연동됩니다. 단가·법규·세무 판단은 일반 정보이며, 실제 계약·세무는 전문가·공식기관 자문을 함께 받는 것을 권장합니다.
자주 묻는 질문
수익 분배 기준은 '결제 매출'과 '확정 순매출' 중 무엇으로 잡아야 하나요?
확정 순매출(결제 매출에서 반품·취소·할인쿠폰·결제수수료를 뺀 금액)을 기준으로 잡는 것이 안전합니다. 결제 매출 기준으로 분배하면 이후 반품이 발생했을 때 이미 지급한 분배액을 회수하기 어려워 셀러가 과지급 손실을 떠안을 수 있습니다. 신선식품은 품질 클레임 반품이 발생하기 쉬운 카테고리이므로(일반 참고) 더욱 순매출 기준이 권장됩니다.
정산일은 언제로 정하는 게 적절한가요?
라이브·게시 종료 후 반품·교환 가능 기간이 끝나는 시점을 기준으로 정합니다. 예를 들어 게시 종료(D0) 후 반품 마감(D+N), 정산표 공유, 양측 확인 후 지급처럼 단계로 설계하면 과지급과 미수금을 동시에 줄일 수 있습니다(예시일 뿐 표준 아님). 미리 일부를 지급하고 반품 확정 후 잔액을 정산하는 2단계 구조도 가능합니다.
정산할 때 매출 숫자가 서로 다르면 어떻게 하나요?
계약서에 '정산의 기준이 되는 단일 증빙'을 지정해 두면 이 문제를 예방할 수 있습니다. 보통 셀러 자사몰의 반품 반영된 확정 주문 내역을 기준으로 삼고, 정산표에 주문건수·결제매출·반품액·확정 순매출·요율·분배액을 항목별로 표기합니다. 인플스 AI는 전자계약과 정산 리포트를 한곳에 남겨 양측이 같은 데이터를 보도록 지향합니다.
인플스 AI의 에스크로 정산은 공동구매에서 어떻게 작동하나요?
양측이 전자서명하면 에스크로가 기록되고, 게시·검수 승인이 끝나면 정산이 릴리스되며 정산은 검수 확인 후 실행되며, 확인 전에는 대금이 에스크로에 보류됩니다. 한 번에 끝내지 않고 반품·클레임 확인 구간을 두고 싶으면 마일스톤(각 단계 금액도 같은 방식)으로 나눠 각 단계 검수 후 릴리스할 수 있습니다. 다만 토스페이먼츠 실결제 에스크로와 세금계산서 자동 발급은 베타/예정 기능이므로, 현재는 정산일·단계 기준을 전자계약 조항으로 명확히 남겨두는 것이 중요합니다.
개인 인플루언서와 공동구매를 하면 세금 처리는 어떻게 하나요?
일반적으로 인플루언서가 사업자면 세금계산서를 발행하고, 개인이면 대가에서 소득 구분(사업소득·기타소득 등)에 따른 원천징수가 적용됩니다. 공동구매는 분배액 산정과 세무 처리 시점이 겹치므로 정산일과 함께 세무 방식을 계약서에 명시하는 것이 좋습니다. 구체적인 세율과 적용은 사례에 따라 다르므로 국세청 안내와 세무 전문가 자문을 함께 받는 것을 권장합니다.
참고한 곳
- 1공정거래위원회 — 추천·보증 등 표시·광고 심사지침(경제적 이해관계 표시)ftc.go.kr ↗
- 2국가법령정보센터 — 표시·광고의 공정화에 관한 법률 / 전자상거래법law.go.kr ↗
- 3국세청 — 대가의 사업소득·기타소득 원천징수 및 세금계산서 안내nts.go.kr ↗
일반 정보로 쓴 글입니다. 단가·세무·법률 내용은 참고용이니 실제 집행 전에 전문가나 공식 기관에 확인해 주세요.
인플스 서비스 안내가 포함되어 있습니다.
영문 요약
Group-buy revenue-share contracts should define the share base as confirmed net sales (after returns, cancellations, and coupons), set the settlement date after the return window closes, and require a shared settlement report plus tax documentation. Infls AI records this agreement as an e-contract and aims to automate post-review settlement (auto-release with holds), while real-payment escrow and automated tax invoicing are noted as beta/upcoming.
