This topic is another great question from a Proformative reader or webcast attendee.  As a Proformative Topic Expert, I was asked to weigh in on this on that website already, but thought I'd also provide a slightly edited version here.

This is still a newer area in revenue recognition treatment, but it's a scenario that we're seeing more frequently.  E&Y has provided some good guidance in a paper called "Revenue recognition on the sale of virtual goods" - I'd recommend that as a good resource for starters. 

Essentially, there are three revenue recognition models tha may apply:

1. Game-based model (Average life of game) – Rev rec amortized over the anticipated game’s run. This is a bit tricky as it may be challenging to know how long the game will be popular among gamers if it is a new and untested title. Slowest form of revenue recognition as most companies are anticipating 5 year run rates or longer based on the investments made.
2. User-based model (Average user life) – Rev rec amortized over the average player’s gaming activity. The tricky part here is anticipating lulls when users have no activity but may come back months alter to start paying again.
3. Item-based model (Consumption model of virtual goods) – Most difficult rev rec method, but offers the quickest time to start recognizing revenue. Items need to be classified as either:

(a) "Consumable" - This meets the delivery test you mention in the post. But if the virtual item has a lasting effect on the user’s character even after physical consumption and the delivery occurred, the item may still need to be classified as durable.
(b) "Durable" – This is where the item enhances the user’s character over n extended period of time and may require amortization over the user's life (assuming the effects of the virtual item become part of the character’s attributes).

From a systems and general compliance perspective, the issue is how delivery is defined.  Is delivery giving the customer the virtual cash to spend, or is delivery the customer actually purchasing the virtual goods?  The latter has the feel for final delivery, but may necessitate very high volume percent complete / milestone delivery type revenue tracking for relatively small amounts of money.

If there is no physical effort required after the initial purchase transaction - and no additional cost incurred - you may be able to justify a revenue method based on the initial purchase of virtual cash. Options could include amortization of revenue straight line over the usual customer consumption period (sort of an inventory turns model), or on purchase, or two months after purchase. It would be helpful to find a simplifying assumption to help with the detailed revenue transaction management.

The following excerpt from the Zynga 10K (using the Item-based model) may be of interest:

“The proceeds from the sale of virtual goods are initially recorded in deferred revenue. We categorize our virtual goods as either consumable or durable. Consumable virtual goods represent goods that can be consumed by a specific player action. For the sale of consumable virtual goods, we recognize revenue as the goods are consumed, which approximates one month. Durable virtual goods represent virtual goods that are accessible to the player over an extended period of time. We recognize revenue from the sale of durable virtual goods ratably over the estimated average playing period of paying players for the applicable game, which represents our best estimate of the estimated average life of durable virtual goods. If we do not have the ability to differentiate revenue attributable to durable virtual goods from consumable virtual goods for a specific game we recognize revenue on the sale of durable and consumable virtual goods for that game ratably over the estimated average period that paying players typically play that game.”

Going forward, it will be interesting to see how social gaming companies deal with the issue of virtual sales in real life.  I expect that this is evolving.

 When software companies are interested in Tensoft's Revenue Cycle Management (RCM) product, we first try to determine a fit for their requirements, so that no one's time is wasted.  Even if they have not yet created a requirements document, we find that a lot can come out of considering these three variables:

1) Billing. How does your company go to market (eCommerce, enterprise agreement, channel model, etc.)?  You'll want to look for a billing system or a billing support system that matches your go-to-market model.

2) Revenue Recognition. The rules for software industry revenue recognition are complex and changing. For the basics, you'll need a sub-ledger for deferred and recognized revenue analysis and appropriate methods and models to support your revenue recognition models.

3) Revenue Compliance. Could be part of the above, but is often a sub-set of that, and one that not every company needs.  There is no easy way to describe this, but if you have a sales process with multiple related elements in it (like software plus maintenance), and there are different recognition periods for the elements, you are most likely subject to more complex accounting guidelines.

Tensoft Revenue Cycle Management (RCM) supports billing requirements as well as complex software revenue recognition and contract management.