Tax on International SaaS Transactions: 2 Things to Remember

 

 

 

 

 

The taxation of international SaaS transactions is complicated and not all worked out, but I thought I would summarize a few key points from a recent Grant Thornton article on the subject.

Here are a few key things to think about:

Permanent Establishment – this is accounting speak for do you have enough of a presence in a country for the country’s tax authorities to tax your SaaS offering.

The mains factors are:

• Is there a fixed place of business in the country? [BTW, owning hardware in country = fixed place of business]
• Is there a dependent agent in the country (‘dependent agent’ is not the same as ‘independent agent/contractors’)?

If there is a PE, then

• You will be taxed by the local authorities on the income generated from that location.
• The transfer pricing rules apply (we can figure this one out another day, but here is some info on it from Wikipedia).

Sales and VAT Taxes  – these taxes often apply, even if you don’t have a PE in a country.

Few things.

• SaaS is considered taxable for VAT purposes in the European Union (in the country where your customer is located).
• Your customer should pay this, so make sure in your contract that your clarify that you customer is responsible for any sales, use, VAT and other similar taxes.

If you look at the history, most tax regimes were originally setup to tax tangible goods (i.e. not software or software services) so trying to fit SaaS in does not work that well (at least not right now). Ok this is messy and complex, so don’t be surprised if you are a little confused by all of this. Even though it helps to learn the basics, I highly recommend you talk to your tax accountant or attorney about these issues, as this is beyond my pay grade.

Resources: 

A Link to the Grant Thornton Article

Great Tax Article on SaaS Taxation Issues (even though it is from 2008)

 

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law. 

Sales Tax on SAAS. What I Learned, and You Should Know!

I was presenting at the OpenView CFO Forum in Boston (on SAAS contracts) last week to their portfolio companies, and at the conference I learned quite a lot from the Grant Thornton tax presenters about the current state of confusion of the applicability of sales tax to SAAS transactions. GT wrote a short article on it, so I thought it was worth sharing on my blog, as their article was on point and timely (plus I thought I would provide my 2 cents worth).

My takeaways from the article are:

1) Current State: Most states have not specifically addressed taxation of software-as-a-service transactions, and so you have to shoehorn it into their existing rules (i.e. it is messy and a grey area).  You understand, as your hosting company is in x state, you are in y state and your customer is in z state.

2) Form of Agreement Matters: The form of agreement you use matters (is it a ‘software license agreement,’ ‘subscription services agreement,’  ’professional services agreement,’ or something in between), but of course so does the substance of the services you are providing.

3) Proposed Federal Legislation: There is no answer yet, but there is a bill going through Congress which could help provide some clarity and predictability on taxation of SAAS. Here is the latest on the bill (at least on one website).

Take a read of the short Grant Thornton article, as I think they nailed the current state of things–even if there is no clear guidance right now–and is a must read for your finance leader.

Disclaimer: This is provided for educational and informational purposes only, and is not legal advice. Hire an attorney for legal advice, as they should consider the pertinent facts and applicable law before providing any advice.

SAAS Revenue Recognition (boy, these rules are different)

While I know a little bit about SAAS accounting issues, there are people that know a lot more about it. I ran into Jay Howell (from BDO Seidman) at a recent SAAS seminar I presented at (regarding SAAS contracts) in Washington DC (he is the technical guru on SAAS issues at BDO), and I thought I would share some of his presentations and materials (really good stuff for you SAAS accounting/finance types). Any SAAS business should have the right person look at this, especially as these new rules took effect on June 15, 2010.

Before I give you the links, I thought I would share a few points that resonated with me.

1) SAAS Accounting Rules are Different. Yes, these rules are very different (like comparing an apple to an orange) from the typical rules regarding software accounting and revenue recognition (different rules and different interpretations). Don't think of them as similar at all. (see page 6 of his presentation)

2) Less VSOE Proof Requirements. The good news is the SAAS accounting rules are less stringent on the requirements regarding VSOE, so this creates some additional flexibility for the SAAS model. (see page 8 of his presentation) Here is a definition of VSOE if you have not heard of it before.  Note to self: figure out how to use this flexibility.

3) More Flexibility in Sharing Your Roadmap with SAAS Customers. Typically if a software licensing company commits or says too much about their roadmap, then the license revenue will be deferred and cannot be recognized upfront. Well, in the SAAS accounting world there is more flexibility here. Note to self: use this as an advantage when competing with a traditional software licensing competitor. (see page 31 of his presentation).

Ok, here are the links.

Long Version: Jay's 45 Page Presentation (pretty technical if you ask me, so give this to your accounting/finance person to review).

Short Version (for the non-accounting/finance types; but willing to read a few pages on this technical issue).

Resources:

Interesting Post by Netsuite CFO

Another One of My SAAS Revenue Recognition Blog Posts.

Disclaimer: This is for informational and educational purposes, and no legal advice is provided. Consult your attorney for legal advice.

3 PRACTICAL Things to Remember About Collecting Sales Tax on Software

Ok this is a complex issue, but let me see if I can put together a few practical things to remember (at least from the perspective of a software attorney).

1) This is a State Law Issue. You really have to look at the rules on a state-by-state basis.

• Some states don't tax software and others do (example, NY);
• Some states only tax off-the-shelf software but not custom software (example, NC); and
• Some states tax the software if you send a CD/media but not if it is downloaded from the Internet (example, CA).

Takeaway: Figure out where your customers are, and then look at that state's sales and use tax law. I wish there was a website with a chart of which states require you to collect sales tax for software license sales, but I have not found it yet… if it even exists.

2) Don't Kick the Can Down the Road. I have seen too many software companies say I will deal with this down the road, but then find out it is really difficult and expensive to fix later. Think about it this way, you are supposed to collect and remit the sales tax to the state taxing authority, but if you don't you are still liable for the sales tax. It is really difficult and kinda of embarrassing, to call up your customer after the fact and ask them to reimburse you for sales tax on a transaction from years ago that you forgot to collect. If you don't get the sales tax money from them, you will still likely owe that tax.  By the way,this will come up during any investment or sale of your company. So the real risk is (a) you can't collect all the money you owe the taxing authority, and (b) you still owe that amount plus interest and penalties (not a great position to be in).

3) Get Reseller (Exemption) Certificates. You don't have to collect and remit any sales tax from companies that are reselling your software, however, get a resale certificate from them. The taxing authorities probably will ask for these certificates, and if you don't have them then you may be paying some tax you shouldn't owe. What needs to be in a resale certificate?  Here is one example.

So, while this is very complex and needs to analyzed on a state by state, and distribution basis, these are 3 practical things to remember.

Here is a lot more detailed information. Sales and Use Taxation of Internet Sales: Evolving Case Law.

Disclaimer: This is for informational and educational purposes, and no legal advice is provided. Consult your attorney for legal advice.

5 Most Important Software Agreement and SAAS Agreement Revenue Recognition Issues.

From the perspective of a software copyright attorney, here are the 5 most important revenue recognition issues (based on my experience), for Software Agreements and SAAS Agreements.

Acceptance. Make sure there is express language in the license agreement or order that states that the software is 'accepted' on the order date. I can bore you with all of the reasons why, but I would simply add this one to your end user license agreement or other type of end user software agreement [in general this is more of a software licensing issue for business customers, than a licensing issue to consumers or a SAAS issue].

Warranties with Refund Rights. This is a pretty thorny issue, but in general, other than a standard limited duration performance warranty that the software will perform in material accordance with its documentation and an infringement indemnity warranty/remedy, any additional warranty with refund rights could create a real revenue recognition risk.

Future Deliverables. If you think about it, this should be an easy one. The customer is buying the license for the software (as it currently exists), so there should not be any commitment regarding future enhancements (other than standard maintenance/support) in the contract or outside the contract.

Signed Agreement. While this should be a no-brainer too, having a signed agreement (that means by BOTH parties) is critical to a final deal. While most people focus on getting the deal done, it is really not done until the agreement is signed (more on this topic: When is a Deal Done). By the way, enforceable electronic or click contracts should be fine.

Fee is Clear and Collectable. The license agreement and order should be clear about what the customer will receive and what they will pay for. This seems pretty basic to me, but it should not be overlooked with vague descriptions of what will be provided, or unclear and indefinite payment/fee terms.

When working with my software company clients I try to remind them of these basic rules (at least a software copyright attorney's take on them).

More Details: Here is some reference material on this topic: PWC Material