5가지 이상의 전자상거래 회계 모범 사례 (상세 분석)

일요일 밤 11시입니다. 지난 두 시간 동안 Shopify 지급 보고서와 QuickBooks 입금액 간의 1,600달러 차이에 대해 알아내려고 애쓰고 있습니다. CSV를 두 번 다시 내보냈고, 날짜 범위를 세 번 확인했습니다. 은행에서는 이번 달에 14,200달러가 입금되었다고 합니다. Shopify에서는 15,800달러를 판매했다고 합니다. QuickBooks에는 세 번째 숫자, 즉 14,740달러가 있는데, 어디서 나왔는지 전혀 알 수 없습니다.

그래서 합리적인 사람이라면 누구나 하는 것처럼 “전자상거래 회계 모범 사례”를 구글에 검색합니다. 그리고 여러 회사에서 게시한 동일한 기사를 찾게 되고, 똑같은 조언을 받게 됩니다. 개인 재정과 사업 재정을 분리하세요. 클라우드 회계 소프트웨어를 사용하세요. 판매 원가를 추적하세요. 매월 결산하세요.

이미 이 모든 것을 하고 있습니다. 그런데도 장부는 여전히 틀립니다. 그러다 보면 어느 순간 조용한 거짓말을 믿기 시작합니다. 전자상거래 회계는 본질적으로 복잡하며, 대충 해도 최선이다.

그렇지 않습니다. 문제는 모범 사례를 무시하는 것이 아닙니다. 문제는 모든 사람이 게시하는 전자상거래 회계 모범 사례가 잘못되었거나, 오히려 전통적인 소규모 사업체에는 올바르지만 수익을 수집하는 플랫폼과 기록하는 소프트웨어가 근본적으로 다른 언어를 사용하는 사업체에는 맞지 않는다는 것입니다.

아무도 언급하지 않는 전자상거래 회계 모범 사례의 구조적 문제

이 1,600달러의 차이는 실제로 다음과 같은 이유로 발생합니다. 지난달 Shopify 스토어에서 총 15,800달러의 매출을 처리했습니다. 하지만 Shopify는 15,800달러를 보내지 않았습니다. 돈이 은행 계좌에 입금되기 전에 Shopify는 결제 수수료 620달러, 반품된 7건의 주문에 대한 환불 480달러, Shopify 구독 및 앱 요금 340달러, 차지백 조정 160달러를 공제했습니다. 은행에 도착한 금액은 순액인 14,200달러입니다.

귀하의 회계 소프트웨어는 이 모든 것을 알지 못합니다. QuickBooks는 14,200달러의 입금을 확인하고 기록했습니다. 하지만 14,200달러는 귀하의 수익이 아닙니다. 수익도 아니고 이익도 아닙니다. 귀하의 수익에서 네 가지 범주의 공제액을 뺀 금액이며, 이 모든 것을 모호하게 만드는 단일 숫자로 통합된 것입니다.

이것이 바로 구조적인 문제입니다. 전자상거래 플랫폼은 순 지급액을 지급합니다. 회계 소프트웨어는 총 거래를 예상합니다. 둘 사이에는 네이티브 번역 계층이 없습니다. 그리고 이를 구축하기 전까지는 “전자상거래 회계 모범 사례”가 깨진 기반 위에 세워지는 것입니다.

월별로 "정산하라"는 말을 들을 때, 상대방은 귀하의 회계 소프트웨어에 이미 정산할 올바른 데이터가 있다고 가정합니다. 그렇지 않습니다. "COGS를 정확하게 추적하라"는 말을 들을 때, 수익 수치가 마진 계산을 의미 있게 만들 만큼 정확하다고 가정합니다. 그렇지 않습니다. 조언이 틀린 것은 아닙니다. 다만 불완전할 뿐입니다. 실제로 중요한 부분을 건너뜁니다.

실제로 중요한 계정과목표 및 수수료 분리 결정

모든 것을 바꾸는 첫 번째 관행은 지루하게 들릴 수 있습니다. 바로 계정 차트를 올바르게 설정하는 것입니다. 기본 QuickBooks 계정 차트가 아니라, 돈이 은행에 도달하기 전에 플랫폼을 통해 이동하는 비즈니스를 위해 설계된 계정 차트입니다.

가장 중요한 단일 결정은 Shopify Payments 잔액을 QuickBooks의 은행 계좌로 취급하는 것입니다. 그것이 바로 그것이기 때문입니다. Shopify는 자금을 보유하고, 일괄 처리하고, 일정에 따라 지급합니다. 은행 계좌와 정확히 같습니다. QuickBooks에 "Shopify 지급금" 계정을 만들고 유형을 은행으로, 상세 유형을 당좌 예금으로 설정하면, 갑자기 14,200달러 입금이 미스터리가 되지 않습니다. 그것은 한 계좌(Shopify)에서 다른 계좌(귀하의 은행)로의 이체가 됩니다. 총 수익, 수수료, 환불은 모두 Shopify 계정 내에 있으며, 그곳에 있어야 합니다.

두 번째 결정은 수수료 분리입니다. 대부분의 스토어 소유자는 Shopify의 결제 처리 수수료를 단일 일괄 비용으로 기록합니다. 기록한다면 말입니다. 하지만 모든 지급금에는 최소 세 가지의 별도 수수료 범주가 숨어 있습니다. 결제 처리 수수료(거래당 카드 수수료), 플랫폼 수수료(Shopify 구독료, 앱 요금), 환불 관련 조정. 각 수수료는 다르게 작동하고, 다르게 확장되며, 비즈니스에 대해 다른 것을 알려주기 때문에 다른 비용 계정에 속해야 합니다.

할인 및 환불에 대한 역매출 계정도 필요합니다. 환불은 비용이 아니라 수익의 감소입니다. 이를 비용으로 기록하면 매출 총액과 비용 총액이 모두 부풀려져 실제 마진이 보이지 않게 됩니다. 환불용 역매출 계정과 할인용 역매출 계정을 별도로 두면 총 수익이 정확하게 유지되고 순수익을 계산할 수 있습니다.

요약 분개 및 월별 마감의 실제 모습

대부분의 스토어 소유자를 놀라게 하는 한 가지 관행이 있습니다. 아마도 Shopify의 모든 개별 거래를 QuickBooks로 동기화해서는 안 될 것입니다.

월 500건의 주문을 처리한다면, 각 주문을 동기화하는 것은 QuickBooks에 500개의 개별 항목을 생성하는 것을 의미합니다. 여기에 관련 수수료 항목, 세금 항목, 환불 항목까지 더해지면 QuickBooks가 느려집니다. 보고서 생성에 시간이 오래 걸립니다. 파일 탐색에 시간이 더 걸리기 때문에 회계사가 더 많은 비용을 청구합니다. 그리고 아이러니하게도, 그렇게 세분화된 정보가 장부를 더 정확하게 만드는 것이 아니라 사용하기 어렵게 만듭니다.

더 나은 접근 방식은 요약된 분개입니다. 하루 또는 주 단위로 특정 기간의 모든 거래를 하나의 항목으로 통합하는 요약입니다. 하나의 항목이 해당 일자의 총 매출, 수수료, 환불, 수금된 세금, 순 지급액을 기록합니다. 장부는 깔끔하게 유지되고, 보고서는 빠르게 실행되며, 숫자는 은행 입금액과 정확히 일치합니다.

이것이 대부분의 숙련된 전자상거래 회계사가 권장하는 방식이며, LedgerPort와 같은 도구가 자동으로 생성하는 것입니다. 하지만 거래량이 충분히 적다면 수동으로 할 수도 있습니다. 문제는 "충분히 적은" 것이 귀하의 스토어를 설명하는지 여부이며, 이는 월별 마감으로 이어집니다.

기사에서 "월별로 조정하라"고 할 때, 전자상거래 스토어의 경우 실제로 어떻게 보여야 하는지는 다음과 같습니다.

1. 해당 월의 Shopify 지급 보고서를 가져옵니다. 여기에는 모든 지급액과 그 내용이 표시됩니다.
2. 각 지급액을 은행 계좌의 입금액과 일치시킵니다. 모든 지급액은 1-3 영업일 이내에 해당 입금액이 있어야 합니다.
3. 각 지급액의 총 구성 요소(매출, 수수료, 환불)가 QuickBooks에 개별 항목 또는 요약 분개로 올바르게 기록되었는지 확인합니다.
4. QuickBooks의 Shopify 지급 자금 계정을 0으로 조정합니다 (또는 Shopify가 미결제 자금을 보유하고 있는 경우 현재 보유 잔액으로 조정합니다).
5. 손익 보고서를 실행하고 총 수익, 순 수익 및 수수료 합계가 Shopify 관리자 대시보드와 일치하는지 확인합니다.

월 500건 이상 주문을 수동으로 처리하는 경우, 1-3단계는 4-8시간이 소요됩니다. 2,000건 이상 주문 시에는 계산이 완전히 불가능해집니다. 항목을 놓치거나 숫자를 잘못 입력하게 되며, 매월 "대충 맞는" 조정으로 마감하게 되어 분기마다 현실에서 더 멀어집니다. 자동화 도구는 지급액-총액 변환을 자동으로 처리하여 이를 1시간 미만으로 단축합니다.

수동 조정이 필요한 시기를 알고 올바른 것을 자동화하기

모든 전자상거래 회계 모범 사례 기사는 회계 자동화를 권장합니다. 하지만 무엇을 언제 자동화해야 하는지에 대해서는 거의 알려주지 않습니다.

수동 전자상거래 장부 기록에는 한계점이 있으며, 대부분의 사람들이 생각하는 것보다 낮습니다. 월 200-300건의 주문부터는 거래 수동 분류, 지급액 일치, 수수료 조정에 드는 시간 비용이 자동화 도구 비용을 초과하기 시작합니다. 월 500건 이상 주문 시, 수동 조정은 거의 확실하게 시간당 가장 비싼 항목이 됩니다. 단지 시간으로 비용이 처리될 뿐, 송장에는 표시되지 않기 때문에 보이지 않을 뿐입니다.

잘못된 정산 관행은 단순히 시간을 낭비하는 것이 아닙니다. 수익을 잃게 됩니다. 업계 데이터에 따르면, 부실한 정산은 추적되지 않은 수수료, 누락된 차지백, 잘못 분류된 환불을 통해 총 매출의 2-3%를 조용히 누출시킬 수 있습니다. 연간 매출 100만 달러를 올리는 상점의 경우, 이는 돈이 도난당해서가 아니라 장부가 불일치를 잡아내지 못했기 때문에 발생하는 20,000~30,000달러의 보이지 않는 손실입니다. 이 수치는 "대부분의 Shopify 스토어 소유자가 저지르는 7,500달러의 실수"에서 다룬 내용과 일맥상통합니다. 이 문제를 잘못 처리하는 비용은 대부분의 소유자가 생각하는 것보다 훨씬 빠르게 누적됩니다.

하지만 “모든 것을 자동화하라”는 잘못된 조언입니다. 중요한 특정 자동화는 지급액-총매출 변환입니다. 즉, 순 입금액 14,200달러를 받아 총 매출 15,800달러, 처리 수수료 620달러, 환불 480달러, 플랫폼 수수료 340달러, 차지백 조정 160달러의 구성 요소로 다시 분해하는 것입니다. 이것이 바로 지루하고 오류가 발생하기 쉬우며 구조적으로 반복적인 변환입니다. 실제로 변화를 가져오는 자동화입니다.

이메일 마케팅이나 재고 재주문을 자동화하는 것은 유용합니다. 지급액-총매출 변환을 자동화하는 것은 기본입니다. 이것이 없으면 비즈니스의 다른 모든 재무 프로세스는 불완전한 데이터로 작동하게 됩니다. 해당 변환 계층이 실제로 어떻게 작동하는지 정확히 확인할 수 있습니다.

“전자상거래 회계 모범 사례”의 아이러니

이 기사를 찾아온 것은 해야 할 일 목록을 얻기 위해서였을 것입니다. 재정 분리, QuickBooks 사용, 매출 원가 추적, 월별 정산 등, 그 목록을 보셨을 겁니다. 북마크했을 수도 있습니다. 모든 항목을 확인했을 수도 있습니다. 그런데도 일요일 밤 장부는 여전히 1,600달러가 맞지 않았습니다.

아이러니하게도 전자상거래 정산 재앙을 실제로 방지하는 관행은 누구의 표준 목록에도 없습니다. 이는 계정 원장 설정 방식, 플랫폼 지급 처리 방식, 요약 항목 또는 거래별 동기화 사용 여부, 그리고 지급액 변환을 수동으로 중단하는 시점과 같은 구조적 결정입니다. 이것들은 화려하지 않습니다. 목록 기사의 좋은 헤드라인을 만들지 못합니다. 하지만 다른 모든 전자상거래 회계 모범 사례를 실제로 작동하게 만드는 기반입니다.

그 1,600달러의 차이는 미스터리가 아니었습니다. 처리 수수료 620달러, 환불 480달러, 플랫폼 수수료 340달러, 차지백 조정 160달러였습니다. 이 모든 것은 돈이 은행에 도달하기 전에 공제되었고, 회계 소프트웨어 어디에도 기록되지 않았습니다. 일단 그것을 이해하면, 수정은 기계적입니다. 변환 계층을 설정하는 것(올바른 계정 원장으로 수동으로 또는 LedgerPort와 같은 도구로 자동화)은 일치하지 않는 숫자를 보며 보내는 또 다른 일요일 밤보다 시간이 덜 걸립니다.

무료로 시작하기를 클릭하고 첫 달 정산을 자동으로 확인하세요.