한눈에 보기
상품을 출고했다고 해서 곧바로 매출이 되는 것은 아닙니다. 원칙적으로는 상품에 대한 통제가 고객에게 넘어간 시점에 매출을 인식하기 때문에, 출고는 됐지만 아직 매출로 잡을 시점이 아니라면 창고 밖에 있는 상품도 셀러의 재고로 남아 있어야 합니다. 다만 계약에 따라 출고하는 순간 통제가 고객에게 넘어가는 경우도 있어, 실제 매출 인식 기준일은 채널과 계약조건을 함께 확인해 정해야 합니다.
여기서 장부가 꼬이기 시작합니다. 출고한 날 재고에서는 빼면서 매출은 정산이 끝난 뒤에 잡는다면, 그 사이 상품은 재고에도 매출에도 잡히지 않게 됩니다. 해외 판매처럼 출고 후 배송완료와 구매확정, 정산까지 여러 단계가 이어지는 경우에는 이 공백이 월말 결산에서 더 크게 드러날 수 있습니다.
결국 중요한 건 출고와 매출 사이에 있는 상품을 어디에 두고, 언제 다음 상태로 넘길 것인지를 정해두는 일입니다. 그래야 매출과 원가도 같은 기간에 맞춰 볼 수 있고, 월말마다 달라지는 숫자를 다시 찾아 헤매지 않을 수 있습니다.
출고와 매출 인식 시점 사이에는 왜 시차가 생길까요?
출고와 매출 인식 사이에는 배송완료와 주문 확정이라는 단계가 남아 있기 때문입니다. 상품을 출고한 뒤 배송이 완료되기까지 시간이 걸리고, 배송이 끝난 뒤에도 채널에서 주문을 확정하는 절차가 이어집니다. 같은 날 출고한 상품이라도 물류 방식이나 배송 국가, 택배사, 채널의 자동 구매확정 기준에 따라 매출이 확정되는 시점이 달라지는 이유입니다.
물류 방식에 따라 이 과정을 얼마나 자세히 확인할 수 있는지도 달라집니다. FBA는 아마존이 보관부터 포장, 배송, 반품까지 맡기 때문에 셀러가 아마존에서 제공하는 재고 원장과 상태값을 기준으로 확인해야 합니다. 반면 3PL은 셀러가 물류사와 직접 계약하는 구조라 입출고 내역이나 재고실사 자료를 요청해 차이가 발생한 원인을 직접 확인하기가 상대적으로 쉽습니다.
FBA는 필요한 데이터가 아마존 안에 모여 있지만 셀러가 재고 차이를 직접 확인하기는 어렵습니다. 반대로 3PL은 실제 재고를 확인하기 쉽지만, 구매확정이나 정산 정보는 채널 데이터와 따로 연결해야 합니다. 결국 물류 방식은 달라도 출고 이후의 상품 상태와 매출 인식 시점을 하나의 흐름으로 연결해 관리하는 데는 각각의 한계가 있습니다.
구매확정 기준은 채널마다 어떻게 다를까요?
앞에서 살펴본 것처럼 출고 후 매출이 인식되기까지는 배송완료와 주문 확정 같은 여러 단계가 있습니다. 그런데 이 과정이 모든 채널에서 똑같이 진행되는 것은 아닙니다. 채널마다 주문을 확정하는 방식과 제공하는 데이터가 다르기 때문에, 매출 인식 시점을 판단할 때 참고할 수 있는 날짜도 달라집니다.
국내 오픈마켓은 구매확정일을 별도로 제공하는 경우가 많지만, 해외 채널은 구매확정 절차가 없거나 수취확인, 주문완료처럼 다른 방식으로 주문을 확정하기도 합니다.
이 차이가 가장 잘 드러나는 곳이 아마존입니다. 네이버 스마트스토어처럼 구매확정일을 확인할 수 있는 채널과 달리, 아마존은 별도의 구매확정일을 제공하지 않습니다. 그래서 아마존에서는 출고일이나 Posted Date(Payment Report에 거래가 반영된 날짜)처럼 다른 날짜를 기준으로 삼아야 합니다.
여러 채널을 함께 운영한다면 같은 날 출고한 상품이라도 매출로 인식되는 시점이 달라질 수 있습니다. 그래서 채널별로 어떤 날짜를 매출 인식 기준으로 사용할지 미리 정해두고, 그 기준을 문서화해 두는 것이 중요합니다. 그래야 월말에 채널별 매출을 맞춰볼 때도 같은 기준으로 숫자를 비교할 수 있습니다.
출고 후 매출 인식 전, 회계 처리를 잘못하면 장부에서 무엇이 틀어질까요?
상품을 출고한 뒤 매출로 인식하기까지의 기준을 잘못 잡으면 장부에서는 크게 세 가지 문제가 생길 수 있습니다. 재고가 실제보다 적게 잡히거나, 매출이 너무 일찍 인식되거나, 매출과 원가가 서로 다른 달에 기록되는 경우입니다. 대부분 출고일과 매출 인식일을 같은 날로 보거나, 재고와 매출에 서로 다른 기준일을 적용하면서 발생합니다.
세 가지 오류는 겉으로는 달라 보여도 출발점은 같습니다. 재고를 빼는 시점과 매출, 원가를 인식하는 시점이 서로 다른 기준으로 움직이는 것입니다. 그러면 월말마다 재고와 매출, 원가 중 어느 한쪽이 앞서거나 뒤처지면서 장부를 다시 맞춰야 하는 일이 생깁니다.
여기서 구매확정일이나 정산일을 매출 인식일로 바로 보는 것도 주의해야 합니다. 두 날짜는 매출 인식 시점을 판단할 때 참고할 수 있는 데이터일 뿐, 실제 인식 시점은 계약조건과 배송·취소·반품 구조를 살펴 상품의 통제가 고객에게 넘어간 시점을 기준으로 정해야 합니다. 따라서 정산서가 들어온 날을 그대로 매출 인식일로 삼는 것은 적절하지 않을 수 있습니다.
상품의 재고·판매 상태는 왜 둘이 아니라 셋으로 나눠야 할까요?
앞에서 살펴본 것처럼 상품은 출고된 뒤에도 배송완료나 고객 인수 등 매출 인식 기준을 충족하기까지 시간이 걸릴 수 있습니다. 이 기간의 상품을 별도로 관리하지 않으면 출고된 상품이 재고에서도 빠지고 매출로도 잡히지 않는 공백이 생길 수 있습니다. 그래서 보유재고와 판매완료 사이에 ‘출고·판매전환 대기재고’ 상태를 하나 더 두고, 상품이 언제 다음 상태로 넘어가는지 기준을 명확하게 정해두는 것이 좋습니다.
여기서 중요한 것은 ② 출고·판매전환 대기재고를 어디까지 포함할 것인지입니다. 창고에서 출고되어 배송 중인 상품은 물론, 해외 운송·통관 중인 상품이나 배송 지연으로 분실 여부를 확인 중인 상품도 여기에 포함됩니다. 배송이 완료됐더라도 계약상 고객의 검수나 승인이 남아 있다면 역시 ② 상태로 관리합니다.
반대로 주문만 접수되고 아직 출고되지 않은 상품은 ① 보유재고에 해당합니다. 송장번호만 발급되고 상품이 창고에 남아 있는 경우도 마찬가지입니다. 반송되어 창고에 다시 입고된 상품은 ① 보유재고로 돌아갑니다.
결국 ②를 구분하는 기준은 상품의 물리적인 위치가 아니라 매출 인식 기준을 충족했는지 여부입니다. 이 경계를 명확하게 정해두면 출고와 매출 인식 사이에 있는 상품을 재고에서 놓치지 않고 관리할 수 있습니다.
출고 후 재고 상태는 어떤 원장으로 관리할까요?
앞에서 나눈 세 가지 재고 상태를 실제 장부에 반영하려면, 상품이 어느 상태에 있는지를 구분해 관리할 수 있는 별도의 구조가 필요합니다. 가장 일반적인 방법 중 하나가 ERP 안에 가상창고를 만들어 재고 상태를 나눠 관리하는 것입니다. 가상창고는 실제 건물이 있는 창고가 아니라, 재고가 어디에 있고 어떤 상태인지를 ERP에서 구분하기 위해 만든 논리적인 창고입니다.
예를 들어 고객에게 출고된 상품은 ‘고객배송중’이라는 가상창고로 옮겨 두고, 매출 인식 기준을 충족하면 해당 재고를 판매출고로 처리하는 방식입니다. 상품의 상태가 바뀔 때마다 창고이동 전표로 수량을 옮기고, 매출이 인식되는 시점에는 별도의 판매출고 전표를 생성하면 각 단계의 재고와 매출을 연결해서 확인할 수 있습니다.
이렇게 상태별 재고를 나누면 각 창고에서 기초재고 + 입고 − 출고 = 기말재고라는 흐름을 기준으로 수량을 확인할 수 있습니다. 아마존의 Inventory Ledger도 기초와 기말 재고를 확인할 수 있기 때문에, FBA 재고를 관리할 때는 리포트의 Starting/Ending Warehouse Balance와 ERP의 V20 잔액을 비교해 차이를 확인할 수 있습니다.
여기에 ERP 전표만 남기는 것보다 상품의 상태가 바뀐 시점과 근거가 되는 원천 데이터를 함께 기록해 두는 것이 중요합니다. 그래야 월말에 숫자가 맞지 않을 때 단순히 수량만 조정하는 것이 아니라, 어느 주문에서 어떤 상태 변화가 있었는지 원본 데이터까지 거슬러 올라가 확인할 수 있습니다.
이런 별도 관리 구조가 필요한지 여부를 매출 규모만으로 판단할 필요는 없습니다. 판매 채널이 여러 개이거나 FBA 같은 해외 창고를 사용하고, 월말에 배송 중인 재고 금액이 매출원가에 영향을 줄 정도로 크다면 가상창고와 상태 전환 로그를 도입하는 것을 검토할 수 있습니다. 외부감사 대상이라면 각 재고 상태와 전환 근거를 추적할 수 있도록 원장과 로그를 갖춰두는 것이 특히 유용합니다.
월말 결산 컷오프에는 어떤 데이터를 남겨야 할까요?
앞서 살펴본 것처럼 출고·판매전환 대기재고는 매출 인식 기준을 충족하기 전까지 별도로 관리해야 합니다. 따라서 월말에는 기준 시점에 어떤 상품이 이 상태에 있었는지를 확인할 수 있도록 스냅샷을 남겨두는 것이 중요합니다. 그래야 다음 달 배송이 완료된 상품을 전월 말 재고와 1:1로 연결해 확인할 수 있습니다.
이 스냅샷이 없다면 다음 달 배송완료된 상품이 전월 말에는 배송 중이었던 재고였다는 사실을 입증하기 어렵습니다. 결국 전월 재고와 다음 달 매출·매출원가를 연결할 근거도 함께 사라지기 때문에, 월말 결산에서 발생한 차이가 단순한 시점 차이인지 실제 재고 차이인지 확인하기가 어려워집니다.
월말 스냅샷은 분실이나 배송 지연을 확인하는 데도 활용할 수 있습니다. 예를 들어 장기간 배송이 완료되지 않은 상품을 월말마다 별도로 확인해두면, 이후 분실로 판단되는 건을 찾아 보상 청구 등 필요한 후속 조치를 진행하기가 수월합니다.
또한 감사 대응이나 환율 차이를 설명할 때도 컷오프 시점의 기록이 필요합니다. 특히 출고일과 정산일이 다른 해외 판매에서는 두 시점의 환율이 달라질 수 있으므로, 스냅샷 당시 적용한 환율과 원본 데이터를 함께 남겨두면 이후 발생한 금액 차이를 시점별로 추적할 수 있습니다.
FBA 리포트와 Payment 리포트는 어디서 어긋날까요?
앞서 월말 기준으로 출고·판매전환 대기재고를 남겨야 한다고 설명했습니다. 그렇다면 실제 FBA 재고와 매출 데이터를 맞춰볼 때는 어떤 자료를 함께 봐야 할까요? FBA에서는 재고 수량이 움직인 시점과 금액이 반영되는 시점이 서로 다르기 때문에, 월말 경계에서 Inventory Ledger와 Payment Report가 어긋나는 경우가 있습니다. 많은 셀러가 Payment Report를 기준으로 매출을 인식하기 때문에, 두 리포트의 차이를 확인하는 것만으로도 출고와 매출 반영 시점의 차이를 파악할 수 있습니다.
다만 Inventory Ledger 상세 리포트에는 Reference ID는 있지만 Amazon Order ID가 없습니다. 따라서 주문 단위로 출고와 매출을 연결하려면 Amazon Fulfilled Shipments Report를 중간 연결 자료로 함께 활용해야 합니다.
세 자료를 연결하면 출고와 Payment 매출이 어긋난 주문을 구분해서 볼 수 있습니다. 월말에는 특히 당월 Posted Date로 매출에 반영됐지만 당월 출고 내역이 없는 주문과, 당월에 출고됐지만 당월 Payment Report에는 반영되지 않은 주문을 함께 확인해야 합니다. 전자는 전월 출고분이 당월에 매출로 반영된 것인지 매핑 오류인지 확인하고, 후자는 지급 보류나 취소, 다음 달 반영 여부를 확인해 차이가 발생한 이유를 구분할 수 있습니다.
환불과 반품 입고도 서로 다른 시점에 반영될 수 있습니다. 환불이 Payment Report에 먼저 기록됐지만 상품은 아직 FBA에 입고되지 않을 수 있고, 반품 상품이 고객 파손이나 불량 등의 이유로 판매 가능한 재고로 돌아오지 않을 수도 있습니다. 환불 후 고객이 상품을 반송하지 않는 경우도 있기 때문에, 환불 Posted Date와 Inventory Ledger 또는 FBA Customer Returns Report의 반품 입고 내역을 함께 비교해야 합니다.
분실·파손은 처리 흐름이 조금 다릅니다. FBA 창고에서 분실이나 파손이 발생하면 Inventory Ledger에 재고조정이 먼저 반영되고, 보상금은 아마존의 조사와 승인 이후 Payment Report에 반영됩니다. 이 과정은 고객 주문과 무관한 창고 내부 조정이기 때문에 Amazon Order ID가 없는 경우도 많습니다.
따라서 분실·파손이 확인된 재고는 재고에서 차감해 재고손실로 처리하고, 이후 보상이 승인되면 해당 금액을 상품매출과 구분해 FBA 보상수익 또는 재고손실 환입으로 처리할 수 있습니다. 이후 Payment Report에 반영된 보상금과 회계 처리 금액을 대사하면, 재고 손실부터 보상금 수령까지의 흐름을 하나로 연결해 확인할 수 있습니다.
출고와 매출 사이의 상품이 보여야 월말 결산을 맞출 수 있습니다
출고와 매출 인식 사이에 있는 상품은 판매 채널이 하나일 때는 크게 눈에 띄지 않을 수 있습니다. 하지만 아마존, 큐텐, 쇼피처럼 주문 확정 방식이 서로 다른 채널을 함께 운영하고 해외 창고까지 사용하기 시작하면, 채널마다 다른 시점에 매출과 재고가 움직이면서 월말마다 설명하기 어려운 차이가 생길 수 있습니다.
이럴 때 가장 먼저 필요한 것은 상품이 어느 상태에 있는지를 구분하는 기준을 정하는 일입니다. 보유재고, 출고·판매전환 대기재고, 판매완료의 경계를 명확하게 정해두면 월말 스냅샷과 리포트 대사도 매달 같은 방식으로 반복할 수 있고, 채널마다 다른 매출 인식 시점도 하나의 기준 안에서 관리할 수 있습니다.
포트원은 채널마다 흩어진 주문·출고·정산 데이터를 하나의 기준으로 연결해, 재무팀이 월말 결산에서 재고와 매출의 흐름을 일관된 기준으로 확인할 수 있도록 재무 마감 자동화 구조를 만들고 있습니다. 매출 인식 기준일을 어떻게 정해야 하는지 더 궁금하다면 매출 인식 기준일 관련 아티클도 함께 살펴보세요.
흩어진 채널 데이터를 재무의 언어로 다시 묶는 것, 재무 OS가 필요한 이유입니다.
자주 묻는 질문 (FAQ)
Q1. 아마존에는 구매확정일이 없는데, 매출 인식 시점은 무엇으로 잡아야 하나요?
아마존에서는 구매확정일 대신 출고일, 배송완료일, Posted Date 등 리포트에서 확인할 수 있는 날짜를 활용할 수 있습니다. 다만 어떤 날짜를 선택할지는 회사의 계약조건과 상품의 통제가 고객에게 이전되는 시점을 기준으로 판단해야 합니다. 구매확정일이 없다는 이유로 특정 날짜를 일괄적으로 매출 인식일로 정하기보다는, 회사가 정한 기준에 따라 일관되게 적용하고 매출원가도 같은 기준에 맞추는 것이 중요합니다.
Q2. 구매확정일이 제공되는 채널이라면 그 날짜를 그대로 매출 인식일로 써도 되나요?
네이버 스마트스토어처럼 구매확정일을 제공하는 채널이라면 해당 날짜를 매출 인식 기준으로 활용할 수 있습니다. 다만 구매확정일 자체가 회계상 매출 인식 시점을 자동으로 결정하는 것은 아닙니다. 계약조건에 따라 상품의 통제가 그보다 앞서 고객에게 이전된다면 실제 매출 인식 시점도 달라질 수 있으므로, 구매확정일은 통제 이전 시점을 판단하기 위한 데이터 중 하나로 보는 것이 좋습니다.
Q3. 이동중 재고와 출고·판매전환 대기재고는 같은 개념인가요?
두 개념은 일부 겹치지만 범위가 다릅니다. 이동중 재고는 일반적으로 창고에서 출고되어 운송 중인 상품을 의미하지만, 출고·판매전환 대기재고는 배송이 완료된 뒤에도 고객 검수나 승인 등 매출 인식 조건이 남아 있는 상품까지 포함합니다. 따라서 출고·판매전환 대기재고를 구분하는 기준은 상품의 물리적인 위치가 아니라 매출 인식 기준을 충족했는지 여부입니다.
Q4. FBA 분실 보상금은 어떻게 회계 처리하나요?
FBA 분실 보상금은 상품 판매의 대가가 아니므로 상품매출과 구분해 FBA 보상수익으로 처리하거나, 회사의 회계정책에 따라 기존에 인식한 재고손실을 환입하는 방식으로 처리할 수 있습니다. 특히 분실에 따른 재고손실 인식 시점과 보상 승인 시점이 서로 다른 달에 걸릴 수 있으므로, Reimbursements Report를 기준으로 분실·파손 재고와 보상금의 연결 관계를 남겨두는 것이 중요합니다. 그래야 월말 결산에서도 재고손실과 보상금이 각각 언제, 어떤 사유로 발생했는지 추적할 수 있습니다.
PortOne Close 도입문의 →
