AI Highlights States’ Need to Clarify Cloud Service Taxability

The Tennessee Court of Appeals’ decision earlier this month in SAP America, Inc. v. Gerregano shows that state tax law’s familiar categories—license, service, hosting, infrastructure—are growing too rigid for products that are partly local, partly remote, and almost always some degree of cloud-dependent. Courts need a better way to decide when software cloud dependence becomes taxable cloud access.

SAP’s case may be a preview of the next fight—not whether software is local or remote, but how much remoteness matters. When does a server-side function merely help software operate, and when does it become the thing the customer is really buying?

At first blush, the decision looks like a familiar software tax classification dispute. SAP sold cloud-based services. Tennessee wanted business tax on the receipts, while SAP argued that at least some of what it sold wasn’t taxable under the state’s business levy.

The court split the difference, holding that software licenses remained nontaxable intangible property, while cloud hosting and cloud-based services were taxable services delivered electronically into Tennessee. The split matters—but the interesting question isn’t whether the court got SAP right on the facts. (It probably did.) The harder question involves what happens when the facts stop being so well-behaved.

States should begin adopting a software-specific safe harbor rather than treating every remote function as taxable cloud access. Software should be presumed to remain as software rather than a service offering unless the state can show a specific set of remote features is central to what the customer is buying.

SAP’s offerings were cleanly separated, which might prompt undue confidence in the case’s relevance for precedential purposes. A customer of SAP could license software, buy cloud hosting, or purchase services delivered via the cloud—each neatly delineated on separate invoices. That allowed the court to preserve familiar tax classifications.

But modern software increasingly fails to fit these categories so cleanly. Even offerings that feel largely local may depend on remote elements for authentication, updates, syncing, analytics, payment processing, storage, or customer support. And with artificial intelligence increasingly being folded into ordinary software, the days of remote processing being an exception are ending.

Remote functionality shouldn’t recharacterize software unless the state can show how the remote component does more than help the product work.

Photographer: Krisztian Bocsi/Bloomberg via Getty Images

The Tennessee court used the “true-object” test to determine the taxability of cloud-hosting. The test stipulates that when a transaction contains more than one element, courts ask what the customer was really buying and use that answer to guide taxability.

This true-object test asks courts to characterize the transaction after the components have already potentially been blended. That works well enough when the pieces are visible, like when the allegedly taxable service is separately sold, priced, and perceived by the customer.

It’s much less clear when the product is entirely integrated and the remote function is buried inside what the customer experiences as “software.” Without a threshold rule, it will become too easy for a state to argue that any meaningful remote processing changes the object of the transaction.

AI pushes this central problem into the foreground. If a customer buys a desktop tax-preparation product that runs calculations locally but sends ambiguous entries to a remote AI model for classification, is the true object still software? Probably.

But suppose the same product uses a hosted model to generate return positions, risk analyses, audit explanations, and tax planning recommendations. Is the customer now buying software or buying remote analysis delivered through a software frontend? That answer is less obvious.

Also, suppose a customer pays based on usage of the model, stores data processed by the model in the vendor’s cloud, and can’t meaningfully use the product without hosted processing that is entirely invisible to them. Calling that transaction a software license starts to feel like calling a restaurant a chair-rental business because customers sit down.

Clarifying the true-object test, not abandoning it, would be the best solution to determining this threshold. States should presume that a software transaction remains a software license when remote functionality is used only for a set list of functions—such as authentication, updates, syncing, security, or modest enhancements of the product. But the state should be allowed to rebut that presumption when the customer is really buying hosted processing, managed infrastructure, access to models, AI inference, or other platform-level functionalities.

States could easily say AI processing turns any product into a taxable service. That would be administrable, in the same way that declaring all soup to be beverages would be administrable. But it’d be just as wrong.

The better rule asks what role the remote function plays in the transaction. Is it just helping the software operate? Is it enhancing a product that still has even a modicum of independent utility?

This would be a guardrail for applying the true-object test to hybrid software. The traditional test asks what the customer is really buying, but it doesn’t say how much embedded remote functionality is enough to change the answer—because it assumed the answer wouldn’t be a matter of degree.

True object should remain the central question, but a safe harbor would supply the missing threshold and burden. Remote functionality shouldn’t recharacterize software unless the state can show how the remote component does more than help the product work. Without that guardrail, AI is about to give states a tempting shortcut to turn every software tool with a remote model feature into taxable cloud access.

The case is SAP Am., Inc. v. Gerregano, Tenn. Ct. App., No. M2024-01399-COA-R3-CV, decided 5/13/26.

Andrew Leahey is an assistant professor of law at Drexel Kline School of Law, where he teaches classes on tax, technology, and regulation. Follow him on Mastodon at @andrew@esq.social.

Read More Technically Speaking