2026년 SaaS 및 클라우드 소프트웨어 기업을 위한 다주 판매세(Sales Tax) 준수: 창업자를 위한 실무 가이드

ARR(연간 반복 매출)이 400만 달러인 창업자 중심의 B2B SaaS 스타트업은 첫 재무 담당자를 채용하기도 전에 9개 주에 걸쳐 6자릿수 규모의 과거 미납 판매세 위험에 직면할 수 있습니다. 이러한 상황은 드물게 일어나는 극적인 사건 때문이 아닙니다. SaaS를 과세 대상으로 취급하는 뉴욕, 텍사스, 펜실베이니아, 워싱턴주 등에서 고객이 서서히 늘어남과 동시에, 2년 전 이미 경제적 넥서스(economic nexus) 임계값을 조용히 넘어선 빌링 시스템이 결합되어 나타나는 결과입니다.

과거에 판매세는 신발을 파는 소매업체의 문제였지, API와 대시보드를 파는 클라우드 기업의 문제는 아니라고 여겨졌습니다. 이러한 가정은 2018년 6월 21일 미국 대법원이 South Dakota v. Wayfair 판결을 내리면서 더 이상 유효하지 않게 되었습니다. 2026년 현재, 판매세가 있는 거의 모든 주에는 경제적 넥서스 규칙이 존재하며, SaaS를 과세 대상 제품 또는 서비스로 취급하는 주가 점점 늘어나고 있습니다. 이 체계는 매우 복잡하고 위험 요소도 크지만, 다행히도 이를 운영하는 방법은 이제 충분히 정립되었습니다.

이 가이드는 2026년 SaaS 또는 클라우드 기업을 위한 방어적인 판매세 프로그램을 구축하는 방법을 단계별로 설명합니다. 주별 과세 여부를 파악하는 방법, 넥서스 임계값에 대한 사고법, Stripe Tax, Anrok, Avalara 또는 TaxJar와 같은 도구를 선택하는 방법, 번들 거래(bundled transactions)를 처리하는 방법, 그리고 과거의 노출된 세액을 자발적 공시 협약(VDA)으로 정리하는 방법까지 다룹니다.

SaaS 판매세가 이커머스 판매세와 다른 이유

이커머스 판매자는 비교적 명확한 사고 모델을 가지고 있습니다. 즉, 유형 동산(tangible personal property)은 일반적으로 과세 대상이며, 배송지 주소에서 세금을 징수하고, 세율은 조회 테이블에서 가져옵니다. 그러나 SaaS는 이 모델의 모든 부분을 무너뜨립니다.

SaaS는 손에 잡히는 유형 자산이 오가지 않습니다. "배송"은 인터넷을 통해 이루어지며, 종종 청구지 주소와 다른 주에 있는 사용자에게 전달됩니다. 제품은 소프트웨어 액세스, API 호출, 전문 서비스, 교육 및 스토리지를 포함할 수 있는 구독 형태이며, 각 항목은 다르게 과세될 수 있습니다. 고객은 종종 재판매 면제(resale exemption) 자격이 있을 수도 있고 없을 수도 있는 기업입니다. 그리고 근본적인 질문인 *'SaaS가 과세 대상인가?'*에 대한 답은 관할 구역마다 다릅니다.

SaaS 기업이 파악해야 할 세 가지 계층은 다음과 같습니다.

넥서스(Nexus) — 해당 주가 귀사에 세금 징수를 요구할 권한이 있는가?
과세 대상 여부(Taxability) — 해당 주가 실제로 귀사가 판매하는 품목에 과세하는가?
원천지 결정(Sourcing) — 과세 대상인 경우, 누구의 주소를 기준으로 세율을 결정하는가?

이 중 하나라도 틀리면 세금을 과다 징수하여 화가 난 고객에게 환불 절차를 진행해야 하거나, 과소 징수하여 가산세와 이자가 붙은 부채를 쌓게 됩니다.

1단계: 주별 SaaS 과세 대상 여부 파악

세무 프로그램에서 가장 중요한 테이블은 주별로 "이 제품에 과세하는가?"를 나타내는 테이블입니다. 2026년 일반적인 B2B SaaS 구독의 경우, 환경은 대략 다음과 같습니다.

SaaS에 광범위하게 과세하는 주

뉴욕주는 배송 방식에 관계없이 SaaS를 기성 소프트웨어(prewritten software)의 판매로 보아 과세합니다. 고객 위치에 따라 원천지가 결정됩니다.
펜실베이니아주는 SaaS를 표준 판매세율이 적용되는 과세 대상 기성 소프트웨어로 취급합니다.
텍사스주는 SaaS를 *데이터 처리 서비스(data processing service)*로 과세하지만, 요금의 20%만 과세 대상입니다. 텍사스는 데이터 처리에 대해 20% 면제를 부여하므로, 100달러 인보이스에 대한 실효 세율은 20달러에 대해 주 및 지방 세율을 적용한 금액입니다.
워싱턴주는 소매 판매세 하에서 SaaS를 "디지털 자동 서비스(digital automated service)"로 과세하며, 사업 및 직업세(B&O tax)를 별도로 적용합니다.
테네시주는 비즈니스용 및 개인용 SaaS 모두에 과세합니다.
사우스캐롤라이나주는 광범위한 통신 서비스 정의에 따라 SaaS에 과세합니다.
유타주는 원격으로 액세스하는 기성 소프트웨어에 과세합니다.
오하이오, 커네티컷, 아이오와, 매사추세츠, 로드아일랜드, 하와이, 뉴멕시코 주는 각각 SaaS에 과세하며, 비즈니스용과 개인용에 따라 세율이 다른 경우도 있습니다.

일반적으로 SaaS에 과세하지 않는 주

캘리포니아주는 SaaS에 과세하지 않습니다. 유형 동산의 이전이 없으므로 SaaS는 비과세 대상이라는 규칙이 적용됩니다. (고객을 위해 개발된 맞춤형 소프트웨어는 다를 수 있습니다.)
플로리다, 조지아, 일리노이, 버지니아, 콜로라도(시 단위 예외 있음), 노스캐롤라이나 주는 현재 일반적으로 SaaS에 과세하지 않습니다.

변화하는 중간 지대

지난 몇 년 동안 여러 주가 입장을 바꿨으며, 메인주는 2026년 7월 1일부터 시행되는 SB 162에 따라 새로운 유형의 디지털 구독 서비스를 과세 대상에 추가했습니다. 이 리스트는 매 분기마다 다시 확인해야 합니다. 주 세무 당국은 별다른 공고 없이 제품 분류를 변경하는 유권해석(letter ruling)을 조용히 내놓기도 하기 때문입니다.

실무적인 조언: 일회성 스프레드시트를 만들고 방치하지 마십시오. 주별 세무 추적 서비스(Anrok, Avalara, TaxJar, Numeral 등은 변경 로그를 게시함)를 구독하거나, 매 분기마다 상위 10개 주의 상태를 재확인하도록 캘린더 미리 알림을 설정하십시오.

2단계: Wayfair 경제적 넥서스 이해하기

South Dakota v. Wayfair 판결은 주 정부가 원격 판매자에게 경제 활동만으로도 판매세를 징수하도록 요구할 수 있게 허용했습니다. 대부분의 주는 사우스다코타의 선례를 따라 10만 달러 또는 200건의 거래 기준을 채택했습니다. 몇몇 주는 예외적입니다:

캘리포니아주는 합산 매출 50만 달러를 기준으로 사용합니다 (거래 건수 기준 없음). 200건 거래 트리거는 적용되지 않습니다.
텍사스주는 수익 50만 달러를 기준으로 사용합니다.
뉴욕주는 50만 달러 및 100건 이상의 거래를 기준으로 사용합니다 (두 조건 모두 충족 시).
테네시주는 수익 10만 달러를 기준으로 사용합니다.
캔자스주는 거래 건수 기준을 폐지하고 현재 수익 10만 달러를 기준으로 사용합니다.

창업자들이 흔히 놓치는 몇 가지 실무적 유의 사항:

임계값은 일반적으로 과세 매출이 아닌 총 매출을 기준으로 계산합니다. 해당 주에서 SaaS가 비과세 대상이더라도, 구독 수익은 종종 해당 주의 넥서스 임계값 계산에 포함됩니다. 따라서 컴플라이언스 유지를 위해 세금이 0원인 신고(zero-tax returns)를 등록하고 제출해야 할 수도 있습니다.
마켓플레이스 퍼실리테이터(Marketplace facilitators)(예: Stripe Atlas, AWS Marketplace, Apple App Store 등)는 많은 경우 귀하를 대신해 세금을 징수하며, 이들이 중개한 매출이 귀하의 임계값에 포함되는지 여부는 주마다 다릅니다.
**트레일링 넥서스(Trailing nexus)**가 중요합니다. 캘리포니아의 경우, 임계값 미만으로 떨어지더라도 다음 달력 연도까지 계속해서 세금을 징수해야 합니다.

실시간 넥서스 추적기를 구축하십시오. 대부분의 조세 엔진은 이를 자동으로 수행하며, 스프레드시트를 사용 중이라면 매월 갱신하십시오.

3단계: 해당 당국에 등록하기

임계값을 초과했거나 초과할 예정이라면 주 조세국(Department of Revenue)에 등록해야 합니다. 주요 절차는 다음과 같습니다:

SST(Streamlined Sales Tax) 회원국 (아이오와, 캔자스, 미시건, 미네소타, 네브래스카, 네바다, 뉴저지, 노스캐롤라이나, 노스다코타, 오하이오, 오클라호마, 로드아일랜드, 사우스다코타, 테네시, 유타, 버몬트, 워싱턴, 웨스트버지니아, 위스콘신, 와이오밍, 아칸소, 조지아, 인디애나, 켄터키 등 24개 주)은 SSUTA 중앙 등록 시스템을 통해 단일 통합 신청서를 접수합니다.
비 SST 주는 각각 자체 포털을 운영합니다. 어떤 곳은 쉽지만(10분 만에 온라인 완료), 어떤 곳은 번거롭습니다(종이 신청서, IRS 서신 팩스 송신, 보증 요구 등). 텍사스, 캘리포니아, 플로리다는 각기 특유의 등록 단계가 있습니다.
자치구 관할권(Home-rule jurisdictions) — 콜로라도, 루이지애나, 앨라배마에는 주 정부와 독립적으로 운영되는 지역 판매세 당국이 있습니다. 콜로라도의 경우, 주 정부 외에도 덴버, 볼더, 오로라와 같은 도시에 별도로 등록해야 할 수도 있습니다.

등록 후에는 예상 매출 규모에 따라 신고 일정(매월, 분기별 또는 매년)을 부여받습니다. 대부분의 주에서 이 일정은 협상의 대상이 아니며, 0달러 신고를 누락하더라도 벌금이 부과됩니다.

4단계: 조세 엔진 설정하기

2026년 현재, SaaS 판매세 자동화는 다음 네 가지 플랫폼이 주도하고 있습니다:

Stripe Tax — 이미 Stripe 결제를 사용 중인 경우 가장 적합합니다. 계산을 처리하고 Stripe Invoices 및 Subscriptions와 깔끔하게 통합됩니다. 신고 및 납부의 경우, Stripe은 자체 처리가 아닌 TaxJar나 Taxually와 같은 파트너사로 연결해 줍니다.
Anrok — 반복 구독 및 복잡한 과금 모델(사용량, 시트 수, API 호출 등)을 가진 B2B 및 B2C SaaS를 위해 특별히 제작되었습니다. 스타터 요금제는 월 100달러이며 계산, 모니터링 및 신고 기능이 포함됩니다. 신고와 면세 증명서 관리를 한 곳에서 처리해야 하는 SaaS 네이티브 기업에 가장 강력한 선택지입니다.
Avalara (AvaTax) — NetSuite, SAP, Oracle과 같은 ERP에 1,000개 이상의 통합을 제공하는 엔터프라이즈 옵션입니다. 가격 책정을 위해서는 영업 상담이 필요합니다. 스택이 복잡할 때 유용하지만, 시리즈 A 단계의 SaaS에게는 과할 수 있습니다.
TaxJar (Stripe 계열사) — 이커머스 및 마켓플레이스에 강점이 있으며 AutoFile 서비스(2026년 기준 신고당 50–55달러, 이전 연도 25–35달러에서 인상됨)를 제공합니다. Anrok보다는 SaaS 특화도가 낮지만 Stripe과 잘 통합되어 있습니다.

모든 조세 엔진이 귀하에게 요구하는 사항:

고객 주소 검증 — 청구지 주소(bill-to)와 배송지 주소(ship-to)가 실제 관할 구역으로 확인되어야 합니다. 잘못된 입력값은 잘못된 결과값(Garbage in, garbage out)을 낳습니다.
제품 과세 여부 매핑(Product taxability mapping) — 모든 SKU 또는 구독 티어에는 엔진에 해당 항목이 무엇인지 알려주는 세금 코드가 필요합니다. "SaaS — B2B 구독"은 "디지털 다운로드"나 "전문 서비스"와 다르게 매핑됩니다.
면세 증명서 수집 — 고객이 면세 대상(재판매, 비영리, 정부 기관 등)인 경우 주별로 유효한 증명서를 수집하고 보관해야 합니다. Anrok과 Avalara는 면세 증명서 워크플로우를 포함하고 있으며, Stripe Tax의 경우 Numeral이나 Sphere 같은 도구를 추가로 연결할 수 있습니다.
청구지 vs. 배송지 vs. 사용 위치 소싱(Sourcing) — SaaS의 경우 대부분의 주는 고객의 주 사업장 주소를 사용하지만, 일부는 사용자의 위치를 보기도 합니다. 조세 엔진이 권장하는 규칙을 인코딩하고 이를 문서화하십시오.

5단계: Handle Bundled Transactions With the True Object Test

실제 SaaS 인보이스는 종종 다음과 같습니다:

$5,000 — 연간 플랫폼 구독료
$1,500 — 도입/구축 서비스
$400 — 교육 크레딧
$200 — 프리미엄 지원 애드온

구독료는 해당 주에서 과세 대상이고 서비스는 그렇지 않은 경우, 이를 분리하여 과세할 수 있을까요? 정답은 True Object Test(거래의 본질 원칙이라고도 함)에 달려 있습니다. 이는 고객이 근본적으로 무엇을 구매하는지를 묻는 테스트입니다.

고객이 SaaS 플랫폼 이용권을 구매하는 것이 목적이고 도입/교육이 부수적인 것이라면, True Object Test를 광범위하게 적용하는 주에서는 전체 묶음(Bundle)이 과세 대상 소프트웨어로 취급될 수 있습니다. 도입 서비스가 별도의 결과물을 가진 실질적이고 개별적으로 협상된 서비스라면, 구성 요소를 별도로 청구하고 과세할 수 있습니다.

두 가지 실무적 방어 방안:

인보이스에 각 구성 요소를 별도로 명시하고 가격을 책정하십시오. 개별 청구를 허용하는 주들은 거의 예외 없이 고객에게 발행되는 인보이스에 구성 요소가 별도로 표기될 것을 요구합니다.
계약상의 의도를 문서화하십시오. 도입 서비스를 자체 작업 명세서(SOW)를 가진 별도의 계약으로 설명하는 기본 서비스 계약(MSA)은, 견적서에 한 줄로 표시하는 것보다 개별 거래로 인정받기에 훨씬 유리합니다.

2026년 4월 뉴욕주의 묶음 SaaS 거래에 대한 최근 판결은 소프트웨어 구성 요소가 "부수적인 것이 아니라 핵심적"일 때 전체 거래가 소프트웨어로서 과세된다는 점을 재확인했습니다. 따라서 가장 안전한 방법은 명확하고 개별적으로 가격이 책정된 서비스 항목이 있는 경우에만 의도적으로 묶음 구성을 하는 것입니다.

6단계: 특수 사례 주의 깊게 살펴보기

자주 발생하는 몇 가지 상황은 별도로 언급할 가치가 있습니다:

텍사스주 20% 데이터 처리 면제 조항 — 텍사스에서는 SaaS에 과세되지만, '데이터 처리 서비스'로 분류되어 요금의 80%가 면제됩니다. 사용 중인 세금 엔진이 이를 인지하고 있어야 합니다. 많은 엔진이 기본적으로 전체 세율을 적용하여 세금을 과다 징수하곤 합니다.
뉴욕주 정보 서비스 — SaaS와는 별개로, '정보 서비스'(예: 수집된 산업 데이터)는 자체적인 규칙이 있으며 데이터가 개인화된 경우 면제될 수 있습니다.
클라우드 인프라(IaaS) vs. SaaS — 테네시주는 SaaS에 과세하지만 IaaS에는 과세하지 않는데, 이는 유형의 개인 자산이 인도되지 않기 때문입니다. 뉴욕은 IaaS를 비과세로 처리하는 반면 SaaS는 과세 대상으로 봅니다. 하이브리드 제품을 판매할 때 이 차이가 중요해집니다.
무료 체험 및 프리미엄(Freemium) — 대부분의 주에서는 구독의 유료 부분을 과세 사건으로 간주합니다. 무료 티어는 세금 징수를 유발하지 않지만, 일부 주에서는 "거래"가 발생한 것으로 간주하여 경제적 넥서스(Economic Nexus) 기준치 산정에 포함될 수 있습니다.
연간 청구 vs. 월간 청구 — 세금 발생 시점은 일반적으로 수익이 인식되는 시점이 아니라 인보이스를 발행하는 시점입니다. 1월에 12개월 연간 구독에 대한 인보이스를 발행하면, 1년 치 전체 판매세가 1월에 발생합니다.

7단계: VDA를 통한 과거 미납 노출 정리

지난 2년 동안 특정 주에서 세금을 징수했어야 했다는 사실을 발견했다면, 단순히 사업자 등록을 하고 앞으로만 징수하기 시작해서는 안 됩니다. 그렇게 하면 신고하지 않은 신고서와 징수하지 않은 세금에 대한 책임이 남게 되며, 주는 보통 6년에서 10년 전까지 소급하여 추징할 수 있습니다.

해결책은 **자발적 공개 계약(VDA, Voluntary Disclosure Agreement)**입니다. (보통 세무 고문이나 VDA 전문 업체를 통해) 주 정부에 익명으로 접근하여, 제한된 소급 기간(영구적 소급 대신 보통 3~4년)에 합의하고 미납된 세금을 납부하는 것입니다. 그 대가로 주는 벌금을 면제해주고, 때로는 이자를 감면해주며, 형사 처벌로부터의 보호를 보장합니다.

VDA가 필요한 경우:

세금을 징수하지 않았고 주 정부가 귀하의 존재를 인지하지 못한 경우. (세금을 징수하고도 납부하지 않은 경우에는 대상이 되지 않습니다. 이는 '신탁 기금' 책임으로 간주되어 다른 결과가 따릅니다.)
과거 미납 노출액이 충분히 커서 면제받는 벌금이 법률 비용보다 많은 경우(보통 미납 세액이 2만 5천 달러 이상일 때 의미가 있습니다).
펀딩이나 인수를 앞두고 장부를 정리하고 싶은 경우. 판매세 미납 노출은 실사 과정에서 흔히 발견되는 항목입니다.

과거에 얼마를 미납했는지는 실제로 인보이스를 어떻게 발행했느냐에 달려 있습니다. 이것이 바로 미납 노출을 발견했을 때 깨끗하고 감사 가능한 재무 기록이 매우 중요한 이유입니다. 모든 인보이스, 고객 주소, 판매 항목, 청구 금액에 대한 신뢰할 수 있는 과거 기록은 모든 VDA 계산의 기초가 됩니다. 이를 재구성할 수 없다면, 미납 세액 계산은 주 정부에 유리한 추정치로 설정됩니다.

8단계: 분기별 대조 작업 운영화

정상적으로 작동하는 판매세 준수 프로그램은 다음과 같은 주기적인 업무를 수행합니다:

매월 — 등록된 각 주에 신고서를 제출합니다. 대부분의 엔진이 자동 제출 기능을 제공하며, 귀하는 이를 확인합니다.
분기별 — 빌링 시스템에서 징수된 세금과 신고서에 보고된 세금을 대조합니다. 차이점을 조사하고 넥서스 추적기를 최신 상태로 업데이트합니다.
연간 — 새로운 주 정부 판결에 따라 과세 여부 매트릭스를 검토하고, 면세 증명서의 만료 여부를 감사하며, 갱신이 필요한 주 등록을 갱신합니다.
이벤트 발생 시 — 제품 출시(새로운 SKU, 새로운 세금 코드), 가격 변경(번들링 변경), 인수(승계된 넥서스), 또는 대대적인 지리적 확장이 있을 때 다시 평가합니다.

첫날부터 재무 기록을 세무 감사에 대비시키세요

판매세 준수는 장부 관리의 결과물입니다. 빌링 데이터, 고객 주소, 수익 인식 상태가 깨끗하지 않다면 위의 모든 단계는 더 힘들어질 것이며, 주 정부 감사는 Stripe 엑스포트 파일과 오래된 계약서를 뒤지는 비싸고 고통스러운 과정이 될 것입니다.

Beancount.io는 모든 거래, 고객, 인보이스에 대해 완전하고 감사 가능한 기록을 제공하는 플레인 텍스트 기반의 버전 관리형 회계를 지원합니다. 이는 주 세무 당국이 5년 치 거래 내역을 요청할 때 정확히 필요한 것입니다. 블랙박스도 없고, 벤더 종속성도 없으며, 모든 변경 사항은 Git으로 추적됩니다. 무료로 시작하여 세무 프로그램(및 미래의 인수자)이 신뢰할 수 있는 재무 기반을 구축하세요.