States, eager to replenish their coffers, are doing their darndest to convert SaaS products into taxable, electronically-delivered software. Every state auditor on the hunt for a mega assessment turns to the vendor’s service agreements, searching for any hint as to how the SaaS products should be treated – as services (typically not taxable), or as software (taxable). To make this determination, auditors look at how a SaaS vendor describes itself in its SaaS agreements.
In the interest of arming contract negotiators with knowledge, the thrust of this article will highlight some key provisions auditors hone in on. We’ll focus our review on the Salesforce Main Services Agreement (the “Agreement”). Does Salesforce describe its products as a service or software? Let’s dive in and see!
How Does Salesforce Describe Itself?
The duty to pay taxes is a matter of state law, not a contractual obligation. A SaaS vendor who has nexus (e.g., a strong enough connection) with a state is required to collect any applicable taxes and pay those collected taxes over to the state, regardless of what its services agreements states. Unfortunately, the obligation to collect (or not collect) applicable taxes is not something that, under the laws of every state that levies a sales or use tax, can be contracted away. If there is an inconsistency between a state law regarding the payment of taxes and the contract, the state law will govern. At best, the tax section of the contract gives the vendor a contractual right to go after its customers for taxes it was assessed by a state on the sale of SaaS product to that customer- though whether the vendor really wants to do that is a business decision fraught with the risk of jeopardizing valuable customer relationships.
The provision of most SaaS agreements dedicated to taxes may seem the most obvious starting point, but it is the least interesting, and quite frankly least significant, of the nuggets auditors look for.
As noted, auditors are looking for how a SaaS vendor describes itself. So, for purposes of our example, how does Salesforce describe itself?
Section 5.6 of the Agreement calls on Salesforce’s customers to be responsible for paying all taxes associated with their purchase of the Salesforce product. In the preamble and continuously throughout the Agreement, Salesforce describes itself as “SFDC Services.” However, when you look at the definition section, “Service” is defined as “products and services”, which could signal that there is taxable software bundled with non-taxable services.
What About a Bundled Software and Service?
This suggestion is bolstered by two other references. First, Section 3.4 prohibits “licens[ing]” or “sublicense[ing]” Salesforce’s services. Auditors often assume that only software (not services) can be licensed. Second, Section 6.3 refers to “program code created by or for” a customer–signaling software. Throughout the Agreement, Salesforce refers to non-Salesforce applications “that interoperate with the Services.” This suggests that the Salesforce platform has a software component to its services. Where a bundle of software and services exists, unfortunately, the taxable component (software) taints the entire package, making the whole thing taxable.
New York has tried to argue that the language of Section 6.5 proves SaaS products are indeed software. It doesn’t. Section 6.5 means only that the terms on which SaaS offerings are sold to the federal government must be sold on the same terms as those offerings are sold to the general public. The state’s effort is indicative of how little auditors understand the tech industry and the danger to SaaS companies that can come from an inexperienced auditor.
Hybrid SaaS: Multi-state Taxes for Multi-state Users
Agreement terms that govern usage present both challenges and opportunities. Sections 3.2 and 3.4 of the Agreement indicate that “users” are subject to limits on their usage of the Services, described in their order form. An auditor would likely request copies of those order forms for further evaluation. While the Agreement is careful to always refer to Salesforce’s offerings as services, SaaS vendors should take care to ensure that their order forms and supporting documents use consistent terminology. To refer to the offerings as subscription services in the Agreement, but software subject to a license on the order form could undercut their protection on audit.
However, the reference to customer usage also indicates that there could be multiple users on the same subscription. If those users are based in multiple states, SaaS vendors may want to request a Multiple Points of Use Statement from their customers, providing more detail as to the states in which the users are based, and the percentage of users in each state. This allocation will allow the SaaS vendor to concentrate its potential tax obligations only in those states that treat SaaS as taxable – and only to the extent of the users in that state. Without this statement, the subscription will be sourced entirely to the headquarters state of the purchaser – and if that state taxes SaaS, the vendor (and its customers!) could be on the hook for substantially more taxes than may be necessary.
Conclusion
Taxes – and tax implications- hide in plain sight throughout SaaS agreements. Both vendors and their clients should be on the alert for the common traps for the unwary, and for the potential opportunities to minimize their tax liabilities.
