SaaS Sales Tax Obligations Across US States
Understanding which of 24 states tax SaaS and how depends on your specific product and customers.

Roughly 24 to 25 states tax SaaS as of 2025. That range is not imprecision. It reflects genuine ambiguity in how you count states that tax only part of a transaction, only certain customer types, or only specific use cases. I've watched compliance teams spend weeks arguing about whether a given state belongs in the "taxable" column, and the answer is often: it depends on what you're selling and to whom.
"In some form" carries enormous operational weight. It includes states that tax SaaS at a reduced rate, states that tax consumer purchases but exempt business customers, and states that tax only the portion of the service attributable to in-state use. When someone says "about half of states tax SaaS," they're technically right. But that statistic becomes almost useless the moment you start mapping it to your actual customer base.
Five states have no statewide sales tax: Alaska, Delaware, Montana, New Hampshire, and Oregon. SaaS is untaxed at the state level in each of these by default, not because of any deliberate SaaS policy, but because there is no sales tax system to trigger. Alaska is the one to watch. Some localities there have begun imposing local taxes on SaaS transactions under a regional commission framework, so "no state tax" in Alaska no longer means zero obligation everywhere in Alaska.
The states with functioning sales tax regimes that still exempt SaaS are a separate and more confusing category. California and Florida both have robust sales tax systems and both currently exempt SaaS, not because they oppose taxing software, but because their classification logic hasn't yet pulled SaaS inside the taxable base. That can change through legislation, administrative guidance, or a court ruling. In some cases it already has, with very little warning.
The Classification Frameworks States Use to Reach Their Conclusions
Every state that taxes SaaS got there through one of three analytical frameworks. Once you understand which framework a state uses, you understand almost everything about how it will treat your product. This is the part most founders skip, and it costs them later.
The first framework treats SaaS as functionally equivalent to tangible personal property or a digital product. States using this approach reason that software is software, regardless of delivery mechanism: disc, download, or browser. New York and Washington are the primary examples. The logic is blunt. If your product does what software does, it's taxable. The delivery method is irrelevant.
The second framework classifies SaaS as a data processing service. Texas is the clearest case. The reasoning is that a computer processes data on the customer's behalf, the customer pays for the output of that process, and data processing is an enumerated taxable service under Texas law. Your product's name doesn't matter. Your marketing language doesn't matter. If the function fits the definition, the tax applies. I've seen companies try to argue themselves out of this classification in Texas and it almost never works.
The third framework requires an actual transfer of tangible personal property for a transaction to be taxable. California and Colorado use this logic. Because SaaS involves no physical transfer, and because these states haven't separately enumerated cloud-based software as a taxable service, the transaction falls outside the taxable base entirely. It's not that they've decided to exempt SaaS; it's that their existing framework has no hook to tax it.
Where a state has issued no explicit guidance and no court has weighed in, auditors often fall back on the "true object test": what did the customer primarily pay for? If the answer looks like software functionality, the transaction looks like a taxable software sale. If the answer looks like a service outcome, it escapes. The frustrating reality is that "primary purpose" is a judgment call, and two auditors in the same state reviewing similar products can reach genuinely different conclusions. I've seen it happen. It is not a hypothetical.
What Nexus Means for a SaaS Company and When the Obligation to Collect Begins
Nexus is the legal connection between a business and a state that creates the obligation to collect and remit sales tax. For SaaS companies, two types matter.
Physical nexus is the older concept. An office, a data center, employees: all of these create it. For SaaS companies specifically, a single remote employee working from their home in a state is sufficient to establish physical nexus there. This catches founders off guard constantly, particularly when hiring across multiple states without thinking through the tax footprint each new hire creates. Someone hires their third engineer, who lives in Ohio, and suddenly they have Ohio nexus. The hire and the tax obligation happen simultaneously.
Economic nexus is the post-2018 reality. The Supreme Court's decision in South Dakota v. Wayfair, Inc. established that states can require out-of-state sellers to collect tax based on sales volume alone, with no physical presence required. South Dakota's thresholds, $100,000 in annual sales or 200 transactions into the state, became the model most states adopted in the years following the ruling.
Two states set materially higher thresholds. New York requires both $500,000 in taxable sales and 100 transactions in the preceding four calendar quarters before economic nexus attaches. Texas requires more than $500,000 in total sales, taxable and nontaxable combined, over the prior twelve months.
A significant ongoing shift is reshaping the economic nexus landscape: states are eliminating the 200-transaction threshold and moving to revenue-only standards. At least 16 states, including California, Illinois, and Washington, have already made this change. Alaska eliminated its transaction threshold effective January 1, 2025. Utah followed effective July 1, 2025. Illinois removes its threshold effective January 1, 2026, and Kentucky joins effective August 1, 2026.
The practical consequence is direct. A SaaS company that previously stayed under the transaction count in a given state while its revenue climbed can now find itself over the economic nexus threshold on revenue alone. Nexus positions that were accurate when last reviewed no longer reflect current exposure. This is not a set-it-and-forget-it analysis. It requires periodic re-examination, ideally at least annually.
The States Where SaaS Is Taxable and How Each One Works

New York
New York treats prewritten software as tangible personal property regardless of delivery method. Accessed through a browser, downloaded, or shipped on physical media: all three are treated identically. There is no B2B exemption; both business and consumer purchases are taxable. The state rate is 4%; combined with local taxes the average rate reaches 8.53%.
The one explicit exemption is custom software developed to a single customer's specifications, never replicated for another customer. Standard SaaS products don't qualify, almost by definition, because the whole model is one codebase serving many customers simultaneously.
New York's sourcing rule follows the buyer. If a customer accesses software from a New York location, the transaction is taxable in New York even if the servers are elsewhere. Bundling creates additional exposure here. A single invoice combining taxable software access with non-taxable consulting or support, where the components are not clearly separated with independently defensible pricing, pulls the entire charge into the taxable base.
Texas
Texas classifies SaaS as a data processing service, a position affirmed through multiple administrative decisions and court rulings. The rate structure is unusual: 80% of the sales price is subject to tax and 20% is exempt, functioning as a built-in partial exemption. The state rate is 6.25%; local governments can add up to 2%, bringing the typical combined rate to roughly 8.25%.
When SaaS is used across multiple states, the Texas-attributable portion of use can be apportioned, reducing the Texas taxable base. This multi-state apportionment rule is one of the more nuanced and frequently underutilized provisions in Texas SaaS tax law. Companies with large enterprise customers spread across many states leave real money on the table by not working through the apportionment math.
Texas finalized amended rules on the sales and use tax treatment of data processing services in April 2025, published in the Texas Register on March 28, 2025. Companies with Texas customers should review their positions against the updated guidance specifically.
Washington
Washington treats SaaS as a taxable digital service and has already eliminated the 200-transaction threshold for economic nexus, moving to a revenue-only standard.
Hawaii
Hawaii taxes SaaS under its general excise tax framework, treating it as a taxable digital service. The general excise tax applies broadly and carries fewer exemptions than a conventional sales tax structure.
Maryland
Maryland's mid-2025 change is one of the most consequential recent shifts in the SaaS tax landscape. Effective July 1, 2025, the state expanded its taxable base to cover SaaS, technology information and data services, web hosting, and website development services. B2B transactions are now taxable at a new 3% rate. B2C transactions are taxable at the standard 6% rate. Custom software, previously exempt in Maryland, is now taxable under the revised rules.
This is the clearest recent example of how quickly an exempt jurisdiction becomes a taxing one. A single statutory change with a defined effective date. No years of administrative rulemaking. No gradual phase-in. Just a new obligation, starting on a specific date.
Connecticut
Connecticut's approach is use-dependent. SaaS used for business purposes is taxed at a reduced 1% rate; SaaS used for personal purposes is taxed at the standard rate. The distinction turns on how the software is used, not strictly on whether the customer is a business entity. That nuance matters when customers use business software for mixed purposes.
Iowa
Iowa taxes SaaS for consumer transactions and exempts it for business customers. Iowa is one of the clearer B2B exemptions in the country, but it requires documentation. The exemption is not automatic, and sellers need valid exemption certificates on file. That detail is easy to overlook when you're used to exempt states where no certificate is needed at all.
Illinois and Chicago
Illinois does not impose a statewide tax on SaaS. Chicago, however, imposes a 9% Personal Property Lease Transaction Tax on SaaS and certain cloud-based services used by customers within city limits. The obligation follows the customer's location. A company headquartered outside Illinois with customers accessing software from Chicago addresses has to assess this tax. The city-level obligation exists entirely independently of any state nexus analysis, which surprises people the first time they encounter it.
Additional Taxing States
Arizona, Indiana, Kentucky, Michigan, Minnesota, North Carolina, Ohio, Pennsylvania, South Carolina, Tennessee, Utah, West Virginia, and Wisconsin all tax SaaS in some form. Several updated or clarified their positions in 2024 and 2025. The specific mechanics, rates, and exemptions vary enough that each requires individual analysis rather than pattern-matching from a neighboring state.
The States Where SaaS Is Currently Not Taxable and Why That Can Change
California exempts SaaS because its sales tax law requires a transfer of tangible personal property for a taxable sale to occur. SaaS involves no such transfer, and California has not separately enumerated cloud-based software as a taxable service. The exemption is structural under current law. That framing matters: it's not a policy choice that protects SaaS, it's an absence of a hook.
Colorado applies comparable reasoning. Cloud-based services are non-taxable under current rules for the same foundational logic.
Florida has historically exempted SaaS from sales tax, though the state's approach to digital goods has attracted periodic legislative scrutiny. The exemption holds for now. Florida's history on digital services taxation, however, is not one of settled indifference. Legislative attention surfaces there with some regularity.
The Maryland example from the previous section is worth keeping in front of you here. A state that exempted B2B SaaS comprehensively became a taxing state through one statutory change and a defined effective date. That is the template for how these transitions happen. Compliance maps built on today's exempt-state list need ongoing monitoring, not periodic review.
The five no-sales-tax states, Alaska, Delaware, Montana, New Hampshire, and Oregon, are categorically different. The absence of SaaS taxation there is a function of having no general sales tax system. Alaska's local framework is the active exception: some localities impose tax on SaaS transactions through the regional commission structure, and as that framework matures, local obligations in Alaska will expand.
B2B Assumptions That Lead to Audit Exposure
The most pervasive misconception in SaaS sales tax is that selling to businesses means sales tax doesn't apply. I have seen this assumption made confidently by founders, by CFOs, by sales teams who set up billing structures around it. Auditors know it exists, and they know where to look for it.
The state-by-state reality directly contradicts it. New York makes no distinction between B2B and B2C: both are taxable at the same rate. Texas taxes both, at 80% of the sales price. Maryland, post-July 2025, taxes both, at different rates. Iowa taxes B2C but exempts B2B. Connecticut applies different rates based on use type rather than customer classification. "Businesses don't get taxed on SaaS" is not a general principle; it is sometimes true, state-specifically, with documentation requirements attached.
Where B2B exemptions do exist, they are not self-executing. An Iowa business customer does not automatically exempt a sale by being a business. The exemption requires a valid exemption certificate, collected from the customer before or at the time of the sale, and retained by the seller. If an audit surfaces a transaction treated as exempt and no valid certificate exists in the file, the seller, not the customer, is liable for the uncollected tax, plus interest, plus penalties.
This gap between assumption and documentation is one of the most common audit triggers I've seen for SaaS companies. The assumption is not always wrong. The failure is in treating the assumption as a substitute for the certificate.
Exemption Categories That Legitimately Reduce Tax Obligations
Several exemption categories can meaningfully reduce a SaaS company's tax obligations when handled correctly. The operative phrase is "when handled correctly."
Resale exemptions apply when a customer purchases SaaS to resell it, as a managed service provider or reseller does. These customers can provide resale certificates to purchase tax-free. The seller's obligation is to collect, validate, and retain those certificates. Accepting a certificate without confirming it is valid in the relevant state, and for the transaction type at issue, creates its own audit exposure.
Nonprofit and government exemptions are available in most taxing states, but they require the same certificate discipline. A nonprofit's tax-exempt status in one state does not confer exemption on purchases made in another. Each state has its own exemption criteria, and each customer relationship requires a certificate specific to the state in question. This is where certificate programs get messy at scale.
Custom software exemptions exist in states like New York that tax only prewritten or standardized software. Software developed exclusively for a single customer and never replicated for another customer qualifies. For most SaaS products, this exemption is structurally unavailable: the defining feature of SaaS is that the same codebase serves many customers simultaneously. For professional services firms building genuinely custom software under one-time contracts, the exemption is real and worth evaluating carefully.
Manufacturing use exemptions exist in certain states for software used directly in production processes. The criteria are narrow, but for SaaS products sold into manufacturing verticals, the qualification analysis is worth conducting.
Multi-state apportionment, most explicitly in Texas, allows the taxable base to be reduced when the same service is used in multiple states. The Texas-attributable portion of use, rather than the full contract value, becomes the basis for the tax calculation. This requires documentation of usage patterns across jurisdictions, but it produces material reductions in taxable amounts for companies with geographically distributed enterprise customers. Most companies with Texas exposure don't fully work through this calculation.
Certificate management is where operational risk concentrates. Certificates expire. Customers change their legal status, their use cases, their organizational structure. A certificate that was valid when collected is invalid when an auditor asks to see it, if the underlying facts have changed. Exemption certificate programs require ongoing maintenance to remain defensible, not a one-time collection exercise.
How Bundled Pricing and Sourcing Rules Create Unexpected Tax Exposure
Bundled Pricing
Packaging SaaS with implementation, configuration, training, onboarding, or support on a single invoice is where a surprising amount of unintended tax liability originates. When a taxable item and a non-taxable item are combined into a single undifferentiated charge, many states treat the entire amount as taxable. The logic is simple from the state's perspective: if you won't tell me what the software costs separately, I'll tax everything.
New York applies this principle clearly. A bundled charge combining software access with professional services, where the components are not separately stated with defensible, independently reasonable pricing, makes the full invoice amount taxable. Separate line items help, but they are not always sufficient; some states require that separately stated prices also reflect actual market values for each component, not an arbitrary allocation designed to minimize the taxable portion.
States diverge on whether configuration, support, and training are taxable when provided alongside SaaS. Some states tax these ancillary services as part of a software package even if the same services would be exempt when sold independently. This means a billing structure that creates no liability in one state creates significant liability in another using the identical invoice format. Uniform invoice design is a convenience that carries a concealed and compounding tax cost.
Sourcing Rules
The taxing state in a SaaS transaction is almost universally the buyer's location. Where the servers sit is irrelevant to nearly every state's sourcing analysis. What matters is where the customer uses the software.
For enterprise contracts where a single customer uses software from offices in multiple states, the sourcing question becomes genuinely complex. Some states will tax the full contract value if the customer has any in-state users; others will apportion based on the proportion of users or usage attributable to in-state locations. Texas's apportionment framework is the most developed example, but other states have begun addressing multi-state usage as enterprise SaaS contracts have grown larger and more geographically distributed.
The tax obligation follows your customers wherever they work. A company based in a no-tax state with customers in taxing states is not insulated by its own location. The obligation exists at the customer's end of the transaction, and the collection responsibility sits with the seller.


