Спазване на данъчното законодателство за данък върху продажбите в множество щати за SaaS и облачни софтуерни компании през 2026 г.: Практическо ръководство за основатели

B2B SaaS стартъп, ръководен от своите основатели, с 4 милиона долара годишен повтарящ се приход (ARR), може да се окаже изправен пред шестцифрена експозиция от ретроспективно дължими данъци върху продажбите в девет щати, още преди да е наел първия си финансов специалист. Причината рядко е еднократна драматична промяна. По-скоро става въпрос за бавно натрупване на клиенти в Ню Йорк, Тексас, Пенсилвания и Вашингтон — всеки от които третира софтуера като услуга (SaaS) като облагаем — съчетано с билинг система, която тихо е преминала праговете за икономически нексус (economic nexus) преди две години.

Данъкът върху продажбите трябваше да бъде проблем на търговците на дребно, продаващи обувки, а не на облачните компании, продаващи API и табла за управление. Това предположение престана да бъде вярно на 21 юни 2018 г., когато Върховният съд взе решение по делото South Dakota v. Wayfair. През 2026 г. почти всеки щат с данък върху продажбите има и правило за икономически нексус, а нарастващ брой от тях третират SaaS като облагаем продукт или услуга. Тази мозайка от правила е объркваща, залозите са реални, а добрата новина е, че оперативните стъпки вече са добре разбрани.

Това ръководство разглежда как да изградите надеждна програма за данък върху продажбите за SaaS или облачна компания през 2026 г.: как да картографирате облагаемостта щат по щат, как да преценявате праговете на нексус, как да избирате инструменти като Stripe Tax, Anrok, Avalara или TaxJar, как да се справяте с пакетни транзакции и как да изчистите историческа експозиция чрез споразумение за доброволно разкриване (VDA), когато откриете такава.

Защо данъкът върху продажбите за SaaS е различен от този за електронната търговия

Продавачите в електронната търговия имат сравнително ясен модел: материалната лична собственост обикновено е облагаема, събирате данъка според адреса на местоназначение, а ставките идват от справочна таблица. SaaS разбива всяка част от този модел.

Няма физическа собственост, която да сменя собственика си. „Доставката“ се извършва по интернет, често до потребител в щат, различен от адреса за таксуване. Продуктът е абонамент, който може да включва софтуерен достъп, API повиквания, професионални услуги, обучение и съхранение — всеки от които потенциално се облага по различен начин. Клиентите често са фирми, които могат или не могат да се квалифицират за освобождаване при препродажба. А основният въпрос — облагаем ли е изобщо SaaS? — има различен отговор във всяка юрисдикция.

Има три нива, които една SaaS компания трябва да картографира:

Нексус (Nexus) — има ли щатът юрисдикция да изисква от вас да събирате данък?
Облагаемост (Taxability) — облага ли щатът реално това, което продавате?
Определяне на източника (Sourcing) — ако е облагаем, чий адрес определя данъчната ставка?

Сгрешете което и да е от тях и рискувате или да съберете повече данък (и да преминете през процеси на възстановяване на разгневени клиенти), или да съберете по-малко (и да натрупате задължения, които се увеличават с неустойки и лихви).

Стъпка 1: Картографиране на облагаемостта на SaaS щат по щат

Най-важната таблица във вашата данъчна програма е тази, която казва за всеки щат: „облагам ли този продукт?“. За типичен B2B SaaS абонамент през 2026 г. пейзажът изглежда приблизително така:

Щати, които широко облагат SaaS

Ню Йорк облага SaaS като продажба на предварително написан софтуер (prewritten software), независимо от метода на доставка. Местоположението на клиента определя източника на облагане.
Пенсилвания третира SaaS като облагаем готов софтуер (canned software) по стандартната ставка на данъка върху продажбите.
Тексас облага SaaS като услуга за обработка на данни (data processing service), но само 20% от сумата подлежи на данък — Тексас предоставя 20% освобождаване за обработка на данни, така че ефективната ставка върху фактура от $100 е щатската плюс местната ставка, приложена върху $20.
Вашингтон облага SaaS като „дигитална автоматизирана услуга“ (digital automated service) съгласно данъка върху продажбите на дребно и прилага B&O данък отделно.
Тенеси облага SaaS както за бизнес, така и за лична употреба.
Южна Каролина облага SaaS съгласно своите широки дефиниции за комуникационни услуги.
Юта облага предварително написан софтуер с отдалечен достъп.
Охайо, Кънектикът, Айова, Масачузетс, Роуд Айлънд, Хаваи и Ню Мексико облагат SaaS, понякога с различни ставки за бизнес спрямо лична употреба.

Щати, които по принцип не облагат SaaS

Калифорния не облага SaaS — правилото е, че SaaS не е облагаем, тъй като не се прехвърля материална лична собственост. (Персонализираният софтуер, разработен за конкретен клиент, може да бъде различен случай.)
Флорида, Джорджия, Илинойс, Вирджиния, Колорадо (с изключения на ниво град) и Северна Каролина по принцип не облагат SaaS към днешна дата.

Променящата се среда

Няколко щати промениха позицията си през последните няколко години, а Мейн добави нови категории услуги за дигитален абонамент към облагаемата основа през 2026 г. съгласно SB 162, в сила от 1 юли 2026 г. Третирайте този списък като нещо, което одитирате отново всяко тримесечие — щатските данъчни служби тихо издават писмени решения, които прекласифицират продукти без много шум.

Практическият извод: не създавайте еднократна таблица, която след това да забравите. Абонирайте се за услуга за проследяване на щатските данъци (Anrok, Avalara, TaxJar и Numeral публикуват дневници с промени) или си създайте напомняне в календара да проверявате отново топ десетте си щати всяко тримесечие.

Стъпка 2: Разбиране на икономическата свързаност (Economic Nexus) съгласно Wayfair

Делото Южна Дакота срещу Wayfair позволи на щатите да изискват от дистанционните продавачи да събират данък върху продажбите въз основа единствено на икономическата им активност. Повечето щати последваха примера на Южна Дакота и приеха тест за праг от 100 000 долара или 200 транзакции. Няколко щата се различават:

Калифорния използва 500 000 долара комбинирани продажби (без тест за брой транзакции). Прагът от 200 транзакции не се прилага.
Тексас използва 500 000 долара приходи.
Ню Йорк използва 500 000 долара и повече от 100 транзакции (изискват се и двете).
Тенеси използва 100 000 долара приходи.
Канзас премахна теста за брой транзакции и сега използва 100 000 долара приходи.

Няколко практически бележки, които често изненадват основателите:

Праговете обикновено отчитат брутните продажби, а не облагаемите продажби. Дори ако SaaS услугите не са облагаеми в даден щат, приходите ви от абонаменти често се зачитат към прага за nexus в този щат. Така че може да се наложи да се регистрирате и да подавате данъчни декларации с нулева стойност, само за да останете в съответствие със закона.
Фасилитаторите на пазари (Marketplace facilitators) като Stripe Atlas, AWS Marketplace и Apple App Store събират данъци от ваше име в много случаи, а техните улеснени продажби могат или не могат да се зачитат към вашия праг в зависимост от щата.
Последващата икономическа свързаност (Trailing nexus) е важна. Калифорния изисква да продължите да събирате данъци през следващата календарна година, дори ако паднете под прага.

Изградете инструмент за проследяване на nexus в реално време. Повечето данъчни софтуери правят това автоматично; ако използвате електронна таблица, актуализирайте я ежемесечно.

Стъпка 3: Регистрация в съответните органи

След като преминете прага (или сте напът да го направите), трябва да се регистрирате в щатския данъчен отдел (Department of Revenue). Механиката:

Щатите, членуващи в Опростения данък върху продажбите (SST) (24 щата, включително Айова, Канзас, Мичиган, Минесота, Небраска, Невада, Ню Джърси, Северна Каролина, Северна Дакота, Охайо, Оклахома, Роуд Айлънд, Южна Дакота, Тенеси, Юта, Върмонт, Вашингтон, Западна Вирджиния, Уисконсин, Уайоминг, Арканзас, Джорджия, Индиана и Кентъки) приемат едно общо заявление чрез Централната система за регистрация по SSUTA.
Щатите, които не са част от SST, имат собствени портали. Някои са лесни (онлайн за 10 минути), други са трудни (хартиено заявление, писмо от IRS по факс, изискване за гаранция). Тексас, Калифорния и Флорида имат специфични стъпки за регистрация.
Юрисдикции с местно самоуправление (Home-rule jurisdictions) — Колорадо, Луизиана и Алабама имат местни органи за данък върху продажбите, които работят независимо от щатските. В Колорадо това може да означава отделна регистрация в градове като Денвър, Боулдър и Аврора в допълнение към щатската.

След регистрацията ще получите график за подаване на декларации (месечен, тримесечен или годишен), обвързан с очаквания ви обем. Графикът не подлежи на договаряне в повечето щати, а пропуснатите подавания — дори на декларации със стойност 0 долара — водят до санкции.

Стъпка 4: Конфигуриране на данъчния софтуер

Към 2026 г. четири платформи доминират автоматизацията на данъка върху продажбите за SaaS:

Stripe Tax — най-подходящ, ако вече използвате Stripe за фактуриране. Той управлява изчисленията и се интегрира чисто със Stripe Invoices и Subscriptions. За подаване и превеждане на данъка Stripe ви насочва към партньори като TaxJar или Taxually, вместо да го прави вътрешно.
Anrok — създаден специално за B2B и B2C SaaS с повтарящи се абонаменти и сложни модели на таксуване (потребление, брой потребители, API повиквания). Първоначалната цена е 100 долара на месец и включва изчисления, мониторинг и подаване. Anrok е най-добрият избор за SaaS компании, които се нуждаят от управление на подаването на декларации и сертификати за освобождаване на едно място.
Avalara (AvaTax) — решение за големи предприятия с над 1000 интеграции в ERP системи като NetSuite, SAP и Oracle. Ценообразуването изисква разговор с търговски представител. Заслужава си, когато софтуерният ви пакет е сложен; излишно е за SaaS компания в серия А.
TaxJar (компания на Stripe) — силна позиция в електронната търговия и онлайн пазарите, с услугата AutoFile (50–55 долара на подаване към 2026 г., спрямо 25–35 долара в предходни години). По-малко специализирана за SaaS от Anrok, но добре интегрирана със Stripe.

Какво изисква всеки данъчен софтуер от вас:

Валидиране на адреса на клиента — адресите за фактуриране и за доставка трябва да съответстват на реална юрисдикция. При неточни данни резултатите също ще бъдат неточни.
Картографиране на облагаемостта на продуктите — всеки SKU или абонаментен план се нуждае от данъчен код, който указва на софтуера какъв е продуктът. „SaaS — B2B абонамент“ се картографира по различен начин от „дигитално изтегляне“ или „професионални услуги“.
Събиране на сертификати за освобождаване от данъци — когато клиент е освободен (препродажба, нестопанска цел, държавна институция), трябва да съберете и съхраните валиден сертификат за съответния щат. Anrok и Avalara включват работни процеси за сертификати за освобождаване; при Stripe Tax може да се наложи да добавите инструмент като Numeral или Sphere.
Определяне на източника според адреса на фактуриране, доставка или ползване — за SaaS повечето щати използват основния бизнес адрес на клиента, но някои гледат местоположението на потребителите. Въведете правилото, което вашият данъчен софтуер препоръчва, и го документирайте.

Стъпка 5: Обработка на пакетирани транзакции чрез "Теста за основната цел" (True Object Test)

Реална SaaS фактура често изглежда така:

5 000 долара — годишен абонамент за платформата
1 500 долара — услуги по внедряване
400 долара — кредити за обучение
200 долара — добавка за премиум поддръжка

Ако абонаментът е облагаем в даден щат, а услугите не са, можете ли да ги облагате отделно? Отговорът зависи от теста за основната цел (true object test) — наричан още доктрина за „същността на транзакцията“ — който пита какво фундаментално купува клиентът.

Ако клиентът купува достъп до SaaS платформата, а внедряването/обучението са второстепенни, целият пакет може да се третира като облагаем софтуер в щатите, които прилагат широко теста за основната цел. Ако внедряването е съществена, отделно договорена услуга със собствени резултати, може да имате възможност да фактурирате и облагате компонентите отделно.

Две практически защити:

Посочете и оценете всеки компонент отделно във фактурата. Щатите, които позволяват разпакетиране, почти универсално изискват компонентите да бъдат посочени отделно във фактурата към клиента.
Документирайте договорното намерение. Рамков договор за услуги (MSA), който описва внедряването като отделен ангажимент със собствено описание на работата (SOW), подкрепя непакетираното третиране много по-добре от един ред в офертата.

Решение на щата Ню Йорк от април 2026 г. относно пакетирани SaaS транзакции потвърди, че когато софтуерният компонент е „централен, а не съпътстващ“, цялата транзакция е облагаема като софтуер — така че най-безопасният път е пакетно ценообразуване по дизайн само когато имате ясен, отделно оценен ред за услуги.

Стъпка 6: Обърнете внимание на специалните случаи

Някои ситуации възникват достатъчно често, за да бъдат изрично споменати:

Тексас: 20% освобождаване за обработка на данни — SaaS е облагаем в Тексас, но като „услуга за обработка на данни“ 80% от таксата е освободена. Вашият софтуер за изчисляване на данъци трябва да знае това; много системи изчисляват пълната ставка по подразбиране и събират прекомерни суми.
Информационни услуги в Ню Йорк — отделно от SaaS, „информационните услуги“ (като компилирани индустриални данни) имат свои собствени правила и могат да бъдат освободени, ако данните са персонализирани.
Облачна инфраструктура (IaaS) срещу SaaS — Тенеси облага SaaS, но не и IaaS, тъй като не се прехвърля материална лична собственост. Ню Йорк третира IaaS като необлагаема, докато SaaS е облагаема. Разликата е важна, когато продавате хибридни продукти.
Безплатни пробни периоди и freemium — повечето щати третират платената част от абонамента като облагаемо събитие. Безплатните нива не задействат събиране на данък, но все пак могат да се броят към праговете за икономическа свързаност (nexus) в някои щати, тъй като включват „трансакции“.
Годишно спрямо месечно таксуване — данъчното събитие обикновено е моментът на фактуриране, а не когато приходите са признати. Януарска фактура за 12-месечен годишен абонамент генерира пълния данък върху продажбите за годината през януари.

Стъпка 7: Изчистете миналата експозиция чрез VDA

Ако откриете, че е трябвало да събирате данъци в даден щат през последните две години, не просто се регистрирайте и започвайте да събирате оттук нататък. Това оставя след себе си неподадени декларации и несъбран данък, за които щатът все още може да ви потърси отговорност — често с ретроспективен период от шест или десет години.

Решението е споразумение за доброволно оповестяване (VDA). Вие (обикновено чрез данъчен консултант или фирма, специализирана във VDA) се свързвате с щата анонимно, договаряте ограничен ретроспективен период (обикновено 3–4 години вместо неограничен) и плащате дължимия данък за минали периоди. В замяна щатът опрощава неустойките, понякога намалява лихвите и ви осигурява защита от наказателно преследване.

Кога VDA имат смисъл:

Не сте събирали данък и щатът не е знаел за вашето съществуване. (Ако сте събирали данък, но не сте го превели, не отговаряте на условията — това е отговорност за „доверителни фондове“ (trust fund liability) с различни последици.)
Вашата историческа експозиция е достатъчно голяма, така че спестяванията от опростени неустойки да надвишават разходите за правни такси (обикновено това е оправдано при над 25 000 долара дължим данък).
Искате да изчистите досието си преди привличане на капитал или придобиване, където експозицията по данъка върху продажбите е стандартна част от надлежната проверка (due diligence).

Сумата, която дължите за минали периоди, зависи от това какво действително сте фактурирали — ето защо чистите и подлежащи на одит финансови записи са изключително важни при откриване на експозиция. Надеждната историческа справка за всяка фактура, адреса на клиента, какво е продадено и каква сума е начислена, е в основата на всяко изчисление за VDA. Ако не можете да възстановите тези данни, изчислението на данъка за минали периоди ще се базира на прогнозни оценки, които са в полза на щата.

Стъпка 8: Въведете тримесечно равняване

Една работеща програма за данък върху продажбите включва следните повтарящи се процедури:

Месечно — подаване на декларации, дължими във всеки регистриран щат. Повечето системи подават автоматично; вие само потвърждавате.
Тримесечно — равняване на събрания данък във вашата билинг система с данъка, отчетен в декларациите. Проверка на разминаванията. Актуализиране на вашия регистър за икономическа свързаност (nexus tracker).
Годишно — преглед на матрицата на облагаемост спрямо нови щатски решения, одит на сертификатите за освобождаване от данък за изтичащи срокове и подновяване на всички щатски регистрации, които го изискват.
При конкретно събитие — преоценка след стартиране на продукт (нов SKU, нов данъчен код), промяна в ценообразуването (промени в пакетирането), придобиване (наследена свързаност) или голямо географско разширяване.

Поддържайте финансовите си записи готови за данъчен одит от първия ден

Спазването на данъчното законодателство е следствие от вашето счетоводство. Ако данните за таксуване, адресите на клиентите и признаването на приходите не са чисти, всяка стъпка по-горе става по-трудна — а щатският одит се превръща в скъпоструващо ровене в експорти от Stripe и стари договори.

Beancount.io предлага текстово счетоводство с контрол на версиите, което ви осигурява пълен и подлежащ на одит запис на всяка трансакция, клиент и фактура — точно това, от което се нуждаете, когато щатската данъчна служба поиска история на трансакциите за пет години назад. Без „черни кутии“, без зависимост от конкретен доставчик и с проследяване на всяка промяна в Git. Започнете безплатно и изградете финансовата основа, на която ще се опират вашата данъчна програма (и вашият бъдещ купувач).