SaaS Sales Tax Nexus Rules for US-Based Subscription Products

US sales tax on SaaS runs on two tests: nexus and taxability. You need both before you owe a state a dime. Mix that up and you'll do one of two dumb things: register in a state that doesn't tax software at all, or ignore a state that's been taxing SaaS since the Obama years because someone on your team once said "software's a service, services aren't taxed" and everyone nodded along like that settled it. That line is wrong more often than it's right, and it's wrong in a different way in every state, because there's no federal rulebook defining what software even is. Each state writes its own definition, argues with itself about it, then changes its mind every few years. As of 2025 there are over 13,000 taxing jurisdictions in the US, and trying to track that from memory, or from a spreadsheet your old ops lead built in 2019, is how founders end up holding a letter from a department of revenue wondering what they did wrong.

What nexus actually means and the two types that affect SaaS companies

Nexus is the tripwire. It's whatever connection your business has to a state that gives that state legal grounds to make you collect its tax. No nexus, no obligation, and that part's not negotiable.

Physical nexus is the old kind: an office, an employee, a contractor doing work inside a state's borders. Doesn't take much either, since one remote hire working off their kitchen table in a state you've never actively sold into can create nexus there, and nobody notices until finance runs an audit months later and asks why Nebraska is on the list. Companies used to argue that owning servers counted as physical presence too. That argument technically still stands, though it's mostly academic now since almost nobody runs their own racks.

Economic nexus is newer, and it's the one that rewired this whole area of law. Before 2018, a state couldn't force you to collect tax unless you had people or property there. Then the Supreme Court decided South Dakota v. Wayfair, and physical presence stopped being a requirement. Revenue or transaction volume alone can trigger nexus now, no office, no employee, nothing. That single ruling is why multi-state SaaS companies need an actual plan instead of a shrug. Among midsize businesses, 77% report that Wayfair made expanding across the U.S. harder, and with fifty states each drawing their own line in the sand, that number checks out.

A third, smaller trap catches people off guard: click-through nexus. Run an affiliate program with referral partners sitting in a state, and that alone can create nexus there. No revenue threshold, no employees, just a partner clicking "sign up" on your behalf.

Here's where founders trip constantly: crossing a revenue threshold in a state doesn't automatically mean you owe tax there. If that state doesn't tax SaaS at all, hitting the threshold is a non-event, like a fire alarm going off in an empty building. Nexus tells you a state can require collection, while taxability tells you whether it actually does, for your specific product. You need both pieces, and losing either one collapses the whole analysis.

How economic nexus thresholds work and where they currently stand

Most states trigger economic nexus one of two ways: a revenue ceiling (commonly in the six-figure range), a transaction count, or both stacked together. Cross either one and you're supposed to register.

Here's where it gets annoying if you run a high-volume, low-price product. As of July 2025, 15 states dropped the separate transaction-count threshold entirely, and that matters more than it sounds like it should. Picture a $9-a-month tool with fifteen thousand subscribers scattered across the country. Under the old rules, that company could trip a transaction-count threshold in some random state well before it ever hit the revenue floor, purely because it had a lot of small customers paying tiny amounts. In states that killed the count-based trigger, that risk is gone. Revenue only, now.

New York does the opposite of everyone else, seemingly on principle. It requires both a revenue threshold and a transaction count before nexus kicks in, so crossing one alone does nothing. It's a small wrinkle, but it's exactly the kind of detail that trips up a founder who built their compliance checklist off Texas's rules and assumed the rest of the country worked the same way.

None of this is a once-a-year, check-the-box job either. Thresholds get measured on a rolling basis, and you can cross one in June just as easily as December. Once you're over the line in a state, you're supposed to register before the next customer there pays you, not three months later when your accountant flags it during tax season.

The taxability map: which states tax SaaS and on what logic

By 2026, SaaS is taxable in some form in 26 states. The rest either exempt it outright or haven't legislated the question, which in tax law usually means "ask again in eighteen months." States generally reach SaaS through one of three doors.

Some states tax it as tangible personal property, treating remote software access like a transfer of goods no matter how it's delivered. New York, Texas, and Massachusetts fall here. New York charges 4% at the state level, and once local additions stack on top, New York City lands at 8.875% combined. Massachusetts runs a flat 6.25% on prewritten software regardless of delivery method.

Other states call SaaS a digital product or service instead. Hawaii and Indiana take this route. Hawaii's General Excise Tax sits at 4.0% and touches nearly every service in the state, SaaS included, no carve-outs. Indiana taxes digital goods and SaaS broadly at 7.0%. Texas takes an odd middle path, calling SaaS a "data processing service," then only taxing 80% of the charge. That quirk trips up finance teams doing quick math at midnight before a filing deadline.

Then there's the exempt camp. California and Florida have historically let SaaS off the hook, on the logic that nothing tangible changes hands. Florida hasn't budged. California is about to, and that shift is big enough to earn its own section below.

Five states skip sales tax entirely: Alaska, Delaware, Montana, New Hampshire, and Oregon. Small asterisk on Alaska though, since some of its localities impose their own local taxes without a state-level sales tax behind them.

One distinction worth knowing cold: many taxable states draw a line between custom software (built for one specific customer) and prewritten, off-the-shelf software. Custom often stays exempt while the standardized product gets taxed, and that line can shape product decisions, not just how your accountant books revenue.

B2B versus B2C matters more every year, too. Iowa exempts SaaS sold to businesses but taxes it when sold to consumers, so you need to know your buyer type transaction by transaction, not just market by market. Connecticut goes further and runs two rates for the identical product: 6.35% for personal use, 1% for business use. Same software, same seller, wildly different math depending on who's paying.

A few other 2026 rates worth having on hand: Arizona runs a 5.6% Transaction Privilege Tax, Louisiana moved to 5.0% after a January 2025 increase, Indiana broadly taxes SaaS at 7.0%, Nebraska is at 5.5%, and Iowa's consumer rate is 6.0%.

California's SB 122 and what it means for SaaS founders starting January 2027

Governor Newsom signed SB 122 on June 29, 2026, effective January 1, 2027. This is the biggest change to SaaS sales tax in years, and if you sell into California, it deserves your attention now, not in December 2026 when you're scrambling.

The law applies sales and use tax to prewritten software no matter how it's delivered, which pulls SaaS in directly. Custom software built to one customer's spec stays exempt, consistent with most other states. Where exactly the line falls between "custom" and "prewritten" is still an open question, and the California Department of Tax and Fee Administration hasn't clarified it as of this writing.

The rate is California's 7.25% state tax plus whatever local district tax applies, and that local piece varies by the buyer's address. Your effective rate shifts customer to customer, sometimes block to block.

Scale matters here in a way it doesn't for most state-level changes. California is the fifth-largest economy in the world and home to one of the largest concentrations of SaaS buyers in the country. Estimates put the new revenue at roughly $900 million for the general fund and $1.1 billion in local sales tax, landing around $2 billion combined. That's not a rounding error for the state, and it won't be one for your finance team either if California is a meaningful chunk of your revenue.

Sourcing runs off the purchaser's known address in California, so the accuracy of your customer location data now directly determines whether you're taxing correctly and how much. There's a narrow carve-out: once a seller's gross receipts from remotely accessed digital products exceed $5 million in aggregate for the calendar year, the obligation to collect tax on those sales gets relieved. That mostly matters for huge enterprise contracts, not your average subscription base.

B2B exemptions still exist under the new law, but only with paperwork behind them. Resale buyers and qualifying exempt entities won't owe tax, provided you're holding a valid California exemption or resale certificate on file. No certificate means no exemption, no matter who the buyer says they are over email.

A few things SB 122 leaves unresolved: how bundled transactions with mixed taxable and exempt pieces get handled, what happens to multi-year contracts straddling the January 1, 2027 line, and transition guidance generally. CDTFA guidance is expected, just not published yet. If you've got meaningful California revenue, register with CDTFA, update your billing system to apply address-based rates correctly, and start collecting exemption certificates from qualifying customers before the deadline hits.

Where a sale is taxed: sourcing rules and the billing address problem

Sourcing decides whose tax rules apply to a given sale. Most states use destination-based sourcing for SaaS, meaning tax follows the customer's location, not yours. Simple enough, on paper.

The catch is SaaS has no physical delivery point. There's no truck, no warehouse, no shipping label to point at and say "that's where it landed." So the billing address becomes the default stand-in for "where the sale happened," and that works fine right up until it doesn't.

Enterprise accounts break the model fast. A single subscription used by employees across five different states raises a real question nobody's fully answered: whose state actually gets the tax? States don't agree. Some look at the billing address, some the business address, some actual user location, and a handful require you to allocate the sale proportionally across every state where the product gets used. Seat-based plans sold to multi-office companies sit right in the middle of that mess.

California's SB 122 leans hard on this same weak point. Its customer-address method only works as well as the address data behind it, so the accuracy of your billing system determines whether you're calculating the right rate or just guessing confidently.

Local taxes stack another layer on top. Chicago charges a 9% Personal Property Lease Transaction Tax on SaaS and cloud services used by customers inside city limits, entirely separate from Illinois's state tax, and it's triggered purely by where the customer sits.

None of this works without clean data. Sourcing accuracy is as much a database problem as a tax problem, and one missing or outdated customer address doesn't just cause a single bad transaction. It seeds a pattern of misclassification that compounds every billing cycle after it, until someone finally notices.

How pricing structure — especially usage-based billing — changes the compliance picture

Flat-rate and seat-based subscriptions are the easy case. Revenue by state stays fairly predictable, which makes it simple to watch against nexus thresholds month over month without much drama.

Usage-based billing throws that predictability out the window. One customer's usage spike, a sudden burst of API calls or storage consumption, can push your revenue in a state over the nexus threshold in a single month, with zero warning. Checking your state-by-state numbers once a quarter under this pricing model isn't a compliance program; it just looks like one.

Bundling adds its own wrinkle. Package SaaS access with professional services, support, or data exports under one price, and some states will tax the entire bundle the moment even one piece inside it is taxable on its own. Split billing might dodge that outcome; combined billing might not, and it depends entirely on the state, with no shortcut around checking.

Founders sometimes treat a pricing model change as a one-time update: flip the switch, tweak the invoice template, move on. That's the wrong mental model. Switching from seat-based to consumption pricing resets your whole compliance baseline and turns nexus monitoring into an ongoing job instead of something you clear once. Anytime you change how you charge, map that change against taxability rules again, not just once at launch.

The practical compliance sequence: registration, collection, filing, and when to use a Merchant of Record

Once nexus and taxability both exist in a state, the sequence is straightforward, even when the execution isn't.

Register with the state's tax authority before your next customer there pays you a dollar. Set up billing to apply the correct rate transaction by transaction, using the customer's address as the sourcing signal. Collect exemption or resale certificates from qualifying B2B customers, which matters especially in states like Iowa, Connecticut, or California under SB 122, where buyer type changes the entire tax outcome. Then file returns on whatever schedule the state assigns, and expect that schedule to get more frequent as your revenue there grows, because it will.

There's no shortcut through registration. Every state with an obligation needs its own separate filing; there's no federal one-stop form covering all fifty at once, no matter how much you wish there were.

Monitoring can't stop once you've registered somewhere, either. Thresholds keep moving as revenue grows, and states keep rewriting their own rules, like the 15 states that recently dropped their transaction-count triggers without much warning. What was true about your obligations last year might just not be true this year.

For founders who don't want to build and staff this whole operation in-house, a Merchant of Record setup is worth understanding. An MoR becomes the legal seller of record for the transaction, which shifts sales tax collection, remittance, and filing off your company and onto them. Your customer still buys your product the same way, nothing changes on their end, but the MoR is the one figuring out nexus, applying the right rate, and filing in each state behind the scenes. It fits well for early-stage or solo founders without the time to run multi-state compliance by hand. Tiun works this way, operating as a Merchant of Record and handling US tax compliance alongside authentication, payments, and customer data, so founders aren't stitching together five separate vendors to solve five pieces of the same problem.

If you'd rather keep billing in-house but still need accurate rate calculation across more than 13,000 jurisdictions, automated tax software sits in the middle ground between doing it all yourself and handing the whole thing off.

Either way, the SB 122 deadline on January 1, 2027 is a good excuse to check your compliance posture now, not just for California, but everywhere you already have nexus, or are close enough that you should be watching.