🔎
한눈에 보기
• 전표 처리 단위 — 마켓플레이스 매출을 주문별로 전표에 반영할지, 일별로 합산할지는 대개 ERP 연동 도구가 결정합니다. 어떤 방식을 택하느냐에 따라 감사 증빙부터 반품 대사, 월 마감 업무량까지 달라집니다.
• 주문 단위 처리 — 전표 하나가 원 주문 하나와 연결돼 있어 감사 증빙을 제시하거나 반품을 처리하기 수월합니다. 다만 하루 500건의 주문이 발생한다면 한 채널에서만 월 약 1만 5,000건의 전표가 쌓입니다.
• 일별 합산 처리 — ERP의 처리 부담은 줄일 수 있지만, 3주 뒤 들어온 반품이나 특정 주문의 수수료 오류를 합산 전표에서 찾아내려면 별도의 추적 작업이 필요합니다.
• 핵심은 전표를 어떤 단위로 올리느냐보다, 주문 단위 데이터가 보존돼 있고 장부의 숫자와 공식적으로 연결돼 있느냐에 있습니다.
마켓플레이스 매출을 총계정원장(GL)에 반영할 때는 주문 건별로 전표를 만들 수도 있고, 하루 또는 정산 기간의 매출을 합산해 하나의 전표로 처리할 수도 있습니다. 그런데 막상 실무에서는 브랜드가 이 방식을 직접 선택하기보다, 마켓플레이스와 ERP를 연결하는 연동 도구가 정해둔 방식에 따라 처리하는 경우가 많습니다.
마켓플레이스 매출의 전표 처리 단위는 누가 정할까요?
마켓플레이스 매출을 어떤 단위로 전표에 반영할지는 대개 브랜드가 아니라 마켓플레이스와 ERP를 연결하는 커넥터나 연동 도구가 결정합니다. 애초에 미들웨어가 주문별 전표를 생성하도록 설계됐다면 주문 단위로, 일별 매출을 합산하도록 설계됐다면 합산 단위로 전표가 올라가는 식이죠. 그러다 보니 재무팀이 별도로 검토하거나 선택하기도 전에 처리 방식이 이미 정해져 있는 경우가 많습니다.
그렇다고 이 차이를 가볍게 넘겨서는 안 됩니다. 전표를 어떤 단위로 처리하느냐에 따라 감사인이 요청한 증빙을 얼마나 수월하게 제시할 수 있는지, 반품을 원 거래와 얼마나 정확하게 대사할 수 있는지, 나아가 월 마감 때 재무팀이 감당해야 할 대사 업무가 얼마나 늘어나는지까지 달라지기 때문입니다.
주문 단위 전표는 왜 감사에 유리할까요?
가장 큰 이유는 전표 하나하나가 실제 거래와 직접 연결돼 있기 때문입니다. 반품이 발생해도 일별 합산액을 거슬러 올라가 금액을 다시 계산할 필요 없이, 해당 주문의 원 전표를 찾아 역분개하면 됩니다. 감사인이 특정 매출의 근거가 된 주문을 요청하더라도 별도의 자료를 일일이 대조하지 않고 해당 전표를 조회해 확인할 수 있죠.
매출을 인식하는 시점을 관리하기에도 유리합니다. K-IFRS 제1115호에 따라 고객에게 재화에 대한 통제가 이전되는 시점을 기준으로 수익을 인식해야 하는 경우, 주문별 전표에는 해당 거래의 날짜가 개별적으로 기록되므로 매출 인식 시점을 확인하고 관리하기가 수월합니다. 다만 구체적인 인식 시점은 브랜드의 계약 조건과 회계정책에 따라 달라질 수 있습니다.
이처럼 주문 단위 전표는 거래의 발생부터 매출 인식, 반품 처리까지 하나의 흐름으로 추적할 수 있다는 점에서 감사 증빙을 갖추기에 유리합니다. 특히 감사를 준비하고 있거나 K-IFRS를 적용하는 브랜드라면, 거래별 근거를 확인하는 과정에서 불필요한 대조 작업을 줄일 수 있습니다.
주문 단위 전표 처리는 왜 현실적으로 어려울까요?
문제는 거래량이 늘어날수록 ERP가 처리해야 할 전표도 함께 늘어난다는 점입니다. 예를 들어 쇼피에서 하루 500건의 주문을 처리하는 브랜드라면, 이 채널 하나에서만 한 달에 약 1만 5,000건의 전표가 쌓입니다.
모든 ERP가 이처럼 단일 매출 소스에서 대량의 전표가 유입되는 상황을 감당하도록 설계된 것은 아닙니다. 전표가 많아질수록 시스템 처리 속도가 느려질 수 있고, 월 마감에도 더 많은 시간이 걸리죠. 결국 재무팀은 정작 숫자를 검토하고 이상 거래를 확인하는 일보다, 전표가 제대로 처리되는지 시스템을 관리하는 데 시간을 쏟게 됩니다.
이처럼 거래량이 일정 수준을 넘어서면 주문 단위 전표가 아무리 이상적인 방식이라도 ERP에 모든 거래를 개별 전기하는 것은 현실적인 선택이 되기 어렵습니다.
일별 합산 전표는 무엇을 잃게 될까요?
일별 합산 전표를 사용하면 ERP가 처리해야 할 전표 수를 줄일 수 있습니다. 하루 또는 정산 기간의 거래를 하나로 묶어 처리하면 시스템 부담도, 재무팀이 관리해야 할 전표 수도 줄어들죠. 다만 이 과정에서 놓치기 쉬운 것이 있습니다. 바로 개별 주문과 장부에 기록된 숫자 사이의 연결 고리입니다.
예를 들어 판매가 발생한 지 3주가 지난 뒤 반품이 처리됐다고 가정해 보겠습니다. 주문별로 전표를 관리한다면 해당 주문의 원 전표를 찾아 확인할 수 있지만, 여러 주문이 하나로 묶여 있다면 이야기가 달라집니다. 원 전표에 500건의 주문이 포함돼 있다면 반품이 어느 전표에 속하는지부터 확인해야 하기 때문입니다.
감사 대응도 마찬가지입니다. 감사인이 특정 매출의 근거가 된 거래를 요청하면 합산 전표만으로는 충분하지 않아 정산 리포트까지 함께 제시해야 합니다. 이때 전표와 개별 주문을 연결하는 매핑 정보가 없다면 두 자료를 일일이 대조해 근거를 찾아야 하죠.
문제는 오류를 발견하는 과정에서도 나타납니다. 특정 주문의 수수료가 잘못 계산됐더라도 합산 전표 안에서는 이를 바로 알아채기 어렵습니다. 오류가 전체 금액에 섞여 있다가 은행 입금액과 대사하는 과정에서 차이로 드러나면, 그제야 어떤 거래에서 문제가 발생했는지 역으로 추적해야 합니다.
두 방식의 차이를 정리하면 다음과 같습니다.
결국 두 방식은 서로 다른 장단점을 가집니다. 주문 단위 전표는 거래별 추적이 수월한 대신 ERP가 처리해야 할 물량이 늘어나고, 일별 합산 전표는 처리 부담을 줄여주는 대신 개별 주문의 흐름을 파악하기 어려워집니다. 따라서 합산 전표를 사용하더라도 개별 주문을 추적할 수 있는 데이터와 연결 구조를 어떻게 유지할지가 중요합니다.
결국 전표 처리에서 중요한 것은 무엇일까요?
지금까지 살펴본 두 방식은 각각 장단점이 있지만, 사실 더 중요한 기준이 있습니다. 바로 주문 단위 데이터가 보존돼 있고, 장부에 기록된 숫자와 공식적으로 연결돼 있느냐입니다. ERP에 모든 거래를 주문별로 전기하는 것도 방법이지만, 이 연결 구조를 확보하는 유일한 방법은 아닙니다.
일별 합산 전표를 사용하더라도 주문 단위 데이터를 구조화된 형태로 보관하고, 각 전표에 어떤 주문이 포함됐는지 매핑 정보를 유지한다면 개별 거래까지 추적할 수 있습니다. 전표는 합산하더라도 그 안에 담긴 거래 내역을 필요할 때 확인할 수 있다면 감사 추적성도 확보할 수 있죠.
반대로 주문 단위 데이터가 마켓플레이스에서 내려받은 리포트 파일에만 남아 있고, 장부의 전표와 공식적으로 연결돼 있지 않다면 상황이 달라집니다. 감사 요청이 들어올 때마다 증빙을 다시 구성해야 하고, 반품이 발생하면 원 거래를 찾기 위해 수작업으로 대사해야 합니다. 개별 거래의 오류 역시 합산액에 가려진 채 뒤늦게 발견될 수 있습니다.
결국 핵심은 전표를 얼마나 잘게 나누느냐가 아닙니다. 어떤 방식으로 전표를 처리하든, 장부의 숫자에서 개별 주문까지 거슬러 올라갈 수 있는 구조를 갖추는 것이 중요합니다.
브랜드는 이 문제를 어떻게 풀고 있을까요?
그렇다면 브랜드는 주문 단위 데이터와 장부 사이의 연결을 어떻게 유지하고 있을까요? 실무에서 선택할 수 있는 방법은 크게 세 가지입니다.
가장 먼저 떠올릴 수 있는 방법은 마켓플레이스 데이터를 내려받아 직접 대사하는 것입니다. 특히 초기 단계의 브랜드는 영업이나 운영팀이 스프레드시트와 리포트를 활용해 거래 내역을 확인하는 경우가 많습니다. 별도의 시스템을 구축하지 않고도 바로 시작할 수 있다는 장점이 있지만, 거래량이 늘어나면 수작업만으로 모든 데이터를 관리하기 어려워집니다. 담당자가 바뀌거나 퇴사했을 때 업무가 끊길 수 있고, 감사인이 GL의 숫자와 원천 거래 데이터를 체계적으로 연결해 보여달라고 요청하면 기존 파일만으로 대응하기도 쉽지 않습니다.
두 번째는 데이터 웨어하우스나 미들웨어 같은 내부 데이터 계층을 직접 구축하는 방식입니다. 마켓플레이스별 주문 데이터를 저장하고 ERP에 올라가는 합산 전표와 매핑해 두면, 거래량이 늘어나더라도 데이터를 일관된 구조로 관리할 수 있습니다. 다만 이를 구축하고 유지하려면 엔지니어링 인력이 필요합니다. 특히 마켓플레이스가 정산 리포트의 형식이나 데이터 구조를 변경할 때마다 관련 매핑 로직도 수정해야 하는데, 이러한 유지보수 부담은 생각보다 자주 발생합니다.
마지막으로 외부 솔루션을 활용하는 방법도 있습니다. 주문 단위 데이터 계층을 직접 구축하고 관리하는 대신, 이를 대신 유지해 주는 솔루션을 이용하는 것이죠. 그러면 ERP에는 재무팀이 원하는 단위로 합산 전표를 올리면서도, 개별 주문 데이터는 별도의 대사 계층에 구조화된 형태로 보존할 수 있습니다. 전표 처리의 효율성을 유지하면서도 거래 단위의 추적 가능성을 확보할 수 있다는 점이 장점입니다.
세 가지 방식을 비교하면 다음과 같습니다.
전표 단위보다 주문 데이터가 장부와 이어져 있는지가 먼저입니다
결국 중요한 것은 주문별로 전표를 만들지, 일별로 합산할지 자체가 아닙니다. 주문 단위 데이터가 어디에 보관돼 있고, 장부에 기록된 숫자와 얼마나 안정적으로 연결돼 있느냐가 핵심이죠. 이 연결 구조만 갖춰져 있다면 앞서 살펴본 세 가지 방식 중 무엇을 선택하더라도 감사 증빙을 제시하고, 반품을 대사하고, 오류가 발생한 거래를 찾아 바로잡을 수 있습니다. 반대로 연결이 끊겨 있다면 감사나 반품 처리가 필요한 순간마다 데이터를 다시 맞춰야 하고, 결국 가장 많은 시간과 비용이 드는 시점에 그 한계가 드러납니다.
포트원은 이러한 문제를 해결하기 위해 마켓플레이스 정산 데이터를 주문·SKU 단위로 수집하고 대사합니다. ERP에는 합산 전표를 올리더라도 그 안에 어떤 주문이 포함돼 있는지 별도의 대사 계층에 구조화해 보존하기 때문에, 필요할 때 개별 거래 내역을 다시 구성하는 번거로움 없이 확인할 수 있습니다. 리포트의 날짜 기준 역시 브랜드의 매출 인식 시점에 맞춰 설정할 수 있으며, 마켓플레이스가 정산 리포트 형식을 변경하면 그 변화를 추적해 반영합니다.
전표는 효율적으로 처리하면서도, 장부의 숫자에서 개별 주문까지 언제든 거슬러 올라갈 수 있도록 하는 것. 이것이 전표 처리 단위와 관계없이 데이터의 연결성을 확보하는 방법이며, 재무 OS가 필요한 이유이기도 합니다.
자주 묻는 질문 (FAQ)
Q1. 월 마감 부담을 줄이기 위해 일별 합산 전표로 바꿔도 감사에 문제가 없을까요?
일별 합산 전표를 사용하더라도 주문 단위 데이터가 보존돼 있고, 각 전표에 어떤 주문이 포함됐는지 매핑 정보를 제시할 수 있다면 감사 추적성을 확보할 수 있습니다. 반면 주문 단위 데이터가 내려받은 리포트 파일에만 남아 있고 장부와 연결돼 있지 않다면, 감사 요청이 들어올 때마다 거래의 근거를 다시 찾아 맞춰야 합니다.
Q2. 일별 합산 전표에서 반품은 어떻게 회계 처리하나요?
먼저 반품이 발생한 주문을 확인하고, 해당 주문이 원래 어느 기간의 합산 전표에 포함됐는지 추적해야 합니다. 주문 단위 데이터와 전표 간 매핑이 유지돼 있다면 원 거래를 찾아 대사할 수 있지만, 그렇지 않다면 판매가 발생한 지 몇 주가 지난 반품도 수작업으로 거래 내역을 추적해야 합니다.
Q3. 오픈마켓 정산 데이터는 어떤 날짜를 기준으로 전표를 끊어야 하나요?
전표의 기준일은 브랜드의 회계정책에 따른 매출 인식 시점에 맞춰야 합니다. 주문일, 출고일, 배송 완료일, 정산일 중 어떤 날짜를 적용하느냐에 따라 동일한 주문이라도 매출이 인식되는 월이 달라질 수 있기 때문입니다. 따라서 브랜드의 매출 인식 기준을 먼저 확인하고, 전표와 대사 리포트에도 일관된 날짜 기준을 적용하는 것이 좋습니다.
포트원 클로즈 도입 문의하기
