전자상거래에서 환불 및 반품 회계 처리 방법

A refund is not a negative sale. It's four separate accounting events wearing one trench coat.

---

It's the second week of January. Q4 was your best quarter ever — December alone did more revenue than the entire first half of last year. Then the returns window opened.

Now the refunds are pouring in, and the books have stopped making sense. Your payouts are noticeably smaller than your sales. Half the refunds you're processing belong to orders from December — a month you thought was closed. And when you total up what left your account versus what you refunded customers, the numbers don't match, because the processing fees from the original sales seem to have vanished into nowhere.

If you've been staring at this and wondering whether you broke something, you didn't. You're just discovering that nobody ever taught you how to account for refunds in ecommerce — and the intuitive approach almost everyone starts with is wrong in a specific, fixable way.

Here's the intuition, stated plainly: "A refund is just a negative sale. Subtract it and move on."

That's the lie. It feels right because the customer's experience is symmetrical — money in, money out. But your books aren't recording the customer's experience. They're recording four separate financial events, and a refund reverses each one differently. Some fully, some partially, and one not at all.

How to Account for Refunds in E-commerce: One Refund, Four Ledgers

Let's make this concrete with a clearly fictional order.

In December, a customer bought a jacket for $120 total: $112 for the product, $8 in sales tax. Your processor charged you a $3.50 processing fee on the sale. The jacket cost you $45 wholesale, which you recorded as cost of goods sold.

In January, the customer returns it. Here's what actually has to happen in your books.

1. Revenue: contra-revenue, not deleted income

Your first instinct might be to delete or reduce the original sale. Don't. That December sale really happened — erasing it destroys your gross revenue figure, your refund-rate visibility, and your audit trail.

대신, $112는 소득 아래에 위치하며 차변 잔액을 갖는 "환불 및 반품" 또는 "판매 반품 및 할인"이라고 하는 역매출 계정에 기록됩니다. 총 매출은 그대로 유지되고, 환불은 자체 항목으로 표시되며, 순매출은 그 차이입니다. 이제 귀하의 매장이 $112의 매출과 $112의 반품을 기록했음을 알 수 있으며, 이는 "아무 일도 일어나지 않음"이라는 정보와는 매우 다른 정보입니다.

2. Processing fees: the money that doesn't come back

이것이 대부분의 1월 정산을 어렵게 만드는 부분입니다. Shopify Payments를 포함한 대부분의 결제 처리업체는 고객에게 환불할 때 처리 수수료를 반환하지 않습니다.

따라서 고객은 $120 전액을 돌려받지만, 12월의 $3.50 수수료 비용은 그대로 남습니다. 상계 분개는 필요 없으며, 수수료는 단순히 실제 비용으로 장부에 남습니다. 이는 모든 환불이 조용히 비용을 발생시키며, 환불이 많은 주간의 지급액은 "매출 마이너스 환불" 예측보다 적을 수 있음을 의미합니다. 그 차이는 오류가 아닙니다. 수수료입니다.

3. Sales tax: reversing a liability, not income

$8의 판매세는 귀하의 돈이 아니었습니다. 이를 징수했을 때, 이는 판매세 부채 부채 계정으로 들어갔습니다. 귀하는 주를 대신하여 이를 보유하고 있었습니다.

주문을 환불할 때 해당 부채는 취소되어야 합니다. 판매세 부채 $8 차변, 더 이상 빚지지 않음. 이 단계를 건너뛰면 더 이상 존재하지 않는 판매에 대한 세금을 납부하게 됩니다. 주에서는 그 돈을 돌려주는 데 관대하지 않으므로, 처음부터 보내지 않는 것이 훨씬 좋습니다.

4. Inventory and COGS: only if the goods come back sellable

재킷이 재판매 가능한 상태로 돌아오면 비용 측면을 취소합니다. 재고 $45 차변, 매출 원가 $45 대변. 재킷은 다시 자산이 됩니다.

손상되거나 착용되었거나 전혀 돌아오지 않으면 취소하지 않습니다. $45는 해당 거래의 실제 비용으로 매출 원가에 그대로 유지됩니다. 이는 소프트웨어가 완전히 결정할 수 없는 판단이므로, 반품 프로세스에 장부 기록에 반영되는 "재판매 가능 여부" 확인 단계가 필요한 이유입니다.

재킷이 재판매 가능한 상태라고 가정할 때, $120 반품에 대한 전체 그림은 다음과 같습니다.

부분	계정	차변	대변
매출	환불 및 반품 (역매출)	$112.00
판매세	판매세 부채	$8.00
현금 지출	결제 처리업체 정산 계정		$120.00
재고	재고	$45.00
매출 원가	매출 원가		$45.00

그리고 수수료는요? 이 분개에는 어디에도 없습니다. 원래 $3.50는 12월에 그대로 두었던 곳에 그대로 있습니다. 순 결과: 현금 $120을 잃었고, 수수료 $3.50를 영원히 잃었으며, 재킷 $45를 돌려받았습니다. 이것이 실제 환불 하나입니다.

[이미지: 하나의 환불이 네 개의 화살표로 나뉘는 다이어그램 - 매출, 수수료, 판매세, 재고 - 각각 다른 계정에 안착함]

The Special Cases That Bite in January

깔끔한 네 부분 버전은 단일 품목 주문에 대한 전체 환불을 다룹니다. 실제 1월은 더 복잡합니다. 전자상거래 매장이 실제로 직면하는 반품 회계 처리입니다.

Partial refunds

$120 주문 중 $40를 환불하면 모든 부분이 비례적으로 조정됩니다. 부분 역매출, 부분 판매세 취소 - 재고는 일반적으로 전혀 움직이지 않습니다. 부분 환불은 일반적으로 고객이 상품을 보유했음을 의미하기 때문입니다. 배송 지연에 대한 $40 보상 환불은 매출, 세금 및 현금에 영향을 미칩니다. 매출 원가에는 영향을 미치지 않습니다.

Cross-period refunds: the December sale, refunded in January

이것이 1월의 도서 판매가 "중단"되는 가장 큰 단일 이유입니다. 판매는 12월에 발생하고 환불은 1월에 발생합니다. 서로 상쇄하기 위해 12월을 다시 열지 마세요. 환불은 1월의 이벤트이며 1월의 부채 수익으로 기록됩니다.

결과: 1월의 순수익은 12월 판매 없이 12월의 반품 물량을 부담하기 때문에 나빠 보입니다. 이것은 회계 오류가 아닙니다. 그것은 현실이며, 그것을 명확하게 보는 것이 요점입니다. 또한 12월 수치가 최종적으로 유지한 금액을 약간 과대평가한다는 의미이기도 합니다. 4분기 총매출을 기준으로 1월 재고에 대한 베팅을 하기 전에 기억할 가치가 있습니다.

Chargebacks vs. refunds

결제 거부는 태도가 다른 환불이 아닙니다. 그것은 다른 메커니즘입니다. 고객의 은행이 카드 처리업체를 통해 돈을 다시 가져가며, 일반적으로 그 위에 분쟁 수수료가 부과됩니다 (환불 자체와 달리, 승소해야만 돌려받을 수 있으며), 이 모든 것이 몇 주 동안 해결되지 않은 상태로 남아 있을 수 있습니다.

결제 거부를 환불에 묶지 말고 별도의 계정으로 처리하세요. 수수료 메커니즘이 다르고, 시기가 다르며, 증가하는 결제 거부율은 볼 수 있어야 하는 운영상의 경고 신호입니다.

취소는 또 다른 세 번째 종류이며, 동기화 소프트웨어가 차이를 어떻게 모델링하는지 보는 것이 좋습니다. LedgerPort에서는 "취소된 주문에 대한 QB 주문 취소" 설정이 이미 동기화된 주문이 취소될 때 QuickBooks 거래를 취소합니다. 삭제나 환불이 아닌 취소이므로 기록은 감사 추적을 위해 유지되고 수익은 차감됩니다. 동기화되기 전에 취소된 주문은 단순히 건너뜁니다. 대조적으로, 환불은 항상 원본 판매에 대한 연결된 취소 문서를 생성합니다. 현금 환불 대신 스토어 크레딧을 발행하는 경우, 이는 네 번째 이벤트입니다. 기프트 카드 및 스토어 크레딧은 수익이 아닌 부채로 기록됩니다. 위에서 설명한 판매세와 동일한 논리가 상품에 적용되며, 이는 귀하가 현재 빚지고 있는 상품입니다.

Restocking fees

10%의 재입고 수수료를 부과하는 경우, 120달러 주문에 대해 108달러를 환불하지만, 부채 수익 항목은 여전히 전체 제품 금액을 기준으로 합니다. 귀하가 보유한 12달러는 자체 소득 항목(재입고 수수료 소득)으로 기록되거나 환불 감소로 기록됩니다. 어느 쪽이든, "충분히 비슷하다"는 환불 금액으로 조용히 사라지게 하지 마세요. 왜냐하면 환불 총액과 현금 지급 총액이 일치하는지 여부를 확인하는 데 차이가 있기 때문입니다.

The Structure That Keeps This Sane

1월에 환불 회계를 한 번에 하나씩 수정하는 것이 아닙니다. 한 번 설정하면 구조로 수정합니다. 세 가지 구성 요소:

전용 부채 수익 계정. 환불이 현재 수익 라인을 보이지 않게 줄이고 있다면, 소득 아래에 "환불 및 반품"을 만들고 모든 환불을 그곳으로 보내세요. 귀하의 손익 계산서는 즉시 환불율을 알려주기 시작합니다. 대부분의 상점 주인은 그 숫자에 놀랍니다.

월별 환불 요약 항목. 환불마다 4가지 분개 항목이 필요하지는 않습니다. 필요한 것은 각 월의 환불을 수익, 세금, 재고의 4가지 항목에 걸쳐 정확하게 요약하는 것입니다. 수수료는 그대로 두어 월별로 독립적으로 처리할 수 있습니다. 이것이 기간 간 환불이 문제가 되지 않는 이유이기도 합니다. 1월의 요약에는 단순히 12월의 반품이 포함됩니다.

환불을 예상하는 지급액 일치. 반환되지 않은 수수료 때문에 환불이 많은 지급액은 판매액에서 환불액을 뺀 금액과 절대 일치하지 않습니다. 조정 프로세스에서는 각 지급액을 판매, 환불, 수수료로 나누어 은행 입금액과 비교해야 합니다. 전체 방법은 QuickBooks에서 Shopify 지급액 조정하기 가이드에 나와 있습니다. 연말 전에 이 구조를 갖추면 세금 신고 시즌이 고고학 프로젝트가 되지 않습니다. Shopify 스토어를 위한 세금 준비 체크리스트는 정리된 환불 데이터가 얼마나 유용한지 보여줍니다.

Where Automation Picks This Up

위의 모든 것은 수동으로 할 수 있습니다. 또한 소프트웨어가 처리해야 하는 반복적이고 동시에 4가지 작업을 수행하는 것과 정확히 일치하므로 동기화 도구가 유용합니다.

LedgerPort의 환불 처리는 Shopify 및 WooCommerce 스토어에 대해 이 구조를 자동으로 적용합니다. 환불은 판매를 덮어쓰는 대신 역분개 수익 계정에 게시되고, 판매세 취소는 환불별로 계산되며, 반환되지 않은 처리 수수료는 별도로 유지되어 지급액이 일치하고, 기간 간 환불은 마감된 장부에 영향을 주지 않고 올바른 월에 처리됩니다. Scale 요금제에서는 수수료와 환불이 이미 분리된 지급액 분개가 제공됩니다. 가격은 무료부터 시작하며, 유료 요금제는 월 25달러부터 시작하고 14일 환불 보장 정책이 있습니다.

QuickBooks 측은 회계사가 수동으로 하는 작업을 반영합니다. 송장으로 동기화되는 주문에는 원본 송장에 연결된 신용 메모가 있고, 판매 영수증으로 동기화되는 주문에는 원본 판매에 연결된 환불 영수증이 있습니다. 어느 쪽이든 원본 12월 거래는 그대로 유지됩니다. 이는 위의 4가지 항목 구조에서 "판매 삭제 금지" 규칙을 소프트웨어가 적용한 것과 정확히 일치합니다. 부분 환불은 환불된 금액에 대해서만 거래를 생성하며, Shopify에서 환불된 금액과 일치하도록 항목, 세금 및 배송이 분리됩니다.

활성화는 설정 한 번으로 가능합니다. 동기화 구성 » 주문에서 환불됨, 부분 환불됨 또는 둘 다를 결제 상태 트리거로 선택하세요.

A few honest trade-offs to know before you rely on it. A refund can only attach to an order that already exists in QuickBooks — if the original sale never synced, the refund has nothing to land on until you sync the order first. If a refund gets edited in Shopify after it was issued, the synced amount can come through wrong until you push it again. And if neither refund trigger is enabled, refunds are excluded from syncing entirely and your QuickBooks balance quietly drifts away from Shopify. None of these are rebuild-the-books problems: when one slips through, you manually re-sync the specific order and LedgerPort creates the missing refund transaction.

On WooCommerce: refunds are per-gateway plumbing

The story above is the Shopify edition. On WooCommerce, refunds are a first-class synced entity in their own right: the LedgerPort plugin registers a dedicated refund.created webhook, so issuing a refund fires its own sync event instead of being inferred from an edit to the order. And because different gateways settle refunds differently, refund sync is configured per gateway in Sync Config » Payments: each payment gateway LedgerPort detects in your store gets its own refund-enabled toggle, its own clearing account, and its own refund reference numbering — a prefix/suffix format or the WooCommerce refund ID — so every refund in QuickBooks traces back to the exact store event that created it.

The operational payoff is verification. The Manual Sync page's Payments tab replaces text search with two dropdown filters — payment gateway and sync status — so "every Stripe payment that hasn't reached QuickBooks yet" is a two-dropdown query. That same filter pair is how you confirm, during a refund-heavy week, that the contra-revenue flow actually ran for each gateway rather than assuming it did.

One honest caveat: no tool can tell you whether a returned jacket is sellable. The inventory leg still needs a human decision at the returns desk. What automation removes is everything after that decision.

Refunds Never Become Fun. That's Not the Goal.

Here's the tragicomic truth about all of this: even with perfect books, January refunds still sting. You're still returning cash from your best quarter, still eating the processing fees, still watching net revenue dip while the returns wave passes through.

What changes is that the sting becomes legible. The payout matches. The tax liability is right. December stays closed. The refund rate is a number on a report instead of a bad feeling in your stomach. Refunds go from being a crisis to being boring — and boring, in bookkeeping, is the entire goal.

1월 매출이 이 게시물 상단의 예시처럼 줄어드는 지급액, 12월 환불이 1월까지 이어지는 문제, 누락된 수수료 등으로 어려움을 겪고 있다면, 4단계 구조가 해결책입니다. 다음 환불 물결이 오기 전에 이를 실행할 수 있습니다. LedgerPort로 무료 체험을 시작하고 다음 환불을 올바르게 처리하도록 하세요 →