지난주 고객들이 여러분에게 10,000달러를 결제했습니다. 하지만 은행 계좌에는 9,412.55달러만 입금되었습니다. 나머지 587.45달러는 어디로 갔을까요? 그리고 왜 입금액은 단일 송장 금액과 일치하지 않는 것일까요?
Stripe, Square, PayPal, Shopify Payments 또는 기타 결제 프로세서를 통해 카드 결제를 받는다면, 현대 소규모 비즈니스에서 가장 흔한 장부 정리의 골칫거리인 '일치하지 않는 정산액' 문제를 이미 겪어보셨을 것입니다. 해결책은 더 많은 스프레드시트가 아닙니다. 정산액에 실제로 무엇이 포함되어 있는지 이해하고 각 항목을 올바른 위치에 기록하는 것입니다.
입금액이 매출과 일치하지 않는 이유
결제 프로세서는 고객과 은행 사이에 위치합니다. 고객이 결제할 때 돈은 여러분에게 바로 전달되지 않습니다. 프로세서가 이를 수집하고 잠시 보유한 뒤, 지급해야 할 금액이나 보유금을 차감하고 남은 금액을 정산액(플랫폼에 따라 'settlement' 또는 'deposit')이라는 묶음으로 보냅니다.
이 정산액은 깔끔한 숫자로 떨어지는 경우가 거의 없는데, 일반적으로 다음과 같은 항목들이 하나의 정산액에 묶여 있기 때문입니다.
- 총 매출(Gross sales) — 고객에게 청구된 전체 금액
- 결제 수수료(Processing fees) — 프로세서의 몫으로, 보통 카드 거래당 약 2.9% + $0.30
- 환불(Refunds) — 해당 기간 동안 고객에게 반환된 금액
- 차지백 및 분쟁(Chargebacks and disputes) — 강제 환불로, 종종 추가 수수료가 발생함
- 판매세(Sales tax) — 판매 가격 외에 징수된 세금 (이것은 수익이 아니라 부채입니다)
- 순환 유보금(Rolling reserves) — 프로세서가 완충 장치로 보유하는 매출의 일부
- 조정 항목(Adjustments) — 환전 차이, 수정 사항 및 기타 수수료
은행 명세서에는 최종 순액만 표시됩니다. 만약 그 순액을 "수입"으로 기록한다면, 장부는 최소 세 가지 면에서 틀리게 됩니다. 수익은 과소평가되고, 결제 수수료는 보이지 않게 되며, 판매세 부채는 사라집니다. 세금 신고 시기가 되면 그 어떤 것도 일치하지 않게 됩니다.
정산 내역 조정의 목표는 간단합니다. 고객이 지불한 금액과 은행에 입금된 금액 사이의 격차를 항목별로 설명하는 것입니다.
중간 계정(Clearing Account): 총액과 순액 사이의 가교
이를 처리하는 가장 깔끔한 방법은 중간 계정(Clearing account) (보유 계정 또는 일부 소프트웨어에서는 "미입금 자금"이라고도 함)을 사용하는 것입니다. 이를 결제 프로세서 내부의 잔액을 반영하는 임시 보관소라고 생각하세요.
기본 모델은 다음과 같습니다.
- 고객이 결제하면 돈이 중간 계정으로 유입됩니다 (여기에 총 매출을 기록합니다).
- 수수료, 환불, 유보금은 발생 시 중간 계정에서 차감하여 기록합니다.
- 프로세서가 정산액을 보내면 돈이 중간 계정에서 유출되어 은행 계좌로 이동합니다.
- 어느 시점에서든 중간 계정의 잔액은 프로세서 대시보드의 실제 잔액과 일치해야 합니다.
중간 계정 잔액이 프로세서가 보고한 잔액과 일치한다면 조정이 완료된 것입니다. 일치하지 않는다면 무언가 누락된 것이며, 어디를 살펴봐야 할지 정확히 알 수 있습니다.
이 접근 방식은 모든 복식 부기 시스템에서 작동합니다. Beancount와 같은 텍스트 기반 회계 도구는 모든 거래를 명시적이고 감사 가능하게 만들기 때문에 이 워크플로우에 매우 적합합니다. 아래 예시는 Beancount 구문을 사용하지만, 구조는 모든 복식 부기 장부에 적용될 수 있습니다.
계정 설정하기
전용 계정 세트가 필요합니다.
Assets:Stripe:Clearing ; mirrors your balance inside the processor
Assets:Stripe:Reserve ; funds the processor is holding back
Assets:Bank:Checking ; where payouts land
Income:Sales ; gross revenue
Expenses:ProcessingFees ; the processor's cut
Expenses:Chargebacks ; lost disputes and dispute fees
Liabilities:SalesTaxPayable ; tax collected on behalf of the state
Income:Sales:Refunds ; contra-revenue for returned sales유보금을 별도의 자산 계정으로 유지하는 것이 중요합니다. 그 돈은 여전히 여러분의 소유이지만 아직 사용할 수 없을 뿐입니다. 이를 중간 계정에 묻어두면 대차대조표에서 실제 자산이 숨겨지게 됩니다.
매출 기록하기
고객에게 200달러와 판매세 16달러가 청구되면, 전체 216달러가 중간 계정으로 들어옵니다. 매출과 세금 부채는 별도로 기록됩니다.
2026-05-12 * "Customer payment - Invoice 1043"
Assets:Stripe:Clearing 216.00 USD
Income:Sales -200.00 USD
Liabilities:SalesTaxPayable -16.00 USD아직 수수료가 나타나지 않았다는 점에 유의하세요. 대부분의 프로세서는 거래 단위로 수수료를 부과하지만, 이를 모아두었다가 정산 시점에 기록할 수도 있습니다. 한 가지 방법을 선택하고 일관성을 유지하세요. 거래당 수수료를 기록하는 것이 더 정밀하지만, 정산당 기록하는 것이 더 빠릅니다. 대부분의 소규모 비즈니스의 경우 정산당 기록하는 것이 실용적인 선택입니다.
수수료 기록하기
결제 수수료는 운영 비용이며, 전액 공제 가능한 실제 사업 비용입니다. 정산 시점에 이를 기록할 때는 프로세서의 정산 보고서에서 총 수수료 수치를 가져오면 됩니다.
2026-05-15 * "Stripe processing fees - payout period"
Expenses:ProcessingFees 18.45 USD
Assets:Stripe:Clearing -18.45 USD수수료는 프로세서가 그 돈을 가져갔기 때문에 중간 계정에서 빠져나갑니다. 그 돈은 절대 은행에 도달하지 않습니다. 흔히 하는 실수는 수수료를 매출에서 차감하여 기록하는 것입니다 (수입 200달러와 비용 18.45달러 대신 수입 181.55달러로 기록). 이는 매출과 비용을 모두 과소평가하게 만들고, 마진을 왜곡하며, 감사 시 문제가 될 수 있는 방식으로 과세 상황을 조용히 왜곡할 수 있습니다.
환불 기록하기
고객에게 환불을 진행하면 자금이 다시 유출됩니다. Income:Sales 계정을 직접 줄이는 대신 수익 차감 계정(contra-revenue account)을 사용하세요. 이렇게 하면 총 매출과 환불액을 별도의 수치로 관리할 수 있어 반품률 분석에 유리합니다.
2026-05-14 * "Refund - Invoice 1039"
Income:Sales:Refunds 50.00 USD
Liabilities:SalesTaxPayable 4.00 USD
Assets:Stripe:Clearing -54.00 USD대부분의 결제 대행사는 고객에게 매출세를 환불해 주지만, 원래의 결제 수수료는 환불해 주지 않습니다. 이러한 불일치는 실제 금전적 손실이며, 수수료가 실제로 발생했으므로 Expenses:ProcessingFees 계정에 그대로 남게 됩니다.
지급 거절 및 분쟁 기록하기
지급 거절(Chargeback)은 강제적인 승인 취소입니다. 고객의 은행이 자금을 회수하며, 대개 $15–$25의 분쟁 수수료를 추가합니다. 분쟁이 해결될 때까지 결제 대행사는 귀하의 잔액에서 원금과 수수료를 모두 차감합니다.
2026-05-13 * "Chargeback - Invoice 1031 plus dispute fee"
Expenses:Chargebacks 115.00 USD
Assets:Stripe:Clearing -115.00 USD나중에 분쟁에서 승소하면 결제 대행사는 원금을 돌려줍니다(수수료는 돌려받지 못하는 경우가 많습니다). 자금이 돌아오면 이를 역분개로 기록하세요. 지급 거절을 별도의 비용 계정으로 추적하는 것은 그만한 가치가 있습니다. 지급 거절 비율의 상승은 사기, 이행 문제 또는 결제 대행사와의 관계 위험을 알리는 조기 경고 신호이기 때문입니다.
롤링 리저브(Rolling Reserves) 기록하기
**롤링 리저브(Rolling reserve)**는 리스크 완충용 유보금입니다. 결제 대행사는 매출의 일정 비율(보통 5%에서 15%)을 보류하고, 일정 기간(종종 90일에서 180일)이 지난 후에 이를 반환합니다. 이는 신규 사업체, 고위험 산업군, 또는 지급 거절 발생률이 높은 가맹점에서 흔히 볼 수 있습니다.
중요한 회계적 관점: 유보금은 여전히 귀하의 자산입니다. 이는 비용이 아니며 손실된 수익도 아닙니다. 단지 지금 당장 사용할 수 없는 귀하의 현금일 뿐입니다. 이를 두 자산 계정 간의 이체로 기록하세요.
2026-05-15 * "Stripe rolling reserve withheld - 10%"
Assets:Stripe:Reserve 120.00 USD
Assets:Stripe:Clearing -120.00 USD몇 달 후 결제 대행사가 유보금을 해제하면, 정산 계정으로 다시 유입되어 일반적인 정산의 일부로 지급됩니다.
2026-08-15 * "Stripe rolling reserve released"
Assets:Stripe:Clearing 120.00 USD
Assets:Stripe:Reserve -120.00 USD유보금을 별도의 계정으로 관리하면 대차대조표의 정확성을 유지할 수 있고, 얼마나 많은 현금이 묶여 있는지 명확하게 파악할 수 있습니다. 유보금을 무시하는 기업들은 종종 "벌어들였지만" 지출할 수 없는 수천 달러의 존재를 뒤늦게 알고 당황하곤 합니다.
정산(Payout) 기록하기
위의 모든 과정이 끝난 후 정산 계정에 남은 금액이 결제 대행사가 실제로 송금하는 금액입니다. 정산 거래는 단순히 정산 계정에서 은행 계좌로 자금을 이동시키는 것입니다.
2026-05-15 * "Stripe payout to checking"
Assets:Bank:Checking 412.55 USD
Assets:Stripe:Clearing -412.55 USD이 거래가 기입되면 은행 명세서와 장부상의 입금액이 일치하게 됩니다. 그리고 총 매출, 수수료, 환불, 지급 거절, 유보금 등 다른 모든 항목이 동일한 정산 계정을 통해 기록되었으므로 전체 자금 흐름을 증명할 수 있습니다.
전체 대조 과정 살펴보기
어느 정산 기간에 다음과 같은 활동이 발생했다고 가정해 보겠습니다.
| 항목 | 금액 |
|---|---|
| 총 매출 | +$600.00 |
| 징수된 매출세 | +$48.00 |
| 환불 | −$54.00 |
| 지급 거절 + 수수료 | −$115.00 |
| 결제 수수료 | −$18.45 |
| 롤링 리저브 (10%) | −$48.00 |
| 순 정산액 | $412.55 |
순서대로 계산해 보겠습니다. 매출 $600에 세금 $48를 더하면 정산 계정에 $648가 입금됩니다. 여기서 환불 $54, 지급 거절 $115, 수수료 $18.45, 유보금 $48를 차감하면 $412.55가 남으며, 이는 정산액과 정확히 일치합니다. 모든 거래를 입력한 후 정산 계정은 0으로 돌아가며(처리 중인 거래가 없다고 가정할 때), 유보금 계정에는 $48가 남게 됩니다.
잔액이 0이 되는 것이 바로 증거입니다. 만약 정산 계정이 0이 되지 않거나 결제 대행사 대시보드의 "대기 중(pending)" 잔액과 일치하지 않는다면, 거래가 누락되었거나 잘못 분류된 것이며 어느 정산 기간을 조사해야 하는지 정확히 알 수 있습니다.
정확한 정산 기록이 중요한 이유
이것은 단지 장부 정리를 위한 것이 아닙니다. 정산을 정확하게 기록하는 것은 실제 의사 결정의 근거가 됩니다.
- 실제 수익 파악. 순 입금액만으로는 매출을 과소 평가하게 됩니다. 투자자, 대출 기관 및 국세청은 모두 총 매출을 요구합니다. 결제 대행사로부터 받는 1099-K 양식에는 총 거래액이 보고되므로, 장부에 순액만 기록되어 있으면 즉시 불일치를 해명해야 하는 상황이 발생합니다.
- 가시적인 비용. 결제 수수료는 종종 비즈니스에서 세 번째 또는 네 번째로 큰 비용입니다. 지불하고 있는 비용을 측정하지 않으면 더 나은 요율을 협상하거나 대행사를 변경할 수 없습니다.
- 정확한 매출세 관리. 징수한 세금은 주 정부에 납부해야 할 부채이지 귀하의 수입이 아닙니다. 이를 매출에 혼합하면 수익이 과대 산정되고 세금을 과소 납부할 위험이 있습니다.
- 정확한 현금 흐름 파악. 유보금 및 미결제 자금은 실제 자산입니다. 이를 무시하는 대차대조표는 귀하가 보유한 자산을 과소 평가하게 됩니다.
- 감사 대비. 1원 단위까지 딱 맞는 정산 계정은 5분 만에 끝날 대조 작업을 5시간 동안의 고된 추적 작업으로 바꾸지 않게 해줍니다.
피해야 할 흔한 실수들
- 순입금액을 수익으로 기록하는 것. 가장 흔하게 발생하는 오류입니다. 수수료, 환불, 세액 정보가 한꺼번에 사라지게 됩니다.
- 수수료를 매출과 상계(Netting)하는 것. 항상 총매출과 수수료를 별도로 기록하세요. 수익률과 벤치마크 지표의 정확성은 여기서 결정됩니다.
- 유보금을 비용으로 처리하는 것. 유보금은 나중에 돌려받게 될 자산입니다. 이를 비용으로 처리하면 수익과 자산이 모두 과소 산출됩니다.
- 환불된 수수료를 무시하는 것. 판매 건을 환불하더라도 원래 발생한 결제 수수료는 대개 환급되지 않고 소멸됩니다. 이를 취소(Reverse) 처리하지 마세요.
- 1년에 한 번만 정산하는 것. 맞지 않는 입금 내역은 발생한 당해 주에 바로잡기 쉽지만, 11개월이 지난 후에 추적하려면 매우 고통스럽습니다. 매 입금 시마다, 혹은 최소 매달 정산하세요.
- 여러 결제 대행사를 혼용하는 것. Stripe, PayPal, Square를 함께 사용한다면 각 서비스마다 별도의 클리어링 계정을 할당하세요. 하나의 계정에 섞어 쓰면 어떤 플랫폼의 잔액이 맞지 않는지 파악하기가 불가능합니다.
첫날부터 체계적인 재무 관리 유지하기
결제 대행사의 정산은 장부가 복잡해지기 시작하는 지점입니다. 클리어링 계정은 이를 깔끔하게 유지할 수 있는 방법입니다. 고객이 결제한 모든 금액은 총판매액부터 수수료, 환불, 유보금을 거쳐 은행에 입금되기까지의 과정을 추적할 수 있어야 합니다.
Beancount.io는 이러한 대조 작업을 자연스럽게 만들어주는 플레인 텍스트 회계(Plain-text accounting) 기능을 제공합니다. 모든 거래는 명시적이고, 모든 계정 잔액은 감사 가능하며, 전체 장부는 블랙박스나 벤더 종속성 없이 버전 관리됩니다. 위에서 설명한 것처럼 클리어링 계정, 유보금, 매출 차감 항목을 정확하게 모델링한 다음, Fava와 같은 대시보드를 통해 시각화할 수 있습니다. 무료로 시작하기를 통해 왜 개발자와 재무 전문가들이 플레인 텍스트 회계로 전환하고 있는지 확인해 보세요.
출처: Ridgeway Financial Services — Payment Processor Settlement Accounting, Stripe Documentation — Payout Reconciliation Report, Lightspeed — Payment Reconciliation, PaymentCloud — What is a Rolling Reserve, Checkout.com — What is a Rolling Reserve.