Category Archives: revenue recognition

This Week on The Web 2009-09-20

Leave a reply

These are the discussions that happened around the web this week – maybe you already read about them, maybe you need to again.  Come join the party on twitter (follow me here and you’ll participate in the conversation live.)

I also realized that many of you might have no idea what you’re seeing below.  Sorry.  These are “tweets”, 140 maximum character messages sent via Twitter.  Within the Twitterverse individual users follow others and have followers (think of it like overlapping Venn diagram circles).  To read a tweet, you have to wade through a bit of jargon used to make the most of the 140 character limitation.  “RT” for example, is shorthand for “Re-tweet” and the @____ is the username of some other individual on Twitter.  Combined together, then, “RT @_____” means that someone else wrote a tweet that I found important and I now want to forward along to my followers.  The URL’s are then also shortened by shortening services like bit.ly to make the most of the character limitation, too.  Lastly, you might see “hash” identifiers “#______” which are ways to tag tweets of a particular flavor for easy searching later and “<” which means that I am commenting on what came before it.

Advertisement

Revenue Recognition

Leave a reply

One of the most confounding negotiation topics is Revenue Recognition (RevRec). This is partially due to ill-informed people and partially due to a lack of understanding on BOTH sides of the negotiation table. For the purposes of this post, I’m talking about the “RevRec Excuse” – when a vendor uses RevRec as a way to block a request for some contractual provision.

The American Institute for Certified Public Accountants (AICPA) releases published guidelines for accountants, auditors and other financial management folks on how to account for a variety of transactions. In 1997, they released the latest version of their RevRec guidelines for software transactions, SOP 97-2 (with a small amendment in 1999). This book is available for purchase via the AICPA. I highly recommend that negotiators who do software transactions buy a copy. It’s $17.50 well spent.

These guidelines lay out the framework for how an organization should account for software transactions, including maintenance/support, custom development, refunds, future purchases, etc. So, when a party makes reference to revenue recognition, they should be able to support the statement with a reference to a section of SOP 97-2.

Of course, this rarely happens. The buyer wants something like future versions of the current product and the seller’s response is that “no, we can’t do this because of RevRec issues.” From a negotiation perspective, this is using the “authority” tactic. (If you’ve never heard of this tactic, check out Herb Cohen’s books.) Essentially, they’re telling you that there’s a written authority/guideline/policy that prevents them from doing what you are asking… but oh, they would help you out if they could.

“OK,” I respond. “Can I please talk with your accounting director who is enforcing this guideline?”

This request is usually met with resistance, but if they want to use the RevRec excuse, we’ll need to explore it with the policy maker (which is almost never the negotiator). Once you have the accounting director on the phone, simply ask them if they follow the AICPA RevRec guidelines (you can even call it out by name: SOP 97-2, they’ll know what you’re talking about).

If the answer is yes, lead them through the guidelines to show them how your request doesn’t violate the guidelines. Or, if your a bit more bold, ask them to show you the guidelines that are preventing your request. Either way, you need to have read the guidelines to know what you’re talking about. But they’re pretty straight forward, so don’t worry too much.

In the event that the buyer does not want to read SOP 97-2, or if they simply don’t care about the vendor’s RevRec issues, the buyer always has the ability to use an alternative response to the RevRec Excuse.

“Your RevRec issues are not my problem.”

I give this response to you so you know that it might come (a gift to my vendor-readers). It truly isn’t the buyer’s problem to worry about how the vendor is going to book the revenue. Just like it’s not the vendor’s problem to figure out how the buyer makes their payments on time, so long as they do.

This doesn’t prevent the buyer from using this statement, and it doesn’t help the vendor respond, though. To respond appropriately, the vendor should have a firm grasp of the real issue. If it’s really a RevRec problem, be prepared to support it with the SOP. If it’s really a RevRec Excuse, be prepared to concede the point.

At a higher level, however, the vendor should not use RevRec as an excuse. Like our discussion of Maintenance from last week, there is a snowball effect. The more it’s used as an excuse, the less impact it will have overall. Most vendors I’ve worked with have made every effort to give me what I’m asking for – especially when they know that I’m educated about their issues (another reason to read the SOP).