마켓 정산 ERP 전표 처리 기준과 미수금, 외화 환산

정산 엑셀을 ERP 업로드 양식으로 옮길 때, 매출 전표는 정산서 금액이 아닌 출고나 배송 기록으로 올립니다. 정산서 금액을 매출로 올리면 월말에 출고된 주문이 다음 달 매출로 잡히고, 수수료와 입금이 어느 매출에서 나왔는지 추적하기 어렵습니다. 아래 예는 모두 K-IFRS를 쓰는 회사 기준입니다. 일반기업회계기준을 쓰는 회사, 그리고 본인과 대리인 구분이나 반품 추정처럼 판단이 들어가는 부분은 감사인과 먼저 맞춥니다.

주문 한 건의 단계별 ERP 전표

단계마다 근거 문서가 다릅니다.

주문 내역만으로는 매출 전표를 만들지 않습니다. 취소된 주문과 아직 출고되지 않은 주문이 섞여 있어, 출고·배송 기록과 맞춘 건만 올립니다.

판매자가 본인이면 수수료를 빼기 전 대가 총액을 매출로 인식하고, 마켓 수수료는 비용으로 기록합니다(K-IFRS 제1115호 문단 B35B). 상품이 고객에게 가기 전까지 판매자가 그 상품을 통제하면 본인입니다(문단 B35). 부가세처럼 제삼자를 대신해 받은 금액은 매출에서 빼고(문단 47), 판매자가 부담한 쿠폰도 수익에서 뺍니다(문단 70).

BATI CIS도 채널의 주문과 출고, 정산 데이터를 모아 실제 출고 기준으로 일매출을 만들고, 들어온 정산과 매일 대사한 결과를 ERP가 받는 형식의 회계 전표로 보냅니다. SAP 연동은 공개 사례가 있고, 다른 ERP도 같은 방식으로 연동할 수 있습니다(SAP 연동).

매출 인식 시점과 월말 추정 항목

수익은 고객이 자산을 통제할 때 인식합니다(K-IFRS 제1115호 문단 31). 정산은 이와 다른 시점에 만들어집니다. 스마트스토어는 빠른정산을 쓰지 않으면 구매확정이나 반품완료, 교환완료로 주문이 끝난 날부터 1영업일째에 정산하고, 아마존 정산서에는 그 기간에 지급된 거래만 들어가며 유보 중인 거래는 빠집니다.

2026년 달력에 스마트스토어 규칙을 적용한 가상 예입니다.

정산서를 매출 장부로 쓰면 10월에 배송이 끝난 이 주문이 11월 매출로 잡힙니다. 같은 달 매출도 어느 날짜를 기준으로 보느냐에 따라 금액이 다릅니다. 결제일 기준에서 취소, 미출고, 반품을 빼면 출고일 기준이 되고, 여기서 아직 정산이 들어오지 않은 금액을 빼면 정산일 기준이 됩니다.

아마존에서는 발생주의 회계와 매출 대조에 기간별(Date Range) 리포트를 쓰고, 은행 입금 대조에 정산서를 씁니다. 채널별 정산 주기와 입금일은 이커머스 정산 대사 글의 표에 있습니다.

재무제표는 발생기준으로 작성하므로(K-IFRS 제1001호 문단 27), 정산서가 오기 전이라도 그 달에 생긴 비용과 부채는 월말에 추정해 잡습니다.

• 수수료: 월말까지 정산서가 오지 않은 주문의 수수료를 요율로 추정하고, 정산서가 오면 차이를 고칩니다. 금액이 작아 정산서가 올 때 반영하려면 감사인과 합의합니다.
• 반품 예상분: 수익으로 잡지 않고 환불부채로 둡니다. 돌려받을 제품은 자산으로 기록하고 그만큼 매출원가를 조정합니다(K-IFRS 제1115호 문단 B21).

정산서 항목별 계정 대응표

공식 문서의 항목 이름에 계정 예를 붙였습니다. 계정 이름은 예시이고, 처리는 회사 정책과 감사인 의견을 따릅니다. 아마존 정산 리포트 V2는 가격과 수수료 열을 유형, 설명, 금액 열로 합쳐 보여 줍니다.

받은 파일에 표에 없는 항목이 나오면 별도 목록으로 모아 계정을 정합니다. 아래 예시는 채널마다 다른 정산서 항목 이름을 표준 비용 항목으로 묶고 ERP 계정에 대응한 것입니다.

아마존 정산 파일의 열과 금액 유형은 아마존 정산 리포트 V2 글에 있습니다.

마켓별 미수금 잔액 대사 양식

마켓별 미수금은 마켓마다, 해외 마켓은 국가나 샵마다 나눠 관리합니다. 매달 아래 식이 맞아야 합니다.

기초 미수금 + 이달 매출 − 수수료 − 환불 − 입금 ± 외환차이와 기타 조정 = 기말 미수금

기말 잔액에는 출고(배송)됐지만 구매확정 전인 주문, 아마존이 유보 중인 대금, 정산은 됐지만 아직 입금되지 않은 정산금이 남습니다. 이 목록의 합계가 잔액과 다르면 빠진 수수료나 조정 항목부터 찾습니다. 아래는 매달 채우는 양식의 가상 예입니다(장부 통화 기준).

외화 미수금의 환율 적용 시점과 외환차이

쇼피가 페이오니아로 보내는 정산금은 인도네시아(IDR)를 빼고 USD입니다. 정산할 때 환율이 적용되고, 이 환율은 당일 환율과 다를 수 있습니다. 외화 미수금의 통화는 마켓이 어느 통화로 금액을 확정해 지급하는지(판매 통화인지 USD인지)로 판단하고, 그 근거를 감사인과 맞춥니다.

장부가 원화면 거래일, 보고기간 말, 입금일에 각각 다른 환율을 씁니다. 미수금은 받을 금액이 정해진 화폐성항목이라 보고기간 말에 마감환율로 다시 환산합니다(K-IFRS 제1021호 문단 16, 23). 아래는 USD 100 판매의 가상 예이고, 수수료는 뺐습니다.

외환차이 합계는 +1,000원으로, (1,390 − 1,380) × 100과 같습니다. 판매와 입금이 같은 회계기간 안에 있으면 보고기간 말 환산 없이 입금 때 외환차이를 한 번에 인식합니다(문단 29).

ERP 연동 전 확정 사항

1. 매출 인식 기준일: 출고일과 배송 완료일 가운데 무엇으로 할지는 판매 계약 조건에 따라 다릅니다. 채널과 판매 조건별로 정해 근거를 남기고, 감사인과 먼저 맞춥니다.
2. 정산서 항목별 계정: 위 대응표처럼 항목마다 계정을 하나씩 정하고, 처음 보는 항목은 별도 목록으로 모읍니다.
3. 미수금 관리 단위: 마켓, 국가, 샵 가운데 어디까지 나눠 볼지 정합니다.
4. 상품 코드: 채널 SKU와 ERP 품목 코드의 대응표를 만듭니다.
5. 전표 단위: 주문마다 올릴지, 일별이나 채널별 합계로 올릴지 정합니다. 합계로 올려도 주문 단위 근거는 보관합니다.
6. 환율 기준: 어느 기관의 환율을 쓸지, 일별 환율과 평균환율 가운데 무엇을 쓸지 정합니다.
7. 원본 보관: 아마존 결제 보고서는 만든 뒤 90일 동안 내려받을 수 있습니다(미국 셀러센트럴 기준). 정산 파일은 받을 때마다 저장합니다.
8. 전표 수신 형식: ERP가 전표를 업로드 양식으로 받는지 API로 받는지 확인합니다.
9. 마감 순서: 미수금 잔액 대사, 외화 환산, 전표 전송의 순서와 담당자를 정하고 매달 같은 순서로 마감합니다.