You buy a server, you pay tax once. You buy AWS capacity, you may pay over and over. Should taxes be the latest decision point in the in-house vs. cloud conversation?
Tax laws are always a few beats behind technology. Interstate telephone calls were taxed based on the billing address of the phone customer and the location at the end of some copper wire of sending and receiving equipment. Now one end of a call may be on a subway line, the other in an airplane traveling from Boston to Paris. Who gets to tax it?
The latest conundrum: Both business-to-business and business-to-consumer transactions are moving to the cloud, and some startups are putting all of their IT infrastructure in provider sites. How, in an integrated 50-state economy, are tax concepts supposed to deal with this in a way that's practical and doesn't become an unfair burden for any entity? Of course, all computing takes place on servers that are physically located somewhere. Maybe you hire a cloud provider to store company records. You may not know where those records are at any given moment. The storage vendor may not know either, because it maintains server farms in multiple states or countries.
People thinking about how to tax cloud computing generally break it down into paradigms that roughly track the standard SaaS/IaaS/PaaS model. However, that's where standardization ends.
Old-fashioned transaction taxes generally source sales to customer location. Subject to jurisdictional constraints, if you run a furniture store in North Carolina that ships products all over the country, you generally collect tax based on destination.
But in cloud computing, there is no physical thing whose destination can be tracked. So where should transactions be sourced? Three obvious possibilities: the location of the vendor, the server location and the billing address of the customer.
There are two problems with approach No. 1. First, the vendor may have facilities and staff in multiple states or countries, and it may do whatever it does to generate or complete a sale in more than one place. Second, this approach creates a strong incentive for in-state purchasers of cloud computing to buy services from vendors located outside the state.
Approach No. 2 has many adherents among state governments, but it's also flawed. It permits vendors to avoid tax by using servers located in jurisdictions that have no sales tax, like New Hampshire or Oregon. And in some cases, the vendor may not even know where the server doing a given processing function is located.
Approach No. 3 is simple and easy to audit, but it's also highly subject to manipulation. A vendor and purchaser can "conspire" to have bills sent to a state that either doesn't tax the transaction or uses a different sourcing principle.
Because of these problems, as efforts to tax cloud computing proliferate, the sourcing methodology most likely to be embraced is based on location of use of the products and services sold. There is precedent for this approach in the taxation of electronically distributed software by a number of states.
But how clear is it where SaaS or data processing or storage services are used by a multistate business? Certain kinds of enterprise-wide software are naturally considered to be used in proportion to employee head count in a state, because virtually everyone in the company uses the software. But other software with a more limited function -- CAD/CAM, sales force support or accounting support, for example -- may be used more sporadically and by a more fluid cast of employees. The same could be said of data storage and data processing services.
Some states have addressed this problem by claiming to accept any reasonable method for apportioning use of computer services by a purchaser as long as the method is consistently applied. The danger here is that the states will "chase the cloud" by applying rules that, while based on use, define the location of that use variously. Because states generally don't offer a credit for a use tax paid in another state, this could easily lead to systematic taxation of the same services in multiple states.
This kind of multiple taxation generally does not violate constitutional principles and therefore is immune from attack on those grounds. But the problem cries out for a solution that imposes uniformity across the states in the sourcing methods to be applied, or at least a common sourcing "safe harbor" that states will be forced to accept. That sort of solution requires congressional action, however, and in the fractured political environment in which we find ourselves, a congressionally imposed solution to a taxation issue could be a long time coming.
Multicloud Infrastructure & Application ManagementEnterprise cloud adoption has evolved to the point where hybrid public/private cloud designs and use of multiple providers is common. Who among us has mastered provisioning resources in different clouds; allocating the right resources to each application; assigning applications to the "best" cloud provider based on performance or reliability requirements.
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.