Combining Desktop and Cloud Software: Hybrid Contracts

In today’s mobile and interconnected world, many software companies offer cloud services in conjunction with software licenses, leading to increasingly complex contracts. Additionally, companies across many industries are starting to bill customers using a recurring subscription model. Many software companies find it difficult to apply the five-step model found in Accounting Standards Codification (ASC) 606 to these software-cloud-hybrid transactions, especially with the elimination of software industry-specific guidance. This article begins by providing a revenue recognition foundation and explores areas of software hybrid contracts that may require significant judgment. We conclude with a hybrid contract case study that illustrates how to properly apply professional judgment within the context of ASC 606.

Judgment Required in Step Two

For software hybrid contracts, step two of the five-step model is likely to require the most judgment because entities must identify the distinct goods and services promised in a contract. When software is combined with cloud-based services, determining whether the software is distinct from the services can be difficult.

When identifying performance obligations, entities must first deter  mises are distinct “within the context of the contract.” ASC 606-10-25-21 provides three factors to consider when determining whether two or more promised goods or services are distinct within the context of the contract, and thus separately identifiable:

• If the entity “provides a significant service of integrating goods or services with other goods or services promised in the contract,” (emphasis added) then the inputs included in the contract and integrated into a combined output are not distinct. Instead, the combined output of the integrated goods or services is distinct from other promises within the context of the contract.
• If “one or more goods or services significantly modifies or customizes, or are significantly modified or customized by, one or more of the other goods or services promised in the contract,” they are not distinct within the context of the contract.
• If “the goods or services are highly interdependent or highly interrelated,” they are not distinct within the context of the contract. As ASC 606-10-25-21(c) further explains, “in some cases, two or more goods or services are significantly affected by each other because the entity would not be able to fulfill its promise by transferring each of the goods or services independently.”

Depending on the distinct performance obligations that exist in a contract, the pattern and timing of revenue recognition may change, resulting in accelerating and/or smoothing revenue recognition. Because considerable judgment is required when making these determinations, subjective accounting decisions by management may influence revenue recognition.

When Software Contracts are Straightforward

The examples in this section are straightforward when it comes to identifying performance obligations in software contracts. The following background facts are common to both examples:

The following example illustrates how to identify separate performance obligations when promises are distinct within the context of the contract.

In this simple example, Living Picture should identify two separate performance obligations: (1) the perpetual LPS license to Techie, and (2) the service of standing ready to provide cloud capabilities. Neither promise in the contract meets the criteria in ASC 606-10-25-21:

• The desktop software is not integrated with the cloud capabilities. Each may operate independently of the other, and neither requires the other to function.
• The desktop software does not modify or customize the cloud capabilities. While the cloud capabilities may enhance the user experience of the software, the cloud capabilities do not modify or customize the software. Furthermore, Living Picture does not provide a significant service of modifying or customizing the desktop software—it is essentially an “off-the-shelf” product.
• While the desktop software and cloud capabilities work together seamlessly, they are not highly interrelated or highly interdependent. Techie can benefit from each element individually, without regard to the other. Additionally, the fact that Techie can continue to use the software after the contract period confirms that the software and cloud capabilities are not interdependent.

The total transaction price of $1,500 ($300 x 5 years) must be allocated to each performance obligation based on their relative standalone selling prices (SSP). As stated, the SSP of the desktop software is $1,200 and the SSP of the cloud capabilities for a 5-year period is $100 each year, or a total of $500. The transaction price is allocated to the two performance obligations on a relative basis: the desktop software is allocated $1,059 of the transaction price, and the cloud capabilities obligation is allocated $441. When Living Picture delivers the functional and perpetual software license to Techie, Living Picture has completely satisfied its obligation to Techie. Therefore, the software revenue is recognized upfront, when delivered to Techie. The revenue from the cloud capabilities obligation is recognized over time because the obligation meets the first criteria in ASC 606-10-25-27: “The customer simultaneously receives and consumes the benefits provided by the entity’s performance as the entity performs.” Living Picture recognizes $88.20 of revenue each year as it fulfills its obligation to provide continual access to its proprietary cloud capabilities. For more information about how to allocate the transaction price and recognize revenue in a similar transaction, see RevenueHub’s “Case Study: Software and PCS.”

In contrast to the previous example, the following example illustrates when promises in a contract are clearly not distinct:

Example B provides every indication that Living Picture should identify a single performance obligation in the contract. Living Picture offers a singular service of providing accessible and insightful metrics and analytics to Techie with a unique version of LPS. Based on the description above, the software suite and cloud capabilities are not capable of being distinct, suggesting a single performance obligation in the contract. In addition, Living Picture will find that the two promises are not distinct within the context of the contract, using the factors found in ASC 606-10-25-21:

• Living Picture fundamentally integrates the desktop software and cloud capabilities. The software is merely an end-user portal that enables Techie to access the core functionality and service provided by the cloud capabilities. Techie has not contracted for a stand-alone desktop software and cloud capabilities individually; rather, the customer has contracted to receive the combined output of the two integrated elements.
• Neither the desktop software nor the cloud capabilities significantly modify the other.
• The goods and services promised to Techie are highly interdependent. As mentioned above, Living Picture would not be able to fulfill its promise to the customer if it were to transfer each of the promised goods or services in the contract individually and independently.

Based on the analysis above, a single performance obligation exists—Living Picture will provide specialized and customized data analysis tools over the five-year contract period. This is consistent with the example given in ASC 606-10-55-56: “…Examples of licenses that are not distinct from other goods or services promised in the contract include the following: … (b) A license that the customer can benefit from only in conjunction with a related service (such as an online service provided by the entity that enables, by granting a license, the customer to access content).”

The entire $1,500 transaction price should be recognized as revenue over time. This will result in monthly per-license revenue of $25 ($1,500 / 60 months), or annual revenue of $300.

When Software Contracts are Not Straightforward

Examples A and B above are both relatively straightforward. However, many software contracts that incorporate a desktop software element and a cloud-based service are more ambiguous and will require significant judgment. In these instances, professionals will need to consider other issues such as the following:

• Scope and optionality of updates
• Desktop software reliance on updates to function
• Desktop software ability to function without cloud services
• Ownership/legal use of software after the end of the contract period
• Practical use of software after the end of the contract period
• Cloud computing/storage availability to non-software license purchasers

The objective of the new standard is to recognize revenue “to depict the transfer of promised goods or services to customers” (ASC 606-10-05-03). However, what goods and services transfer to the customer and when they transfer are sometimes ambiguous and may be perceived differently by different customers and by the company. For example, one customer may perceive a software and cloud-based services contract as a subscription for an integrated product while another customer with an identical contract may see the software as separate from the cloud-based services. When applying professional judgment, it may be unclear whether to approach the contract from the company’s or customer’s perspective, and whether to prioritize substance or legal form.

ASC 606 seems to advocate conflicting approaches, making the proper application of professional judgment more crucial—and more difficult. For example, ASC 606-10-25-16 requires that companies identify implicit promises that the customer may reasonably perceive in the contract: “… a contract with a customer also may include promises that are implied … if, at the time of entering into the contract, those promises create a reasonable expectation of the customer that the entity will transfer a good or service to the customer” (emphasis added). Later, ASC 606-10-25-21(a) requires that an entity consider the customer’s perspective when identifying performance obligations and distinctness within the context of the contract: “The entity provides a significant service of integrating goods or services… that represent the combined output or outputs for which the customer has contracted” (emphasis added). This doesn’t necessarily mean a company must consider all the possible ways a customer can misconstrue a contract, but it does prioritize the customer’s perception of contract substance over form.

In contrast, other paragraphs in ASC 606 and subsequent interpretations by the Transition Resource Group (TRG) direct entities to prioritize legal form over contractual substance. One example of this is termination clauses. In TRG Memo 10, example 5, the TRG says, “If [the] past practice [of not enforcing the termination clause] does not change the parties’ legally enforceable rights and obligations, then the contract term is the stated term.” In some jurisdictions, the past practice of not enforcing the termination clause will diminish its legal enforceability, but in other jurisdictions the clause is legally enforceable regardless of past and expected practice. This difference can completely change the contract duration, as noted in TRG Memo 10. Thus, only the legally enforceable rights in the stated contract should be considered, not the customer’s justifiable perception and expectation of the termination clause.

Because the standard sometimes prioritizes substance over form and other times form over substance, careful analysis and professional judgment are needed when applying the standard to complex contracts where the substance and legal form differ. Where the standard is unclear or its application to a specific transaction is ambiguous, companies should consider the merits of both approaches, always keeping in mind the overarching objective of revenue recognition is “…to depict the transfer of promised goods or services to customers in an amount that reflects the consideration to which the entity expects to be entitled.”

Hybrid Contract Case Study: Desktop Software and SaaS

We finish with a contract more and more typical of those found in the software industry. The following example is similar to Adobe Creative Cloud product offerings and associated contracts. While the example is written to be similar to the Adobe Creative Cloud, the contract is simplified and will be used to illustrate some of the many complexities that arise in a realistic contract. RevenueHub does not suggest a specific accounting treatment for Adobe’s contracts with customers and has not corresponded with Adobe to discuss this case. Critical internal data from Adobe would impact the specific accounting treatment for Adobe.

In considering the customer’s perspective, Brick may determine that Olivia simply wants the full BIC experience, which she gets during the entire contract period. According to this perspective, the revenue would be recognized ratably over time, $50 each month. Alternatively, Brick may reasonably expect that Olivia, being a professional photographer and graphic designer, only wants a few elements of BIC, namely PhotoBrick, DrawBrick, Brick Pro, the associated updates, and Brick Briefcase to showcase her work. She does not need and will not use any other portion of BIC. Brick is required to allocate the $600 transaction price to the identified performance obligations based on Olivia’s supposed intended usage, and Brick may have trouble determining the exact nature of its promise based on Olivia’s intended usage. When multiplied by hundreds of thousands of contracts with unique customers, this psychoanalytic accounting approach breaks down both technically and practically. The approach does not accurately and faithfully reflect the full nature of Brick’s promises, the transfer of goods and services to Olivia, and/or the amounts to which Brick would expect to be entitled. For this reason, we suggest that the appropriate accounting treatment considers all relevant information: the customer’s perception of the entity’s promises, the entity’s perception of its obligations, and the legal form of the contract.

Taking all perspectives into account, Brick determines that it has promised to make the 25 desktop software programs available for download, installation, and use at any time during the contract period, beginning the first day of the license term. The software will remain usable with continued payment and internet access per the payment terms. Brick also promises continual access to tutorials, updates on a when-and-if basis, and Brick Briefcase.

Accounting Analysis

Brick, like many of its peers in the software industry, must determine the degree to which the various elements of the contract are interdependent and/or interrelated; this determination significantly impacts revenue recognition. On the one hand, separate performance obligations would result in the allocation of the transaction price to the different obligations, and each may have its own pattern and timing of recognition. On the other hand, if the cloud elements and software elements are so interrelated as to suggest a single performance obligation, that single obligation would likely meet the criteria for over-time recognition, and the entire transaction price would be recognized ratably over the contract term.

ASC 606 eliminates software industry-specific guidance and generally moves away from any bright-line thresholds. Software companies must exercise sound professional judgment when determining both the degree of interrelatedness and the corresponding threshold used to separate or combine contract promises. Because the standard does not offer any guidance surrounding approaches to measure interdependency or interrelatedness, we offer two approaches here.

The first approach, which we have termed “the Sahara Principle,” focuses on theoretical possibility: If the user were in the middle of the Sahara Desert with no internet connection, how functional would the software be? In Brick’s case, a user could gain substantially all the benefits of the previously downloaded software without an internet connection in the middle of the Sahara. This would suggest that the elements are not interrelated or interdependent enough to warrant combining the software, updates, tutorials, or briefcase promises into a single performance obligation.

The second approach, which we call “the Reality Check,” focuses on actual usage: How much do customers use the software with meaningful cloud integration? To this end, Brick analyzes user- and software-submitted usage data and finds that on average, 90 percent of the time spent using the various software applications does not use any cloud integration. This further suggests that the software and cloud promises are not highly interdependent or interrelated, and Brick should not combine them into a single performance obligation.

Because both approaches reach the same conclusion, Brick’s transaction is straightforward. However, applying ASC 606 may be more ambiguous if the two approaches suggest there are distinct performance obligations. For example, Brick’s competitor, Clay, only makes video editing software. Clay has developed a revolutionary splice rendering technology that significantly improves workflow efficiency by continuously rendering customers’ videos on the cloud as the users make edits on their personal computers. Where there is no internet connection, the customers may still render their videos on personal computers, though it is a very power-intensive and time-consuming process. The Sahara Principle would suggest that Clay’s promises are distinct because the software does not require the cloud to achieve the same function or result. However, virtually all customers take advantage of Clay’s time-saving splice rendering technology every time they edit videos. Because nearly 100 percent of the software usage depends on and is integrated with cloud functionality, the Reality Check approach would suggest combining promises into a single performance obligation. The standard is not clear on its “correct” application to these and similar circumstances, and companies must exercise significant judgment when deciding how to recognize revenue in a way that most accurately reflects the transfer of goods and services to the customer.

Per the criteria in ASC 606-10-25-21 and the discussion above, Brick determines that the tutorials, updates, and website are each distinct within the context of the contract. Updates and Tutorials are in no way related, and both are beneficial to Olivia in conjunction with the previously-transferred, and thus readily-available, licenses to software programs. The updates enhance, but are not necessary for the core functionality of the desktop software programs. The Brick Briefcase service can be delivered to Olivia on its own, independent of any other element in the contract.

Another aspect of the revenue recognition process that requires professional judgment is related to the software licenses—identifying one or many performance obligations and subsequently allocating revenue. While it is possible for Olivia to receive up to three additional months of use from the downloaded software beyond her payment, in no case will the software function beyond the full 12-month contract term. Also, per the explicit contract and any implied promises, monthly payment is associated with a full-year contract, and the four-month validation requirement is only to balance (a) protecting Brick’s intellectual property (IP) from misuse and (b) allowing legal software usage when internet connection is unavailable for a prolonged period. The purpose of the four-month validation requirement is not to extend the usage period beyond the payment period. Nonpayment would be a breach of contract or contract modification, which is beyond the scope of this article.

Brick determines that the nature of the promise is to deliver 25 distinct software licenses, considering the three criteria listed in ASC 606-10-25-21. However, their distinctness from each other does not ultimately impact revenue recognition, as shown in the paragraphs below.

Before analyzing and estimating SSPs for allocating the transaction price, and to fully understand what Brick transfers to Olivia, we turn our discussion to IP license types. ASC 606-10-55-58 through 55-63A provide guidance on licenses of IP, which includes software licenses. When considering the nature of its promises, Brick must determine if it provides customers with a right to use IP or a right to access IP. The pattern of revenue recognition depends on the IP license classification. In accordance with ASC 606-10-55-59, Brick first determines that the software meets the definition of functional IP, not symbolic IP, because the software has significant standalone functionality. Further, ASC 606-10-55-62 states that a license to functional IP provides a right to use IP unless both following criteria are met, in which case the license provides a right to access IP:

1. “The functionality of the intellectual property … is expected to substantively change during the license period as a result of activities of the entity that do not transfer a promised good or service to the customer …
2. The customer is contractually or practically required to use the updated intellectual property resulting from the activities in criterion (a).”

Each individual software program is not expected to substantively change during the 12-month license period, so each license is one that grants Olivia a right to use the IP. The corresponding revenue is recognized at a point in time.

Going back to step four of the revenue recognition model, Brick must allocate the transaction price to the performance obligations based on relative SSPs. Brick no longer offers the software licenses individually—they must be purchased together. Therefore, Brick determines that the SSP for each license is quite uncertain. ASC 606-10-32-34 suggests three approaches to estimating SSP: “Adjusted market assessment approach,” “Expected cost plus margin approach,” and “Residual approach.” ASC 606-10-32-34(c) allows for the residual approach only when other goods or services in the contract have observable SSPs. ASC 606-10-32-35 suggests that the residual approach can be used to first allocate a portion of the transaction price to multiple uncertain or highly variable performance obligations, which are then subsequently allocated a portion of that residual amount using other estimation methods:

…For example, an entity may use a residual approach to estimate the aggregate standalone selling price for those promised goods or services with highly variable or uncertain standalone selling prices and then use another method to estimate the standalone selling prices of the individual goods or services relative to that estimated aggregate standalone selling price determined by the residual approach…

Using external market data and previously used VSOE amounts, Brick tutorial, updates, and website performance obligations, at $20, $50, and $120, respectively. Because the other goods and services have observable SSPs in the form of VSOE amounts, and because the individual SSPs of the 25 software licenses are unknown and difficult to estimate, Brick uses the residual method to estimate the aggregate SSP of all 25 software licenses at $410. All 25 licenses are right-to-use licenses and will be recognized at the same point in time. In this case, it makes no difference if each software license is distinct from the others, or if Brick estimates each software SSP at $50 or $500; each of the 25 licenses is allocated a portion of the transaction price that totals $410 in aggregate, all of which is recognized at a point in time.

Brick must next determine when the software licenses are transferred to Olivia, that is, at what point in time to recognize the corresponding revenue. As ASC 606-10-25-23 explains, “An asset is transferred when (or as) the customer obtains control of that asset.” Paragraph 25-25 further explains that control “refers to the ability to direct the use of, and obtain substantially all of the remaining benefits from, the asset.” Olivia can direct the use (or non-use) of each license immediately at contract inception. ASC 606-10-55-58C clarifies that revenue from a license of IP cannot be recognized before both when “An entity provides (or otherwise makes available) a copy of the [IP] to the customer” and “The beginning of the period during which the customer is able to use and benefit from its … right to use the [IP].” Revenue can be recognized on the first day of the contract, when Brick makes the software licenses and programs available.

To clarify, the software license is a legal construct that gives Olivia the right to use certain IP for a specified period. This license is different from the software program itself, which is computer code that can be interpreted by Olivia’s PC and perform many functions and tasks. Admittedly, Brick continues to make the software program available for download throughout the year. However, if Olivia already has the license, many software companies consider the method of transferring the actual software program immaterial. Once Olivia has the license, she may legally download and use the software via Brick’s website, an email attachment, her own personal backup, etc. Essentially, Brick promises to provide the most up-to-date version of the software over the contract period, which we have identified as the “updates” performance obligation. This “updates” performance obligation means standing ready to provide the most up-do-date software throughout the contract term—whether the whole software program or an updated portion.

Brick determines that control of each software license is transferred on January 1, 20X1, at which point all 25 software license performance obligations are satisfied. The tutorial, updates, and website performance obligations are satisfied ratably over time. The revenue recognition for each performance obligation is summarized in the tables below:

The accounting conclusion reached here is not necessarily applicable to every hybrid subscription contract, and individual facts and circumstances must be considered.

Other Industry Considerations, Diversity in Thought

In a January 2015 comment letter written and signed by executives representing Adobe, VMware, Symantec, and other “key software companies in the San Francisco Bay Area,” the companies suggest additional industry-specific guidance for software companies. They propose that paragraphs be added to ASC 606, including examples and indicators that suggest that licenses are not distinct in the context of “certain license and hybrid-cloud transactions.” While the Financial Accounting Standards Board (FASB), to which the comment letter was addressed, did not issue authoritative clarifying guidance, the views expressed in the comment letter may represent the commonly accepted interpretation in the industry. Of interest to this BIC case are the following stated indicators, some of which suggest a customer-perspective or psychoanalytic approach:

…d. If the contractual terms of the arrangement include initial delivery of licenses and also require the vendor to provide various services, software and other elements throughout the arrangement period that are considered by the customer to represent a combined solution[,] this could indicate that control of the license is not distinct because the risk and rewards of the underlying contract substantively transfer over the contract term.

… f. The customer’s rights to the software cease when the hosting or hybrid cloud arrangement ends or the license term expires. This would indicate that the software is not distinct.

… h. If the economics of the transaction suggest that the software is not an independent component of the arrangement and that the value for delivery of such software cannot be determined easily, it might suggest that the arrangement is for providing a combined set of obligations that can be considered as a single performance obligation.

These statements are not found in the current ASC 606 standard. However, if software companies do follow these suggestions, some may suggest that the BIC contract in this case has a single performance obligation because none of the promised goods or services, including the software licenses, are distinct within the context of the contract.

The American Institute of Certified Public Accountants (AICPA) offers non-authoritative guidance specific to private companies in the software industry. On October 3, 2016, the AICPA issued a working draft for Software issue #14-1, containing proposed wording to be included in its Revenue Recognition Guide. This working draft focuses on determining the distinctness of software and other cloud services in hybrid contracts. In paragraphs 16a and 16b, the AICPA suggests that a software license is generally distinct from cloud storage and sharing capabilities. However, a company may determine that:

…the online storage and sharing is integrated with the on-premise software in such a manner that the customer gains capabilities or workflow efficiencies that would not be available when using another vendor’s hosted services. In such circumstances … the customer obtains a significant functional benefit by purchasing the complete hybrid offering from the entity. This may indicate that the software license and hosting service are interrelated to each other, and are not distinct within the context of the contract.

According to this guidance, Brick should assess how truly interrelated the software programs and cloud services are to each other by analyzing the customer’s perceived efficiencies when using the software with the cloud services.

This type of language appears in Adobe’s 2016 Form 10-K and may influence its revenue recognition under ASC 606. When discussing the interaction of the software’s functionality and Adobe’s cloud capabilities in the Adobe Creative Cloud, the company says, “Adobe CreativeSync… synchronizes all files, photos, fonts and other assets used in a particular workflow so that users can begin creative work on any device and seamlessly continue it on another” (page 8). Additionally, Adobe claims its strategy with Creative Cloud is, among other things, “to enable us to… grow a recurring and predictable revenue stream that is recognized ratably” (page 41).

The current wording in ASC 606 seems to suggest that given the facts in the “Brick Imagination Cloud” case presented here, the front-loaded pattern of revenue recognition is the only supportable way to recognize this revenue. Other sources may suggest otherwise given slightly different facts, and many companies may have to alter the structure of their business practices and product offerings to get the ratable accounting treatment they desire. This would be a classic scenario of “the tail wagging the dog.”

While the standard appears to require a front-loaded pattern of recognition, we suggest this may be a flaw in the standard, as it doesn’t necessarily reflect what both companies and customers perceive in the contract. The company sells a subscription service. The customer pays for a subscription service. The nature and size of the software requires it to be installed locally, even though the customer may not care where the software is installed—on Brick’s servers or on Olivia’s laptop. The customer just wants to have access to and use the software. But because the software is installed locally and the licenses are delivered to the customer immediately, Brick may have to recognize revenue up front. This type of situation may need to be addressed more clearly in future implementation guidance.

Comparison to ASC 605

A commonly cited part of ASC 605 to support ratable, over-time recognition involves the concept of a “contingent cash cap” or “contingent revenue cap.” Per ASC 605-25-30-5, “The amount allocable to the delivered unit or units of accounting is limited to the amount that is not contingent upon the delivery of additional items… (the noncontingent amount).” Put simply, if consideration is contingent on other deliverables, a company can’t allocate it to an already satisfied deliverable and recognize it as revenue. Under ASC 605, a company could achieve ratable recognition by adjusting the payment terms in a way that would prevent revenue from being front-loaded.

Applying this thinking  to the examples in this article, the revenue from the contract would be recognized as the monthly fee is due. While this result is similar to a possible over-time conclusion under ASC 606, the logical path leading to the pattern of recognition is quite different. ASC 605 recognizes revenue ratably because all future payments are contingent upon the company fulfilling its future obligations, and revenue corresponding to those contingencies cannot presently be recognized. In contrast, ASC 606 recognizes revenue ratably over time only if the contract promises are not separately identifiable and the performance obligations meet the criteria to be satisfied over time.

As an example of this ASC 605 recognition pattern in practice, Adobe’s 2016 Form 10-K states, “The subscription model [currently] results in a ratably reported revenue stream that is recurring and highly predictable” (page 5).  Adobe provides some information on how ASC 606 will impact its revenue streams on page 73, but it is unclear which category its Creative Cloud offering falls under—term licenses or cloud offerings: “… [W]e currently believe the most significant impact [of ASC 606] relates to our accounting for arrangements that include term-based software licenses bundled with maintenance and support… [U]nder the new standard we will be required to recognize as revenue a portion of the arrangement fee upon delivery of the software license. While we currently expect revenue related to our … cloud offerings … to remain substantially unchanged, we are still in the process of evaluating the impact of the new standard on these arrangements” (page 73). If Adobe considers the Creative Cloud offering as a collection of “term-based software licenses bundled with maintenance and support,” then future revenue will closely match the pattern presented in this BIC case. If Adobe places the Creative Cloud in the “cloud offerings” category, then they expect ratable revenue over the contract term, “substantially unchanged” from revenue recognition under ASC 605.

Conclusion

It comes as no surprise that software companies are concerned about proper revenue recognition under ASC 606 when the industry previously had industry-specific guidance under ASC 605. Many applications of ASC 605 to software contracts resulted in operationally simple, ratable and smoothed revenue over the contract term. This may not be the case under ASC 606, and software companies will need to exercise considerable judgment when determining how to recognize revenue in a way that accurately reflects the transfer of goods and services to the customer. Companies with contracts similar to those presented above should evaluate the impact of ASC 606 on their business, anticipating potentially additional transition costs to properly apply ASC 606.

Other RevenueHub Articles Central to Analysis

• Case Study: Software & PCS
• Case Study: Software as a Service (SaaS)
• Licenses of IP

Resources Consulted

• ASC 606
• Adobe's 2016 Form 10-K.
• FASB TRG Memo 10: “Contract Enforceability and Termination Clauses.” 31 October 2014.
• RevRec-15, Comment Letter No. 30. 21 January 2015.