Research boundary
This guide is educational, not legal or tax advice. State treatment changes and fact patterns matter. Confirm the current rule and your facts with the relevant revenue authority or advisor before changing collection.
The short answer
Software as a service is not uniformly taxable or exempt in the United States. A state may analyze a subscription as remotely accessed prewritten software, data processing, a digital automated service, an information service, or a broader service bundle. The same product can receive different treatment across states.
That is why a single SaaS flag is a weak control. A stronger workflow records what the customer receives, how the product is used, where that use occurs, how charges are stated, and which authority supports the conclusion.
Start with the product, not the marketing label
Before researching a state, describe the actual offering:
- Does the customer control or direct software functionality?
- Does the product mainly store, retrieve, transform, or analyze customer data?
- Is there downloadable code, an app, an activation key, or only browser access?
- Is human professional work the primary value, or is it incidental to automated functionality?
- Are implementation, training, data entry, customization, and support separately stated?
- Does one charge bundle software with other services?
These details can change classification. Contract language and invoices should agree with the product behavior that tax and finance teams review.
Three official examples show why a national shortcut fails
New York: remote access can be taxable prewritten software
The New York Department of Taxation and Finance computer software guidance states that a license to remotely access prewritten software is subject to state and local sales tax. A 2024 New York advisory opinion concluded that charges for use of an online portal constituted taxable prewritten software, while certain optional services could receive different treatment when reasonable and separately stated.
An advisory opinion applies to its petitioner and facts, but it is still useful research evidence. It shows why remote hosting alone does not make a software charge exempt in New York.
Texas: SaaS can fall within taxable data processing
Texas defines taxable data processing broadly around entering, storing, manipulating, or retrieving customer data. The Comptroller's Taxable Services publication identifies sellers of SaaS and application service providers within the data-processing discussion. Texas also provides a statutory partial exemption for qualifying data-processing charges, so the taxable base can matter as much as the classification.
The practical lesson is not that every technology service receives identical treatment. It is that a product team must understand which functions use customer data, whether another service classification is stronger, and how the invoice presents the charge.
Washington: digital products and remote access software have their own framework
Washington's digital products guidance addresses downloaded and streamed digital goods, digital automated services, and remote access software. It explains that remote access software is prewritten software provided remotely and is generally subject to sales and use tax, while exclusions and exemptions can depend on the product and use.
Washington also changed treatment for several services effective October 1, 2025. That kind of dated change is why a taxability answer should store the authority's effective date and review date instead of living forever in a spreadsheet.
Build a fact record before assigning taxability
A useful SaaS taxability record includes:
| Fact group | Questions to preserve |
|---|---|
| Product | What functions does the customer use? Is software control transferred? |
| Delivery | Browser, app, download, API, activation code, or mixed delivery? |
| Services | Which human, training, support, or customization services are included? |
| Charges | Are distinct services reasonable and separately stated? |
| Customer | Business, consumer, reseller, exempt organization, or government? |
| Location | Where are users, billing contacts, or points of use located? |
| Authority | Which statute, regulation, bulletin, or ruling supports the result? |
| Time | When did the authority take effect, and when was it last reviewed? |
Sourcing is a separate decision
Even after classifying the product, the seller still needs a sourcing method. States can look to billing address, user location, where the software is received, or another statutory hierarchy. Enterprise subscriptions may be used by employees in several states.
Do not let a billing ZIP silently stand in for the sourcing analysis. Preserve the available location evidence, the chosen rule, and any multistate-use documentation.
A controlled SaaS tax workflow
1. **Define product families.** Group offerings only when their functions, delivery, and contract terms support the same analysis. 2. **Capture transaction facts.** Keep SKU, charge type, customer type, exemption evidence, and location inputs attached to the invoice line. 3. **Research state authority.** Prefer current revenue-department material and controlling law. Record the link, quoted proposition, effective date, and review date. 4. **Apply a deterministic rule when coverage is complete.** If required facts or authority are missing, stop or route the item for review. 5. **Review material changes.** New features, bundles, pricing, user locations, and state law can invalidate an old answer. 6. **Connect the decision downstream.** Carry the reviewed treatment into calculation, exemption, reconciliation, and filing preparation.
Questions software companies should ask now
- Can we explain what every subscription line actually delivers?
- Do our contracts and invoices separate materially different services?
- Can we identify customer use locations when the state requires them?
- Does every state conclusion have a current official source and reviewer?
- Will a product launch or packaging change trigger a tax review?
- Can finance trace collected tax back to the product rule used at transaction time?