Skip to main content

Cloud Computing, As a Service, and Taxes


In the past months a number of articles were published about Cloud Computing and taxes.  As a techie, choosing a software vendor on the basis of taxes may not be something considered.  But, depending on the jurisdiction, software purchases can be charged sales taxes, service taxes, or value added taxes.  While one might think ‘rented software’ isn’t a purchase and can’t be charged a sales tax, in some places it may be considered a capital acquisition (and taxes as a sale) while in others it could be charged a valued added tax (which taxes services as well as sales in European countries and Israel) or might be subject to various business taxes (such as a franchise tax in Texas where every company’s data on the Cloud is considered a local franchise and taxes as such.)

First an important definition of terms, because almost EVERY “Cloud Computing will be Taxed” article I read got it absolutely WRONG…

Cloud Computing – renting computing resources from a remote vendor on the basis of computing units rather than physical equipment.  For example, I need web serving ability that can handle a site taking 100,000 visits an hour and storage for 5,000 high resolution photos.  I do not rent servers, computers, or hard disks, I rent “capacity” and often pay for capacity x price-per-capacity-unit per day of use.

When using Cloud Computing resources, I do not know where the resources I’m using are or what physical equipment is involved.  I just need some “capacity” to “run my stuff”.

Software / Platform / Integration / Infrastructure AS A Service – renting use of particular software capabilities with the software operating at the remote vendor.  For example, I need CRM (Customer Resource Management) functions for my business, so I decide to use Salesforce.com which provides me a series of software-package abilities that I access remotely running somewhere on their servers (or in their Cloud).  I do not rent servers and install their software, I rent “software capacity” measured in software usage units (per day / month / or year), such as number of users from my office + number of customer records I store in their software x price-per-software-unit x amount of time used.

Cloud Computing is something IT people might talk about and use, particularly infrastructure people.  …As a Service is something the business people might talk about, such as “should we buy SAP CRM or use Salesforce.com Software as a Service”? 

As states and countries are becoming desperate for taxes, all kinds of weird tax schemes are being extended to cover data centers and software services.

The whole point of Cloud Computing and Software (etc.) as a Service is that the user (the company using the services) do not need to worry about where the supporting equipment is, what it is, is it secure / backed up / managed / etc.  All the physical operational details are managed by the Cloud or As a Service vendor.

Even further, the vendors themselves are expected to managed and balance their physical capacity, so from where your service is being provided, upon what your service is running and where your data is located may change as the vendor rebalances their customer load.

However, if we factor taxes into the picture it’s possible using software in a location or having your data in a location could subject you to local taxes.  Which means these questions suddenly apply (which are the opposite of the point and goals of Cloud Computing and As a Service)…

  • In what state / country / jurisdiction is the service user (company) located?
  • In what state / country / jurisdiction is the service provider located?

  • When companies are multi-state and multi-national, those questions can be even more complicated.

  • In what state / country / jurisdiction is the computing power located (where’s it running, or where’s the data center it’s running within)?
  • In what state / country / jurisdiction is the data storage located?

  • You can’t just ask “where’s the server”, as the server may be virtualized or relocated depending on capacity requirements at any given time.  With current Cloud Computing technology, it’s probably staying within 1 physical data center though.

  • Does the service provider have a physical location in the state / country / jurisdiction where the service user is located?
  • (This one’s extra complicated.)  Is the service user using the provided service for their own business or reselling the provided service in some way?  (As an example, photo hosting site SmugMug uses Amazon S3 cloud storage service to store people’s photos.)
  • So now when considering Cloud or As a Service, one must also consider the tax implications in the ‘buyer’s’ jurisdiction, the ‘seller’s’ jurisdiction, the jurisdiction of the data center providing the computing power and the jurisdiction of the data center providing storage capacity (if different from the computing power).

    As noted above, Texas (somewhat accidentally) tries to charge a business franchise tax if Texas based data centers are providing your Cloud or As a Service services (the assumption being your computing or data in their state is a physical presence in their state – which is why Cloud vendors all left Texas).

    Similarly California recently tried to tax Amazon.com by stating local people in your affiliate program qualifies as a local office (to which Amazon responded by cancelling their affiliate program for anyone with a California address).

    To date the Cloud vendors are solving the problem by avoiding jurisdictions where such taxes might have impact.  But in major deals it’s appropriate to involve your lawyers and accountants to verify contract and local law details that may apply.

    Much internet growth was fueled by the opportunity to avoid brick-and-mortar taxes.  Let’s hope politicians don’t overly tax the Cloud market before it has a chance to develop it’s advantages and provide a business base worth taxing.

    Popular posts from this blog

    Integration Spaghetti™

      I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th

    Solving Integration Chaos - Past Approaches

    A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology

    From Spaghetti Code to Spaghetti Connections

    Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider