Stripe 대시보드는 지난달에 $48,000을 수금했다고 말합니다. 손익계산서는 $52,000이라고 말합니다. 은행 계좌는 총 $41,000의 입금을 보여줍니다. 세 숫자 모두 같은 고객이 같은 인보이스를 결제한 데서 나온 것입니다. 그렇다면 실제 매출은 어느 것일까요?
Stripe Billing으로 SaaS 기업을 운영한다면, 이 세 숫자의 불일치는 도구의 버그가 아닙니다. 하나의 경제적 사건 — 고객이 구독료를 결제함 — 이 네 곳(구독, 인보이스, 결제, 지급금)에 나타나는 예측 가능한 결과입니다. 그중 하나 이상을 매출로 기록하면 이중 계상이 됩니다. 잘못된 것을 기록하면 세금, 지표, 향후 실사(due diligence)가 모두 부풀려진 숫자 위에 놓이게 됩니다.
이 가이드는 각 Stripe 객체가 장부에서 정확히 어디에 속하는지, 대부분의 SaaS 창업자를 잡는 세 가지 이중 계상 함정, 그리고 월 마감을 1센트까지 일치시키는 결제 계정(clearing account) 워크플로를 보여줍니다.
Stripe가 이중 계상을 쉽게 만드는 이유
전통적인 인보이싱은 매출 한 건당 하나의 문서, 즉 인보이스를 제공합니다. Stripe Billing은 같은 돈에 대해 연결된 객체들의 사슬을 제공합니다:
- 구독(Subscription) — 반복 계약(월 $99 요금제)입니다.
- 인보이스(Invoice) — Stripe가 매 주기마다 생성하는 청구서로, 일할 계산(proration), 크레딧, 세금이 포함됩니다.
- 결제(Payment, charge) — 해당 인보이스에 대해 실제로 자금이 이동한 것입니다.
- 지급금(Payout) — 수수료, 환불, 조정을 차감한 후 Stripe가 보내는 일괄 은행 예금입니다.
각 객체는 자체 대시보드, 자체 리포트, 자체 합계를 가집니다. 매출로 "인보이스 합계"를 더한 다음 "지급금 입금"도 수익으로 기록하는 창업자는 같은 달러를 두 번 기록한 것입니다. 여기에 연간 선불 결제 — 오늘 12개월 서비스에 대해 $12,000 인보이스 한 장 — 를 더하면, 현금 기준 사고방식은 1월에 1년치 매출을 모두 기록하게 됩니다.
이 모든 것을 방지하는 핵심 원칙은 다음과 같습니다: 고객 자금의 각 달러는 수익이 실현되는 시점에 총매출로 정확히 한 번만 기록되며, 그 외의 모든 것은 수수료, 환불, 시점 차이, 또는 재무상태표상의 이동입니다. 이 글의 나머지 부분은 이 원칙을 적용하는 방법입니다.
함정 1: 인보이스와 지급금을 모두 매출로 기록하기
이것은 SaaS 부기에서 가장 흔한 이중 계상입니다. 증상은 명백합니다: 손익계산서의 매출이 대략 인보이스에 은행 입금을 더한 것과 같고, 장부는 은행 잔고가 결코 확인해주지 않는 성장을 보여줍니다.
고객이 월 $1,000 인보이스를 결제할 때 실제로 일어나는 일은 다음과 같습니다:
- Stripe는 $1,000 인보이스를 생성하고 $1,000 결제를 수금합니다.
- Stripe는 처리 수수료(예: $30.30)와 환불을 공제합니다.
- 며칠 후 Stripe는 가용 잔액을 지급금 예금으로 일괄 처리합니다.
인보이스와 지급금은 같은 $1,000에 대한 두 가지 관점입니다 — $1,000의 매출에 또 다른 $970의 매출이 더해지는 것이 아닙니다. 올바른 처리는 다음과 같습니다:
- 인보이스가 결제될 때(또는 발생주의 회계의 경우 실현될 때) $1,000의 총매출을 한 번 기록합니다.
- $30.30의 수수료를 처리 비용으로 기록하며, 매출의 차감으로 잡지 않습니다.
- 지급금을 Stripe 결제 잔액에서 은행 계좌로의 이체로 기록하며, 절대 수익으로 잡지 않습니다.
수수료를 매출에서 차감하는 것(즉 $969.70의 입금만을 매출로 기록)은 거울상의 오류입니다: 총매출을 과소계상하고 공제 가능한 처리 비용을 숨깁니다. 7자리 매출 항목에서 이러한 숨겨진 수수료는 손실된 공제액과 오해를 부르는 지표로 연간 수만 달러에 쉽게 이릅니다.
결제 계정(clearing-account) 해결책
Stripe를 계정과목표에서 자체 소규모 은행 계좌 — 결제 계정(clearing account) — 로 취급하세요. 모든 Stripe 이벤트가 먼저 여기에 기록됩니다:
- 고객 결제 성공: Stripe 결제 계정 차변 $1,000, 매출(또는 아래에서 다루는 이연 매출) 대변 $1,000.
- Stripe가 수수료를 가져감: 처리 수수료 비용 차변 $30.30, Stripe 결제 계정 대변 $30.30.
- 환불 발행: 환불(대체 매출, contra-revenue) 차변, Stripe 결제 계정 대변.
- 지급금이 은행에 도착: 은행 계좌 차변, 지급금 금액만큼 Stripe 결제 계정 대변.
지급금이 기록된 후 결제 계정에는 미결제 Stripe 잔액만 남아 있어야 합니다. 매달 남는 잔액이 늘어난다면 무언가 — 보통 기록되지 않은 환불이나 누락된 수수료 — 가 새고 있는 것입니다. 그 잔여물이 조기 경보 신호이며, 이것이 결제 계정이 존재하는 이유입니다.
함정 2: 연간 선불 결제를 한꺼번에 인식하기
고객이 연간 요금제로 $12,000을 선불로 결제합니다. 현금 회계에서는 이를 1월 매출 $12,000이라고 부를 수 있습니다. 투자자, 대출 기관, GAAP 모두가 기대하는 발생주의 회계에서는 한 달치 서비스를 실현했고 11개월치가 더 남아 있습니다.
올바른 처리는 서비스 기간에 걸쳐 인식을 분산시킵니다:
- 결제 시: Stripe 결제 계정 차변 $12,000, 이연 매출(부채) 대변 $12,000. 아직 매출은 없습니다.
- 매달: 이연 매출 차변 $1,000, 구독 매출 대변 $1,000.
첫 달에 전체 인보이스를 매출로 기록하면 1월 이익이 $11,000 과대계상되고 다음 11개월이 과소계상됩니다. 또한 인수자가 실제로 인수 심사하는 지표 — 월간 반복 매출(MRR), 순 매출 유지율(NRR), 이연 매출 잔액 — 를 망가뜨립니다. 이 모든 것은 수금된 현금이 아닌 실현된 매출에서 파생됩니다.
일할 계산, 업그레이드, 중간 주기 변경
Stripe는 요금제 변경을 일할 계산 인보이스로 처리합니다 — 기존 요금제의 미사용 시간에 대한 크레딧과 새 요금제에 대한 청구가 더해집니다. 이들은 작은 금액으로 상계되지만, 각 부분은 여전히 올바른 처리가 필요합니다: 크레딧은 매출을 감소시키고(또는 이연 매출을 증가시키고), 새 청구는 동일한 시간 경과 실현 규칙을 따릅니다. 순 일할 계산 금액만 기록하는 지름길은 보통 월간 요금제에는 통하지만, 연간 요금제 업그레이드의 경우 이연 매출 스케줄을 재작성해야 하며, 그렇지 않으면 부채 잔액이 실제와 어긋납니다.
쿠폰과 고객 크레딧도 같은 주의가 필요합니다. 20% 쿠폰은 정가 $1,000 인보이스에 대해 $800의 총매출을 의미합니다 — $1,000의 매출에 $200의 마케팅 비용이 더해지는 것이 아닙니다. 실제로 실현한 것을 기록하세요.
함정 3: 환불, 분쟁, 크레딧을 새 비용으로 계산하기 — 또는 무시하기
환불은 매출을 감소시킵니다. 별도의 영업 비용이 아니며, 결코 보이지 않는 것도 아닙니다. $500 인보이스를 환불할 때:
- 환불(총매출에 대응하는 대체 매출 계정) 차변 $500.
- Stripe 결제 계정 대변 $500.
비용이 아닌 대체 매출(contra-revenue)로 잡는 이유는 무엇일까요? 총매출에서 환불을 빼면 순매출이 되기 때문입니다 — 세금 신고서, 이사회 자료, 단위 경제학이 모두 원하는 숫자입니다. 환불을 일반 비용에 묻으면 최상위 매출선과 비용 구조가 모두 부풀려지고, 환불률 분석이 불가능해집니다.
지불 거절(chargeback)과 분쟁은 중간 보관 처리가 필요합니다: 분쟁이 시작되면 금액을 분쟁 미수금 또는 지불 거절 손실 계정으로 이동시키고, 인식된 매출을 그대로 두지 마세요. 이기면 되돌리고, 지면 확정된 매출 감소에 분쟁 수수료가 비용으로 더해집니다. 한편 실패한 결제와 독촉(dunning) 재시도는 실제로 자금이 이동할 때까지 아무것도 건드리지 않습니다 — 미납 인보이스는 매출이 아니라 매출채권이며, 두 번 수금된 것이 아닙니다.
월간 Stripe 조정 체크리스트
월말 이후 한 시간을 확보하고 이 목록을 순서대로 작업하세요. 각 단계는 서로 다른 오류 유형을 잡아냅니다:
- 지급금 조정 리포트를 가져옵니다. 해당 월에 입금된 각 지급금에 대해 총 청구액에서 수수료, 환불, 조정을 뺀 금액이 은행 입금액과 1센트까지 일치하는지 확인합니다.
- 결제 계정을 조정합니다. 기말 잔액이 미결제 Stripe 잔액(대기 중인 지급금에 예비금 보류를 더한 것)과 같아야 합니다. 마감 전에 다른 잔여물이 있으면 조사합니다.
- 이연 매출을 이월합니다. 기초 잔액에 새 선불 결제를 더하고 인식된 매출을 빼면 기말 잔액과 같아야 하며, 기말 잔액은 Stripe의 미실현 구독 가치 합계와 일치해야 합니다.
- 인보이스를 인식된 매출과 대사합니다. 해당 월의 인식된 구독 매출 합계는 수금된 현금이 아니라 실현된 인보이스 라인 항목(쿠폰, 크레딧, 일할 계산 후)과 조정되어야 합니다.
- 환불과 분쟁을 정리합니다. Stripe의 모든 환불은 대체 매출에 나타나야 하고, 모든 미결 분쟁은 인식된 매출이 아닌 보관 계정에 있어야 합니다.
- 다중 통화와 세금을 확인합니다. 여러 통화로 청구하는 경우 환산 손익이 매출과 별도로 기록되는지 확인합니다. 수금한 판매세와 부가가치세는 매출이 아닌 세금 미지급 부채에 있어야 합니다.
여섯 단계가 모두 일치하면 세 숫자가 마침내 서로 맞아떨어집니다: Stripe 총 활동, 손익계산서의 실현 매출, 그리고 수수료, 시점 차이, 재무상태표 이동의 깔끔한 흐름으로 연결된 은행 입금입니다.
무거운 작업을 대신해주는 리포트와 자동화
이 워크플로를 스프레드시트로 처음부터 만들 필요는 없습니다. Stripe의 자체 리포팅 스택이 체크리스트에 직접 대응됩니다:
- 지급금 조정 리포트는 각 은행 입금 내역에 포함된 모든 청구, 환불, 수수료, 조정을 항목별로 나열합니다 — 회계사가 실제로 원하는 문서입니다.
- **잔액 거래(Balance transactions)**는 Stripe를 통해 이동한 모든 1센트의 불변 원장입니다. Stripe는 생성 후 잔액 거래를 절대 변경하지 않으므로, 청구나 인보이스가 아닌 이것이 마감의 진실 공급원입니다.
- **수익 인식 리포트(Revenue Recognition reports)**는 ASC 606과 IFRS 15에 따라 이연 매출 이월을 자동화하여 구독과 인보이스를 감사 준비된 분개로 바꿉니다.
지속적인 자동화를 위해 회계 통합은 총매출, 수수료, 환불을 매일 밤 결제 계정에 기록할 수 있고, 지급금 이벤트에 대한 웹훅은 당일 매칭을 트리거할 수 있습니다. 자동화가 있어도 월간 체크리스트는 유지하세요: 소프트웨어는 시키는 대로 기록하며, 누락된 매핑은 누군가 조정할 때까지 조용히 실패합니다.
첫날부터 구독 매출을 깨끗하게 유지하세요
Stripe Billing은 모든 달러가 구독, 인보이스, 결제, 지급금 등 너무 많은 곳에 나타나기 때문에 부실한 장부에 특히 가차 없습니다 — 각각이 그것을 다시 계산할 새로운 기회입니다. 결제 계정을 설정하고, 선불 매출을 시간에 걸쳐 인식하고, 매달 조정하는 창업자는 문제가 펀딩이나 인수 실사 중에 재무제표 재작성 규모의 정리 프로젝트가 아니라 한 줄 수정으로 해결될 때 잡아냅니다.
정확한 구독 회계는 모든 이벤트를 처음부터 올바른 계정에 기록하는 것에서 시작됩니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제를 제공하는 플레인텍스트 회계를 제공합니다 — 블랙박스도, 벤더 종속도 없습니다. 무료로 시작하세요 그리고 개발자와 재무 전문가들이 플레인텍스트 회계로 전환하는 이유를 확인하세요.
