SaaS Multi-State Tax: Income Tax Nexus, Apportionment, and Where You Owe

A SaaS company with a handful of remote employees and customers scattered across the country can owe income tax in more states than it has ever filed in, and the trigger usually isn’t a new office. It’s crossing a revenue threshold in a state that has adopted economic nexus for income tax, something that now applies in a large majority of states regardless of whether the company has a single employee, contractor, or piece of equipment there.

What creates income tax nexus for a SaaS company?

Nexus is the connection to a state that gives it the constitutional authority to tax a company’s income, and it comes in two forms. Physical presence nexus is the traditional trigger: an office, employees (including a single remote employee working from home in that state), independent contractors performing services there, or equipment such as servers physically located in the state. Economic nexus is the newer and, for most SaaS companies, more consequential trigger: a state asserting nexus based purely on the volume of business conducted with in-state customers, with no physical presence required at all.

Following the South Dakota v. Wayfair decision and the Multistate Tax Commission’s factor-presence model statute, most states now apply a bright-line economic nexus standard for income tax, commonly built around a receipts threshold in the range of $500,000 of in-state sales (the exact figure and its indexing vary by state and change periodically, so the current threshold needs to be checked state by state before filing). A SaaS company that has never sent an employee or a piece of hardware into a state can still owe income tax there once its customer revenue from that state clears the threshold.

Are SaaS sales sourced by market or cost of performance?

Once nexus exists, the next question is how much of the company’s income gets apportioned to that state, and that starts with sourcing the receipts themselves. There are two methods, and the choice matters a great deal for a company whose engineering team sits in one or two states while its customers are everywhere.

• Cost-of-performance (COP) sourcing assigns service receipts to the state where the greater proportion of the income-producing activity occurred, historically meaning where the people doing the work were located. Under a strict COP rule, a SaaS company with all its engineers in one state could end up sourcing all of its receipts to that single state, regardless of where its customers are.
• Market-based sourcing assigns service receipts to the state where the customer received the benefit of the service, which for SaaS generally means the customer’s location or the location where the software is used.

The majority of states, more than 30 at this point, have moved to market-based sourcing specifically because COP produced results that didn’t track economic reality for service and software businesses: a national customer base generating no apportioned income in most of the states where the actual revenue was earned. The states that still use COP are a shrinking minority, but a company that has customers concentrated in a COP state and an engineering team in a different state needs to model both rules, because the two methods can point to a materially different apportionment result for the same set of facts.

How does single sales factor apportionment work?

Apportionment determines what percentage of a multi-state company’s total income gets taxed by each state, and the trend on that front has moved in parallel with the sourcing trend. States historically apportioned income using a three-factor formula (property, payroll, and sales, often weighted equally or with sales weighted more heavily), but the majority of states have since moved to a single sales factor formula: only the sales factor matters, and property and payroll located in the state have no bearing on the apportionment percentage.

The policy logic behind the shift was to stop penalizing companies for having in-state property and payroll (which discouraged investment and hiring), and it has a direct effect on SaaS: a company with all of its engineers and offices in one state and customers everywhere else apportions income based purely on where its sales are sourced, using whichever sourcing method that state applies.

Apportionment concept	Older approach	Majority current approach
Nexus for income tax	Physical presence required	Economic nexus, often a receipts threshold near $500,000
Sourcing of service/SaaS receipts	Cost of performance (where the work happened)	Market-based sourcing (where the customer is)
Apportionment formula	Three-factor (property, payroll, sales)	Single sales factor
Throwback/throwout rules	Common	A shrinking minority of states still apply either rule

Throwback and throwout rules are the remaining wrinkle in a small number of states. A throwback rule assigns a sale into the origin state’s sales factor numerator if the destination state lacks jurisdiction to tax the seller; a throwout rule instead removes that sale from the denominator entirely. Both rules matter less than they used to now that economic nexus reaches so broadly, since a sale that used to fall outside any state’s taxing jurisdiction increasingly falls inside one.

Does P.L. 86-272 protect SaaS from state income tax?

P.L. 86-272, a federal statute from 1959, protects a company from a state’s income tax (not sales tax) if its only in-state activity is the solicitation of orders for sales of tangible personal property, with the orders approved and shipped from outside the state. The statute has never covered services, licenses, or software, because SaaS revenue isn’t a sale of tangible personal property to begin with.

The reason this comes up constantly in SaaS planning is that some companies assumed general “sales” protection applied more broadly than it does, and the Multistate Tax Commission removed any ambiguity in its 2021 revised statement on internet activities: presenting static information online, or using cookies solely to facilitate the solicitation of tangible goods, can stay protected, but providing SaaS itself, offering post-sale customer support through chat or email, or using cookies to gather customer data for purposes beyond solicitation, all exceed the statute’s protection. Several states have adopted this interpretation administratively, and the underlying statutory reading was never really in dispute for a company whose product is the software rather than a good delivered alongside it. A SaaS company should not plan around P.L. 86-272 protection at all; it simply doesn’t reach the product.

What’s the practical process for figuring out where you owe?

Getting compliant is a four-step process, and skipping the first step is the most common mistake.

1. Run a nexus study. Pull customer revenue by state for the last several years and compare it against each state’s current economic nexus threshold, and separately map out physical presence: every remote employee’s home state, every contractor’s location, and any equipment or inventory anywhere.
2. Register in each state where nexus exists. This typically means registering with the state’s Department of Revenue for income tax and, separately, with the Secretary of State to do business in the state.
3. Apportion income using each state’s specific rules. Sourcing method (market-based versus cost of performance) and apportionment formula (single sales factor versus another weighting) both vary by state, so a spreadsheet built for one state’s rules generally cannot be copy-pasted for the next.
4. File returns going forward, and address any past-due years using the process below rather than simply starting fresh and hoping the earlier years go unnoticed.

What if you’ve been out of compliance for years?

Most states run a voluntary disclosure agreement (VDA) program specifically for this situation: a company that comes forward on its own, before being contacted by the state, in exchange for a limited look-back period (commonly three to four years for income tax rather than the full period of exposure) and, in most states, a waiver of penalties. Interest on the unpaid tax is usually still due even under a VDA. The catch is that the offer only exists before the state has already identified the company; a company that waits for a notice loses access to the program and faces the full exposure period plus penalties. A nexus study that turns up several years of unfiled exposure in multiple states is exactly the situation a VDA process was built for, and it’s worth running before, not after, a state’s data-matching program finds the company on its own.

What should I do next?

If your SaaS company has customers in states where you’ve never registered, and your revenue in any of those states is approaching or past the $500,000 range, that’s worth a nexus study before the next filing season, not after a notice shows up.

• SaaS bookkeeping, chart of accounts, and MRR tracking, the revenue-by-state data a nexus study depends on
• SaaS startup costs and burn rate before revenue, for companies weighing multi-state registration costs against a still-thin cash position
• SaaS stock options and 409A valuations, because remote employees exercising options can create withholding obligations in states beyond where the company itself has income tax nexus
• Construction multi-state tax nexus, withholding, and sales tax, a parallel walkthrough of nexus mechanics for a business model built on physical rather than economic presence

This guide is general information, not tax advice for your specific situation. Which points apply, and how, depends on your facts.