당신의 API가 340명의 고객으로 월간 반복 매출 $18,000를 넘어섰고, Stripe 대시보드는 건강한 78%의 총 마진을 보여주며, 회계사가 수익 인식 일정을 요청합니다. 장부를 열어보지만 보여줄 것이 없습니다 — Stripe 보고서와 일치하지 않는 입금만 있는 당좌예금 계좌와 3월에 업데이트를 중단한 스프레드시트뿐입니다.
그 공백이 바로 마이크로-SaaS 회계가 무너지는 지점입니다. 비즈니스는 기만적으로 단순해 보입니다 — 재고가 없고, 창고가 없으며, 소매업자가 부러워할 마진을 자랑합니다 — 하지만 돈의 움직임은 표준적인 "수입에서 지출을 뺀" 장부로는 포착할 수 없는 방식입니다. 계량 사용량, 선불 크레딧 팩, 현금을 보기도 전에 차감되는 프로세서 수수료, 당신을 대신해 징수되는 글로벌 세금, 그리고 은행 잔고를 거짓말하게 만드는 이연 수익. 그 중 하나라도 틀리면 수익을 잘못 표시하거나, 세금을 과다 납부하거나, 다음 요금제를 환상적인 수치로 책정하게 됩니다.
이 가이드는 마이크로-SaaS 또는 API 비즈니스에 실제로 맞는 회계를 다룹니다: 장부를 깨끗하게 유지하기 위해 사용량 기반 과금을 어떻게 구조화하는지, 월말에 정신을 잃지 않고 결제 프로세서를 어떻게 조정하는지, 그리고 왜 70% 이상의 마진 사업도 첫날부터 진정한 발생주의 회계가 필요한지.
마이크로-SaaS 장부가 보기보다 어려운 이유
전통적인 소규모 비즈니스는 현금이 오가거나 송장이 결제될 때 판매를 기록합니다. 마이크로-SaaS는 거의 그렇게 하지 않습니다. 작은 API 또는 AI 도구의 일반적인 한 달을 생각해 보세요:
- 120명의 고객이 500회의 포함된 API 호출이 포함된 월 $29 스타터 플랜 사용
- 40명의 고객이 5,000회의 포함된 호출과 호출당 99 프로 플랜 사용
- 60명의 고객이 선불 크레딧 팩($49로 2,000 크레딧)을 구매하고 불규칙하게 사용
- 1월에 징수한 연간 선불 결제를 한 소수의 엔터프라이즈 고객
어느 날이든 아직 수익이 아닌 현금을 받고, 몇 주 전에 받은 수익을 인식하고, 청구하지 않은 프로세서 수수료를 부담하며, 아직 청구되지 않은 사용량을 제공합니다. 현금주의 장부는 이 모든 것을 "돈 들어오고, 돈 나가고"로 축소하며 비즈니스가 실제로 성장하고 있는지에 대해 거의 아무것도 알려주지 않습니다.
마이크로-SaaS를 다르게 만드는 세 가지
단위당 변동 비용. 모든 API 호출, AI 생성, 또는 웹훅 전달에는 비용이 발생합니다 — 업스트림 LLM 토큰 수수료, 컴퓨팅, 대역폭, 또는 재판매하는 타사 API. 고정 구독은 파워 유저가 평균의 50배를 소비하여 전체 코호트의 마진을 지울 때까지 그 변동성을 숨깁니다. 장부에는 총 호스팅 지출이 아닌 단위당 매출원가(COGS)가 표시되어야 합니다.
고객별 변동 수익. 동일한 $29 플랜의 두 고객은 초과분과 크레딧 충전이 시작되면 완전히 다른 수익을 창출할 수 있습니다. 구독료만 기록하고 초과분을 부수적인 것으로 취급하면 가장 좋은 고객의 수익을 과소계상하고 요금제를 잘못 책정하게 됩니다.
선불 및 이연 수익. 크레딧 팩과 연간 플랜은 오늘 현금을 주고 수주 또는 수개월에 걸쳐 제공할 서비스에 대한 대가입니다. 그 현금은 고객이 실제로 크레딧을 소비하거나 서비스 기간이 경과할 때까지 부채 — 미실현 수익 — 입니다. 수령 시 소득으로 기록하면 지금 이익을 과대계상하고 나중에 과소계상하게 되며, 대출, 기업가치 평가, 또는 현실과 일치하는 세금 신고가 필요한 순간에 문제가 됩니다.
원장이 견딜 수 있는 과금 모델 선택
선택하는 과금 모델은 가격 결정 결정만큼이나 회계 결정입니다. 각 모델은 서로 다른 인식, 조정, 과세 이벤트를 만듭니다.
고정 구독
모든 사람이 사용량과 관계없이 동일한 요금을 지불합니다. 회계는 사소합니다: 고객당 기간당 반복 청구서 하나, 수익은 기간에 걸쳐 균등하게 인식. 문제는 회계가 아니라 경제적입니다 — 헤비 유저에게 보조금을 지급하고 라이트 유저에게서는 돈을 남겨 둡니다. 고정 가격은 소비를 측정하는 학습 단계로 작동하지만 단위 비용을 이해하고 나면 거의 유지되지 않습니다.
순수 사용량 기반 (호출당, 토큰당, 좌석-시간당 과금)
소비를 계량하고 사후에 청구합니다. 수익과 비용이 함께 움직이며, 스프레드시트에서는 만족스럽지만 지출을 예측할 수 없는 엔터프라이즈 구매자에게는 무섭습니다. 회계 관점에서 순수 사용량은 매월 말마다 미청구 수익 — 아직 청구되지 않은 제공된 서비스 — 을 만듭니다. 이를 발생시켜야 합니다. 또한 원장이 신뢰할 수 있는 견고한 계량이 필요합니다. 청구서는 카운터만큼만 정확하기 때문입니다.
구매자가 사용량을 예측할 수 있을 만큼 기술적인 개발자 대상 API에 가장 적합합니다. 예측 가능성이 판매의 핵심인 프로슈머 도구에는 덜 적합합니다.
하이브리드: 구독 기본 + 포함 할당량 + 초과분
이것은 대부분의 마이크로-SaaS 및 AI 도구에서 등장한 기본값입니다: 월간 구독에는 할당량(크레딧, 호출, 생성)이 포함되고, 할당량을 초과하는 소비는 단위당 초과 요율로 청구되며, 종종 실제 비용의 2~4배입니다.
운영상 승리하는 이유: 구매자는 일반적인 사용량에 대한 예측 가능성을 얻고, 파워 유저로부터 더 많은 수익을 포착하면서 라이트 유저를 놀라게 하지 않으며, 초과분이 비용보다 훨씬 높게 책정되므로 총 마진이 보호됩니다. 장부 측면에서 하이브리드 과금은 고객당 두 개의 수익 흐름을 의미합니다 — 비례적으로 인식되는 반복 구독 수익과 초과분이 발생할 때 인식되는 변동 초과 수익. 이들을 별도의 원장 계정에 유지하세요. 나중에 "MRR의 몇 퍼센트가 실제로 변동인가?"라고 묻는다면 송장을 뒤지지 않고 답을 얻을 수 있습니다.
실용적인 요금제 스케치:
- **스타터 월 0.05
- **프로 월 0.04
- **스케일 월 0.03
해당 요금제의 약 80% 고객이 한도를 넘지 않도록 각 할당량을 조정하세요. 제품은 무제한처럼 느껴지고, 한도에 도달하는 20%가 인프라 비용을 충당합니다.
선불 크레딧 팩
고객이 크레딧을 선불로 구매하고 시간이 지남에 따라 사용합니다. 크레딧은 더 나은 현금 타이밍(제공 전에 징수)과 잔액이 부족할 때 자연스러운 업셀 트리거를 제공합니다. 그러나 모든 크레딧 판매는 첫날에 이연 수익을 만듭니다. 현금을 차변에, Liabilities:UnearnedRevenue:CreditPacks 같은 부채 계정에 대변을 기록하고, 크레딧이 소비됨에 따라 Income:CreditUsage로 이동시킵니다. 각각 49,000를 소득으로 기록하는 것은 은행 계좌에는 좋지만 손익계산서에는 틀립니다.
전환율이 좋은 일반적인 구조:
- 500 크레딧 $14 (만료 없음)
- 2,000 크레딧 $49 (14% 할인)
- 10,000 크레딧 $199 (29% 할인, 우선 처리)
- 월 자동 충전: 1,500 크레딧 월 $39, 동일 팩 대비 10% 보너스
정기적으로 충전하는 팩 구매자는 월 자동 충전의 최고 후보입니다 — 크레딧당 계산을 명확하게 하고 업그레이드가 스스로 팔리게 하세요.
결과 기반 가격 책정
성공적인 결과당 청구 — 해결된 지원 티켓당, 전환된 리드당, 완료된 워크플로우당. 결과가 측정 가능하고 가치가 있을 때 매력적이지만, 결과가 실제로 발생했음을 추적하고 증명할 인프라가 필요합니다. 회계 관점에서 각 "결과"는 특정 시점에 충족하는 수행 의무이며, 모든 청구서를 뒷받침할 감사 추적이 필요합니다.
결제 프로세서 조정: 돈이 실제로 가는 곳
Stripe, Paddle, Lemon Squeezy, 또는 Fungies나 Dodo Payments 같은 판매대행자(Merchant of Record)를 사용한다면 은행 계좌에 입금되는 현금은 대시보드가 보여주는 숫자가 결코 아닙니다. 일반적인 Stripe 정산은 다음과 같습니다:
- 총 매출: $12,400
- Stripe 수수료 차감(건당 2.9% + 412
- 환불 차감: -$180
- 분쟁 및 차지백 차감: -$45
- 은행 순 지급액: $11,763
그 637만큼 소득을 과소계상하고 처리 비용, 환불률, 분쟁 노출을 자신의 재무제표에서 완전히 숨기게 됩니다.
조정 패턴
은행 입금이 아닌 프로세서 보고서에 맞춰 조정하세요. 월말에:
-
프로세서 정산 보고서를 가져옵니다 — 제품/플랜별 총 매출, 수수료, 환불, 분쟁, 징수된 세금. 모든 평판 있는 프로세서는 이러한 열을 일별로 분류한 CSV 또는 API 내보내기를 제공합니다.
-
총액을 올바른 수익 계정에 기록합니다. 구독 기본, 초과분, 크레딧 팩 사용은 각각 고유한 계정을 가집니다. 이것이 누구도 수수료를 떼기 전에 고객이 실제로 지불한 수익입니다.
Assets:Bank:Checking $11,763 Expenses:ProcessorFees:Stripe $412 Assets:AccountsReceivable:RefundsPending $180 Expenses:Disputes:Chargebacks $45 Income:Subscriptions:Starter Income:Subscriptions:Pro Income:Usage:Overage Income:CreditPacks:Redeemed정확한 계정 이름은 선택하기 나름이지만 원칙은 고정입니다: 총액은 수익으로, 수수료와 환불은 차감으로, 순액은 은행으로.
-
수수료를 수익에서 차감하는 것이 아닌 비용으로 기록합니다. 프로세서 수수료는 수익을 징수하는 비용이지 수익의 감소가 아닙니다. 차감하면 실제 취급 수수료율이 숨겨지고 코호트 마진 분석이 불가능해집니다.
-
판매대행자가 징수한 세금을 올바르게 처리합니다. 판매대행자를 통해 판매하면 MoR이 법적 판매자가 되어 VAT, GST, 미국 판매세 징수 및 납부를 처리합니다. MoR 정산서의 "세금" 항목은 당신이 납부할 책임이 아니라 그들의 의무입니다 — 하지만 총액이 보고서와 일치하고 순액이 은행과 일치하도록 여전히 기록해야 합니다. 일부 창업자는 수익에서 차감하지만, 더 깔끔한 방법은 MoR이 납부할 때 0이 되는 통과 부채로 기록하는 것입니다.
-
환불과 차지백을 별도로 추적합니다. 환불은 수익의 역전이고, 차지백은 그 위에 분쟁 수수료를 추가합니다. 함께 합산하면 "환불률이 증가하고 있나요?"라는 질문에 답할 수 없고 이른 시기에 사기 패턴을 발견할 수 없습니다.
일반적인 조정 실수
정산액을 수익으로 기록. 솔로 창업자에게 가장 흔한 실수입니다. 소득을 과소계상하고, 수수료가 사라져 마진을 과대계상하며, 연말에 1099-K와 장부 사이에 불일치를 만듭니다.
보류 중인 정산액 무시. 청구되었지만 아직 지급되지 않은 프로세서 잔액은 미수금입니다. 1월 31일에 장부를 마감했는데 Stripe가 1월 29~31일분을 아직 지급하지 않았다면, 그 수익은 2월이 아닌 1월에 속합니다.
연결 계정의 애플리케이션 수수료를 잊음. 마켓플레이스를 운영하거나 관리 결제 위에 애플리케이션 수수료를 부과한다면, 애플리케이션 수수료가 당신의 수익이고 기저 결제는 아닙니다. 당신의 것만 기록하세요.
크레딧 팩 판매를 이연 수익에 맞추지 않음. 모든 크레딧 팩 판매에는 크레딧이 소비됨에 따라 풀리는 일치하는 부채 항목이 있어야 합니다. 이연 잔액이 매달 증가하지만 인식된 수익이 증가하지 않으면, 고객이 소비하는 것보다 더 빨리 팩을 판매하고 있는 것입니다 — 현금 흐름에 유용한 신호이며, 판매 시 소득으로 기록했다면 보이지 않습니다.
70% 이상의 총 마진에도 진짜 장부가 필요한 이유
고마진 소프트웨어 비즈니스는 정교한 회계가 필요 없다고 생각하기 쉽습니다. 호스팅은 저렴하고, 재고가 없으며, 이익은 스스로 관리되는 것처럼 보입니다. 세 가지 현실이 그 생각을 빠르게 교정합니다.
COGS에 실제로 포함되는 것
마이크로-SaaS 또는 API 비즈니스에서 COGS는 "호스팅"이 아닙니다. 사용량에 직접 비례하여 증가하고 고객이 0명이면 존재하지 않을 모든 비용입니다:
- 업스트림 API 및 LLM 토큰 비용(OpenAI, Anthropic 또는 자체 GPU 추론)
- 계량 인프라(요청당 컴퓨팅, 이그레스 대역폭, 이미지 생성 시간)
- 재판매하는 타사 데이터 또는 인리치먼트 API
- 포함된 구성 요소의 좌석당 라이선스 비용
사용량에 비례해 증가하지 않는 호스팅(정적 프런트엔드, 관리 대시보드, 고정 데이터베이스)은 운영 비용이지 COGS가 아닙니다. 이 구분을 올바르게 하는 것이 플랜별, 고객별 진정한 총 마진을 계산할 수 있게 해줍니다. 500회 생성이 포함된 1.50일 수 있지만, 2,000회 생성의 파워 유저가 있는 동일 플랜은 $12일 수 있습니다. 둘 다 장부에서 동일한 "총 이익"으로 표시된다면 가격을 제대로 책정할 수 없습니다.
초과분 가격은 단위당 COGS의 35배를 목표로 하세요. 생성 한 번의 총비용이 0.01$0.015로 책정하세요. 이는 초과분에서 70~80%의 총 마진을 유지하고 모델 비용이 급등하거나 고객이 자동화를 발견할 때 보호합니다.
이연 수익이 은행 잔고를 거짓말하게 만든다
연간 선불과 크레딧 팩을 판매하는 마이크로-SaaS는 징수 시점에 따라 현금이 풍부하고 이익이 낮아 보일 수 있습니다 — 또는 그 반대입니다. 예시: 1월에 연간 프로 플랜 40개를 각각 39,600을 징수했습니다. 현금 기준으로 1월은 최고의 달입니다. 발생 기준으로는 1월에 36,300을 갚아야 합니다. 1월의 현금을 1월의 이익처럼 지출하면 12월에는 부족해집니다.
발생주의 회계는 의무를 충족할 때 수익을 인식함으로써 이를 해결합니다 — 징수할 때가 아닙니다. 연간 판매를 다음과 같이 기록하세요:
- 현금 차변, 이연 수익(부채) 대변
- 매월, 이연 수익 차변, 구독 수익 대변으로 1/12씩
같은 논리가 크레딧 팩에도 적용됩니다: 판매 시가 아닌 사용 시 수익. 더 많은 작업이 필요하며, 성장하고 있는지 아는 것과 단지 현금이 움직이는 것을 지켜보는 것 사이의 차이입니다.
단위 경제성이 다음 결정을 좌우한다
투자자, 대출 기관, 그리고 심지어 가격을 올릴지 결정하는 밤 11시의 당신도 같은 질문을 합니다:
- 순수익 유지율은 무엇인가 — 기존 고객이 시간이 지남에 따라 더 많이 지출하고 있나?
- 플랜별 총 마진은 무엇이며, 어떤 등급이 어떤 등급을 보조하나?
- 실제 COGS와 프로세서 수수료를 포함한 고객 확보 비용 회수 기간은?
- 이연 수익은 무엇이며 향후 두 달의 의무를 충당하는가?
그 중 어느 것도 당좌예금 잔고로는 답할 수 없습니다. 구독과 초과분, 총액과 순액, 확정과 이연, COGS와 OPEX를 분리하는 원장이 필요합니다. 일반 텍스트 회계는 이러한 범주가 통제하는 파일의 명시적 계정이고, git에서 버전 관리되며, 어느 시점이든 감사 가능하기 때문에 여기서 빛을 발합니다 — 정의를 무단 변경하는 대시보드에 묻혀 있지 않습니다.
작동하는 최소 계정과목표
200줄의 계정과목표가 필요하지 않습니다. 위 질문에 답할 수 있는 충분한 구조만 있으면 됩니다:
Income:Subscriptions:Starter/Pro/ScaleIncome:Usage:OverageIncome:CreditPacks:Redeemed(팩 판매 자체는 먼저Liabilities:UnearnedRevenue:CreditPacks로 이동)Expenses:COGS:Inference(LLM / 모델 비용)Expenses:COGS:MeteredInfra(요청당 컴퓨팅, 대역폭)Expenses:COGS:DataAPIs(재판매되는 타사 API)Expenses:ProcessorFees:Stripe(또는 Paddle / MoR)Liabilities:UnearnedRevenue:AnnualPlans및Liabilities:UnearnedRevenue:CreditPacksAssets:AccountsReceivable:ProcessorPending(확정되었지만 아직 지급되지 않은 금액)
거기서 시작하세요. 현재 구조로 답할 수 없는 질문이 생길 때 계정을 추가하세요. 그 전에는 추가하지 마세요.
1인 SaaS를 위한 월말 결산
결산을 제대로 하기 위해 재무 팀이 필요하지 않습니다. 한 달에 한 번 한 시간이 걸리는 반복 가능한 체크리스트만 있으면 됩니다:
-
전체 월의 프로세서 정산 보고서를 가져와 제품별 총액을 기록하고 수수료, 환불, 세금을 분리합니다.
-
은행 입금을 조정합니다 — 은행의 모든 정산액은 원장의 정산 배치와 일치해야 합니다. 청구되었지만 아직 지급되지 않은 보류 배치를 표시합니다.
-
이연 수익 일정을 업데이트합니다. 각 연간 플랜과 크레딧 팩에 대해 확정된 부분을 부채에서 수익으로 이동합니다. 크레딧 팩에 만료가 없으면 오래된 크레딧(12~18개월 이상 미사용 팩)에 대한 브레이키지 정책을 고려하고 문서화하세요 — 여기가 회계 판단이 필요한 곳이므로 기록해 두세요.
-
미청구 사용량을 발생시킵니다. 초과분을 후불로 청구하면 월말에 미청구 금액을 추정하거나 계량하여 발생 수익으로 기록합니다.
-
COGS를 조정합니다. 업스트림 API 청구서(OpenAI, 클라우드 제공업체)를 지불 날짜가 아닌 해당 사용 기간에 맞춥니다. 지난달 토큰에 대해 5일에 지불한 $2,400 추론 청구서는 지난달에 속합니다.
-
실패한 결제와 이탈을 검토합니다. 재시도될 실패한 청구는 아직 손실 수익이 아닙니다. 더닝 버킷에 넣으세요. 재시도 기간이 지나면 상각하고 이탈을 정확히 기록합니다.
-
이연 및 발생 잔액을 조정합니다. 이연 부채는 일정과 일치해야 합니다 — 모든 달러가 특정 고객과 서비스 기간에 연결됩니다. 총액이 일정에서 벗어났다면 무언가가 두 번 기록되었거나 전혀 기록되지 않은 것입니다.
재무 팀 없이 세금 및 규정 준수
미국 고객에게만 판매하고 주 경제적 넥서스 기준 미만이라면 직접 Stripe 통합이 관리 가능합니다. 글로벌로 판매하는 순간 세금 규정 준수는 배가됩니다: 고객 요율의 EU VAT, 호주의 GST, 캐나다의 HST, 미국 주마다 다른 SaaS 취급, 그리고 등록 의무를 촉발하는 원거리 판매 기준.
판매대행자(MoR)가 그 복잡성을 흡수합니다. 각 관할권에서 세금을 징수하고 납부하며, 규정 준수 송장을 발행하고, 차지백을 처리하며, 판매자로 등록되어 외국 VAT 신고를 할 필요가 없습니다. 대가는 더 높은 거래 수수료(일반적으로 4~5% + 고정 금액)와 Stripe의 2.9% + $0.30 및 별도 세금 계산 부가 기능의 비교입니다. 첫날부터 글로벌로 제공하는 소규모 팀에게 MoR 수수료는 거의 항상 직접 처리하는 엔지니어링 및 회계 시간보다 저렴합니다 — 그리고 잘못 처리하는 것보다 훨씬 저렴합니다.
Stripe를 직접 유지한다면 최소한: EU 고객이 있으면 EU VAT One-Stop Shop(OSS)에 등록하고, 계산을 위해 Stripe Tax를 활성화하고, 분기별 OSS 신고를 제출하고, 주별 미국 경제적 넥서스를 추적하고(많은 주가 $100,000 판매 기준 사용), 판매하는 모든 관할권에 대한 규정 준수 기록을 유지하세요. 계산 없는 납부는 올바른 가격을 견적하는 데 도움이 되지만 의무를 충족하지는 않습니다.
또한 소득세를 계획하세요: 프로세서 정산액은 수수료 전 총액이므로 1099-K는 더 높은 숫자를 반영합니다. 순 입금액만 기록했다면 신고서가 양식과 일치하지 않아 차이를 설명하는 데 추가 시간을 써야 합니다. 총액을 기록하면 대사는 산술 문제일 뿐입니다.
깨끗한 장부가 제공하는 것
마이크로-SaaS의 깨끗한 장부는 규정 준수만 유지하는 것이 아닙니다. 비즈니스를 운영하는 데 필요한 답을 제공합니다: 실제 COGS 후 어떤 플랜이 최고 마진인지, 크레딧 팩 또는 구독이 더 나은 회수를 이끄는지, 포함 할당량을 올릴지 초과 가격을 올릴지, 그리고 그 "수익성 있는" 달이 실제로 성장으로 위장한 연간 선불이었는지.
구분을 설정하세요 — 구독 대 초과분 대 크레딧 사용, COGS 대 OPEX, 확정 대 이연, 총액 대 수수료 차감 — 첫 달에 하세요, 12번째 달이 아니라. 순 정산액과 잘못 분류된 호스팅을 1년치 역추적하는 것은 창업자들이 진짜 원장으로 시작했더라면 하고 후회하는 작업입니다.
재무 관리를 간소화하세요
마이크로-SaaS가 초기 계량 과금에서 본격적인 하이브리드 가격 엔진으로 이동함에 따라 명확한 재무 기록을 유지하는 것이 가격 결정을 정직하게 하고 세금 시즌을 평온하게 만듭니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제권을 제공하는 일반 텍스트 회계를 제공합니다 — 모든 구독 등급, 크레딧 팩 부채, 프로세서 수수료, COGS 라인이 소유한 원장에서 버전 관리됩니다. 무료로 시작하세요 개발자와 재무 전문가들이 일반 텍스트 회계로 전환하는 이유를 확인하세요.