<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: SaaS Revenue Recognition</title>
	<atom:link href="http://blogs.gartner.com/jim_holincheck/2008/12/15/saas-revenue-recognition/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gartner.com/jim_holincheck/2008/12/15/saas-revenue-recognition/</link>
	<description>A member of the Gartner Blog Network</description>
	<lastBuildDate>Tue, 06 Dec 2011 16:20:11 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Kevin Lennox</title>
		<link>http://blogs.gartner.com/jim_holincheck/2008/12/15/saas-revenue-recognition/comment-page-1/#comment-1494</link>
		<dc:creator>Kevin Lennox</dc:creator>
		<pubDate>Thu, 09 Jul 2009 21:34:42 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/jim_holincheck/2008/12/15/saas-revenue-recognition/#comment-1494</guid>
		<description>The issue of revenue recognition for SaaS vendors goes far beyond the discussion of when the clock should start on a monthly recurring pricing plan. Many SaaS vendors will have have a portfolio of services. Some lending themselves to usage and rating, some being one time and some being a simple monthly fee for value. They will also have many different ways of bundling and pricing those services which will require them to recognize the revenue in several ways.

If a SaaS vendor collects a payment up front front for a usage based service, then revenue probably needs to be recognized as the services are consumed, i.e. on a usage basis. This will require them to keep track of usage and then apply it to a spreadsheet or rating engine to determine what can be recognized 

If a SaaS vendor combines hardware, one time services such as implementation or training and monthly software usage fees but charges the customer only a monthly fee (i.e. does not charge up front for hardware or other one time services as in the classic commit to a 3 year contract and get the phone for free). How is revenue and cost recognized.

Using automated billing systems and having the ability to attach revenue recognition codes to each type of service to be sold is a start in helping to make sure you can manage the legal complexities of GaaP and revenue recognition.

Referring back to Jeffrey Mann&#039;s comments you need to be very careful about anything in your contract that allows a long term or indefinite ability for your customers to dispute the invoice for the services provided. This is typically covered by an acceptance of services clause (I am neither a lawyer or an accountant so please realize this is not legal advice) that requires a customer to agree that the services have been deemed delivered as agreed after a period of time. Typically this would be something such as with 15 days of reciept of invoice, however in an enterprise customer agreement, it could be as long as a period to envelop a quarterly audit.</description>
		<content:encoded><![CDATA[<p>The issue of revenue recognition for SaaS vendors goes far beyond the discussion of when the clock should start on a monthly recurring pricing plan. Many SaaS vendors will have have a portfolio of services. Some lending themselves to usage and rating, some being one time and some being a simple monthly fee for value. They will also have many different ways of bundling and pricing those services which will require them to recognize the revenue in several ways.</p>
<p>If a SaaS vendor collects a payment up front front for a usage based service, then revenue probably needs to be recognized as the services are consumed, i.e. on a usage basis. This will require them to keep track of usage and then apply it to a spreadsheet or rating engine to determine what can be recognized </p>
<p>If a SaaS vendor combines hardware, one time services such as implementation or training and monthly software usage fees but charges the customer only a monthly fee (i.e. does not charge up front for hardware or other one time services as in the classic commit to a 3 year contract and get the phone for free). How is revenue and cost recognized.</p>
<p>Using automated billing systems and having the ability to attach revenue recognition codes to each type of service to be sold is a start in helping to make sure you can manage the legal complexities of GaaP and revenue recognition.</p>
<p>Referring back to Jeffrey Mann&#8217;s comments you need to be very careful about anything in your contract that allows a long term or indefinite ability for your customers to dispute the invoice for the services provided. This is typically covered by an acceptance of services clause (I am neither a lawyer or an accountant so please realize this is not legal advice) that requires a customer to agree that the services have been deemed delivered as agreed after a period of time. Typically this would be something such as with 15 days of reciept of invoice, however in an enterprise customer agreement, it could be as long as a period to envelop a quarterly audit.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeffrey Mann</title>
		<link>http://blogs.gartner.com/jim_holincheck/2008/12/15/saas-revenue-recognition/comment-page-1/#comment-1048</link>
		<dc:creator>Jeffrey Mann</dc:creator>
		<pubDate>Wed, 31 Dec 2008 13:08:50 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/jim_holincheck/2008/12/15/saas-revenue-recognition/#comment-1048</guid>
		<description>Revenue recognition policies and rules have a bigger impact on the software industry than many people realize. I once worked for a vendor, and had to think deeply about how our license policies would affect our cash flow. As an analyst, I&#039;ve had to tell customers that the clauses they want to put into contracts would severely hamper the vendor&#039;s ability to do business. A clause saying that they can get their license fee back if the vendor doesn&#039;t deliver an upgrade two years later can mean that the money has to sit in the bank unused and unrecognized for two years or until they deliver on the promise. No one can run a business that way.</description>
		<content:encoded><![CDATA[<p>Revenue recognition policies and rules have a bigger impact on the software industry than many people realize. I once worked for a vendor, and had to think deeply about how our license policies would affect our cash flow. As an analyst, I&#8217;ve had to tell customers that the clauses they want to put into contracts would severely hamper the vendor&#8217;s ability to do business. A clause saying that they can get their license fee back if the vendor doesn&#8217;t deliver an upgrade two years later can mean that the money has to sit in the bank unused and unrecognized for two years or until they deliver on the promise. No one can run a business that way.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim Holincheck: SaaS Revenue Recognition</title>
		<link>http://blogs.gartner.com/jim_holincheck/2008/12/15/saas-revenue-recognition/comment-page-1/#comment-963</link>
		<dc:creator>Jim Holincheck: SaaS Revenue Recognition</dc:creator>
		<pubDate>Tue, 16 Dec 2008 17:36:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/jim_holincheck/2008/12/15/saas-revenue-recognition/#comment-963</guid>
		<description>[...] Read more&#8230;   Share: [...]</description>
		<content:encoded><![CDATA[<p>[...] Read more&#8230;   Share: [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

