Is there going to be Sales Tax on Open Source software?

Today, in the Washington State legislature, the House and the Senate are reconciling their two different bills to balance the State budget. Both involve significant tax changes, and there are different ramifications for software depending on which goes through.

The Senate bill basically increases the Business and Occupation (B&O) tax on services by 33% and increases the state-wide sales tax. The House bill changes the classification for custom software development to make it a retail sale instead of services.

For the past week, this topic has been hotly discussed on the Seattle Tech Startup list, with a lot of the conversation assuming the House was proposing some entirely new excise tax on software, instead of just making it retail. While that's not the case, the Washington Technology Industry Association (WTIA) came out last week strongly against the proposal to make it taxable.

I'm not convinced that it's such a bad thing to change the taxable status -- but there is a really big problem with the way the House bill is written.

Why Retail Sales Tax isn't so bad

Ok. In general, I hate sales tax. But the thing is, I hate B&O tax more. Much, much more. Sales tax is a tax on spending, and putting a tax on spending will certainly slow it a bit. Sales tax would increase the cost of doing any custom software project by somewhere around 10%, for customers located in Washington, and it would mean I can't deliver quite as much value for the dollars spent by my customers -- since a chunk is going to the State.

However, the B&O tax is worse. It's a tax on my gross revenue -- a tax on every dollar I collect, regardless of whether I'm making a profit or not. Right now it's 1.5% of every dollar I make. And while that may not seem like much -- it's a good deal smaller than the ~10% retail tax -- there's an important difference: Only the end customer pays a retail sales tax. Every single supplier has to pay the B&O tax. This means there's a substantial bias against small businesses working together to deliver a product, compared to a single large company that encompasses an entire supply chain under one organization.

As a small business/startup bigot, I hate any policies/legislation that favor big companies over small.

The effect of location

In Ken Myer's "Innovation Tax" editorial, he points to a new retail tax on custom software as being an economic development problem, driving software providers out of state, if not offshore.

I come to the opposite conclusion. One huge difference between the B&O tax and a retail tax is which party's location matters.

With the B&O tax, the question is, where is the service provider located? If it's in Washington, the service provider gets that 1.5% (or 2%) of their revenue skimmed off the top, regardless of where the customer is. I can avoid this tax by taking my business and moving out of state, but short of that, I'm obligated to pay. And my out of state competitors don't have to pay this tax for serving Washington customers. So I am now at a disadvantage compared to out of state competitors.

With a retail sales tax, what matters is where the customer is located. If a Washington business hires a company for custom development, they would be obligated to pay sales tax regardless of the location of the vendor. If the vendor has a Washington presence, the vendor would collect the tax and remit it to the state. With an out-of-state vendor, the customer would be obligated to pay use tax.

Myer seems to think that customers will skip paying use tax and prefer out-of-state vendors. But I've been audited for use tax, as have half the other business owners I know. And it's generally businesses that are purchasing custom software -- I can guarantee you that the Department of Revenue will make sure use tax on custom software gets paid.

Furthermore, my tax burden for out-of-state customers actually goes down if my services get classified as retail--I don't have to collect any sales tax. There is still a B&O tax on retail services (0.471% right now) but it's substantially lower than that for services--and I believe I don't have to pay that at all for out of state customers.

So my tax burden actually goes down under retail sales, and I'm better able to compete with out-of-state vendors--there's a slight leveling of the playing field.

The Administrative Burden

Let's face it, taxes suck. And the retail tax scheme Washington now uses, "Destination-based sales tax," makes it worse--whenever we sell something subject to retail tax to a customer in Washington state, we need to assign the revenue to a particular location, and the exact rate for each location varies. So another of Myer's arguments is about the administrative burden of managing destination-based sales tax.

But the thing is, lots of businesses have had to deal with this for the past 21 months. This scheme has been in place since July 1, 2008. Bookkeepers have learned how to manage and report these taxes. For small businesses with few customers, this isn't that hard to do. For larger businesses, there's software available--and we've helped several of our customers implement it, so we already have code to handle it.

And who's better equipped to deal with complex tax rules than custom software development shops? Surely this is less of a burden for us than all the regular online retailers without in house developers.

Slippery Slope

Another of Myer's arguments, what I think is the most ridiculous one, is about it being a slippery-slope to next tax other professional services. And the reason it's ridiculous is that the title of the article talks about innovation, but this point is about tradition. Are we innovative, or are we traditional? Surely extreme times call for extreme measures, and innovative industries are best equipped to adapt to change.

It will kill the industry! All the jobs will go away!

This viewpoint was mentioned by a few people on the STS list, suggesting that margins for software development were so thin that an extra 10% might break it completely. They point to some rather hostile acts by Microsoft that resulted in great across-the-board reductions in what they paid contractors, basically saying that add 10% to the cost, and it'll get absorbed by the service providers who don't have the margin to absorb it.

My response is to go back to the basic value proposition a custom software shop offers. Having a sales tax on their services would definitely add some friction, change the market conditions a bit. But changing the cost of doing business has zero effect on the root issue--are your services of value, or not?

One consequence of this change in market conditions is that it adds cost to contracting out labor, and does not add to the cost of employing people. So this might actually encourage companies to create regular W-2 jobs to bypass the tax, instead of outsourcing them on a 1099 (or outsourcing to India, even!) So I would argue that changing this tax classification might lead to more job opportunities, rather than less. And it would have an impact on shops that provide outsourced develpoment (like mine).

The market is constantly changing, and all sorts of factors change all the time with substantial impact on our basic business value proposition. Justifying the value of our services with an additional sales tax seems trivial, compared to things like the rise of open source software decimating the value of proprietary applications.

What's wrong with this bill

Even though I'm not opposed to having a retail sales tax on our services, there is one major, enormous, huge problem with this bill: the definition of custom software. On this point, I'm in full agreement with Myer--the bill as currently poised to pass is rife with ambiguity. Just what exactly is custom software development, and where do you draw the line between it and web development, server administration, or hosting, all of which appear to remain classified as services and not retail?

Our support contract offerings provide a great illustration of the problem.

To adjust to market conditions, we've been bundling everything we do into a single support contract, with a predictable monthly price. Under that arrangement, we include a wide range of services: consulting, training, support, custom development, marketing, Search Engine Optimization (SEO), graphic design, system administration, hosting, and more. Perhaps 10% of what we do involves actually writing code. The vast majority of what we do is configuration, consulting, and making architectural decisions.

So... do we have to unbundle our services and now keep development services separate from the rest of what we do? Where do we draw the line? If we make a change to a CSS file (to adjust the graphic design) is that custom development? If we program a rule using a web interface without opening a code editor, is that custom development?

What about our competition? If a web designer edits a CSS file, or drops in a PHP snippet found on some web site, is that custom development? Even if they're clearly not a programmer?

If I have to charge tax to implement a shopping cart, while a competitor designs a web site, why should I have to collect tax while the competitor doesn't?

And if the actual amount of software development we do under a flat-rate monthly plan varies from month to month, how do I explain to my customers why that taxable amount changes?

In short, for custom software to be classified as retail, there needs to be some clear test for what IS custom software, and how to distinguish it from a lot of other activities that look very similar but are not subject to tax.

IP as a principle for taxation

One of our clients wrote a very interesting response to identify a reasonable test. So lacking any better guidelines, I propose this be the test: If the charge is for the right to use a piece of software, it's taxable. If the charge is for labor, with no accompanying Intellectual Property (IP) rights, it's not taxable.

That's really the only practical test I can think of--are you selling the rights, some sort of license to use the software? If so, it's taxable, along with all the services involved with delivering it.

It makes sense--large corporations have been insisting on IP rights for quite some time now. If they're demanding legal protection for their IP, then it seems like that IP is what has value, and there's a legitimate basis to tax it. If you're not charging for the IP, then it's simply a set of services you're providing, assembling code into something that solves a problem for a company.

Open Source and IP

You knew I was going to get here, didn't you? Because we're an open source shop, we don't charge for IP. We actually base our business around IP that the community has built -- it's not ours to sell. We add to it, configure it, customize it, tailor it to a particular business or association -- but we don't sell it. We pass on the license terms from the original authors, and license our code under the same terms so others may benefit.

In short, we don't sell IP. We merely provide services around it.

I've written about different types of software development projects, and I do think there's a pretty clear distinction between open source development and custom development. What we do is open source development.

So if IP is the test for whether work is classified as custom software development or not, we actually remain in the Services classification, and our customers won't have to pay sales tax at all (unless they commission a proprietary application, under an exclusive license).

Internet presence as basis for taxation

If making the IP license taxable along with all associated activities is not sufficient for the legislature, it seems to me that another possible test would be whether or not the product ends up on the Internet. Of course, this approach does suggest that we're sliding right to the other end of Myer's slippery slope--all sorts of new activities would become subject to retail tax:

• Graphic/web design
• Marketing/copy writing
• System Administration
• Hosting
• SEO

And who knows what else? If you're going to single out one particular profession out of all of these activities, I can't think of another substantive test to be able to definitively draw a line between them.

And if the line is fuzzy, you're asking for shenanigans as shops classify some code changes as "SEO" or "design" instead of custom software, as well as playing favorites among overlapping shops and professions based on their titles, not what they actually do day-to-day.

Whatever you do, make it clear

I really don't have a problem with making what we do subject to retail sales tax. Don't get me wrong--it will be a pain, it will make it harder for me to sell (though I would have a great short-term marketing push to get your project going before the tax goes into effect, July 1, 2010!) and it will likely have an impact on who can afford our services. But we can adjust.

But please, Washington state legislators, if you do change custom software to be included in retail sales, provide more detail about what it is you want to tax, and don't make it single out one particular profession among a dozen related services that are not taxed.

Readers, I'm planning to take this up with the Department of Revenue if this passes--subscribe to our newsletter if you'd like to stay updated on this issue!