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달러는 귀하의 수익이 아닙니다. 수익도 아니고 이익도 아닙니다. 귀하의 수익에서 네 가지 범주의 공제액을 뺀 금액이며, 이 모든 것을 모호하게 만드는 단일 숫자로 통합된 것입니다.

이것이 구조적인 문제입니다. 전자상거래 플랫폼은 순 지급액을 지급합니다. 회계 소프트웨어는 총 거래를 예상합니다. 둘 사이에 네이티브 번역 계층이 없으며, 이를 구축하기 전까지 "전자상거래 회계 모범 사례"는 금이 간 기초 위에 세워집니다. WooCommerce 스토어도 같은 문제에 직면합니다. 저희의 WooCommerce 회계 가이드는 해당 플랫폼의 버전을 다룹니다.

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

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

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

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

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

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

이러한 결정이 추상적으로 들린다면, 실제 동기화 도구에서 어떻게 보이는지 보여드리겠습니다. 바로 탭 페이지입니다. LedgerPort의 동기화 구성 화면에는 일반, 주문, 제품, 고객, 결제, 세금, 기타 등 7개의 탭이 있으며, 각 탭에는 이 섹션의 결정 사항이 포함됩니다. 결제 게이트웨이는 결제 탭에 있으며, 스토어에서 감지된 모든 게이트웨이는 자체 정산 계정을 갖게 되며, 구성하지 않은 모든 항목에 대한 기본 정산 계정이 대체로 사용됩니다. 판매세는 세금 탭에 있으며, 선택한 QuickBooks 부채 계정에 게시됩니다. 각 주문의 형식(판매 영수증 또는 송장)은 주문 탭의 드롭다운 메뉴입니다.

이 페이지의 두 가지 속성은 모범 사례 기사에 중요합니다. 첫째, 문서 자체의 FAQ에 따르면 대부분의 스토어는 동기화 구성을 전혀 건드리지 않고 동기화를 시작할 수 있습니다. 기본값이 합리적이므로 구조가 사전 필수 프로젝트가 아닙니다. 둘째, 구성 변경은 향후 동기화에만 적용됩니다. 이미 게시된 내용은 소급하여 다시 작성되지 않으므로 나중에 결정을 조정해도 마감된 기간이 손상되지 않습니다. 즉, 이 기사의 관행은 열망적인 것이 아닙니다. 그것은 탭입니다.

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

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

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

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

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

알아둘 가치: 최신 동기화 도구에서 요약 항목은 수동으로 만드는 것이 아니라 이름이 지정되고 선택 가능한 모드입니다. LedgerPort는 이를 일일 요약이라고 부릅니다. 하루에 하나의 저널 항목으로, 해당 날짜의 모든 주문을 집계하며, 동기화 구성 » 주문의 주문별 옵션(판매 영수증, 송장)과 동일한 드롭다운에서 선택됩니다. 공급업체 자체의 지침에 따르면 하루에 약 100개 이상의 주문이 임계점이며, 그 이하에서는 주문별 기록이 완벽하게 관리 가능하며 QuickBooks에서 주문 수준의 세부 정보를 제공합니다. 주문별 대 요약은 도구에서 상속하는 철학이 아니라 선택하는 설정입니다.

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

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

동기화 도구를 사용 중이라면, 그 전에 단계 0을 추가하세요. 동기화 로그에서 오류를 필터링하는 것입니다. LedgerPort의 모든 동기화 시도는 동기화됨, 오류, 보류 중, 보류 중 상태로 기록되며, 감사 로그를 상태 = 오류로 필터링하는 것이 존재하는 가장 빠른 사전 조정 확인입니다. 2주차에 동기화에 실패한 주문은 총 수익의 구멍이며 3단계로는 절대 확인할 수 없습니다. 지금 발견하면 수정하고 다시 동기화하면 됩니다. 조정 중에 발견하면 존재하지 않았던 숫자를 찾는 한 시간의 작업이 됩니다. 마감 전에 발견된 오류는 마감 중에 피할 수 있는 저널 누락입니다.

월 500건 이상의 주문을 수동으로 처리하는 경우, 1단계부터 3단계까지는 4시간에서 8시간이 걸립니다. 월 2,000건 이상의 주문의 경우, 계산이 전혀 맞지 않게 됩니다. 항목을 놓치고 숫자를 잘못 입력하며, 매달 현실에서 점점 더 멀어지는 "대충 맞는" 조정으로 월말을 맞이하게 될 것입니다. 자동화 도구는 지급액-총 수익 변환을 자동으로 처리하여 이 시간을 한 시간 미만으로 줄입니다. 각 지급액, 수수료, 환불을 입금액과 일치시키는 전체 수동 안내는 QuickBooks에서 Shopify 지급액 조정 가이드에 나와 있습니다.

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

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

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

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

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

"올바른 것"에 대한 두 번째 테스트가 있으며, 이는 평가하는 모든 도구에 적용할 가치가 있습니다. 자동화가 회계 정책을 따르나요, 아니면 자체 정책을 강요하나요? LedgerPort에서는 대부분의 도구가 하드코딩하는 두 가지 정책이 한 화면에 설정되어 있습니다. 첫 번째는 동기화 방법입니다. 개별 판매 영수증, 미결 수취채권이 있는 송장 또는 일일 요약 저널 항목으로 주문을 게시하는지는 동기화 구성 » 주문에서 선택할 수 있으므로, 주문별 대 요약 장부는 자동화될 뿐 귀하의 아키텍처로 유지됩니다. 두 번째는 수익 인식 시점입니다. 동기화 트리거는 지급 상태와 이행 상태의 행렬이며, 주문은 두 조건이 모두 충족될 때만 게시됩니다. 따라서 수익을 이행 시점에 인식하는 B2B 스토어와 지급 시점에 인식하는 DTC 스토어는 동일한 화면에서 다른 체크박스를 구성하며, 각 스토어는 정책에 맞는 장부를 받게 됩니다.

그리고 이전 섹션과의 정직한 연결: 이 모든 것은 구조 없이는 작동하지 않습니다. 게이트웨이 대 청산 계정 매핑은 동기화 구성 » 지급에 있으며, 이는 자동화가 계정 차트 섹션에서 구축한 수수료 분리 아키텍처에 게시된다는 것을 의미합니다. 이 작업은 대체되지 않고 운영됩니다. 도구 설정으로 표현되는 회계 정책: 이것이 모든 자동화에 적용해야 할 표준입니다.

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

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

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

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

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

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