B2B SaaS 업셀·좌석 추가 추적 감사 체크리스트 2026, upgrade와 add-on을 신규 매출 보고서와 섞기 전 확인할 기준
B2B SaaS 업셀·좌석 추가 추적 감사 체크리스트 2026, upgrade와 add-on을 신규 매출 보고서와 섞기 전 확인할 기준
B2B SaaS에서 매출이 늘었다고 해서 모두 같은 성장 신호는 아닙니다. 신규 고객이 들어온 것인지, 기존 고객이 좌석을 늘린 것인지, 상위 플랜으로 올린 것인지, add-on을 붙인 것인지, 사용량 초과 과금이 발생한 것인지가 다릅니다.
이 값을 모두 new revenue로 넣으면 마케팅 성과가 과대평가되고, 제품팀은 어떤 기능이 확장을 만들었는지 놓치며, 고객 성공팀은 갱신 전 위험 계정과 확장 가능 계정을 구분하지 못합니다. 반대로 확장 매출을 너무 늦게 잡으면 실제로는 건강한 계정인데도 churn 방어 대상처럼 보일 수 있습니다.
이 글은 투자, 회계, 세무, 매출 인식 자문이 아닙니다. B2B SaaS 운영팀이 업셀, 좌석 추가, add-on, 플랜 업그레이드, 사용량 초과 과금을 billing, CRM, 제품 분석, GA4 보고서에 연결하기 전 확인할 데이터 품질 체크리스트입니다. 실제 매출 인식, 계약, 회계 처리는 회사 내부 기준과 담당 전문가 검토를 따라야 합니다.
무료체험에서 유료 전환 흐름은 B2B SaaS trial-to-paid 전환 추적 감사 체크리스트에서 먼저 정리했습니다. 결제 실패와 복구 자동화는 B2B SaaS 결제 실패·dunning 자동화 체크리스트를 같이 보면 됩니다. 취소와 churn reason은 B2B SaaS 구독 취소·churn reason 추적 감사 체크리스트로 분리하고, 환불과 크레딧 조정은 B2B SaaS 환불·크레딧 노트 추적 감사 체크리스트와 연결하면 됩니다.
expansion revenue를 신규 매출과 먼저 분리합니다
업셀과 좌석 추가는 성장 지표이지만 신규 고객 획득과는 다른 운영 사건입니다. 기존 계정 안에서 발생한 확장인지, 새 회사 계정이 생긴 것인지, 같은 고객사의 다른 workspace가 추가된 것인지부터 나눠야 합니다.
| 구분 | 운영상 의미 | 보고서에서 바로 확인할 점 |
|---|---|---|
| new logo | 새 회사 계정이 유료 고객이 됨 | 기존 account와 중복 company가 아닌가 |
| seat expansion | 같은 계정의 유료 사용자 수 증가 | 좌석 수 증가 전후 값이 저장되는가 |
| plan upgrade | Basic에서 Pro, Team에서 Enterprise처럼 플랜 상향 | 이전 price와 새 price가 연결되는가 |
| add-on purchase | 기본 플랜 외 기능, 저장공간, AI 기능, 지원 옵션 추가 | add-on 종류와 owner가 분리되는가 |
| usage overage | API, message, storage, seat 초과 사용량 과금 | 일회성 사용량인지 반복 확장인지 구분되는가 |
| cross-sell | 다른 제품군 또는 모듈 추가 | 기존 제품 사용과 새 제품 사용이 분리되는가 |
| reactivation | 끊겼던 계정이 다시 유료화 | 신규 고객 획득과 섞이지 않는가 |
같은 금액 증가라도 다음 행동은 다릅니다. 새 고객이면 acquisition 채널 품질을 봐야 하고, 좌석 추가라면 adoption과 내부 확산을 봐야 하며, add-on 구매라면 기능 사용량과 권한 구조를 봐야 합니다.
Stripe subscription 변경 이벤트를 한 줄로 저장하지 않습니다
Stripe Billing을 쓰는 팀은 subscription, subscription item, price, quantity, invoice를 따로 봐야 합니다. 구독이 업데이트됐다는 사실만으로 업그레이드인지, 다운그레이드인지, 좌석 추가인지, add-on 추가인지 알 수 없습니다.
원문: 원문기사 보기
원문: 원문기사 보기
원문: 원문기사 보기
원문: 원문기사 보기
| 저장 필드 | 감사 질문 |
|---|---|
| subscription_id | 어떤 구독의 변경인지 고정되는가 |
| subscription_item_id | 어떤 price 또는 add-on 항목이 바뀌었는가 |
| previous_price_id | 변경 전 플랜이나 상품 가격을 남기는가 |
| new_price_id | 변경 후 플랜이나 상품 가격을 남기는가 |
| previous_quantity | 기존 seat 또는 사용량 기준을 저장하는가 |
| new_quantity | 추가 좌석 또는 확장 수량을 저장하는가 |
| proration_behavior | 중간 변경에 따른 비례 과금 또는 credit을 구분하는가 |
| effective_at | 변경 요청일과 실제 적용일을 나누는가 |
| invoice_id | 확장 매출이 반영된 invoice와 연결되는가 |
| initiated_by | customer, admin, sales, success, system 중 누가 시작했는가 |
운영 보고서에는 subscription_updated 하나보다 seat_added, plan_upgraded, addon_added, usage_overage_recorded, cross_sell_started처럼 해석 가능한 내부 이벤트가 필요합니다.
좌석 추가는 quantity 변화와 활성 사용을 같이 봅니다
좌석이 늘었다고 해서 바로 건강한 확장이라고 볼 수는 없습니다. 구매한 좌석이 초대만 되고 실제로 활성화되지 않았을 수 있고, 퇴사자 좌석이 남아 있는 상태에서 새 좌석을 더 산 것일 수도 있습니다.
| 확인 항목 | 좋은 저장 방식 |
|---|---|
| paid_seat_before | 변경 전 유료 좌석 수 |
| paid_seat_after | 변경 후 유료 좌석 수 |
| active_user_before | 변경 전 30일 활성 사용자 수 |
| active_user_after | 변경 후 30일 활성 사용자 수 |
| invited_not_active | 초대 후 미활성 계정 수 |
| department_added | 새 부서 또는 팀 단위 확장 여부 |
| admin_action | 누가 좌석을 추가했는가 |
| seat_source | self-serve, sales-assisted, customer-success-assisted |
좌석 추가가 실제 확산인지 보려면 결제 데이터와 제품 사용 데이터를 연결해야 합니다. 단, 개인별 상세 행동을 넓은 마케팅 도구에 복제하기보다 계정 단위 집계와 제한된 상태값으로 남기는 편이 안전합니다.
plan upgrade와 add-on 구매를 한 필드에 넣지 않습니다
플랜 업그레이드는 제품 패키지 자체가 바뀌는 일이고, add-on 구매는 기존 플랜에 기능이나 한도를 붙이는 일입니다. 둘을 같은 upgrade로 저장하면 어떤 기능이 확장을 만들었는지 알 수 없습니다.
| 이벤트 | 예시 | 분리 이유 |
|---|---|---|
| plan_upgrade | Starter에서 Pro로 변경 | 패키지 가치와 가격 계층 검증 |
| add_on_added | AI add-on, storage add-on, support add-on | 특정 기능 수요 검증 |
| seat_expansion | 20 seats에서 35 seats | 조직 내 사용 확산 검증 |
| usage_limit_increase | API call, workflow run, storage 한도 상향 | 사용량 기반 병목 확인 |
| feature_entitlement_added | SSO, audit log, advanced permission 활성화 | 보안/관리 기능 수요 확인 |
| sales_contract_upgrade | self-serve에서 sales contract로 전환 | 영업 개입과 계약 흐름 분리 |
제품팀은 add-on 구매를 기능 수요로 보고, 영업팀은 plan upgrade를 확장 기회로 보고, 고객 성공팀은 좌석 증가를 adoption 신호로 봅니다. 그래서 이벤트 이름부터 분리해야 합니다.
CRM에는 expansion pipeline을 별도 단계로 둡니다
CRM에서는 새 영업 기회와 기존 고객 확장 기회를 분리해야 합니다. 같은 deal 객체를 쓰더라도 deal type, pipeline, source, existing account 여부를 명확히 남겨야 합니다.
원문: 원문기사 보기
원문: 원문기사 보기
원문: 원문기사 보기
원문: 원문기사 보기
| CRM 필드 | 예시 값 |
|---|---|
| deal_type | new_business, expansion, renewal_expansion, cross_sell |
| expansion_type | seat, plan_upgrade, add_on, usage, product_module |
| existing_account_id | 기존 회사 또는 workspace ID |
| expansion_source | product_usage, customer_success, sales_outreach, self_serve |
| product_signal | limit_reached, team_invites, feature_trial, usage_spike |
| expected_effective_date | 실제 청구 또는 권한 변경 적용일 |
| billing_confirmed | draft, pending_invoice, invoice_paid, applied |
| owner_team | sales, customer_success, billing_ops, self_serve |
CRM의 opportunity와 billing의 subscription update는 같은 순간에 끝나지 않을 수 있습니다. 영업 기회는 closed-won이지만 invoice가 아직 발행되지 않았거나, self-serve 업그레이드는 결제는 완료됐지만 CRM deal이 나중에 생성될 수 있습니다.
GA4에는 업셀 이벤트를 구매 전환과 섞지 않습니다
GA4에서 업셀 또는 add-on 관련 이벤트를 볼 수는 있지만, 신규 구매 전환과 같은 이름으로 보내면 안 됩니다. purchase 하나에 신규 결제, trial-to-paid, upgrade, renewal, add-on을 모두 넣으면 광고와 제품 분석이 모두 흐려집니다.
원문: 원문기사 보기
원문: 원문기사 보기
| 이벤트 예시 | 권장 역할 |
|---|---|
plan_upgrade_started |
플랜 상향 검토 시작 |
plan_upgrade_completed |
플랜 상향 적용 완료 |
seat_expansion_requested |
좌석 추가 요청 |
seat_expansion_applied |
좌석 추가 적용 완료 |
addon_trial_started |
add-on 체험 시작 |
addon_added |
add-on 구매 또는 활성화 |
usage_limit_reached |
한도 도달 신호 |
expansion_invoice_paid |
확장분 invoice 결제 완료 |
이 이벤트는 광고 최적화용 핵심 전환으로 바로 쓰기보다 계정 상태와 제품 사용 흐름을 설명하는 보조 이벤트로 보는 편이 안전합니다. 어떤 이벤트를 key event로 둘지는 광고 계정 연결 구조와 내부 분석 목적을 확인한 뒤 제한적으로 정해야 합니다.
Measurement Protocol은 서버 확정 이벤트에만 사용합니다
업셀과 좌석 추가는 서버에서 확정되는 billing 이벤트와 맞춰야 합니다. 브라우저 클릭만으로 업셀 완료를 기록하면 결제 실패, 승인 대기, invoice 미발행, 권한 적용 실패를 구분할 수 없습니다.
| 확인 항목 | 감사 질문 |
|---|---|
| event_id | 같은 subscription update가 중복 전송되지 않는가 |
| account_id | 개인보다 회사 또는 workspace 기준으로 묶이는가 |
| subscription_id_hash | 내부 subscription을 해시 또는 제한 ID로 연결하는가 |
| expansion_type | seat, plan, add-on, usage를 분리하는가 |
| invoice_status | paid, open, draft, failed를 분리하는가 |
| amount_bucket | 필요한 경우 금액 구간으로만 보내는가 |
| effective_at | 권한 적용 시점과 결제 완료 시점을 구분하는가 |
| consent 기준 | 회사의 데이터 처리 기준에 맞는가 |
서버 이벤트에는 카드 정보, 청구 주소, 고객 담당자 이메일, 계약 원문, 내부 영업 메모를 넣지 않아야 합니다. 분석에 필요한 최소 상태와 ID만 보내는 구조가 좋습니다.
expansion dashboard는 금액보다 원인 분류를 먼저 봅니다
확장 매출 총액만 보면 액션이 나오지 않습니다. 이번 달 확장 매출이 늘었는지보다 어떤 흐름이 늘었는지 봐야 합니다. 좌석 추가가 늘었는지, add-on 구매가 늘었는지, 한도 초과가 반복되는지, sales-assisted upgrade가 늘었는지에 따라 다음 조치가 달라집니다.
| 지표 | 보는 이유 |
|---|---|
| expansion_count_by_type | 확장 유형 분포 확인 |
| expansion_amount_by_type | 금액 영향도 확인 |
| seat_expansion_rate | 계정 내 사용자 확산 확인 |
| addon_attach_rate | 특정 add-on 수요 확인 |
| upgrade_after_limit_reached | 한도 도달이 플랜 상향으로 이어지는지 확인 |
| product_signal_to_upgrade_days | 제품 신호에서 업셀까지 걸린 시간 확인 |
| sales_assisted_expansion_rate | 영업 개입이 필요한 확장 비중 확인 |
| expansion_after_dunning | 결제 실패 복구 뒤 확장 발생 여부 확인 |
| expansion_then_churn_rate | 무리한 업셀이 이탈로 이어지는지 확인 |
| unknown_expansion_type_rate | 분류 품질 확인 |
unknown 비율이 높으면 확장 매출이 좋아 보여도 데이터는 아직 믿기 어렵습니다. 대시보드 첫 화면에는 금액보다 expansion_type, source, billing_status, account_status_after_expansion을 같이 둬야 합니다.
자동화 전에 승인과 권한 적용 로그를 고정합니다
업셀 자동화는 결제만 처리한다고 끝나지 않습니다. 권한이 실제로 열렸는지, 좌석이 배정됐는지, add-on owner가 누구인지, 갱신 시점에 같은 조건이 유지되는지까지 기록해야 합니다.
| 항목 | 체크 질문 |
|---|---|
| requester | 고객 admin, sales, customer success, system 중 누가 시작했는가 |
| approver | 금액 또는 플랜별 승인 기준이 있는가 |
| billing trigger | invoice, checkout, subscription update 중 무엇이 기준인가 |
| entitlement update | 실제 기능 권한이 적용됐는가 |
| seat assignment | 새 좌석이 사용자에게 배정됐는가 |
| customer notice | 고객에게 변경 내용과 적용일이 안내됐는가 |
| rollback path | 결제 실패나 승인 취소 시 되돌릴 수 있는가 |
| audit log | 변경 전후 price, quantity, add-on 값이 남는가 |
특히 self-serve 업그레이드는 빠르게 결제되지만 내부 CRM, CS owner, 보안 검토, 세금계산서 또는 invoice 저장 흐름이 뒤따라오지 못할 수 있습니다. 자동화는 billing, entitlement, CRM, 알림 로그가 같이 남을 때 안정적입니다.
공개 전 점검표
마지막으로 운영팀이 바로 확인할 수 있는 체크리스트를 남깁니다.
- new logo, trial-to-paid, expansion revenue를 같은 신규 매출 필드에 넣지 않습니다.
- seat expansion, plan upgrade, add-on purchase, usage overage를 별도 이벤트로 저장합니다.
- subscription item, price, quantity, invoice 연결을 남깁니다.
- 좌석 추가는 결제 수량과 실제 활성 사용자 수를 같이 봅니다.
- CRM deal에는
deal_type=expansion같은 분리 필드를 둡니다. - GA4에는 업셀 이벤트를 신규 구매 전환과 같은 이름으로 보내지 않습니다.
- Measurement Protocol에는 서버에서 확정된 이벤트만 보냅니다.
- 카드 정보, 계약 원문, 담당자 이메일, 영업 메모는 분석 이벤트에 넣지 않습니다.
- expansion dashboard에는 금액보다 유형, source, billing status, unknown 비율을 먼저 둡니다.
- 결제 완료, 권한 적용, 좌석 배정, 고객 안내, rollback 기준을 한 흐름으로 검증합니다.
정리
B2B SaaS 업셀과 좌석 추가 추적의 목표는 매출 증가를 더 크게 보이게 만드는 것이 아닙니다. 어떤 계정이 왜 확장됐는지, 어떤 제품 신호가 상위 플랜으로 이어졌는지, 어떤 add-on이 실제로 반복 구매되는지 분리해서 같은 숫자를 보는 것입니다.
upgrade와 add-on을 한 줄짜리 결제 이벤트로만 저장하면 신규 고객 획득, trial 전환, 기존 고객 확장, churn 복구, 사용량 초과가 모두 뒤섞입니다. 먼저 billing event, CRM expansion type, GA4 보조 이벤트, entitlement 로그를 나눈 뒤 자동화를 붙이는 편이 안전합니다.
About The Author
