{"content_id":"zpxre8owiy","slug":"seven-policies-before-building-ai-settlement-system","locale":"ko","schema_type":"HowTo","category":"how_to","category_name":"하우투","title":"AI로 정산 시스템을 만들기 전 정해야 할 7가지 정책","summary":"정산은 판매액에서 수수료를 빼는 계산 기능이 아니라 판매대금의 귀속, 지급 조건, 환불, 세금, 실패 처리를 통제하는 금융 운영 체계다. AI에 구현을 맡기기 전 정산 기준일부터 감사 로그까지 7가지 정책을 사람이 먼저 확정해야 한다.","author":{"name":"인조이스 편집팀","url":"https://injoys.com/ko/about"},"key_points":["판매대금은 플랫폼의 자유로운 운영자금이 아니라 판매자 등에 지급해야 할 의무와 연결된 제한성 자금으로 관리해야 한다.","주문 상태와 정산 상태를 분리하고 구매 확정, 환불, 분쟁, 지급 실패를 각각 장부에 기록해야 한다.","개인 판매자에게 항상 3.3%를 원천징수하는 것은 아니며 소득의 법적 성격과 판매자 지위에 따라 판단해야 한다.","PG나 에스크로를 이용해도 정산 주기, 수수료, 보류, 마이너스 이월과 세무 정책은 플랫폼이 결정해야 한다.","AI가 생성한 정산 코드는 회계 원장 대사, 중복 지급 방지, 권한 통제와 전문가 검토를 거친 뒤 운영해야 한다."],"content_markdown":"정산은 단순한 뺄셈 기능이 아니다. 주문별 권리와 의무를 확정하고, 플랫폼이 보관하거나 지급해야 할 자금을 분리하며, 환불·분쟁·세금·송금 실패까지 추적하는 장부 시스템이다.\n\n생성형 AI는 코드와 테스트 작성을 도울 수 있지만 정산 정책의 책임 주체가 될 수는 없다. 정책이 비어 있으면 AI는 그럴듯한 기본값을 만들거나 예외를 누락할 수 있으며, 그 결과는 과지급, 중복 지급, 세금 오류 또는 유동성 사고로 이어질 수 있다.\n\n## 2024년 티몬·위메프 사태에서 확인할 원칙\n\n2024년 티몬과 위메프의 대규모 판매대금 미정산은 정산 지연이 판매자와 소비자에게 얼마나 큰 연쇄 피해를 줄 수 있는지 보여줬다. 다만 사태의 원인을 긴 정산 주기 하나로만 단정해서는 안 된다. 자금 운용, 유동성, 지배구조와 내부 통제 등 여러 요인이 함께 검토돼야 한다.\n\n운영자가 얻어야 할 핵심 교훈은 명확하다.\n\n- 아직 지급하지 않은 판매대금을 자유롭게 쓸 수 있는 회사 현금으로 간주하지 않는다.\n- 정산 주기가 길수록 한 번의 장애나 유동성 부족에 노출되는 미지급 잔액이 커진다.\n- 판매대금 잔액과 실제 보관 자금을 매일 대사한다.\n- 정산 조건과 지연 사유를 판매자에게 투명하게 공개한다.\n- 관련 법령, 계약 구조와 PG 서비스 범위를 따로 확인한다.\n\n판매대금의 법적 귀속과 보호 방식은 거래 구조에 따라 달라질 수 있다. 따라서 일상적으로는 ‘남의 돈’이라는 경계심을 유지하되, 실제 회계·법률 처리는 계약과 현행 법령에 따라 판단해야 한다.\n\n## 구현 전에 정해야 할 7가지 정산 정책\n\n### 1. 정산 기준일과 지급 주기\n\n먼저 주문이 언제 정산 가능한 상태가 되는지 정의한다. 주문일이나 결제일만 기준으로 삼으면 배송 전 취소와 반품 가능 금액이 지급 대상에 들어갈 수 있다.\n\n일반적인 상품 거래에서는 다음과 같은 흐름을 설계할 수 있다.\n\n1. 결제 승인\n2. 배송 완료\n3. 구매 확정 또는 약정된 기간 경과에 따른 자동 확정\n4. 반품·분쟁·이상 거래 여부 검사\n5. 정산 대상 확정\n6. 지급 배치 편입\n7. 송금 및 대사 완료\n\n반드시 결정할 항목은 다음과 같다.\n\n- 상품, 디지털 콘텐츠, 서비스 등 거래 유형별 정산 기준 사건\n- 자동 구매 확정까지의 기간과 기산 시점\n- 매일, 매주 또는 월 단위의 지급 주기\n- 주말과 공휴일 처리 방식\n- 정산 마감 시각과 마감 이후 거래의 귀속 배치\n- 최소 지급액과 소액 잔액 이월 여부\n- 판매자 등급별로 다른 주기를 허용할지 여부\n- 법령이나 계약상 지급 기한을 초과하지 않는지 확인하는 절차\n\n정산 가능일과 실제 지급일은 구분해야 한다. 예를 들어 `eligible_at`은 지급 조건을 충족한 시각이고, `scheduled_payout_at`은 지급 배치에 편입된 시각이며, `paid_at`은 송금 성공이 확인된 시각이다.\n\n### 2. 수수료 계산과 정산 명세서\n\n판매자에게 최종 지급액만 보여주면 검산이 어렵고 문의와 분쟁이 늘어난다. 주문 단위 명세와 기간별 합계가 모두 필요하다.\n\n| 명세 항목 | 설명 |\n|---|---|\n| 총거래액 | 상품가, 옵션가, 배송비 등 계약상 판매액 구성 |\n| 할인 부담액 | 플랫폼·판매자·제휴사가 각각 부담한 할인 |\n| 취소·환불액 | 전액 및 부분 환불과 배송비 조정 |\n| 플랫폼 수수료 | 수수료율, 정액 수수료와 과세 여부 |\n| 결제 관련 비용 | PG 비용을 별도 공제하는지 수수료에 포함하는지 표시 |\n| 세금 조정 | 부가가치세 표시, 원천징수 등 해당 항목 |\n| 기타 조정 | 보상금, 광고비, 페널티 등 계약상 근거가 있는 조정 |\n| 최종 지급액 | 모든 가감 항목을 반영한 송금 예정액 |\n\n수수료 정책에는 계산 기준도 명시해야 한다. 할인 전 판매가와 할인 후 결제액 중 무엇을 기준으로 하는지, 배송비와 부가가치세를 포함하는지, 부분 환불 시 수수료를 어떻게 되돌리는지 정해야 한다.\n\n금액은 부동소수점 자료형으로 계산하지 않는 것이 안전하다. 원화처럼 최소 화폐 단위가 정수인 경우 정수로 저장하고, 외화나 소수 계산이 필요하면 고정소수점 자료형과 통화별 반올림 규칙을 사용한다.\n\n### 3. 환불과 마이너스 정산\n\n이미 판매자에게 지급한 주문이 나중에 환불될 수 있다. 이 경우 환불액과 환급할 수수료를 조정 원장에 기록하고 다음 지급액에서 차감해야 한다.\n\n예를 들어 이번 정산 예정액이 30만 원이고 이전 주문의 환불 관련 차감액이 40만 원이라면 다음과 같이 처리할 수 있다.\n\n- 이번 지급액: 0원\n- 미회수 잔액: 마이너스 10만 원\n- 다음 정산으로 넘길 금액: 10만 원 차감\n\n정책에는 다음 항목이 필요하다.\n\n- 부분 환불 시 상품가, 배송비와 수수료의 배분 방식\n- 마이너스 잔액의 이월 기간과 상계 순서\n- 장기간 판매가 없는 판매자에게 회수하는 방법\n- 보증금이나 지급준비금을 둘 수 있는 계약상 근거\n- 판매자 탈퇴 전에 미결제 의무를 확인하는 절차\n- 환불 취소나 분쟁 결과 변경 시 반대 분개하는 방식\n\n기존 거래 기록을 덮어쓰지 말고 원거래와 조정 거래를 연결해야 한다. 그래야 어느 환불이 어떤 정산을 변경했는지 재현할 수 있다.\n\n### 4. 지급 보류와 해제\n\n전체 판매자 계정의 지급을 무조건 중단하기보다 주문, 금액 또는 사유별로 보류할 수 있어야 한다. 대표적인 보류 사유는 다음과 같다.\n\n- 소비자 분쟁이나 반품 진행\n- 자전거래, 계정 탈취 또는 비정상 결제 의심\n- 판매자 본인·사업자·계좌 인증 실패\n- 법원, 수사기관 또는 관계 기관의 적법한 요청\n- 계약상 정산 서류 미제출\n\n각 보류 기록에는 대상 금액, 사유 코드, 근거 자료, 시작 시각, 검토 기한, 담당자와 해제 조건을 저장한다. 판매자 화면에는 공개 가능한 범위에서 보류 금액과 이유, 필요한 조치, 문의 경로를 표시한다.\n\n운영자가 임의로 보류를 반복하지 못하도록 생성과 해제 권한을 분리하고, 큰 금액의 보류 해제에는 이중 승인을 적용하는 것이 좋다.\n\n### 5. 판매대금 분리 관리와 PG·에스크로 구조\n\n미지급 판매대금과 회사 운영비를 같은 가용 현금처럼 관리하면 유동성 부족이 곧 미정산으로 번질 수 있다. 최소한 내부 장부와 계좌 운영에서 판매대금 관련 자금과 운영자금을 명확히 구분하고 매일 잔액을 대사해야 한다.\n\n다만 별도 계좌를 만들었다는 사실만으로 법적 도산격리나 완전한 자금 보호가 자동으로 성립하는 것은 아니다. 신탁, 예치, 지급보증 등 보호 방식의 효력과 의무는 적용 법령 및 계약 구조를 검토해야 한다.\n\n플랫폼이 결제와 지급 과정에서 어떤 역할을 수행하는지에 따라 전자지급결제대행업 등 전자금융거래법상 등록 문제가 발생할 수 있다. 모든 플랫폼이 동일하게 PG 등록 대상인 것도 아니고, 단순히 정산 데이터를 계산했다는 이유만으로 항상 등록 대상이 되는 것도 아니다. 실제 자금 수취·보관·전달 방식과 계약관계로 판단해야 한다.\n\n초기 플랫폼은 등록 PG가 제공하는 결제, 에스크로 또는 판매자별 분할 정산 서비스를 검토할 수 있다. 그러나 PG를 이용해도 다음 책임은 사라지지 않는다.\n\n- 어떤 주문을 언제 지급 대상으로 전달할지 결정\n- 수수료와 조정액 계산\n- 환불과 마이너스 이월 관리\n- 판매자 정보와 계좌 검증\n- PG 결과와 내부 원장 대사\n- 장애와 지급 실패 대응\n\n에스크로 의무와 예외도 거래 유형과 결제수단 등에 따라 다르므로 전자상거래법과 하위 규정을 확인해야 한다.\n\n### 6. 원천징수, 부가가치세와 증빙\n\n‘개인 판매자는 무조건 3.3%를 뗀다’는 규칙은 정확하지 않다. 3.3%는 일반적으로 사업소득에 대한 소득세 3%와 개인지방소득세 0.3%를 합쳐 부르는 표현이다. 실제 원천징수 여부는 판매자의 사업자등록 유무만이 아니라 소득의 성격, 계약관계, 지급 항목과 예외 규정에 따라 달라진다.\n\n가입과 계약 단계에서 다음 정보를 받아야 한다.\n\n- 개인, 개인사업자, 법인 등 판매자 유형\n- 국내외 거주자 또는 법인 여부\n- 과세, 면세, 간이과세 등 세무상 상태\n- 사업자등록번호와 주민등록번호 등 법정 신고에 필요한 정보\n- 소득의 성격과 지급 사유\n- 세금계산서, 계산서 또는 원천징수영수증 등 필요한 증빙\n\n사업자 판매자에게도 ‘항상 아무 세금도 공제하지 않고 100% 지급한다’고 일반화하면 안 된다. 플랫폼 수수료를 차감하는 계약이라면 거래 총액, 수수료, 부가가치세와 실제 송금액을 구분해야 한다. 플랫폼이 제공한 중개 서비스의 수수료에 대한 세금계산서 발급 주체와 시점도 계약 및 세법상 공급관계에 맞춰 정한다.\n\n원천세는 통상 지급일이 속하는 달의 다음 달 10일까지 신고·납부하는 구조가 적용되지만, 예외나 기한 변경 가능성이 있으므로 실제 신고 시점의 규정을 확인해야 한다. 세무 규칙을 코드에 고정하기보다 적용 시작일과 종료일이 있는 버전형 정책으로 관리하는 편이 안전하다.\n\n### 7. 지급 실패, 정산 어드민과 감사 로그\n\n정상적으로 생성된 지급도 계좌 오류, 예금주 불일치, 거래 제한, 은행 점검 또는 PG 장애로 실패할 수 있다. 실패를 단순히 ‘미지급’으로 표시하지 말고 상태와 재처리 규칙을 세분화한다.\n\n권장 상태 예시는 다음과 같다.\n\n- `scheduled`: 지급 예약\n- `submitted`: 은행 또는 PG에 요청 전달\n- `processing`: 외부 기관 처리 중\n- `paid`: 성공 확인\n- `failed_retryable`: 재시도 가능한 실패\n- `failed_final`: 정보 수정 등이 필요한 최종 실패\n- `reversed`: 성공 후 취소 또는 반환\n\n재시도에는 동일 지급을 식별하는 멱등성 키를 사용해야 한다. 응답 지연을 실패로 오인해 다시 송금하면 중복 지급이 발생할 수 있으므로, 외부 거래번호를 조회해 기존 요청의 결과를 먼저 확인한다.\n\n감사 로그에는 다음을 남긴다.\n\n- 행위자와 사용한 운영자 계정\n- 실행 시각과 접근 위치 등 보안 정보\n- 변경 전후 값\n- 보류·해제·수동 조정의 사유\n- 승인자와 실행자\n- 관련 주문, 정산 배치와 외부 거래번호\n- 실패 코드와 재시도 이력\n\n감사 로그는 일반 운영자가 수정하거나 삭제할 수 없도록 보호하고, 개인정보와 금융정보는 최소 수집, 접근 통제, 암호화와 보존기간 정책을 적용한다.\n\n## 정산 데이터 모델의 최소 구성\n\nAI에 화면부터 만들게 하기보다 다음 원장을 먼저 정의하는 것이 좋다.\n\n| 데이터 객체 | 역할 |\n|---|---|\n| 주문 원장 | 주문·결제·배송·구매 확정 상태 기록 |\n| 정산 항목 | 주문별 총액, 수수료, 세금, 조정액과 귀속 판매자 기록 |\n| 조정 원장 | 환불, 보상, 페널티와 수동 조정 기록 |\n| 보류 원장 | 보류 금액, 사유, 기한과 해제 이력 기록 |\n| 정산 배치 | 특정 기간과 판매자의 지급 대상 묶음 |\n| 지급 원장 | 송금 요청, 성공·실패와 외부 거래번호 기록 |\n| 세무 원장 | 원천징수와 증빙 발급·신고 상태 기록 |\n| 감사 로그 | 운영자와 시스템의 모든 중요 변경 기록 |\n\n각 원장에는 통화, 정책 버전, 생성 시각과 원거래 연결 키가 있어야 한다. 주문 상태를 바꾸는 것만으로 과거 정산 금액이 조용히 변경돼서는 안 된다.\n\n## 반드시 유지해야 할 통제 규칙\n\n정산 시스템은 다음과 같은 불변 조건을 자동 검사해야 한다.\n\n- 하나의 정산 항목은 정확히 한 판매자와 한 원거래에 연결된다.\n- 동일한 지급 키로 두 번 송금하지 않는다.\n- 지급 완료액과 미지급액, 보류액, 조정액의 합계가 원장과 일치한다.\n- 수동 조정에는 사유와 승인자가 존재한다.\n- 이미 마감한 정산은 수정하지 않고 반대 분개와 새 조정으로 고친다.\n- 내부 판매대금 관련 잔액과 PG·은행 잔액의 차이를 매일 조사한다.\n- 세금과 수수료 계산에는 적용된 정책 버전을 기록한다.\n\n## AI에 전달할 정책 명세 예시\n\n다음과 같이 요구사항을 구조화하면 누락을 줄일 수 있다.\n\n\u003e 주문 상태와 정산 상태를 분리해 설계한다. 거래 유형별 구매 확정 조건, 매주 수요일 지급 배치, 휴일 처리, 수수료 기준, 부분 환불 배분, 마이너스 이월, 건별 지급 보류, 원천징수 정책 버전, 지급 멱등성 키와 변경 불가능한 감사 로그를 구현한다. 금액은 정수 또는 고정소수점으로 처리한다. 모든 수동 조정에는 이중 승인과 사유가 필요하다. 구현하기 전에 최소 지급액, 자동 구매 확정 기간, 장기 마이너스 회수, 보류 기한, 재시도 횟수처럼 정해지지 않은 정책을 질문 목록으로 제시하라.\n\nAI에는 코드만 요청하지 말고 다음 산출물도 함께 요구한다.\n\n- 상태 전이도와 예외 목록\n- 데이터베이스 스키마와 제약조건\n- 권한·승인 체계\n- 정상, 경계값, 장애와 중복 요청 테스트\n- 일별 대사 보고서 형식\n- 장애 복구와 수동 처리 절차\n- 개인정보와 금융정보 보호 점검표\n\n## 출시 전 점검표\n\n- [ ] 거래 유형별 정산 기준일이 문서화돼 있다.\n- [ ] 판매자가 정산 명세를 주문 단위로 검산할 수 있다.\n- [ ] 부분 환불과 마이너스 이월 테스트를 통과했다.\n- [ ] 보류 사유, 기한과 해제 권한이 정의돼 있다.\n- [ ] 판매대금 관련 자금과 운영자금의 관리 기준이 구분돼 있다.\n- [ ] PG·에스크로·전자금융업 해당 여부를 전문가와 확인했다.\n- [ ] 판매자 및 소득 유형별 세무 처리를 검토했다.\n- [ ] 중복 지급 방지와 실패 재시도 테스트를 완료했다.\n- [ ] 은행·PG·내부 원장의 일별 대사가 가능하다.\n- [ ] 운영자의 수동 변경이 감사 로그에 남는다.\n- [ ] 정산 장애 시 판매자 공지와 문의 대응 절차가 있다.\n\n## 결론\n\n안전한 정산 시스템의 출발점은 AI 프롬프트가 아니라 명시적인 정책과 분리된 원장이다. AI는 확정된 규칙을 코드, 테스트와 문서로 옮기는 도구로 활용하고, 자금 보관 구조와 전자금융·세무 판단은 PG, 회계·세무 전문가 및 법률 전문가와 함께 검증해야 한다.","content_html":"\u003cp\u003e정산은 단순한 뺄셈 기능이 아니다. 주문별 권리와 의무를 확정하고, 플랫폼이 보관하거나 지급해야 할 자금을 분리하며, 환불·분쟁·세금·송금 실패까지 추적하는 장부 시스템이다.\u003c/p\u003e\n\u003cp\u003e생성형 AI는 코드와 테스트 작성을 도울 수 있지만 정산 정책의 책임 주체가 될 수는 없다. 정책이 비어 있으면 AI는 그럴듯한 기본값을 만들거나 예외를 누락할 수 있으며, 그 결과는 과지급, 중복 지급, 세금 오류 또는 유동성 사고로 이어질 수 있다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#2024%EB%85%84-%ED%8B%B0%EB%AA%AC%EC%9C%84%EB%A9%94%ED%94%84-%EC%82%AC%ED%83%9C%EC%97%90%EC%84%9C-%ED%99%95%EC%9D%B8%ED%95%A0-%EC%9B%90%EC%B9%99\" class=\"anchor\" id=\"2024년-티몬위메프-사태에서-확인할-원칙\"\u003e\u003c/a\u003e2024년 티몬·위메프 사태에서 확인할 원칙\u003c/h2\u003e\n\u003cp\u003e2024년 티몬과 위메프의 대규모 판매대금 미정산은 정산 지연이 판매자와 소비자에게 얼마나 큰 연쇄 피해를 줄 수 있는지 보여줬다. 다만 사태의 원인을 긴 정산 주기 하나로만 단정해서는 안 된다. 자금 운용, 유동성, 지배구조와 내부 통제 등 여러 요인이 함께 검토돼야 한다.\u003c/p\u003e\n\u003cp\u003e운영자가 얻어야 할 핵심 교훈은 명확하다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e아직 지급하지 않은 판매대금을 자유롭게 쓸 수 있는 회사 현금으로 간주하지 않는다.\u003c/li\u003e\n\u003cli\u003e정산 주기가 길수록 한 번의 장애나 유동성 부족에 노출되는 미지급 잔액이 커진다.\u003c/li\u003e\n\u003cli\u003e판매대금 잔액과 실제 보관 자금을 매일 대사한다.\u003c/li\u003e\n\u003cli\u003e정산 조건과 지연 사유를 판매자에게 투명하게 공개한다.\u003c/li\u003e\n\u003cli\u003e관련 법령, 계약 구조와 PG 서비스 범위를 따로 확인한다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e판매대금의 법적 귀속과 보호 방식은 거래 구조에 따라 달라질 수 있다. 따라서 일상적으로는 ‘남의 돈’이라는 경계심을 유지하되, 실제 회계·법률 처리는 계약과 현행 법령에 따라 판단해야 한다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EA%B5%AC%ED%98%84-%EC%A0%84%EC%97%90-%EC%A0%95%ED%95%B4%EC%95%BC-%ED%95%A0-7%EA%B0%80%EC%A7%80-%EC%A0%95%EC%82%B0-%EC%A0%95%EC%B1%85\" class=\"anchor\" id=\"구현-전에-정해야-할-7가지-정산-정책\"\u003e\u003c/a\u003e구현 전에 정해야 할 7가지 정산 정책\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#1-%EC%A0%95%EC%82%B0-%EA%B8%B0%EC%A4%80%EC%9D%BC%EA%B3%BC-%EC%A7%80%EA%B8%89-%EC%A3%BC%EA%B8%B0\" class=\"anchor\" id=\"1-정산-기준일과-지급-주기\"\u003e\u003c/a\u003e1. 정산 기준일과 지급 주기\u003c/h3\u003e\n\u003cp\u003e먼저 주문이 언제 정산 가능한 상태가 되는지 정의한다. 주문일이나 결제일만 기준으로 삼으면 배송 전 취소와 반품 가능 금액이 지급 대상에 들어갈 수 있다.\u003c/p\u003e\n\u003cp\u003e일반적인 상품 거래에서는 다음과 같은 흐름을 설계할 수 있다.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e결제 승인\u003c/li\u003e\n\u003cli\u003e배송 완료\u003c/li\u003e\n\u003cli\u003e구매 확정 또는 약정된 기간 경과에 따른 자동 확정\u003c/li\u003e\n\u003cli\u003e반품·분쟁·이상 거래 여부 검사\u003c/li\u003e\n\u003cli\u003e정산 대상 확정\u003c/li\u003e\n\u003cli\u003e지급 배치 편입\u003c/li\u003e\n\u003cli\u003e송금 및 대사 완료\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e반드시 결정할 항목은 다음과 같다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e상품, 디지털 콘텐츠, 서비스 등 거래 유형별 정산 기준 사건\u003c/li\u003e\n\u003cli\u003e자동 구매 확정까지의 기간과 기산 시점\u003c/li\u003e\n\u003cli\u003e매일, 매주 또는 월 단위의 지급 주기\u003c/li\u003e\n\u003cli\u003e주말과 공휴일 처리 방식\u003c/li\u003e\n\u003cli\u003e정산 마감 시각과 마감 이후 거래의 귀속 배치\u003c/li\u003e\n\u003cli\u003e최소 지급액과 소액 잔액 이월 여부\u003c/li\u003e\n\u003cli\u003e판매자 등급별로 다른 주기를 허용할지 여부\u003c/li\u003e\n\u003cli\u003e법령이나 계약상 지급 기한을 초과하지 않는지 확인하는 절차\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e정산 가능일과 실제 지급일은 구분해야 한다. 예를 들어 \u003ccode\u003eeligible_at\u003c/code\u003e은 지급 조건을 충족한 시각이고, \u003ccode\u003escheduled_payout_at\u003c/code\u003e은 지급 배치에 편입된 시각이며, \u003ccode\u003epaid_at\u003c/code\u003e은 송금 성공이 확인된 시각이다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#2-%EC%88%98%EC%88%98%EB%A3%8C-%EA%B3%84%EC%82%B0%EA%B3%BC-%EC%A0%95%EC%82%B0-%EB%AA%85%EC%84%B8%EC%84%9C\" class=\"anchor\" id=\"2-수수료-계산과-정산-명세서\"\u003e\u003c/a\u003e2. 수수료 계산과 정산 명세서\u003c/h3\u003e\n\u003cp\u003e판매자에게 최종 지급액만 보여주면 검산이 어렵고 문의와 분쟁이 늘어난다. 주문 단위 명세와 기간별 합계가 모두 필요하다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e명세 항목\u003c/th\u003e\n\u003cth\u003e설명\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"명세 항목\"\u003e총거래액\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e상품가, 옵션가, 배송비 등 계약상 판매액 구성\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"명세 항목\"\u003e할인 부담액\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e플랫폼·판매자·제휴사가 각각 부담한 할인\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"명세 항목\"\u003e취소·환불액\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e전액 및 부분 환불과 배송비 조정\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"명세 항목\"\u003e플랫폼 수수료\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e수수료율, 정액 수수료와 과세 여부\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"명세 항목\"\u003e결제 관련 비용\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003ePG 비용을 별도 공제하는지 수수료에 포함하는지 표시\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"명세 항목\"\u003e세금 조정\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e부가가치세 표시, 원천징수 등 해당 항목\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"명세 항목\"\u003e기타 조정\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e보상금, 광고비, 페널티 등 계약상 근거가 있는 조정\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"명세 항목\"\u003e최종 지급액\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e모든 가감 항목을 반영한 송금 예정액\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e수수료 정책에는 계산 기준도 명시해야 한다. 할인 전 판매가와 할인 후 결제액 중 무엇을 기준으로 하는지, 배송비와 부가가치세를 포함하는지, 부분 환불 시 수수료를 어떻게 되돌리는지 정해야 한다.\u003c/p\u003e\n\u003cp\u003e금액은 부동소수점 자료형으로 계산하지 않는 것이 안전하다. 원화처럼 최소 화폐 단위가 정수인 경우 정수로 저장하고, 외화나 소수 계산이 필요하면 고정소수점 자료형과 통화별 반올림 규칙을 사용한다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#3-%ED%99%98%EB%B6%88%EA%B3%BC-%EB%A7%88%EC%9D%B4%EB%84%88%EC%8A%A4-%EC%A0%95%EC%82%B0\" class=\"anchor\" id=\"3-환불과-마이너스-정산\"\u003e\u003c/a\u003e3. 환불과 마이너스 정산\u003c/h3\u003e\n\u003cp\u003e이미 판매자에게 지급한 주문이 나중에 환불될 수 있다. 이 경우 환불액과 환급할 수수료를 조정 원장에 기록하고 다음 지급액에서 차감해야 한다.\u003c/p\u003e\n\u003cp\u003e예를 들어 이번 정산 예정액이 30만 원이고 이전 주문의 환불 관련 차감액이 40만 원이라면 다음과 같이 처리할 수 있다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e이번 지급액: 0원\u003c/li\u003e\n\u003cli\u003e미회수 잔액: 마이너스 10만 원\u003c/li\u003e\n\u003cli\u003e다음 정산으로 넘길 금액: 10만 원 차감\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e정책에는 다음 항목이 필요하다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e부분 환불 시 상품가, 배송비와 수수료의 배분 방식\u003c/li\u003e\n\u003cli\u003e마이너스 잔액의 이월 기간과 상계 순서\u003c/li\u003e\n\u003cli\u003e장기간 판매가 없는 판매자에게 회수하는 방법\u003c/li\u003e\n\u003cli\u003e보증금이나 지급준비금을 둘 수 있는 계약상 근거\u003c/li\u003e\n\u003cli\u003e판매자 탈퇴 전에 미결제 의무를 확인하는 절차\u003c/li\u003e\n\u003cli\u003e환불 취소나 분쟁 결과 변경 시 반대 분개하는 방식\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e기존 거래 기록을 덮어쓰지 말고 원거래와 조정 거래를 연결해야 한다. 그래야 어느 환불이 어떤 정산을 변경했는지 재현할 수 있다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#4-%EC%A7%80%EA%B8%89-%EB%B3%B4%EB%A5%98%EC%99%80-%ED%95%B4%EC%A0%9C\" class=\"anchor\" id=\"4-지급-보류와-해제\"\u003e\u003c/a\u003e4. 지급 보류와 해제\u003c/h3\u003e\n\u003cp\u003e전체 판매자 계정의 지급을 무조건 중단하기보다 주문, 금액 또는 사유별로 보류할 수 있어야 한다. 대표적인 보류 사유는 다음과 같다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e소비자 분쟁이나 반품 진행\u003c/li\u003e\n\u003cli\u003e자전거래, 계정 탈취 또는 비정상 결제 의심\u003c/li\u003e\n\u003cli\u003e판매자 본인·사업자·계좌 인증 실패\u003c/li\u003e\n\u003cli\u003e법원, 수사기관 또는 관계 기관의 적법한 요청\u003c/li\u003e\n\u003cli\u003e계약상 정산 서류 미제출\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e각 보류 기록에는 대상 금액, 사유 코드, 근거 자료, 시작 시각, 검토 기한, 담당자와 해제 조건을 저장한다. 판매자 화면에는 공개 가능한 범위에서 보류 금액과 이유, 필요한 조치, 문의 경로를 표시한다.\u003c/p\u003e\n\u003cp\u003e운영자가 임의로 보류를 반복하지 못하도록 생성과 해제 권한을 분리하고, 큰 금액의 보류 해제에는 이중 승인을 적용하는 것이 좋다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#5-%ED%8C%90%EB%A7%A4%EB%8C%80%EA%B8%88-%EB%B6%84%EB%A6%AC-%EA%B4%80%EB%A6%AC%EC%99%80-pg%EC%97%90%EC%8A%A4%ED%81%AC%EB%A1%9C-%EA%B5%AC%EC%A1%B0\" class=\"anchor\" id=\"5-판매대금-분리-관리와-pg에스크로-구조\"\u003e\u003c/a\u003e5. 판매대금 분리 관리와 PG·에스크로 구조\u003c/h3\u003e\n\u003cp\u003e미지급 판매대금과 회사 운영비를 같은 가용 현금처럼 관리하면 유동성 부족이 곧 미정산으로 번질 수 있다. 최소한 내부 장부와 계좌 운영에서 판매대금 관련 자금과 운영자금을 명확히 구분하고 매일 잔액을 대사해야 한다.\u003c/p\u003e\n\u003cp\u003e다만 별도 계좌를 만들었다는 사실만으로 법적 도산격리나 완전한 자금 보호가 자동으로 성립하는 것은 아니다. 신탁, 예치, 지급보증 등 보호 방식의 효력과 의무는 적용 법령 및 계약 구조를 검토해야 한다.\u003c/p\u003e\n\u003cp\u003e플랫폼이 결제와 지급 과정에서 어떤 역할을 수행하는지에 따라 전자지급결제대행업 등 전자금융거래법상 등록 문제가 발생할 수 있다. 모든 플랫폼이 동일하게 PG 등록 대상인 것도 아니고, 단순히 정산 데이터를 계산했다는 이유만으로 항상 등록 대상이 되는 것도 아니다. 실제 자금 수취·보관·전달 방식과 계약관계로 판단해야 한다.\u003c/p\u003e\n\u003cp\u003e초기 플랫폼은 등록 PG가 제공하는 결제, 에스크로 또는 판매자별 분할 정산 서비스를 검토할 수 있다. 그러나 PG를 이용해도 다음 책임은 사라지지 않는다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e어떤 주문을 언제 지급 대상으로 전달할지 결정\u003c/li\u003e\n\u003cli\u003e수수료와 조정액 계산\u003c/li\u003e\n\u003cli\u003e환불과 마이너스 이월 관리\u003c/li\u003e\n\u003cli\u003e판매자 정보와 계좌 검증\u003c/li\u003e\n\u003cli\u003ePG 결과와 내부 원장 대사\u003c/li\u003e\n\u003cli\u003e장애와 지급 실패 대응\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e에스크로 의무와 예외도 거래 유형과 결제수단 등에 따라 다르므로 전자상거래법과 하위 규정을 확인해야 한다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#6-%EC%9B%90%EC%B2%9C%EC%A7%95%EC%88%98-%EB%B6%80%EA%B0%80%EA%B0%80%EC%B9%98%EC%84%B8%EC%99%80-%EC%A6%9D%EB%B9%99\" class=\"anchor\" id=\"6-원천징수-부가가치세와-증빙\"\u003e\u003c/a\u003e6. 원천징수, 부가가치세와 증빙\u003c/h3\u003e\n\u003cp\u003e‘개인 판매자는 무조건 3.3%를 뗀다’는 규칙은 정확하지 않다. 3.3%는 일반적으로 사업소득에 대한 소득세 3%와 개인지방소득세 0.3%를 합쳐 부르는 표현이다. 실제 원천징수 여부는 판매자의 사업자등록 유무만이 아니라 소득의 성격, 계약관계, 지급 항목과 예외 규정에 따라 달라진다.\u003c/p\u003e\n\u003cp\u003e가입과 계약 단계에서 다음 정보를 받아야 한다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e개인, 개인사업자, 법인 등 판매자 유형\u003c/li\u003e\n\u003cli\u003e국내외 거주자 또는 법인 여부\u003c/li\u003e\n\u003cli\u003e과세, 면세, 간이과세 등 세무상 상태\u003c/li\u003e\n\u003cli\u003e사업자등록번호와 주민등록번호 등 법정 신고에 필요한 정보\u003c/li\u003e\n\u003cli\u003e소득의 성격과 지급 사유\u003c/li\u003e\n\u003cli\u003e세금계산서, 계산서 또는 원천징수영수증 등 필요한 증빙\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e사업자 판매자에게도 ‘항상 아무 세금도 공제하지 않고 100% 지급한다’고 일반화하면 안 된다. 플랫폼 수수료를 차감하는 계약이라면 거래 총액, 수수료, 부가가치세와 실제 송금액을 구분해야 한다. 플랫폼이 제공한 중개 서비스의 수수료에 대한 세금계산서 발급 주체와 시점도 계약 및 세법상 공급관계에 맞춰 정한다.\u003c/p\u003e\n\u003cp\u003e원천세는 통상 지급일이 속하는 달의 다음 달 10일까지 신고·납부하는 구조가 적용되지만, 예외나 기한 변경 가능성이 있으므로 실제 신고 시점의 규정을 확인해야 한다. 세무 규칙을 코드에 고정하기보다 적용 시작일과 종료일이 있는 버전형 정책으로 관리하는 편이 안전하다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#7-%EC%A7%80%EA%B8%89-%EC%8B%A4%ED%8C%A8-%EC%A0%95%EC%82%B0-%EC%96%B4%EB%93%9C%EB%AF%BC%EA%B3%BC-%EA%B0%90%EC%82%AC-%EB%A1%9C%EA%B7%B8\" class=\"anchor\" id=\"7-지급-실패-정산-어드민과-감사-로그\"\u003e\u003c/a\u003e7. 지급 실패, 정산 어드민과 감사 로그\u003c/h3\u003e\n\u003cp\u003e정상적으로 생성된 지급도 계좌 오류, 예금주 불일치, 거래 제한, 은행 점검 또는 PG 장애로 실패할 수 있다. 실패를 단순히 ‘미지급’으로 표시하지 말고 상태와 재처리 규칙을 세분화한다.\u003c/p\u003e\n\u003cp\u003e권장 상태 예시는 다음과 같다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003ccode\u003escheduled\u003c/code\u003e: 지급 예약\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003esubmitted\u003c/code\u003e: 은행 또는 PG에 요청 전달\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003eprocessing\u003c/code\u003e: 외부 기관 처리 중\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003epaid\u003c/code\u003e: 성공 확인\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003efailed_retryable\u003c/code\u003e: 재시도 가능한 실패\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003efailed_final\u003c/code\u003e: 정보 수정 등이 필요한 최종 실패\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003ereversed\u003c/code\u003e: 성공 후 취소 또는 반환\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e재시도에는 동일 지급을 식별하는 멱등성 키를 사용해야 한다. 응답 지연을 실패로 오인해 다시 송금하면 중복 지급이 발생할 수 있으므로, 외부 거래번호를 조회해 기존 요청의 결과를 먼저 확인한다.\u003c/p\u003e\n\u003cp\u003e감사 로그에는 다음을 남긴다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e행위자와 사용한 운영자 계정\u003c/li\u003e\n\u003cli\u003e실행 시각과 접근 위치 등 보안 정보\u003c/li\u003e\n\u003cli\u003e변경 전후 값\u003c/li\u003e\n\u003cli\u003e보류·해제·수동 조정의 사유\u003c/li\u003e\n\u003cli\u003e승인자와 실행자\u003c/li\u003e\n\u003cli\u003e관련 주문, 정산 배치와 외부 거래번호\u003c/li\u003e\n\u003cli\u003e실패 코드와 재시도 이력\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e감사 로그는 일반 운영자가 수정하거나 삭제할 수 없도록 보호하고, 개인정보와 금융정보는 최소 수집, 접근 통제, 암호화와 보존기간 정책을 적용한다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EC%A0%95%EC%82%B0-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EC%9D%98-%EC%B5%9C%EC%86%8C-%EA%B5%AC%EC%84%B1\" class=\"anchor\" id=\"정산-데이터-모델의-최소-구성\"\u003e\u003c/a\u003e정산 데이터 모델의 최소 구성\u003c/h2\u003e\n\u003cp\u003eAI에 화면부터 만들게 하기보다 다음 원장을 먼저 정의하는 것이 좋다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e데이터 객체\u003c/th\u003e\n\u003cth\u003e역할\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"데이터 객체\"\u003e주문 원장\u003c/td\u003e\n\u003ctd data-label=\"역할\"\u003e주문·결제·배송·구매 확정 상태 기록\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"데이터 객체\"\u003e정산 항목\u003c/td\u003e\n\u003ctd data-label=\"역할\"\u003e주문별 총액, 수수료, 세금, 조정액과 귀속 판매자 기록\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"데이터 객체\"\u003e조정 원장\u003c/td\u003e\n\u003ctd data-label=\"역할\"\u003e환불, 보상, 페널티와 수동 조정 기록\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"데이터 객체\"\u003e보류 원장\u003c/td\u003e\n\u003ctd data-label=\"역할\"\u003e보류 금액, 사유, 기한과 해제 이력 기록\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"데이터 객체\"\u003e정산 배치\u003c/td\u003e\n\u003ctd data-label=\"역할\"\u003e특정 기간과 판매자의 지급 대상 묶음\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"데이터 객체\"\u003e지급 원장\u003c/td\u003e\n\u003ctd data-label=\"역할\"\u003e송금 요청, 성공·실패와 외부 거래번호 기록\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"데이터 객체\"\u003e세무 원장\u003c/td\u003e\n\u003ctd data-label=\"역할\"\u003e원천징수와 증빙 발급·신고 상태 기록\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"데이터 객체\"\u003e감사 로그\u003c/td\u003e\n\u003ctd data-label=\"역할\"\u003e운영자와 시스템의 모든 중요 변경 기록\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e각 원장에는 통화, 정책 버전, 생성 시각과 원거래 연결 키가 있어야 한다. 주문 상태를 바꾸는 것만으로 과거 정산 금액이 조용히 변경돼서는 안 된다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EB%B0%98%EB%93%9C%EC%8B%9C-%EC%9C%A0%EC%A7%80%ED%95%B4%EC%95%BC-%ED%95%A0-%ED%86%B5%EC%A0%9C-%EA%B7%9C%EC%B9%99\" class=\"anchor\" id=\"반드시-유지해야-할-통제-규칙\"\u003e\u003c/a\u003e반드시 유지해야 할 통제 규칙\u003c/h2\u003e\n\u003cp\u003e정산 시스템은 다음과 같은 불변 조건을 자동 검사해야 한다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e하나의 정산 항목은 정확히 한 판매자와 한 원거래에 연결된다.\u003c/li\u003e\n\u003cli\u003e동일한 지급 키로 두 번 송금하지 않는다.\u003c/li\u003e\n\u003cli\u003e지급 완료액과 미지급액, 보류액, 조정액의 합계가 원장과 일치한다.\u003c/li\u003e\n\u003cli\u003e수동 조정에는 사유와 승인자가 존재한다.\u003c/li\u003e\n\u003cli\u003e이미 마감한 정산은 수정하지 않고 반대 분개와 새 조정으로 고친다.\u003c/li\u003e\n\u003cli\u003e내부 판매대금 관련 잔액과 PG·은행 잔액의 차이를 매일 조사한다.\u003c/li\u003e\n\u003cli\u003e세금과 수수료 계산에는 적용된 정책 버전을 기록한다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#ai%EC%97%90-%EC%A0%84%EB%8B%AC%ED%95%A0-%EC%A0%95%EC%B1%85-%EB%AA%85%EC%84%B8-%EC%98%88%EC%8B%9C\" class=\"anchor\" id=\"ai에-전달할-정책-명세-예시\"\u003e\u003c/a\u003eAI에 전달할 정책 명세 예시\u003c/h2\u003e\n\u003cp\u003e다음과 같이 요구사항을 구조화하면 누락을 줄일 수 있다.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e주문 상태와 정산 상태를 분리해 설계한다. 거래 유형별 구매 확정 조건, 매주 수요일 지급 배치, 휴일 처리, 수수료 기준, 부분 환불 배분, 마이너스 이월, 건별 지급 보류, 원천징수 정책 버전, 지급 멱등성 키와 변경 불가능한 감사 로그를 구현한다. 금액은 정수 또는 고정소수점으로 처리한다. 모든 수동 조정에는 이중 승인과 사유가 필요하다. 구현하기 전에 최소 지급액, 자동 구매 확정 기간, 장기 마이너스 회수, 보류 기한, 재시도 횟수처럼 정해지지 않은 정책을 질문 목록으로 제시하라.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eAI에는 코드만 요청하지 말고 다음 산출물도 함께 요구한다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e상태 전이도와 예외 목록\u003c/li\u003e\n\u003cli\u003e데이터베이스 스키마와 제약조건\u003c/li\u003e\n\u003cli\u003e권한·승인 체계\u003c/li\u003e\n\u003cli\u003e정상, 경계값, 장애와 중복 요청 테스트\u003c/li\u003e\n\u003cli\u003e일별 대사 보고서 형식\u003c/li\u003e\n\u003cli\u003e장애 복구와 수동 처리 절차\u003c/li\u003e\n\u003cli\u003e개인정보와 금융정보 보호 점검표\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EC%B6%9C%EC%8B%9C-%EC%A0%84-%EC%A0%90%EA%B2%80%ED%91%9C\" class=\"anchor\" id=\"출시-전-점검표\"\u003e\u003c/a\u003e출시 전 점검표\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e 거래 유형별 정산 기준일이 문서화돼 있다.\u003c/li\u003e\n\u003cli\u003e 판매자가 정산 명세를 주문 단위로 검산할 수 있다.\u003c/li\u003e\n\u003cli\u003e 부분 환불과 마이너스 이월 테스트를 통과했다.\u003c/li\u003e\n\u003cli\u003e 보류 사유, 기한과 해제 권한이 정의돼 있다.\u003c/li\u003e\n\u003cli\u003e 판매대금 관련 자금과 운영자금의 관리 기준이 구분돼 있다.\u003c/li\u003e\n\u003cli\u003e PG·에스크로·전자금융업 해당 여부를 전문가와 확인했다.\u003c/li\u003e\n\u003cli\u003e 판매자 및 소득 유형별 세무 처리를 검토했다.\u003c/li\u003e\n\u003cli\u003e 중복 지급 방지와 실패 재시도 테스트를 완료했다.\u003c/li\u003e\n\u003cli\u003e 은행·PG·내부 원장의 일별 대사가 가능하다.\u003c/li\u003e\n\u003cli\u003e 운영자의 수동 변경이 감사 로그에 남는다.\u003c/li\u003e\n\u003cli\u003e 정산 장애 시 판매자 공지와 문의 대응 절차가 있다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EA%B2%B0%EB%A1%A0\" class=\"anchor\" id=\"결론\"\u003e\u003c/a\u003e결론\u003c/h2\u003e\n\u003cp\u003e안전한 정산 시스템의 출발점은 AI 프롬프트가 아니라 명시적인 정책과 분리된 원장이다. AI는 확정된 규칙을 코드, 테스트와 문서로 옮기는 도구로 활용하고, 자금 보관 구조와 전자금융·세무 판단은 PG, 회계·세무 전문가 및 법률 전문가와 함께 검증해야 한다.\u003c/p\u003e\n","tags":["생성형 AI","정산 시스템","플랫폼 운영","PG","전자금융","세금"],"faqs":[{"question":"정산은 판매 금액에서 수수료만 빼면 되는 기능인가요?","answer":"아니다. 정산에는 구매 확정, 부분 환불, 지급 보류, 마이너스 이월, 세금, 송금 실패, 중복 지급 방지와 원장 대사가 포함된다. 계산식뿐 아니라 상태 전이와 자금 통제가 필요하다."},{"question":"정산 기준일은 반드시 구매 확정일이어야 하나요?","answer":"모든 거래에 하나의 기준을 일률적으로 적용할 수는 없다. 실물 상품은 구매 확정이나 자동 확정을 활용할 수 있지만 서비스, 디지털 콘텐츠, 예약 상품은 이행 완료 조건이 다르다. 거래 유형별 기준 사건과 법정·계약상 지급 기한을 함께 정해야 한다."},{"question":"정산 주기는 짧을수록 항상 좋은가요?","answer":"짧은 주기는 미지급 잔액과 판매자의 현금 부담을 줄이지만 반품, 이상 거래와 운영 비용을 고려해야 한다. 위험을 이유로 불필요하게 장기화하기보다 거래 특성에 맞는 최소한의 검증 기간과 예측 가능한 지급일을 설정하는 것이 중요하다."},{"question":"PG를 이용하면 플랫폼은 정산 정책을 만들 필요가 없나요?","answer":"아니다. PG는 결제, 자금 전달, 에스크로 또는 분할 지급 기능을 제공할 수 있지만 어떤 주문을 언제 지급할지, 수수료와 환불액을 어떻게 계산할지, 누구의 지급을 보류할지는 플랫폼 정책에 달려 있다."},{"question":"개인 판매자에게는 모두 3.3%를 원천징수해야 하나요?","answer":"아니다. 3.3%는 통상 사업소득 원천징수와 개인지방소득세를 합친 표현이다. 원천징수 여부와 세율은 판매자의 등록 형태만이 아니라 소득의 성격, 계약관계, 거주자 여부와 예외 규정에 따라 판단해야 한다."},{"question":"별도 계좌에 판매대금을 보관하면 완전히 안전한가요?","answer":"별도 계좌는 운영자금과 판매대금을 구분하는 기본 통제지만 그 자체로 도산격리나 법적 보호를 보장하지 않는다. 신탁, 예치, 지급보증 등 필요한 보호 방식과 계좌의 법적 성격을 계약 및 현행 법령에 따라 확인해야 한다."},{"question":"마이너스 정산은 어떻게 기록해야 하나요?","answer":"이미 지급한 주문의 환불액을 별도 조정 거래로 기록하고 다음 지급액에서 차감한다. 차감액이 지급 예정액보다 크면 지급액은 0원으로 하고 남은 잔액을 다음 정산으로 이월한다. 원거래를 삭제하거나 과거 정산서를 덮어쓰면 안 된다."},{"question":"송금 요청의 응답이 없으면 바로 다시 요청해도 되나요?","answer":"안 된다. 첫 요청이 실제로 성공했지만 응답만 유실됐을 수 있다. 동일 지급에 멱등성 키와 외부 거래번호를 사용하고, PG나 은행에서 기존 처리 결과를 조회한 뒤 재시도해야 중복 지급을 막을 수 있다."},{"question":"AI가 생성한 정산 코드를 바로 운영해도 되나요?","answer":"권장되지 않는다. 상태 전이, 원장 일치, 동시성, 중복 요청, 부분 환불, 장애 복구와 권한 통제를 테스트해야 한다. 전자금융과 세무 사항은 실제 사업 구조를 기준으로 전문가 검토도 받아야 한다."}],"sources":[{"url":"https://www.law.go.kr/법령/전자금융거래법","title":"전자금융거래법","type":"source"},{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률","title":"전자상거래 등에서의 소비자보호에 관한 법률","type":"source"},{"url":"https://www.law.go.kr/법령/소득세법","title":"소득세법","type":"source"},{"url":"https://www.law.go.kr/법령/지방세법","title":"지방세법","type":"source"},{"url":"https://www.law.go.kr/법령/부가가치세법","title":"부가가치세법","type":"source"}],"images":[{"id":300,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI4NCwicHVyIjoiYmxvYl9pZCJ9fQ==--327ce77d86d637d351158c65c70ddfacddacae1e/ai-ed29586c.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"쇼핑몰과 정산·보안·검증 단계를 연결한 AI 자동화 흐름도","caption":"거래 데이터가 정책에 따라 정산, 검증, 보안 시스템을 거치는 과정을 보여준다.","description":null},"en":{"alt":"AI automation workflow linking online stores with settlement, security, and verification","caption":"Transaction data moves through policy-based settlement, verification, and security processes.","description":null},"ja":{"alt":"オンライン店舗と精算・セキュリティ・検証工程を結ぶAI自動化フロー","caption":"取引データがポリシーに基づく精算、検証、保護の工程を通る様子を示している。","description":null},"es":{"alt":"Flujo de automatización con IA entre tiendas, liquidación, seguridad y verificación","caption":"Los datos de transacciones pasan por procesos de liquidación, verificación y seguridad basados en políticas.","description":null},"id":{"alt":"Alur otomatisasi AI yang menghubungkan toko, penyelesaian, keamanan, dan verifikasi","caption":"Data transaksi mengalir melalui proses penyelesaian, verifikasi, dan keamanan berbasis kebijakan.","description":null},"pt":{"alt":"Fluxo de automação com IA ligando lojas, liquidação, segurança e verificação","caption":"Os dados das transações passam por processos de liquidação, verificação e segurança baseados em políticas.","description":null},"zh-hant":{"alt":"連結商店、結算、安全與驗證環節的 AI 自動化流程圖","caption":"交易資料依據政策流經結算、驗證與安全控管流程。","description":null}}},{"id":301,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--128e8c8dd212c1da8f86663e5bcd292ceb74aec1/ai-1bda19eb.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"보안 방패, 정책 단계, 자금 보관함과 금융기관이 연결된 AI 정산 시스템 일러스트","caption":"AI 정산 시스템의 정책, 보안, 자금 흐름과 외부 연동 구조를 시각화했다.","description":null},"en":{"alt":"AI settlement system linking security shields, policy steps, money vaults, a bank, and servers","caption":"The illustration visualizes policies, security, fund flows, and external connections in an AI settlement system.","description":null},"ja":{"alt":"セキュリティ、ポリシー手順、資金保管庫、銀行、サーバーを結ぶAI精算システム","caption":"AI精算システムのポリシー、セキュリティ、資金の流れ、外部連携を可視化している。","description":null},"es":{"alt":"Sistema de liquidación con IA conectado a controles, bóvedas de fondos, un banco y servidores","caption":"La ilustración muestra las políticas, la seguridad, el flujo de fondos y las conexiones externas del sistema.","description":null},"id":{"alt":"Sistem penyelesaian AI yang menghubungkan keamanan, tahapan kebijakan, brankas dana, bank, dan server","caption":"Ilustrasi ini menampilkan kebijakan, keamanan, aliran dana, dan integrasi eksternal dalam sistem penyelesaian AI.","description":null},"pt":{"alt":"Sistema de liquidação com IA ligado a controles, cofres de fundos, banco e servidores","caption":"A ilustração mostra políticas, segurança, fluxos de fundos e integrações externas do sistema.","description":null},"zh-hant":{"alt":"連結安全防護、政策流程、資金保管庫、銀行與伺服器的AI結算系統","caption":"圖中呈現AI結算系統的政策、安全機制、資金流向與外部串接架構。","description":null}}},{"id":302,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI5NiwicHVyIjoiYmxvYl9pZCJ9fQ==--3a2686f3345b1508eafec0579f0d9db8c756867a/ai-b316880e.webp","is_representative":false,"generation_method":"ai_infographic","license":"ai_generated","mime_type":"image/webp","visible_locales":["ko"],"translations":{"ko":{"alt":"AI 정산 시스템 구축 전 정할 7가지 정책과 결제·정산 흐름을 정리한 인포그래픽","caption":"기준일, 수수료, 환불, 지급 보류, 자금 분리, 세금, 감사 정책을 한눈에 보여줍니다.","description":null},"en":{"alt":"Infographic outlining seven policies and the payment flow to define before building an AI settlement system","caption":"It summarizes policies for timing, fees, refunds, holds, fund separation, taxes, and audits.","description":null},"ja":{"alt":"AI精算システム構築前に決める7つの方針と決済・精算フローのインフォグラフィック","caption":"基準日、手数料、返金、支払保留、資金分離、税務、監査の方針をまとめています。","description":null},"es":{"alt":"Infografía de siete políticas y del flujo de pagos que deben definirse antes de crear un sistema de liquidación con IA","caption":"Resume políticas sobre plazos, comisiones, reembolsos, retenciones, separación de fondos, impuestos y auditoría.","description":null},"id":{"alt":"Infografik tujuh kebijakan dan alur pembayaran sebelum membangun sistem penyelesaian berbasis AI","caption":"Ringkasan kebijakan jadwal, biaya, pengembalian dana, penahanan, pemisahan dana, pajak, dan audit.","description":null},"pt":{"alt":"Infográfico com sete políticas e o fluxo de pagamentos a definir antes de criar um sistema de liquidação com IA","caption":"Resume políticas de prazos, taxas, reembolsos, retenções, separação de fundos, impostos e auditoria.","description":null},"zh-hant":{"alt":"建立 AI 結算系統前須制定的七項政策與付款結算流程資訊圖","caption":"圖中概述基準日、手續費、退款、暫緩付款、資金分離、稅務與稽核政策。","description":null}}}],"published_at":"2026-07-27T00:58:06+09:00","updated_at":"2026-07-27T00:58:06+09:00","license":"cc_by","translation_status":"original","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/ko/articles/seven-policies-before-building-ai-settlement-system"}