3월에 연간 계약 다섯 건을 성사시켜 $60,000이 Stripe 계정에 입금되었습니다. 대시보드는 빛나고, 은행 잔고는 영웅처럼 보입니다 — 그런데 회계사가 방금 3월 수익이 $5,000이라고 말합니다. 아무도 틀리지 않았습니다. 당신은 같은 Stripe 계정에 존재하는 두 개의 서로 다른 숫자를 보고 있는 것입니다: 수금한 현금과 실제로 벌어들인 수익입니다. 이 둘을 조정하기 전까지, Stripe가 보내는 모든 지급금은 당신의 장부가 풀어야 할 수수께끼입니다.
이 가이드는 연간 청구하지만 월간으로 수익을 인식하는 SaaS 기업이 수익을 이중 계산하거나, 이연수익을 잘못 표시하거나, 격차 전체를 숨기는 지표에 속지 않고 Stripe 지급금을 조정하는 방법을 보여줍니다.
Stripe 지급금이 수익의 잘못된 출발점인 이유
Stripe 지급금은 수입처럼 보입니다. 은행 계좌에 단일 입금으로 도착하고, 날짜가 찍혀 있으며, 그 달의 수익처럼 느껴집니다. 그러나 그 어느 것도 사실이 아닙니다. 지급금은 순결제입니다: 총 청구액에서 처리 수수료를 빼고, 환불을 빼고, 분쟁 인출을 빼고, 당신의 일정이 아닌 Stripe의 지급 일정에 따라 묶은 것입니다.
지급금을 수익으로 기록하면 두 가지 왜곡이 발생합니다.
첫째, 수익을 과소계상합니다. 고객이 연간 플랜에 $12,000을 지불했다면 Stripe는 약 $348에 30센트를 더한 금액을 보유하고 나머지를 지급합니다. 지급금을 기록하면 순액이 매출로 기록되고 수수료는 분석할 수도, 깔끔하게 공제할 수도 없는 곳에 묻힙니다.
둘째, 연간 청구에서 훨씬 더 위험한 것은 시점을 잘못 표시한다는 것입니다. $12,000 전액이 1월에 한 번의 지급금으로 도착하지만, 발생주의 회계에서는 서비스를 제공함에 따라 매월 $1,000씩 수익을 인식합니다. 지급금을 1월 수익으로 기록하면 1월은 화려해 보이고 2월부터 12월까지는 죽은 것처럼 보이지만, 사업은 매달 정확히 같은 일을 했습니다.
해결책은 지급금을 그것이 실제로 무엇인지 — 현금 이체 — 로 취급하고, 계약에 따라 구동되는 완전히 별개의 트랙에서 수익을 인식하는 것입니다.
창업자들이 혼동하는 세 가지 숫자: 수주, 청구, 수익
모든 연간 청구 조정은 세 가지 숫자를 분리하는 것으로 시작합니다:
- **수주(Bookings)**는 체결된 계약의 총 가치입니다. 고객이 1월에 $12,000 연간 계약에 서명하면: 1월 수주는 $12,000입니다. 수주는 약속이지, 현금도 수익도 아닙니다.
- **청구(Billings)**는 인보이스 발행하고 수금한 금액입니다. 계약이 연간 선불로 청구되면 1월 청구는 $12,000입니다. 월간으로 청구되면 수주가 $12,000이더라도 1월 청구는 $1,000입니다.
- **수익(Revenue)**은 서비스를 제공하여 벌어들인 것입니다. 12개월 계약의 한 달은 12분의 1을 벌어들입니다: 어느 경우든 1월 수익은 $1,000입니다.
청구와 수익 사이의 격차가 바로 이연수익(Deferred Revenue)(미실현 수익이라고도 함)으로, 아직 제공해야 할 서비스를 나타내는 대차대조표상의 부채입니다. 1월에 $12,000을 수금하고 $1,000을 인식하면 $11,000의 이연수익을 2월로 이월합니다. 그 부채는 문제가 아니라 — 장부가 정직하다는 증거입니다. 계약이 끝날 때까지 매월 $1,000씩 풀립니다.
간단히 말해: 수주는 영업이 어떻게 하고 있는지, 청구는 현금이 어떻게 하고 있는지, 수익은 사업이 실제로 어떻게 수행되었는지를 알려줍니다. 하나가 다른 하나를 대신하게 하는 순간 조정은 무너집니다.
월간 인식을 구동하는 이연수익 스케줄 구축
이연수익 스케줄은 전체 프로세스의 엔진입니다. 고객, 계약 시작, 기간, 총 계약 가치, 월간 인식 금액, 누적 인식 수익, 잔여 이연 잔액으로 구성된 계약별 간단한 표이며, 수익 분개를 유발해야 하는 유일한 문서입니다.
1월 1일에 시작하는 $12,000 연간 플랜의 분개는 다음과 같습니다:
On collection (January):
Dr Stripe clearing $12,000
Cr Deferred revenue $12,000
Each month, January–December:
Dr Deferred revenue $1,000
Cr Subscription revenue $1,000빠진 것을 주목하세요: 지급금은 수익 분개 어디에도 나타나지 않습니다. 현금 수금은 부채인 이연수익을 대변에 기록합니다. 수익은 나중에 스케줄에서 매월 한 달씩 탄생합니다.
스케줄을 성패로 이끄는 두 가지 원칙이 있습니다. 첫째, 모든 신규 연간 계약, 갱신, 확장은 시작한 달에 스케줄에 올라가야 합니다 — 스케줄에서 빠진 계약은 결코 인식되지 않을 수익입니다. 둘째, 매월 스케줄을 총계정원장과 조정하세요: 기초 이연 잔액에 신규 청구를 더하고 인식된 수익을 빼면 기말 이연 잔액과 같아야 합니다. 그렇지 않다면 무언가가 스케줄을 우회한 것입니다 — 보통 환불, 중도 변경, 또는 누군가 수익으로 직행시킨 지급금입니다.
정산 계정으로 지급금 자체를 조정하기
스케줄이 수익 시점을 처리하는 동안, Stripe를 통해 이동하는 자금은 여전히 회계처리해야 합니다. 깔끔한 방법은 Stripe 정산 계정 — "Stripe 안에 있는 현금"을 나타내는 자산 계정 — 입니다.
모든 Stripe 이벤트는 총액으로 정산 계정에 기록됩니다:
Customer charged $1,000:
Dr Stripe clearing $1,000
Cr Deferred revenue $1,000
Stripe fee of $29.30 on that charge:
Dr Processing fees $29.30
Cr Stripe clearing $29.30
Payout of $970.70 lands in your bank:
Dr Bank checking $970.70
Cr Stripe clearing $970.70환불과 분쟁 인출도 반대 방향으로 같은 방식으로 기록됩니다. 지급금 스윕이 정리되면 해당 지급금 항목의 정산 계정은 0으로 상쇄됩니다 — 이것이 바로 정산 계정을 단순한 회계 관례가 아닌 조정 도구로 만드는 이유입니다. 0이 아닌 잔액이 남아 있다는 것은 수수료, 환불 또는 조정이 기록되지 않았다는 뜻입니다.
각 지급금을 그 내용과 연결하려면, 지급금 내의 모든 청구, 환불, 수수료, 조정을 항목별로 나열하는 Stripe의 지급금 조정 보고서를 사용하고, 총액에서 수수료와 환불을 뺀 금액이 은행 입금액과 같은지 확인하세요. 월별이 아닌 지급금별로 이 작업을 하세요: 지급금은 끊임없이 월말을 가로지르며, 월별 일괄 처리가 바로 "은행이 Stripe와 절대 일치하지 않는다"는 미스터리가 나오는 곳입니다. 거래량이 적다면 정산 계정과 함께 주간 리듬으로 작은 불일치를 여전히 추적하기 쉬울 때 잡아내세요.
정산 조정: 스케줄을 깨뜨리는 중도 변경
연간 계약은 좀처럼 12개월 동안 그대로 있지 않으며, 모든 변경은 이연 스케줄에 대한 정산 조정 분개가 필요합니다:
- 업그레이드와 좌석 확장은 잔여 이연 잔액에 추가됩니다. 6개월이 남은 상태에서 $12,000에서 $18,000으로 업그레이드하는 고객은 미인식 잔액 위에 약 $3,000의 신규 이연수익(월 $500 추가 × 6개월)을 더합니다.
- 다운그레이드는 잔액을 줄입니다. 6개월이 남은 상태에서 플랜을 축소하면 차액을 이연수익에서 빼냅니다 — 보통 현금 환불이 아닌 향후 인보이스에 대한 크레딧으로 처리되며, 돈이 움직이지 않아도 분개가 필요합니다.
- **일할 계산(Prorations)**이 메커니즘입니다: Stripe는 미사용 시간 크레딧으로 구독 변경을 처리하며, 그 크레딧은 이연수익을 구 플랜과 신 플랜 사이에서 얼마나 이동시킬지 정확히 알려줍니다.
- 선불 시간을 환불하는 해지는 이연수익을 줄이며, 당월 수익은 절대 건드리지 않습니다. $12,000 플랜의 미사용 6개월을 환불하는 것은 이연수익에 대한 $6,000 차변입니다 — 당월 수익에 기록하면 아무 잘못도 하지 않은 달을 과소계상하게 됩니다.
- 연간 갱신의 결제 실패는 반대 방향으로 주시해야 합니다: 수금된 현금이 없다는 것은 새로운 이연 잔액이 없다는 뜻이므로, 스케줄은 자금 조달이 중단된 계약에 대해 계속 수익을 인식해서는 안 됩니다.
실용적인 규칙: 같은 달에 스케줄 업데이트가 일치하지 않는 Stripe 구독 변경은 없습니다. 두 가지를 벌어지게 놔두는 팀은 분기 말마다 인보이스 PDF에서 무슨 일이 있었는지 재구성하느라 시간을 씁니다.
모든 것을 숨기는 SaaS 지표: 대시보드 MRR은 수익이 아니다
여기에 전체 구조가 감추는 함정이 있습니다. Stripe 대시보드는 MRR이 아름답게 상승하는 것을 보여줍니다 — 연간 플랜은 월간 등가물로 환산되고, 업그레이드는 즉시 확장 MRR을 추가하며, 차트는 오른쪽 위로 기웁니다. 창업자들은 자연스럽게 그 숫자를 "우리가 매월 버는 것"으로 생각하기 시작합니다.
그렇지 않습니다. MRR은 정규화된 런레이트 지표입니다: 아무것도 변하지 않았다면 활성 구독의 월간 가치입니다. 인식된 수익은 발생주의 회계에서 이번 달 실제로 벌어들인 것입니다. 이 둘은 끊임없이 갈라집니다 — 이번 달에 수금된 연간 선불금은 이번 달 수익이 거의 아니고, 월 중 업그레이드로 인한 확장 MRR은 반 달치 수익일 뿐이며, 대시보드의 어떤 수치도 당신의 이연 스케줄, 환불, 정산 조정을 알지 못합니다.
이 격차는 물릴 때까지 보이지 않습니다. 과세 소득은 MRR이 아닌 인식된 수익을 따르므로, 수주가 폭발한 분기는 대시보드를 보고 있던 창업자들을 놀라게 하는 세금 청구서를 만들 수 있습니다. 그리고 인수자와 대출자는 MRR이 아닌 GAAP 수익을 실사합니다 — 실제로는 미인식 청구였던 모든 "수익" 달러는 밸류에이션 대화에서 조정되어 제거됩니다.
두 숫자를 모두 유지하되, 하나가 다른 하나의 역할을 하게 하지 마세요. 유용한 월간 점검: 그 달의 인식된 수익에 이연 잔액의 변동을 더하면 청구로 조정되어야 합니다. MRR이 성장했다고 말하는데 그 방정식이 다르다고 말하면, 방정식을 믿으세요.
Stripe SaaS를 위한 월간 결산 체크리스트
매월 이것을 실행하면 조각들이 서로 연결된 상태로 유지됩니다:
- 지급금을 은행과 대조하세요. 지급금 조정 데이터를 내보내고, 총액에서 수수료와 환불을 뺀 금액이 각 입금액과 같은지 확인하고, 정산 계정을 통해 스윕을 기록하세요.
- 지급금별로 정산 계정을 0으로 만드세요. 남은 잔액은 기록되지 않은 수수료, 환불, 분쟁 또는 조정입니다 — 월말 전에 찾으세요.
- 이연 스케줄을 굴리세요. 신규 계약과 갱신을 추가하고, 그 달의 인식 분개를 기록하고, 기초 잔액에 청구를 더한 후 인식된 수익을 뺀 금액이 기말 잔액과 같은지 확인하세요.
- 중도 변경을 정산 조정하세요. Stripe의 모든 업그레이드, 다운그레이드, 일할 계산, 해지, 환불을 스케줄 조정과 일치시키세요.
- MRR을 인식된 수익과 조정하세요. 대시보드 런레이트와 벌어들인 수익 사이의 격차를 설명하세요; 한 문장으로 설명할 수 없는 것은 조사하세요.
- 수수료와 환불을 별도로 검토하세요. 총수익, 처리 수수료, 환불은 각자 자신의 이야기를 합니다 — 이들을 상계하면 세 가지 모두 숨겨집니다.
일관되게 수행하면 월말이 법의학적 발굴에서 일상으로 바뀝니다: 지급금 측은 현금이 완전함을 증명하고, 스케줄 측은 수익이 벌어들여졌음을 증명합니다.
SaaS 수익을 투자자 대응 가능하게 유지하세요
연간 청구를 확장함에 따라 매월 인식된 수익, 이연 잔액, Stripe 현금을 함께 연결된 상태로 유지하는 것이 회계사, 세무 당국, 미래 인수자에게 숫자를 신뢰할 수 있게 만드는 것입니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제를 제공하는 플레인 텍스트 회계를 제공합니다 — 블랙박스도, 공급업체 종속도 없습니다. 무료로 시작하세요 그리고 개발자와 재무 전문가들이 플레인 텍스트 회계로 전환하는 이유를 확인하세요.
