한눈에 보기
마켓플레이스와 ERP를 연결하면 월 마감도 빨라질 것이라고 기대하기 쉽습니다. 쇼피, 아마존, 큐텐의 정산 데이터가 자동으로 들어오고 ERP에 분개까지 등록되면 재무팀이 하던 일도 크게 줄어든 것처럼 보이죠. 하지만 데이터가 ERP에 들어오는 것과 그 데이터를 바로 마감에 사용할 수 있는 것은 다른 문제입니다.
정산 데이터를 ERP로 옮겼더라도 계정과목이 올바르게 매핑됐는지, 거래에 맞는 환율이 적용됐는지, 원천 데이터와 전표의 숫자가 일치하는지는 별도로 확인해야 합니다. 특히 마켓플레이스마다 리포트 구조가 다르고, 정산 과정에서만 확인되는 프로모션 비용처럼 원천 데이터만으로는 회계 처리가 어려운 항목도 있습니다.
여기에 배송일처럼 회계기간을 판단하는 데 필요한 정보가 정산 파일에 빠져 있는 경우도 있습니다. 숫자는 ERP에 들어왔지만, 그 숫자가 어떤 거래에서 발생했고 어느 기간에 귀속되는지 판단할 근거까지 함께 넘어오는 것은 아닙니다.
그래서 자동화의 효과는 모든 마감 업무를 없애는 데서 나오지 않습니다. 대량의 데이터를 수집하고 입력하거나, 검증된 규칙에 따라 반복적으로 처리하는 일은 시스템이 맡고, 예외 건이나 환율, 프로모션 비용 배부, 회계기간 귀속처럼 판단이 필요한 일은 재무팀이 담당하는 구조가 되어야 합니다.
잘 구축된 자동화라면 재무팀이 원시 데이터를 받아 하나씩 확인하는 대신, 검증과 매핑을 거촜 GL-ready 데이터를 기반으로 마감을 진행할 수 있습니다. 결국 월 마감이 빨라지는 이유는 일이 사라져서가 아니라, 재무팀이 판단하기 전에 시스템이 할 수 있는 일을 먼저 끝내놓기 때문입니다.
왜 월말 결산 속도는 그대로일까요?
마켓플레이스와 ERP를 연결하면 쇼피, 아마존, 큐텐의 정산 데이터가 자동퉾로 들어오고 대시보드에도 거래 내역이 쌓입니다. 여기까지만 보면 재무팀이 하던 일도 상당 부분 줄어든 것처럼 보이죠. 하지만 데이터가 ERP에 들어오는 것과 마감에 바로 사용할 수 있는 데이터가 되는 것은 별개의 문제입니다.
실제로 자동화의 효과가 드러나는 시점은 월말에 GL과 은행 잔액을 맞춰볼 때입니다. 평소에는 거래 내역이 정상적으로 쌓이고 분개도 문제없이 등록되는 것처럼 보여도, 막상 잔액이 맞지 않으면 그때부터 원인을 다시 찾아야 합니다. 어떤 거래가 잘못된 계정으로 들어갔는지, 환율은 제대로 적용됐는지, 원천 데이터와 전표의 금액이 일치하는지를 하나씩 확인해야 하기 때문입니다.
결국 자동화가 처리한 것은 데이터의 이동일 뿐, 그 데이터가 정확한지까지 보장한 것은 아닐 수 있습니다. 특히 계정 매핑이나 환율처럼 회계 기준에 따라 확인해야 하는 항목까지 검증되지 않았다면, ERP에 거래 내역이 아무리 빠짐없이 쌓여 있어도 월말 결산에 바로 활용하기는 어렵습니다.
그래서 재무 마감 자동화를 볼 때는 단순히 “얼마나 많은 데이터를 자동화를 가져왔는가”보다 “재무팀이 다시 확인하지 않아도 되는 상태까지 만들었는가”를 살펴볼 필요가 있습니다. 자동화의 진짜 효과는 데이터를 옮기는 순간보다, 월말에 다시 확인하고 대사해야 할 일이 얼마나 줄었는지에서 확인되기 때문입니다.
마켓플레이스별 데이터는 왜 그대로 ERP에 넣기 어려울까요?
마켓플레이스 정산 데이터를 ERP로 가져오려면 각 리포트의 항목이 실제로 무엇을 의미하는지 해석하고, 그에 맞는 계정과목으로 연결하는 과정이 필요합니다. 문제는 마켓플레이스마다 리포트의 구조와 항목 정의가 다르다는 것입니다. 같은 정산 데이터라도 어떤 항목은 매출로, 어떤 항목은 수수료나 세금으로 처리해야 하기 때문에 단순히 컬럼 이름을 맞춰 넣는 것만으로는 충분하지 않습니다.
아마존 Settlement Report를 예로 들어보겠습니다. 하나의 주문에서도 여러 정산 항목이 별도의 행으로 생성되기 때문에 Principal은 매출로, Commission은 플랫폼 수수료로, FBAPerUnitFulfillmentFee는 풀필먼트 비용으로 각각 구분해야 합니다. Tax와 ItemWithheldTax 역시 단순한 매출 차감액이 아니라 성격에 맞는 부채 계정으로 연결해야 하죠.
결국 정산 데이터를 ERP에 넣는다는 것은 숫자를 옮기는 작업만을 의미하지 않습니다. 각 숫자가 무엇을 나타내는지 해석하고, 그 성격에 맞는 회계 계정으로 연결하는 과정까지 포함합니다.
한 주문에서 최대 5개의 GL 항목이 만들어질 수 있다는 것은, 주문 금액 하나만 가져와서는 회계 처리를 완성할 수 없다는 뜻입니다. 각 정산 항목이 무엇을 의미하는지 구분하고, 그 성격에 맞는 계정으로 정확하게 연결해야 원천 데이터와 장부의 숫자도 맞춰볼 수 있습니다.
마켓플레이스가 늘어나면 이런 작업은 더 복잡해집니다. 쇼피 Income Report는 싱가포르, 베트남, 태국 등 국가에 따라 컬럼 구조가 다르기 때문에 한 국가의 데이터를 기준으로 만든 규칙을 다른 국가에 그대로 적용하기 어렵습니다. 큐텐 역시 QSM 인터페이스와 그 기반 API에서 장바구니 할인 금액을 조회하는 방식에 따라 서로 다른 수치가 반환될 수 있어, 같은 이름의 항목을 연결하는 것만으로는 정확한 값을 보장하기 어렵습니다.
여기에 리포트 형식이 바뀔 가능성도 있습니다. 지난달까지 문제없이 처리되던 구조가 변경되면 기존 규칙이 다른 항목을 읽거나 잘못된 계정으로 값을 보낼 수 있습니다. 한 번 정상적으로 작동했다고 해서 앞으로도 같은 결과를 낸다고 단정하기 어려운 이유입니다.
더 까다룭웜 점은 이런 오류가 시스템의 중단으로 나타나지 않는다는 데 있습니다. 데이터는 계속 들어오고 분개도 정상적으로 생성되기 때문에 자동화가 제대로 작동하는 것처럼 보일 수 있습니다. 잘못된 숫자가 아무 문제 없이 장부에 들어간다면 오류를 발견하는 시점은 결국 월말 마감이나 사후 대사까지 늦어질 수 있습니다.
정산 데이터만으로 전표를 만들기 어려운 이유
정산 파일에는 거래 금액과 수수료, 차감 내역 등이 담겨 있지만, 그 금액을 전표에 반영하는 데 필요한 정보까지 모두 들어 있는 것은 아닙니다. 특히 정산 과정에서만 확인되는 비용은 주문 데이터에 함께 기록되지 않고 별도의 차감 내역으로 나타나는 경우가 있어, ERP에서 해당 비용을 어느 거래에 귀속해야 하는지 판단하기 어려울 수 있습니다.
프로모션 비용이나 큐텐의 메가와리 차감액, 아마존의 프로모션 관련 항목이 대표적입니다. 정산 금액에서 비용이 차감됐다는 사실은 확인할 수 있지만, 그 비용이 어떤 주문에서 발생했는지까지 연결되지 않는다면 ERP에서는 정확다 귀속 대상을 찾기 어렵습니다. 결국 해당 기간에 발생한 하나의 비용으로 묶어 처리하게 되고, 기존 분개 구조에 바로 연결할 계정과목이 없다면 임시 계정이나 통합 계정에 모아두는 경우도 생깁니다.
이렇게 처리한 금액은 나중에 다시 확인해야 할 가능성도 남습니다. 감사나 결산 과정에서 비용의 발생 근거를 확인하려면 정산 파일과 주문 데이터를 다시 찾아 어떤 거래에서 발생한 금액인지 추적하고, ERP에 반영된 금액과 대조해야 하기 때문입니다. 정산 데이터를 ERP로 옮기는 과정에서 거래의 맥락까지 함께 연결하지 못하면, 자동화로 줄인 입력 업무가 결국 사후 검증 업무로 돌아올 수 있습니다.
환율과 회계기간 귀속은 왜 자동화가 어려울까요?
환율이나 회계기간 귀속이 어려운 이유는 단순히 숫자를 옮기는 것으로 끝나지 않기 때문입니다. 같은 거래 금액이라도 어떤 환율을 적용하고, 어느 회계기간에 반영할지에 따라 회계 처리가 달라질 수 있어 거래의 맥락과 회계 기준을 함께 살펴봐야 합니다.
다중 통화 거래부터 보면, 단순히 환율을 하나 적용하는 것만으로는 충분하지 않습니다. 프로세스의 어느 단계에서 환율을 적용했는지, 어떤 환율 소스를 사용했는지 확인해야 하고, 그 결과가 IAS 21에 따른 매출 인식에 사용한 환율과 일관되는지도 살펴봐야 합니다. 특히 거래와 환불이 서로 다른 회계기간에 걸쳐 발생한다면 판단은 더 복잡해질니다. 원거래가 이미 마감된 이후 반품이 발생한 경우에는 해당 원거래와 연결되는 역분개까지 고려해야 하기 때문입니다.
매출을 어느 기간에 인식할지도 마찬가지입니다. K-IFRS에 따른 매출 인식에서는 배송일과 같은 시점 정보가 필요한데, 정산 파일에는 이런 정보가 함께 들어오지 않는 경우가 많습니다. ERP에 매출 금액 자체는 정상적으로 들어왔더라도 그 매출을 어느 회계기간에 귀속해야 하는지를 판단할 근거가 빠져 있는 상황이 생길 수 있는 셈입니다.
결국 환율 적용이나 회계기간 귀속은 데이터가 정해진 규칙에 따라 들어오는지만으로 해결하기 어렵습니다. 어떤 거래인지, 언제 발생했는지, 어떤 회계 기준을 적용해야 하는지를 함께 판단해야 하기 때문에 자동화가 데이터를 옮긴 이후에도 재무팀의 검토가 필요한 영역으로 남습니다.
월 마감 자동화는 어디에서 시간을 줄여줄까요?
앞에서 살펴본 것처럼 모든 마감 업무가 같은 방식으로 자동화되는 것은 아닙니다. 반복해서 처리할 수 있는 일과 거래마다 기준을 적용해야 하는 일을 나눠보면, 자동화로 실제 시간을 줄일 수 있는 영역이 훨씬 선명해집니다.
가장 효과가 큰 영역은 대량의 거래 데이터를 수집하고 입력하는 과정입니다. 예를 들어 정산 데이터 1,000건을 같은 규칙으로 처리해야 한다면 사람이 하나씩 입력하는 것보다 시스템이 일관된 방식으로 처리하는 편이 빠르고 효율적입니다. 원천 데이터의 형식까지 안정적으로 유지된다면 매핑 규칙을 적용하는 과정도 상당 부분 자동화할 수 있습니다. APAC 마켓플레이스에서 비교적 일관된 형식을 갖춘 아마존 Settlement Report가 여기에 해당하며, 주요 예외 케이스를 미리 검증해두면 반복적인 매핑 업무를 안정적으로 처리할 수 있습니다.
반대로 모든 거래에 같은 규칙을 적용하기 어려운 업무는 자동화의 범위가 달라집니다. 예외 건을 어떻게 처리할지, 어떤 환율을 적용할지, 프로모션 비용을 어디에 배부할지, 매출을 어느 회계기간에 귀속할지는 거래의 맥락과 회계 기준을 함께 봐야 하기 때문입니다. 이런 업무까지 동일한 방식으로 자동화하려고 하면 오히려 잘못된 판단을 대량으로 처리하는 문제가 생길 수 있습니다.
그래서 자동화를 잘 활용하는 재무팀은 사람의 업무를 없애는 것보다 사람에게 필요한 판단만 남기는 방향으로 프로세스를 설계합니다. 시스템이 대량의 데이터 수집과 입력, 검증된 규칙에 따른 매핑을 먼저 처리하고 나면 재무팀은 예외 건이나 회계적 판단처럼 자동화하기 어려운 업무에 집중할 수 있습니다. 결국 중요한 것은 자동화의 범위를 최대한 넓히는 것이 아니라, 시스템이 잘할 수 있는 일과 사람이 해야 할 일을 정확히 나누는 것입니다.
데이터가 정상적으로 들어와도 왜 숫자는 틀릴 수 있을까요?
앞서 살펴본 것처럼 자동화는 반복적인 데이터 수집과 입력을 줄이는 데 효과적입니다. 하지만 분개가 정상적으로 등록되고 대시보드에도 문제가 없어 보인다고 해서, 그 숫자까지 정확하다고 보장되는 것은 아닙니다. 오류가 별도의 경고나 중단으로 나타나지 않으면 잘못된 데이터가 그대로 마감에 사용될 수 있기 때문입니다.
특히 주의해야 할 것은 신뢰하기 어려운 원천에서 데이터를 가져오는 경우입니다. 예를 들어 Settlement Report가 아닌 판매자 콘솔이나 UI 화면을 기준으로 데이터를 수집한다면, 화면에서는 정상적인 수치로 보여도 실제 원천 데이터와 다른 값이 전표에 반영될 수 있습니다. 데이터가 들어오지 않는 것이 아니라, 잘못된 데이터가 아무 문제 없이 들어오는 상황인 셈입니다.
이런 오류는 데이터를 가져오는 과정에서 바로 발견하기 어렵습니다. 은행 대사가 맞지 않거나 감사 과정에서 원천 파일을 확인하면서 실제 전표에 반영된 값과 원천 파일의 수치가 다르다는 사실을 뒤늦게 알게 될 수도 있습니다. 그때는 이미 잘못된 숫자를 기준으로 마감을 진행한 뒤일 가능성이 높습니다.
데이터를 가져오는 단계에서 오류를 발견했다면 해당 원천만 바로잡으면 되지만, 마감 이후에 문제가 드러나면 처리해야 할 일이 훨씬 많아집니다. 잘못 반영된 전표를 되돌리고 원천 데이터를 다시 확인한 뒤, 수정된 숫자로 마감 절차를 다시 진행해야 하기 때문입니다.
그래서 자동화에서 중요한 것은 얼마나 많은 업무를 시스템이 처리했는지가 아닙니다. 처음부터 신뢰할 수 있는 원천의 데이터를 가져오고, 그 데이터가 실제 전표에 정확하게 반영됐는지까지 확인할 수 있는 구조인지가 더 중요합니다.
그렇다면 재무 마감은 어디까지 자동화할 수 있음까요?
잘 구축된 자동화는 재무팀이 정산 파일을 받아 직접 해석하고 ERP에 입력하는 구조와는 다릅니다. 데이터를 그대로 ERP에 넘기는 대신, 각 항목을 계정에 맞게 연결하고 데이터와 환율을 검증한 뒤 바로 분개에 사용할 수 있는 GL-ready 데이터로 만들어 전달하는 것이 핵심입니다.
이렇게 데이터가 들어오기 전에 필요한 처리가 끝나 있으면 재무팀은 예외 건이나 환율, 회계기간 귀속처럼 실제 판단이 필요한 부분에 집중할 수 있습니다. 반대로 마감 시점에 계정 연결을 다시 확인하거나, 잘못된 데이터가 어디에서 들어왔는지 거슬러 올라가는 일은 줄어듭니다. 재무팀의 일이 단순히 줄어드는 것보다 확인에 쓰이� 시간을 판단에 쓸 수 있게 되는 것에 가깝습니다.
결국 재무 마감이 빨라지는 이유는 어려운 일이 사라져서가 아닙니다. 재무팀이 데이터를 받아 하나씩 확인하기 전에 시스템이 반복적이둜 기계적인 처리를 먼저 끝내고, 사람이 판단해야 하는 단계만 남겨두기 때문입니다.
PortOne Close도 이 구조를 지햖합니다. 마켓플레이스 정산 데이터를 ERP에 전달하기 전에 각 데이터의 포맷과 계정 연결을 정리하고, 환율을 적용한 뒤 데이터의 정합성을 검증합니다. 재무팀은 검증되지 않은 숫자를 다시 확인하는 대신, 정리되고 검증된 숫자를 바탕으로 실제 판단이 필요한 마감 업무에 집중할 수 있습니다.
판단에 쓸 시간을 확인에 쓰지 않도록 만드는 것. 재무 마감 자동화가 필요한 이유는 바로 여기에 있습니다.
자주 묻는 질문 (FAQ)
Q1. 오픈마켓 정산 자료만으로 계정과목 매핑을 자동화할 수 있나요?
마켓플레이스마다 리포트 구조와 필드 정의가 달라하나의 규칙으로 모든 자료를 처리하기는 어렵습니다. 다만 아마존 Settlement Report처럼 형식이 비교적 일정한 자료라면 주요 예외 ��이스를 충분히 검증한 뒤 매핑 규칙을 안정적으로 적용할 수 있습니다. 쇼피 Income Report는 싱가포르, 뺠트남, 태국 등국가별로 컬럼 구조가 다르기 때문에 각 데이터에 맞는 규칙이 필요하고, 리포트 형식 자체가 변경될 가능성까지 고려해야 합니다.
Q2. 배송일 정보가 없으면 매출 인식 시점은 어떻게 판단하나요?
K-IFRS에 따른 매출 인식에서는 배송 시점과 같은 정보가 필요한데, 정산 파일에 해당 정보가 함께 들어오지 않는 경우가 많습니다. 이 경우 ERP에는 매출 금액과 분개가 정상적으로 들어가더라도 어느 회계기간에 귀속해야 하는지 판단할 근거가 부족할 수 있습니다. 주문 데이터에서 배송 시점을 별도로 확보해 정산 데이터와 연결하는 과정이 필요한 이유입니다. 이런 연결이 없다면 결국 사람이 거래별로 귀속 시점을 확인해야 합니다.
Q3. 정산 단계에서만 확인되는 프로모션 비용은 어떤 계정으로 처리하나요?
큐텐의 메가와리 차감액이나 아마존의 프로모션 관련 항목처럼 정산 과정에서만 확인되는 비용은 주문 데이터와 직접 연결되지 않는 경우가 있습니다. 그러면 ERP에서 특정 주문이나 거래에 비용을 귀속할 기준을 찾기 어려워, 기존 분개 구조에 바로 연결할 계정과목이 없다면 임시 계정이나 통합 계정으로 처리하게 될 수 있습니다.
이렇게 처리한 금액은 마감 이후에도 관리가 필요합니다. 감사나 결산 과정에서 발생 근거를 확인해야 할 때 다시 원천 데이터를 찾아 금액을 추적하고 ERP에 반영된 값과 대사해야 하기 때문입니다.
Q4. 자동화가 제대로 작동하고 있는지는 무엇으로 확인하나요?
분개가 정상적으로 등록되고 대시보드가 깔끔하게 보이는 것만으로는 충분하지 않습니다. 어떤 원천에서 데이터를 가져왔는지, 그리고 그 데이터가 실제 원천 파일과 일치하는지까지 확인해야 합니다.
예를 들어 Settlement Report를 기준으로 데이터를 가져오는지, 아니면 판매자 콘솔이나 UI 화면에서 값을 읽어오는지에 따라 같은 항목이라도 다른 수치가 반영될 수 있습니다. 화면에서는 정상적으로 보이더라도 원천 파일의 금액과 다른 값이 전표에 들어갈 수 있기 때문입니다.
그래서 자동화가 잘 작동하는지는 분개가 등록됐는지보다, 데이터의 출처와 원천 파일 대비 정합성을 확인할 수 있는 구조인지로 판단하는 편이 정확합니다. 은행 대사나 감사 과정에서 차이가 뒤늦게 드러나면, 이미 잘못된 숫자로 마감을 진행한 뒤일 가능성이 높기 때문이죠.
PortOne Close 도입문의 →
