Product Roadmaps: Danger Signs for Revenue Recognition

- By Nick Fink, contributing writer

Sharing product roadmaps or information about future products with customers has the potential to create implied specified deliverables in certain revenue arrangements. When this occurs, revenue from current products may have to be deferred until future products are delivered. Companies commonly provide product roadmaps to build trust in long-term relationships where customers have a vested interest in the vendor’s future product development plans. However, customers may also receive product roadmap information indirectly from presentations at industry conferences, marketing materials posted on a website, or marketing information included in a press release. Furthermore, an increasing number of products from phones to cars have software-based features that could be upgraded during the time of a service and support contract. When customers have an expectation, prior to purchase, that products or key components will be upgraded, it can be difficult to assess whether their initial purchase decision was based on currently available products or in anticipation of a future or upgraded product.

The primary concern when product roadmaps are shared with a customer is whether all current and future obligations (e.g. upgrade rights) of the arrangement have been properly defined at the outset. Typically, specified upgrade rights are found in software arrangements that are subject to SOP 97-2, however, they can also exist in arrangements governed by SAB 104, SOP 98-1, or EITF 00-21. SOP 97-2 defines an upgrade right as "the right to receive one or more specific upgrades/enhancements that are to be sold separately." Furthermore, the Basis for Conclusions of SOP 97-2 states that "AcSEC believes that in arrangements that include upgrade rights, it may be difficult to determine which version of the software induced the customer to enter into the arrangement." Therefore, one of the key factors to consider in assessing whether product roadmap information creates a specified upgrade right is the role the information played in the customer’s decision to enter into the current revenue arrangement.

Determining Revenue Impact
Specific factors that should be considered in the determination of whether the sharing of product development information with customers creates specified deliverables in a current arrangement are as follows: ¹

1. Future Rights: Whether the customer has, or will purchase, the right to receive products included in the product roadmap information through post contract support (PCS) offerings or other subscription arrangements;
2. Demonstrable History: Whether the vendor has a history of separately charging a substantive amount (and a history to corroborate the assertion) for the products or upgrades identified in the product roadmap information;
3. Conditionality: The use of caveat language in contracts and on product roadmap information.
4. Release Dates: The level of specificity and the anticipated release date of future deliverables identified in the product roadmap information;
5. Timing: The manner and timing in which the product roadmap information is provided to the customer; and the time span covered by the product roadmap information.

Future Rights
Generally, if product roadmap information is provided (either explicitly or implicitly) in conjunction with an arrangement in which a customer purchases a software subscription-type arrangement (e.g., PCS or a subscription to software products), and the customer is entitled to receive items communicated as part of the PCS or subscription arrangement term fee, it can be difficult to overcome the presumption of specified deliverables in the current arrangement. If the customer received detailed product roadmap information prior to making a purchasing decision for a subscription that includes rights to items described within the roadmap information, typically some specified deliverables will exist in the arrangement.

Demonstrable History
If a vendor has a history with its customers of charging and receiving a substantive price for each of the items included on the product roadmap information, the presumption of a specified deliverable in the current arrangement often can be overcome, since the customer will have to enter into a separate arrangement (make a future purchasing decision) in order to receive each of the items on the product development information. Generally, such a practice would indicate the sharing of the product development information is not giving rise to a separate obligation in the current arrangement, and therefore, the timing of revenue recognition would not be impacted.

Conditionality
In specific instances the use of caveat language can provide a reasonable amount of uncertainty in the mind of a customer about whether it will actually receive a specified upgrade/enhancement. However, the use of caveat language is only effective in certain product roadmap information sharing scenarios. Specifically, caveat language is most effective when the product roadmap information is shared with a broad audience and is not customized to a specific customer.

Release Date
The level of specificity provided in the product roadmap information can affect the customer’s current purchasing decision. Generally, the greater level of detail and specificity contained in the product roadmap information regarding specific features and product functionality communicated with the customer the more likely it is that the customer has formed an expectation regarding the release of the future product enhancement(s) that has affected the current purchasing decision. The provision of such detail could potentially remove the “when and if” qualifiers that allow an obligation to be considered unspecified.

Timing
The timing of the customer being provided with the product roadmap information is important. If the customer is provided with the product roadmap information before, or at the same time, the arrangement is executed, it is presumed that the customer may have relied on that information, and formed expectations of future deliverables.

Generally, the closer the anticipated release date(s), noted in the product roadmap information, is to the origination of the arrangement with the customer, the more likely it is the customer has formed an expectation regarding the future release, which impacts the current purchasing decision.

In addition, the manner in which the product roadmap information is communicated to the customer should also be considered in determining if a specified deliverable exists in the current arrangement. Typically, if a customer accessed product roadmap information via the use of a wide-spread distribution channel (e.g., a vendor’s website) it may be less likely the information would impact their expectations regarding the current purchasing decision. Contrarily, if a customer is directly provided with customized product roadmap information by a vendor (e.g., as part of a contract or during vendor-customer interactions) that information may be more likely to affect the customer’s expectations and current purchasing decision.

Accounting Methodology
The accounting treatment required by SOP 97-2 for specified deliverables differs from the treatment for unspecified deliverables. Furthermore, SOP 97-2 also provides guidance when an arrangement contains both specified and unspecified elements. However, in applying the guidance set forth in SOP 97-2, another layer of clarification is needed: whether the deliverables are software upgrade rights or rights to additional software products, since these deliverables are treated differently.

Software Upgrade Rights
Software upgrades for a specified upgrade or enhancement evidenced by a specific agreement, commitment, or a vendor’s established practice, should be accounted for as a separate element in accordance with paragraphs 8 through 14 of SOP 97-2. However, rights to receive unspecified upgrades on a when-and-if available basis should be accounted for as PCS. SOP 97-2 is clear that in order to account for an element as PCS all of the upgrades must be unspecified and provided on a when-and-if available basis.

The SEC Staff further clarified this guidance. Specifically, the SEC staff dismissed the belief that if a company promises something but doesn’t specify the features and functionality, it does not have to account for that promise as a specified upgrade. The SEC staff commented on a recent fact pattern where a registrant promised that within the first year of an arrangement, the registrant would provide the customer with an unspecified upgrade. In this situation, the SEC staff determined that the commitment to the customer is more than an if-and-when-available upgrade and was skeptical about applying post-contract customer support ("PCS") accounting. The SEC staff considered alternatives but concluded that even though the registrant did not specify the features and functionality, the registrant promised something and the customer is expecting something. Therefore, unless the registrant had vendor-specific objective evidence of fair value of the upgrade, the revenue should be deferred despite having delivered a significant product.

If it is determined the upgrade right is for a specified upgrade or enhancement, and VSOE of fair value is not available, then revenue recognition would not commence on the arrangement until the specified upgrade right is delivered, or until VSOE of fair value is established. If it is determined that the upgrade right is for unspecified upgrades on a when-and-if available basis (i.e. PCS), and VSOE of fair value is not available, then revenue recognition would commence ratably over the PCS period, once the PCS element becomes the last undelivered element of the arrangement.

Software Products
As previously noted, SOP 97-2 distinguishes between software upgrades and software products. In an arrangement, a vendor may agree to deliver software products currently and also agree to deliver additional software products in the future. The rights to the additional software products may be included in the same licensing agreement, a PCS agreement, or another agreement that comprises the arrangement between a vendor and a customer. Regardless of the agreement that includes such rights, a customer’s right to receive additional software products represents a separate element included in a multiple-element arrangement.

SOP 97-2 distinguishes between the right to receive specified additional software products and the right to receive unspecified additional software products. A right to receive specified additional software products is accounted for as a separate element included in a multiple-element arrangement while a right to receive unspecified additional software products is accounted for as a subscription.

Example: PCS without Conditions
A vendor is currently marketing version 1.0 of a software product and is currently developing an upgrade to version 2.0 of its software product. The upgrade will be generally available in approximately one month, and the vendor publicly announces the release date, the version number, and several of the new features that will be included in version 2.0. In making this public announcement the vendor does not include any type of caveat language or restrictions in its marketing materials.

After the vendor makes the public announcement, it enters into an arrangement with a customer to license version 1.0 bundled with one year of post-contract support (PCS). By definition, PCS is the right to receive unspecified upgrades on a when-and-if-available basis. The contract with the customer is silent with respect to the customer specifically receiving upgrade rights to version 2.0.

As the vendor has provided a high degree of specificity regarding the release of version 2.0, which releases during the customer’s PCS period, and has not provided any caveat language on its marketing materials, the "when and if available" qualifiers of PCS have been removed. Therefore, the arrangement would include a specified upgrade right that should be accounted for as a discrete element within the arrangement.

Example: PCS Element with Conditions
Assume the same facts as in the first example except that the vendor’s marketing materials contain caveat language stating "the information contained on this product roadmap is not a commitment or legal obligation to deliver any of the described features or functionality described herein". Also assume the release date of version 2.0 will be within 8 to 14 months of the announcement.

In analyzing this fact pattern within the context of the five factors noted above, the vendor has utilized caveat language and the release date is not within a short time period of when the customer entered into the initial arrangement. Therefore, it can be argued that a reasonable amount of uncertainty existed in the mind of the customer as to what version they were purchasing and were obligated to receive. Accordingly, no specified upgrade right would exist in this fact pattern.

¹Several of these factors were obtained from the article "When is a Product Roadmap a Separate Element of an Arrangement" that was published August 12, 2005 in Ernst & Young’s Accounting and Auditing News.
² AICPA Conference, December 2005: Software Revenue Issues (G. Anthony Lopez, OCA)

---

About the Author
After spending time with a Big 4 public accounting firm as a certified public accountant, Nichlas Fink has worked for various companies as an expert in a wide-range of technical accounting issues. He is most recently the lead technical accounting expert at a large multi-national corporation.

This article is provided for informational purposes only and is not intended as professional or legal advice.