티스토리 뷰

발급시점
온라인 판매 주문을 월말에 대조할 때 결제일을 전자세금계산서 작성일로 일괄 넣으려다 멈췄습니다. 주문 접수, 출고, 배송 완료, 용역 완료, 입금은 서로 다른 날짜일 수 있습니다. 국세청 안내는 작성일을 거래일인 공급시기, 발급일을 전자서명이 완료된 파일이 공급받는 자의 수신함에 도달한 날, 전송일을 국세청에 전송한 날로 구분합니다. 제 장부에서도 이 세 날짜를 별도 열로 만들었습니다.
거래처가 월말 합산 발급을 요청한 경우에도 모든 주문을 한 줄로 합치지 않았습니다. 공급 형태와 계약 조건, 반품·취소 여부를 주문번호별로 확인하고 세법상 허용되는 발급시기를 국세청 자료와 세무대리인에게 확인했습니다. 결제대행사 정산일은 현금이 들어온 날이지 항상 공급시기를 뜻하지 않을 수 있어 정산 파일만으로 작성일을 만들지 않았습니다. 출고 자료와 거래명세, 계약 내용을 함께 보관했습니다.
제가 실제로 막힌 지점은 판매 채널의 매출 인식 화면과 홈택스 발급 화면의 날짜 이름이 달랐던 부분입니다. 화면 용어를 임의로 맞추지 않고 주문번호, 거래처 사업자번호, 공급 항목, 공급가액, 세액, 공급시기 근거를 한 줄씩 대조했습니다. 날짜 판단이 애매한 설치·용역이나 부분 공급은 일반적인 블로그 설명으로 결론 내리지 않고 세무 전문가에게 거래 사실을 보여 주고 확인했습니다.
전자세금계산서는 결제일과 정산일을 그대로 옮기는 작업이 아니라 공급시기 근거, 거래처, 공급가액 구성, 수정 사유를 거래별로 대조하는 과정입니다.
- 주문일·공급시기·작성일·발급일 구분
- 거래처와 공급가액 구성 대조
- 수수료·할인·배송비를 별도 항목으로 분리
- 수정 사유와 원본 연결 관계 확인
전자세금계산서는 결제일과 정산일을 그대로 옮기는 작업이 아니라 공급시기 근거, 거래처, 공급가액 구성, 수정 사유를 거래별로 대조하는 과정입니다.

공급가액
- 주문별 공급 사실과 날짜 자료 모으기
- 거래처·공급가액·세액 대조
- 발급 전 작성일과 수신 정보를 검토
- 수정 시 원본과 사유를 연결해 장부 반영
공급가액을 계산할 때 판매대금 총액에서 플랫폼 수수료를 바로 뺀 값을 세금계산서 금액으로 쓰지 않았습니다. 판매자와 거래처의 실제 공급 관계, 할인 부담 주체, 배송비 포함 여부를 계약과 정산서에서 분리했습니다. 주문 취소와 부분 반품이 섞인 달에는 원주문 금액, 취소된 품목, 남은 공급분을 각각 표시했습니다. 부가세 포함 금액과 공급가액을 같은 열에 두지 않아 반올림 차이와 세액 오류를 찾기 쉽게 했습니다.
한 거래처의 여러 주문을 합산할 때 사업자등록번호가 동일한지와 상호 변경 여부를 확인했습니다. 주문자 이름이 같아도 세금계산서를 받을 사업자가 다를 수 있고, 지점과 본점 처리도 계약에 따라 달라질 수 있습니다. 발급 요청 메일의 금액을 그대로 복사하지 않고 내 주문 원장과 대조했습니다. 수정 요청을 받은 경우 변경 전후 금액, 요청자, 사유, 확인 자료를 남겨 같은 주문을 두 번 반영하지 않게 했습니다.
외화 결제나 플랫폼 쿠폰이 포함된 주문은 환율과 할인 부담을 추측해 입력하지 않았습니다. 정산 명세의 항목 이름, 실제 거래 계약, 세무 처리 기준을 따로 확인했습니다. 공급가액 차이가 작아 보여도 월 합계만 억지로 맞추지 않고 주문 단위에서 원인을 찾았습니다. 세금계산서 발급 뒤 장부를 고쳤다면 홈택스 문서와 내부 매출 원장도 같은 버전으로 연결하고 파일명에 수정 사유를 남겼습니다.
놓쳤던 부분
플랫폼 정산일을 모든 주문의 공급시기와 같은 날로 본 점입니다. 정산 입금과 재화·용역의 공급 사실은 다른 자료이므로 거래별 근거를 다시 모아야 했습니다.
세금계산서 발급시기와 수정 사유는 거래 사실에 따라 달라집니다. 애매한 거래를 블로그 예시로 확정하지 말고 국세청·관할 세무서·세무대리인에게 확인합니다.
수정점검
수정점검은 기존 전자세금계산서를 삭제하고 새 문서를 하나 더 만드는 방식으로 처리하지 않았습니다. 수정세금계산서 사유와 작성일은 발생 상황에 따라 달라질 수 있어 국가법령정보센터의 현행 규정과 국세청 안내를 확인했습니다. 단순 오타, 계약 해제, 공급가액 변동을 같은 사유로 선택하지 않았습니다. 원본 승인번호와 수정 문서가 연결되는지 발급 전 미리보기에서 확인했습니다.
발급을 마친 뒤에는 홈택스의 성공 표시만 보지 않았습니다. 거래처 수신 여부, 작성일·발급일·전송일, 사업자번호, 공급가액과 세액, 수정 사유를 다시 읽었습니다. 내부 장부에는 원본을 덮어쓰지 않고 원문서와 수정문서를 모두 연결했습니다. 같은 주문이 다음 달 미발급 목록에 다시 나타나지 않도록 주문 상태도 갱신했습니다. 신고 반영 시점이 불명확하면 관할 세무서나 세무대리인에게 확인했습니다.
완료 기준은 발급 건수가 주문 건수와 같아진 상태가 아니었습니다. 각 거래의 공급시기 근거가 있고, 금액 구성과 할인·수수료가 분리되며, 수정이 필요한 건은 적절한 사유로 원본과 연결되고, 거래처와 내부 원장에서 같은 금액을 확인한 상태였습니다. 이 글은 제 대조 절차이며 개별 거래의 세무 판단을 대신하지 않습니다. 법령과 홈택스 화면은 바뀔 수 있어 발급 당일 공식 자료를 다시 확인했습니다.
운영 판단
제가 운영에서 더 중요하게 보는 기준은 발급 속도보다 주문 근거가 다시 추적되는지입니다. 월 합계만 맞추면 당장은 편하지만 반품이나 가격 변경이 생겼을 때 어느 문서를 고쳐야 하는지 찾지 못했습니다. 그래서 정산 파일, 주문 원장, 출고 자료, 거래처 요청을 주문번호로 연결하고 날짜 이름을 분리했습니다. 세무 규정을 아는 척해 한 문장으로 단정하는 것보다 애매한 거래를 표시하고 세무대리인에게 정확한 사실을 전달하는 편이 비용과 재작업을 줄였습니다. 수정 문서는 원본을 없애는 수단이 아니라 변경 이유를 남기는 기록이라는 판단을 유지하고 있습니다.
자주 묻는 질문
Q. 결제일을 작성일로 쓰면 되나요?
A. 공급 형태와 실제 공급시기를 확인해야 하므로 결제일만으로 정하지 않습니다.
Q. 수수료를 뺀 입금액이 공급가액인가요?
A. 수수료와 공급대가의 관계를 계약·정산 자료로 분리해 확인합니다.
Q. 잘못 발급한 문서를 삭제하면 되나요?
A. 수정세금계산서 사유와 절차를 공식 자료와 전문가에게 확인합니다.
- Total
- Today
- Yesterday
- sku관리
- 주문대조
- 온라인판매
- 상품소싱
- 판매수수료정산
- 상품마진
- 재고관리
- 상품광고
- 1688소싱
- 재고계산
- 비용분리
- 판매자쿠폰
- 매출연결
- 재고회전
- 중국발주
- 온라인판매운영
- 광고비상품별배분
- 온라인판매회계
- 상품손익
- 마진관리
- 상품별손익
- 광고성과
- 쿠폰할인분담률
- 반품정산
- 광고비
- 정산차액
- 귀책구분
- 발급시점
- 쿠팡광고
- 상품원가
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
