한눈에 보기
8월이 끝났다고 해서 8월 월 마감까지 끝난 것은 아닙니다. 여러 마켓플레이스에서 판매하는 브랜드라면 플랫폼별 정산 일정과 환불·차지백 처리까지 고려해야 하기 때문에, 8월 월 마감은 9월 10일 전후까지 이어지는 경우가 많습니다.
9월 1일 오전 9시, 8월이 끝난 지 여덟 시간밖에 지나지 않은 시점에 마감 트래커를 열어보겠습니다. 가장 먼저 확인하게 되는 것은 매출이 아니라 '아직 기다려야 하는 것들'입니다. 한국과 동남아는 이미 9월에 들어섰지만 미국은 아직 8월 31일입니다. 지역별 거래가 모두 마무리되고 각 플랫폼의 정산 데이터까지 들어와야 8월 실적을 제대로 확정할 수 있기 때문입니다.
물론 이 시점에도 GMV와 주문 건수는 대략 확인할 수 있습니다. 하지만 이것만으로는 P&L을 완성하기 어렵습니다. 플랫폼 수수료는 프로모션 유형이나 풀필먼트 방식, 반품률 등에 따라 달라지고, 환율 역시 IAS 21에 따라 거래일 기준으로 적용해야 하기 때문입니다. 매출이 발생했다는 사실과 그 매출의 최종 금액을 확정하는 일 사이에는 생각보다 많은 데이터가 필요합니다.
문제는 필요한 데이터가 한꺼번에 들어오지 않는다는 데 있습니다. 9월 1일부터 10일까지 플랫폼마다 서로 다른 일정에 따라 정산 데이터가 순차적으로 도착합니다. 아마존은 2주 단위로 정산하고, 쇼피는 Escrow Report를 통해 정산 구간을 확정하며, 큐텐은 QSM 데이터를 여러 차례에 나누어 제공합니다. 결국 8월의 거래와 비용을 모두 맞춰볼 수 있는 시점도 자연스럽게 뒤로 밀립니다.
여기에 환불과 차지백까지 더해지면 월 마감은 한 번에 끝나지 않습니다. 이미 확인한 8월 실적에 9월 둘째 주까지 새로운 거래 조정 내역이 추가되고, 그때마다 기존 분개를 다시 확인해야 합니다. 같은 분개를 두 번, 많게는 세 번까지 수정하는 일이 생기는 이유입니다.
이 과정이 길어지는 것은 재무팀이 마감을 늦게 시작해서도, 데이터를 놓쳐서도 아닙니다. 마켓플레이스의 정산 주기와 회계팀의 월 마감 일정이 애초에 맞물려 있지 않기 때문입니다.
그렇다면 월 마감에서 중요한 질문은 '왜 이렇게 늦게 끝나는가'가 아닐 수 있습니다. 더 중요한 것은 아직 들어오지 않은 데이터를 기다리는 동안, 추정치와 실제 정산 데이터 사이의 간극을 얼마나 빠르게 좁혀나갈 수 있는가입니다.
월 마감의 첫날은 왜 9월 1일이 아닐까요?
여러 지역의 매출을 하나로 묶어 마감하려면 모든 지역의 거래가 끝나고 필요한 데이터가 모여야 합니다. 문제는 각 지역의 8월이 끝나는 시점도, 마켓플레이스가 정산 데이터를 확정하는 시점도 서로 다르다는 것입니다.
9월 1일 오전 9시를 기준으로 보면 한국과 동남아는 이미 9월에 들어섰지만, 미국은 여전히 8월 31일 오후 8시입니다. 유럽은 이미 자정을 넘겼더라도 마켓플레이스에서 8월 거래를 마감하고 데이터를 확정하는 데는 시간이 더 필요합니다.
그래서 월 마감 첫날에 가장 먼저 확인하는 것은 어제까지의 매출이 아닙니다. 각 지역의 거래가 언제 끝나는지, 플랫폼별 정산 데이터는 언제 확정되는지를 먼저 확인해야 합니다. 달력은 9월 1일을 가리키고 있어도, 재무팀의 8월 마감은 아직 끝나지 않은 셈입니다.
결국 여러 지역에서 판매하는 브랜드의 월 마감은 달력의 첫날부터 바로 시작되지 않습니다. 가장 늦게 거래가 끝나고 데이터가 확정되는 지역과 플랫폼을 기다려야 하고, 그만큼 마감 일정도 뒤로 밀리게 됩니다.
9월 1일에 확인할 수 있는 숫자는 왜 P&L이 될 수 없을까요?
8월 한 달 동안 쌓인 주문 데이터만으로는 매출이 얼마나 발생했는지는 알 수 있어도, 실제로 얼마를 벌었는지까지 알기는 어렵기 때문입니다.
9월 1일에도 총 주문 건수와 대략적인 매출 규모, 어느 채널에서 매출이 발생했는지는 확인할 수 있습니다. 하지만 이 숫자만으로는 Shadow P&L을 만들 수 없습니다. 매출의 흐름을 가늠하는 것과 수수료·프로모션 비용·매출원가까지 반영해 실제 손익을 계산하는 것은 전혀 다른 일이기 때문입니다.
가장 먼저 플랫폼 수수료가 확정되지 않습니다. 수수료는 프로모션 유형이나 풀필먼트 방식, 반품 여부 등에 따라 달라지는데, 9월 1일에는 이런 비용이 아직 정산 데이터에 모두 반영되지 않은 경우가 많습니다.
환율도 마찬가지입니다. IAS 21에 따라 거래일 기준 환율을 적용해야 하기 때문에 월평균 환율 하나를 일괄 적용할 수 없습니다. 주문이 발생한 날짜에 맞춰 각각의 거래에 해당 환율을 적용해야 합니다.
프로모션 비용 역시 아직 남아 있습니다. 쇼피의 11.11이나 큐텐 메가와리처럼 프로모션으로 발생한 차감액은 적절한 비용 항목으로 분류해야 하지만, 실제 차감 금액은 정산 데이터가 들어와야 확인할 수 있습니다. 여기에 매출원가(COGS)까지 실제 주문과 정확히 매칭해야 합니다.
결국 9월 1일에 손에 쥔 숫자는 8월 매출의 '초안'에 가깝습니다. 매출이 얼마나 발생했는지는 보이지만, 그 매출로 얼마를 벌었는지는 아직 보이지 않습니다. P&L을 완성하려면 이후 들어오는 정산 데이터를 기다리며 숫자를 하나씩 확정해야 합니다.
오픈마켓 정산 데이터는 언제, 어떤 순서로 들어올까요?
오픈마켓마다 정산 주기와 데이터 제공 방식이 다르기 때문에, 8월 정산 데이터가 9월 1일에 한꺼번에 들어오는 일은 없습니다. 플랫폼별 일정에 따라 9월 첫째 주부터 열흘 사이에 순차적으로 들어오고, 한 플랫폼의 데이터가 여러 차례에 걸쳐 나뉘어 들어오기도 합니다.
세 플랫폼 모두 달력상의 월말과 실제 정산 주기가 일치하지 않는다는 공통점이 있습니다. 아마존은 2주 단위 정산 주기가 월말을 가로지르고, 쇼피는 월 후반 구간을 별도로 확정합니다. 큐텐은 한 달치 데이터를 한 번에 제공하지 않고 첫째 주 동안 여러 차례에 나누어 전달합니다.
그래서 정산 데이터가 하나씩 들어올 때마다 앞서 추정했던 매출과 비용을 다시 맞춰봐야 합니다. 예상했던 수수료와 실제 수수료가 다를 수도 있고, 임시로 적용했던 환율과 실제 거래일 환율 사이에도 차이가 생깁니다. 미처 반영하지 못했던 프로모션 차감액이 새롭게 확인되는 경우도 있습니다.
이때마다 결산 조정을 반영하고, 추정치로 입력했던 금액을 실제 정산 금액으로 바꿔야 합니다. 결국 월 마감은 어느 하루에 모든 작업을 끝내는 방식이 아니라, 정산 데이터가 들어오는 동안 숫자를 하나씩 확정해가는 과정에 가깝습니다.
8월 마감이 끝난 뒤에도 왜 숫자를 다시 조정해야 할까요?
8월의 거래가 모두 끝났다고 해서 8월 마감이 완전히 끝나는 것은 아닙니다. 환불이나 차지백은 거래가 발생한 시점과 실제 금액이 정산되는 시점이 다르기 때문에, 9월에 확인된 거래를 8월 실적에 다시 반영해야 하는 경우가 생깁니다.
예를 들어 싱가포르의 한 고객이 8월 28일에 제품을 반품했고 같은 날 반품 처리가 완료됐지만, 환불금은 9월 2일에 지급됐다고 가정해 보겠습니다. K-IFRS에 따르면 이 경우 매출을 조정해야 하는 시점은 환불금이 지급된 9월이 아니라 반품이 승인된 8월입니다. 따라서 9월에 확인된 환불 데이터를 8월 매출과 연결해 조정해야 합니다.
문제는 이런 거래가 한두 건에 그치지 않는다는 데 있습니다. 쇼피에서 거래량이 많은 브랜드라면 한 달에 환불 건수가 200건씩 쌓이기도 합니다. 각각의 환불이 어느 주문에서 발생했는지 확인하고, 기존 분개를 수정할지 9월에 상계 처리할지를 건별로 판단해야 합니다.
차지백은 타이밍이 더 복잡합니다. 8월에 결제 분쟁이 제기됐더라도 9월 15일까지 해결되지 않을 수 있기 때문입니다. 분쟁 결과가 확정된 뒤에는 9월에 조정 금액을 반영하는 동시에, 해당 조정이 8월의 어떤 주문과 연결되는지도 추적해 기록해야 합니다.
결국 8월 마감은 9월 1일에 딱 끝나는 작업이 아닙니다. 환불과 차지백처럼 뒤늦게 확정되는 거래가 들어올 때마다 기존 숫자를 다시 확인하고 조정해야 합니다. 9월 둘째 주까지 8월 실적에 작은 조정이 계속 붙는 것은 예외적인 상황이 아니라, 마켓플레이스 월 마감에서 자연스럽게 발생하는 과정입니다.
마감 후에도 바뀌는 숫자, 어떻게 근거를 남길까요?
9월 10일쯤이면 8월의 주요 정산 데이터가 대부분 반영되고, 8월 실적도 실제에 가까운 수준으로 확정됩니다. 하지만 이 과정에서 숫자가 여러 차례 조정됐다는 사실 자체가 문제가 되는 것은 아닙니다. 중요한 것은 각각의 조정이 왜, 언제, 어떤 근거로 이뤄졌는지를 추적할 수 있는가입니다.
9월 1일에 처음 입력했던 대략적인 GMV는 아마존·쇼피·큐텐의 실제 정산 데이터로 차례로 대체됩니다. 여기에 거래일 기준 환율을 다시 적용하고, 환불을 반영하고, 차지백 관련 금액을 조정하면서 같은 분개를 두 번, 많게는 세 번까지 수정하기도 합니다. 이 과정을 거쳐야 CFO가 검토할 수 있는 수준으로 8월 실적이 정리됩니다.
문제는 이듬해 3월, 감사인이 8월의 특정 거래를 다시 들여다볼 때 시작됩니다. "8월 Shopee 매출이 왜 9월 7일에 조정됐고, 9월 9일에 또 조정됐나요?"라는 질문이 나올 수 있기 때문입니다.
이때 각 조정의 근거가 남아 있다면 설명은 어렵지 않습니다. 어떤 정산 리포트를 기준으로 했는지, 어떤 거래에서 차이가 발생했는지, 언제 어떤 이유로 조정했는지를 바로 확인할 수 있기 때문입니다.
반대로 조정 내역만 남아 있고 그 근거를 찾을 수 없다면 이야기가 달라집니다. 마켓플레이스 정산 구조상 자연스럽게 발생한 조정이라도, 왜 숫자가 바뀌었는지 설명할 수 없다면 감사 과정에서 추가 확인이 필요한 항목이 됩니다. 결국 월 마감에서 중요한 것은 숫자를 한 번에 맞추는 것이 아니라, 숫자가 바뀌는 과정을 끝까지 추적할 수 있도록 만드는 것입니다.
재무팀이 서둘러도 월 마감이 늦어지는 이유
지금까지 살펴본 과정에서 재무팀이 특별히 실수한 부분은 없습니다. 그럼에도 월 마감에 열흘이 걸리는 이유는 마켓플레이스의 정산 주기와 회계팀의 마감 일정이 서로 맞춰져 있지 않기 때문입니다. 리포트는 플랫폼의 일정에 따라 나오고, 환불은 실제 처리 시점에 반영되며, 미국과 유럽의 거래는 각 지역의 시간대에 따라 8월 거래가 마무리됩니다.
이처럼 월말 이후에도 일주일 이상 데이터가 추가로 들어오는 구조에서는 월말 당일에 모든 숫자를 확정하기 어렵습니다. 그래서 먼저 확인할 수 있는 데이터를 기준으로 추정치를 세우고, 9월 첫 10일 동안 실제 정산 데이터가 들어올 때마다 금액을 다시 맞춰가는 방식이 일반적인 업무 흐름이 됩니다.
따라서 개선의 여지는 마감 자체를 무리하게 앞당기는 데 있기보다, 추정치와 실제 정산액을 맞춰가는(truing-up) 과정을 얼마나 빠르게 끝낼 수 있는지에 있습니다. 포트원은 추정치와 실제 정산 데이터가 자동으로 이어지는 재무 OS를 구축하고 있으며, 데이터가 들어올 때마다 수작업으로 숫자를 대조하고 조정하는 과정을 자동화해 이 작업을 며칠이 아닌 몇 시간 안에 끝낼 수 있도록 합니다.
마켓플레이스마다 정산 데이터가 어떻게 다르고, 이를 어떻게 맞춰야 하는지 궁금하다면 정산 대사 관련 아티클도 함께 확인해 보세요.
자주 묻는 질문 (FAQ)
Q1. 오픈마켓 정산 데이터가 모두 들어오기 전에 월 마감을 먼저 끝내도 될까요?
먼저 마감하되, 확정된 숫자가 아닌 추정치로 관리하는 방식이 일반적입니다. 아마존은 2주 단위로 정산하고, 쇼피는 Escrow Report, 큐텐은 QSM 데이터를 통해 각각 다른 시점에 정산 금액을 확정합니다. 따라서 9월 1일에 확인할 수 있는 8월 실적은 실제 정산액과 차이가 있을 수 있습니다. 우선 추정치로 마감한 뒤, 실제 정산 데이터가 들어오는 순서에 따라 차이를 조정해 나가는 방식이 현실적입니다.
Q2. 환불의 매출 인식 시점은 반품 승인일과 환불 지급일 중 언제인가요?
반품이 승인된 날을 기준으로 봅니다. K-IFRS에 따라 매출을 되돌리는 시점은 현금이 실제로 지급된 시점이 아니라 반품이 승인된 시점이기 때문입니다. 예를 들어 8월 28일에 반품이 승인되고 환불금이 9월 2일에 지급됐다면, 해당 매출 조정은 9월이 아닌 8월에 반영해야 합니다.
Q3. 같은 계정의 결산 조정이 두세 번 반복되면 감사에서 문제가 되나요?
조정 횟수 자체보다 각 조정의 근거를 추적할 수 있는지가 중요합니다. 마켓플레이스 판매에서는 정산 데이터가 순차적으로 들어오기 때문에 같은 분개를 두세 번 수정하는 일이 발생할 수 있습니다. 다만 각 조정이 어떤 정산 리포트를 근거로, 언제, 왜 반영됐는지 확인할 수 있는 기록이 남아 있지 않다면 감사 과정에서 추가 설명이 필요할 수 있습니다.
Q4. 환율은 월평균 환율 하나를 적용하면 안 되나요?
거래별 환율을 적용해야 하기 때문에 월평균 환율 하나로 일괄 처리하기는 어렵습니다. IAS 21에 따라 거래일 기준 환율을 적용해야 하므로 각 주문을 해당 거래일의 환율과 매칭해야 합니다. 다만 정산 데이터가 늦게 들어오는 경우에는 9월 1일에 임시로 금액을 계산해 두고, 실제 정산 데이터가 확인된 시점에 환율 차이를 조정하는 방식으로 처리할 수 있습니다.
PortOne Close 도입문의 →
