In Brief

Companies continue to struggle with implementing FASB’s new revenue recognition standard, which becomes effective this year. One sector that may experience particular difficulty is the cloud computing industry, which relies upon several unique kinds of arrangements. The authors discuss how the new revenue recognition framework will affect cloud computing arrangements and recommend how service providers and users can adjust their processes to comply with the new guidance.

* * *

Cloud computing arrangements, broadly defined, are hosting arrangements in which the user of a licensed software product does not take possession of the software, but instead accesses and uses the software over the Internet (or other dedicated connection) on either an as-needed basis or by subscription [Accounting Standards Update (ASU) 2015-05, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Customer’s Accounting for Fees Paid in a Cloud Computing Arrangementhttp://bit.ly/2IBYR09]. The corporate shift toward such arrangements has created accounting challenges for both managers and public accountants. With FASB’s recent adoption of Accounting Standards Codification (ASC) Topic 606, “Revenue from Contracts with Customers,” cloud service providers will need to revisit, and in some cases revamp, their revenue recognition policies and practices.

The impact of the new standard will bring about substantial changes in the revenue recognition policies and practices of cloud service providers, both in the public and private sectors. Public entities must comply with the new revenue recognition standard for the first interim period within annual reporting periods beginning after December 15, 2017; nonpublic entities have an additional year to comply. Early adoption is available, and companies can choose to adopt using either a modified or full retrospective approach. Due to a lack of resources and infrastructure, many private company managers are relying on the additional time to learn from public companies’ implementation. Stakeholders, including managers and accountants from both big and small firms, recognize that the revenue changes are more complex than originally anticipated. Furthermore, system implementations to automate changes that should have been completed in 2017 are being pushed into 2018 as preparers continue to seek answers to questions arising from complexities within the revenue recognition process. These uncertainties create obstacles to adoption for public and private companies alike, and further guidance is necessary to overcome these hurdles in the implementation process.

This article discusses, in detail, the accounting challenges faced by providers in implementing the new revenue recognition standard for cloud computing arrangements and the impact that the new standard is likely to have on the cloud computing industry. Preparers, managers, board members, and those just entering this industry should be ready for the challenges that the new revenue recognition rules will create. Users of financial information, such as investors and creditors, should also have a sound understanding of how the new revenue recognition standard could affect decision making.

Prior Guidance for Cloud Computing Arrangements

Cloud service providers must determine whether to account for internal use software in a hosting arrangement as the sale and purchase of a software license or as a service contract, or both. Generally, internal use software obtained through a hosting arrangement is accounted for as a software license if the user has the right to possess the software at any time during the hosting period without incurring a significant penalty and the user can either run the software on its own hardware or contract with a party unrelated to the provider to host the software (ASC 605-55-121).

Under the prior revenue standard, software contracts that meet these criteria were accounted for under ASC Topic 985-605, “Revenue Recognition—Software.” Most cloud-based contracts, however, do not meet the above criteria and were accounted for as service contracts that fall under ASC Topic 605-25, “Revenue Recognition—Multiple Elements Arrangements,” and the SEC’s Staff Accounting Bulletin (SAB) 104. Following this guidance, the contract price is allocated to the identified separate units of accounting at the inception of the arrangement based on the relative selling price method. The selling price for each unit of accounting is based on a provided hierarchy, and the residual method of allocating contract consideration is prohibited. Revenue from a cloud computing arrangement is generally recognized on a straight-line basis over the life of the contract, provided that—

  • persuasive evidence of an arrangement exists;
  • a service has been provided to a customer (delivery has occurred);
  • collectability is reasonably assured (the uncollectible risk is estimable); and
  • the amount of fees the customer must pay is both fixed and determinable (SAB 104, codified under ASC Topic 605).

New Revenue Guidance for Cloud Computing Arrangements

Under the new core revenue recognition principle following ASC Topic 606, companies recognize revenue when goods or services are transferred to customers for the amount that the company expects to be entitled to receive in exchange for those goods or services. The five steps to apply the core revenue recognition principle are—

  • identify the contract with the customer;
  • identify the performance obligations in the contract;
  • determine the transaction price;
  • allocate the transaction price to each performance obligation; and
  • recognize revenue when (or as) each performance obligation is satisfied (ASC 606-10-05-4).

As will be shown, each of the five steps creates new accounting challenges for providers in the cloud computing industry.

Identify the Contract with the Customer

In order for a contract to exist between a provider and a customer of cloud computing services, the legal rights of both must be established. Under ASC 606-10-25-1, revenues cannot be recorded for a contract unless the contract is approved, the parties are committed to their obligations, the payment terms and rights to goods and services are identifiable, the contract has commercial substance, and it is probable that the provider will collect substantially all of the consideration to which it will be entitled in exchange for the goods or services that will be transferred to the customer. When evaluating collectability, a provider must consider both the customer’s ability and intent to pay for the duration of the contract. Providers should also include their ability to manage exposure to credit risk in this assessment, including the right to stop transferring additional goods or services to the customer and advance payments from the customer. This represents a change in the accounting for collectability from prior U.S. GAAP in that cash-basis methods for recording revenues, such as the installment sales method and the cost recovery method, are eliminated under the new standard. This change, discussed below, will affect the cloud computing industry, where certain contracts are accounted for on a cash basis.

In the cloud computing industry, poor cash flows resulting from high initial customer relationship costs have made substantial up-front payments the norm.

Collectibility threshold.

Under the prior revenue standard, the collectibility threshold was met if collectibility could be reasonably estimated (ASC 605-10-S99-1); therefore, if cash was received for a delivered good or service, revenue could be recorded. Under ASC Topic 606, however, if it is not probable that the provider will collect substantially all of the consideration to which it is entitled, revenue may be deferred, even if cash has been exchanged for services that have been provided. This is especially relevant for cloud service providers who operate primarily under a recurring revenue model, in which services are provided for a monthly subscription.

In the cloud computing industry, poor cash flows resulting from high initial customer relationship costs have made substantial up-front payments—often up to the entire value of an annual contract—the norm. For example, Salesforce states in its “Summary of Significant Accounting Policies” disclosure note for 2016: “The Company generally invoices customers in annual installments. The deferred revenue balance is influenced by several factors, including seasonality, the compounding effects of renewals, invoice duration, invoice timing, size, and new business linearity within the quarter. Deferred revenue that will be recognized during the succeeding 12-month period is recorded as current deferred revenue, and the remaining portion is recorded as noncurrent.” Salesforce carried more than $4 million in current deferred revenue on its 2016 balance sheet, compared to $23,886 in noncurrent deferred revenue. With $6,205,599 in total subscription and support revenue for the year, the potential inability to record a portion of deferred current revenue as earned in a given period could have a material negative effect on Salesforce’s measures of income.

The FASB-IASB Joint Transition Resource Group (TRG) for revenue recognition voiced concerns that the collectability threshold under ASC Topic 606 was too narrow. In March 2016, FASB issued ASU 2016-12, Revenue from Contracts with Customers (Topic 606)—Narrow Scope Improvements and Practical Expedients, to help address the collectability issue and other concerns. Following ASU 2016-12, revenue is deferred until either the collectibility threshold or an events test is met. For the events test, at least one of the following three events must take place:

  • There exist no obligations to transfer goods or services to the customer, and all or substantially all of the consideration has been received from the customer and is nonrefundable.
  • The contract has been terminated, and consideration received from the customer is nonrefundable.
  • Control of the goods or services to be received related to the consideration has been transferred by the seller/provider, the seller/provider has ceased transferring goods or services to the customer with no obligation to transfer additional goods or services, and the consideration received from the customer is nonrefundable.

Cloud service providers must assess the collectibility threshold in a forward-looking manner, using judgment as well as the facts and circumstances surrounding each contract. Providers must distinguish between price concessions, bad debts, and a lack of commercial substance in determining the existence of a contract; this determination may be difficult. Providers who fail to meet the collectability threshold must continue to assess the contract and defer all revenues until substantially all of the contract consideration is received or the events test is met. If a cloud service provider extends monthly payment terms to a customer with poor credit, partial cash collection will not warrant revenue recognition unless the contract is complete or terminated. Cloud service providers must prepare themselves for the possibility that certain contracts that met the collectibility threshold under ASC 605-10-S99-1 may not meet the threshold under ASC Topic 606, even when cash deposits are received.

Contract modifications.

Contract modifications, such as a change in the scope or price of an existing contract, are common in the cloud computing industry. Current U.S. GAAP contains very limited guidance on the accounting for contract modifications, other than for contracts that are in the scope of the guidance for construction- and production-type contracts in ASC Topic 605. Cloud service providers generally account for contract modifications on a cumulative catch-up basis by updating their measure of progress under the existing contract for the effects of any modification. ASC Topic 606, however, provides guidance that applies to all contracts with customers.

Contract modifications represent separate contracts that are accounted for on a prospective basis if both the scope of the contract increases due to the addition of goods or services that are distinct and the price of the contract increases by an amount that reflects the provider’s standalone selling prices of those additional goods or services and any other price adjustments that reflect the specific circumstances of the contract, such as a customer discount. In order to be distinct, the additional goods or services must be both capable of being distinct and separately identifiable from other deliverables or promises in the contract. If the additional goods or services are not distinct, providers account for the contract modification as part of the original contract on a cumulative catch-up basis. If the additional goods or services are distinct but the price of the contract does not increase by an amount that reflects the provider’s stand-alone selling prices, the modification is accounted for prospectively as a termination to the original contract and creation of a new contract.

Cloud service providers must assess the collectibility threshold in a forward-looking manner, using judgment as well as the facts and circumstances surrounding each contract.

Cloud computing contracts may allow the service provider to change the terms of the contract depending on factors such as unanticipated costs, customer delays, and disputed or unapproved change orders. These types of unapproved changes meet the definition of a “claim.” Under ASC Topic 606, once a provider determines that it has enforceable rights and obligations related to a claim, the provider must estimate the change in the transaction price resulting from the contract modification following the accounting for contract modifications described above.

The accounting for contract modifications under ASC Topic 606 will cause certain cloud computing contracts that have been accounted for on a cumulative catch-up basis to be accounted for prospectively as separate contracts. This could, in turn, affect the collectability of these contracts, as an analysis of each new contract will be necessary. Companies may choose to either adopt a retrospective approach or report the retrospective cumulative effect of the change in accounting principle at the date of initial application of the new guidance. TRG members have informed FASB that the analysis necessary to account for contract modifications under the new revenue recognition standard will be both time consuming and costly for cloud service providers that have a significant number of contract modifications or for whom the modifications have occurred over a long period of time. ASU 2016-12 provides a practical expedient for all companies, including cloud service providers, to “reflect the aggregate effect of all modifications that occur before the beginning of the earliest period presented in accordance with Topic 606 when identifying the satisfied and unsatisfied performance obligations, determining the transaction price, and allocating the transaction price to the satisfied and unsatisfied performance obligations.”

According to ASC 606-10-25-11, when the parties to a contract have approved a change in scope but the price is yet to be determined, providers should use the guidance on variable consideration to estimate the change in transaction price resulting from the contract modification. A fuller discussion of the guidance for variable consideration occurs later in this article.

In order for the deliverable to be separately identifiable in the contract, it must not be highly interrelated with or dependent upon other deliverables or promises in the contract.

Contract combinations.

Current U.S. GAAP allows cloud service providers to use judgment in evaluating whether to combine contracts that are entered into at or near the same time with the same customer or a related party. Under ASC Topic 606, such contracts must be combined if one of three criteria is met:

  • A set of contracts is negotiated together with a single objective.
  • The amount of contract consideration in one contract is dependent upon the price or performance of another contract.
  • Some or all of the goods or services in more than one contract represent a single performance obligation.

For example, a contract for the sale of a cloud-based service to be used by a business and its related affiliates and a contract to customize the same client’s hardware to run the cloud service will likely be combined under the new revenue recognition standard, as the specialization is not distinct from the cloud application.

Identify the Performance Obligations in the Contract

Cloud computing arrangements often contain multiple deliverables, such as activation or setup fees, a software license, a hosting service, future upgrades, technical support, and customization costs. In order to adequately recognize revenue over the duration of a contract, it is important to identify each individual deliverable in a given contract.

Under the prior standard (ASC 605-25), contract elements are considered separate “units of accounting” if the delivered element has standalone value. Stand-alone value exists only if any vendor sells a deliverable separately or if the customer could resell it on a stand-alone basis. Because most cloud applications are host services that are used up as they are delivered, customers cannot resell the deliverables on a stand-alone basis; cloud service providers should therefore focus on whether a contract deliverable can be sold separately.

Providers must apply substantial judgment in a case where stand-alone value is determined based on whether other providers offer replacement services. Deliverables that do not qualify as separate units of accounting are combined with the amount allocable to the other applicable undelivered items within the contract. The allocation of arrangement consideration and the appropriate recognition of revenue were determined for those combined deliverables as one single unit of accounting under ASC 605-25-25-6.

ASC 605-25-25-5 also states that “if the arrangement includes a general right of return relative to the delivered item, delivery or performance of the undelivered item or items is considered probable and substantially in the control of the vendor.” Cloud computing contracts generally do not include a general right of return.

ASC Topic 606 provides that goods and services are considered separate deliverables (or “performance obligations”) if they are distinct (i.e., capable of being distinct and separately identifiable) from other contract deliverables. “Capable of being distinct” implies that the user should be able to use the deliverable on its own or in combination with other readily available resources. In order for the deliverable to be separately identifiable in the contract, it must not be highly interrelated with or dependent upon other deliverables or promises in the contract. If a deliverable is not distinct, providers must combine it with other deliverables until a distinct performance obligation is identified. In some cases, this will result in accounting for an entire contract as one performance obligation.

Postcontract support services.

A specific example of how performance obligations identified under the new standard will affect cloud service providers is postcontract support services (PCS) such as telephone support, bug fixes, and software upgrades. Currently, PCS is generally accounted for as one separate unit of accounting if the provider can establish stand-alone value. In the absence of stand-alone value, a contract including, for example, a software subscription and PCS, may be treated as one deliverable. In such an instance, revenue recognition of the entire contract is deferred until the final obligation is provided.

Under the new standard, PCS can be separated into multiple performance obligations if the components of PCS are considered to be distinct services. This represents a change in U.S. GAAP for cloud service providers, who generally account for PCS as one unit of accounting. Separating PCS into multiple performance obligations under the new standard will affect both the timing and amount of revenues recognized. The example provided in ASC Topic 606—PCS services that include both technical support and software upgrades that can be accounted for as two separate performance obligations—may be a common one that will accelerate revenue recognition for cloud service providers.

Substantial judgment and care must be used in accounting for PCS as multiple performance obligations. For certain deliverables, such as unspecified upgrades and enhancements, providers must determine the nature of the promise to deliver future services, including whether a clear pattern exists for delivering upgrades or enhancements and whether they are delivered on a stand-ready basis, with no observable pattern. In 2016, the TRG stated that cloud service providers should use judgment in determining the timing of revenue recognition that is provided on a stand-ready basis.

Whereas unspecified upgrades and enhancements may be distinct, others, such as telephone support and bug fixes, may not be viewed as distinct services. Telephone support and bug fixes may be viewed as either quality-type assurances that the hosted software is functioning properly or extended assurance above and beyond quality assurance. These deliverables should be accounted for as separate performance obligations only if they provide the customer with a service beyond quality assurance.

Determining the Transaction Price and Variable Consideration

The treatment of variable consideration under the new revenue recognition standard could mean significant changes in policy for cloud service providers. Cloud service providers typically enter into contracts with variable amounts representing discounts, rebates, credits, incentives, extended payment terms, renewal options, and implied price concessions offered to customers.

Under prior U.S. GAAP, revenues from certain types of variable consideration for cloud service providers were deferred until periods in which the revenue could be reliably measured; this generally occurred either once uncertainties involving collection were known or once cash was received. Under the new guidance in ASC Topic 606, variable consideration is accounted for based on the extent that it is probable that a significant reversal of revenue will not occur when the uncertainty associated with the variable consideration is resolved. The treatment of variable consideration requires extensive judgment and may result in earlier revenue recognition in certain instances, such as when accounting for implied price concessions or contract renewal options. In other instances, the accounting for variable consideration under the new collectability standard may result in the deferral of recognition when revenues would have been recorded under prior U.S. GAAP, such as when a cloud service provider enters into a long-term contract with a customer who has a poor credit rating and pays for services provided on a monthly basis.

The treatment of variable consideration under the new revenue recognition standard could mean significant changes in policy for cloud service providers.

Allocating the Transaction Price to Each Performance Obligation

Under prior guidance, cloud service providers would use the relative selling price method to allocate the contract price to each contract element or unit of accounting at the inception of a cloud computing arrangement. Once the provider had determined the number of elements or units of accounting in a contract, a hierarchy would be applied to determine a selling price for each unit. Under ASC Topic 605-25-30 [as amended by ASU 2009-13, Revenue Recognition (Topic 605): Multiple-Deliverable Revenue Arrangements], providers must first look to vendor-specific objective evidence (VSOE) of fair value, such as the price charged when the contract element is sold separately. Second, they must look to third-party evidence (TPE) of a selling price, represented by the selling price of a similar good or service sold by some other vendor to similar users. If neither VSOE nor TPE is available, providers must use a best possible estimate of the selling price (BESP) of a given unit of accounting. ASU 2009-13 eliminated the residual method of allocation and urged companies to consider all reasonably available information in determining BESP, if necessary.

Per the new guidance in ASC Topic 606, the transaction price is allocated to each performance obligation in a contract to record revenues in accordance with the amount of consideration that a provider expects to be entitled to receive in exchange for transferring goods or services. Generally, this allocation is based on the relative selling price method, where the stand-alone selling price is determined for each performance obligation at contract inception and is based on “observable prices” rather than a defined hierarchy.

Although ASC Topic 606 does not explicitly follow the hierarchy established by ASU 2009-13 in estimating a stand-alone selling price, the overall process is similar. Preferably, the estimated price is directly observable, such as the price that a cloud service provider offers on a stand-alone basis. Cloud contract elements such as licenses, updates, and technical support, however, are not always offered on a stand-alone basis. Under the new standard, if a stand-alone selling price is not directly observable, providers are required to make estimates based on reasonably available information, such as third-party pricing, entity-specific factors, and market conditions. Again, this is similar to prior U.S. GAAP.

Under the new standard, sales commissions will most likely be capitalized as an incremental contract cost, whereas salaries, bonuses, and general proposal costs will most likely be expensed as incurred.

FASB has outlined three possible, but not required, approaches to estimating stand-alone selling prices including an adjusted market assessment approach, an expected cost plus margin approach, and a residual approach. The suggested use of the residual approach to estimate a stand-alone selling price represents a significant change from prior U.S. GAAP, under which the use of the residual approach was eliminated by ASU 2009-13.

The residual approach for cloud applications.

Selling prices for cloud-based applications can be highly variable, and certain goods and services included in a cloud arrangement, such as the right to upgrade software, may never be sold separately. This creates difficulties when estimating stand-alone selling prices. The residual approach can be used if the stand-alone selling prices of one or more goods or services in a contract are highly variable or uncertain, as long as at least one good or service in the contract does not have a highly variable or uncertain stand-alone selling price. The residual approach estimates the stand-alone selling price of a specific performance obligation as the difference between the transaction price and the observable stand-alone selling prices of other performance obligations in the contract. Using it with cloud computing contracts requires substantial judgment due to their service-oriented nature. For many cloud contracts, there is never an exchange of a good.

Providers can use a combination of approaches to estimate stand-alone selling prices. For example, a cloud service provider can first use the residual approach to provide an estimate of the stand-alone selling prices of all contract elements with highly variable or uncertain selling prices as a whole, then use some other approach to allocate the aggregate stand-alone selling price to the individual contract elements. In short, the reintroduction of the residual approach gives service providers another option for allocating a contract price, but it requires substantial judgment and should be reserved for situations in which stand-alone prices are difficult to estimate.

Accounting for Contract Costs

The new revenue recognition standard will also affect the manner in which cloud service providers account for contract costs. ASU 2014-09 added ASC Topic 340-40, Other Assets and Deferred Costs: Contracts with Customers, which requires the capitalization of the incremental costs of obtaining a contract as well as any direct costs of fulfilling a contract. The capitalized costs are to be amortized in a manner consistent with the transfer of goods or services to the customer.

Under the new standard, sales commissions will most likely be capitalized as an incremental contract cost, whereas salaries, bonuses, and general proposal costs will most likely be expensed as incurred. A brief look into the annual reports of cloud service providers reveals a potential divergence in current practice, where guidance is limited. Both Salesforce and NetSuite state in the disclosure notes to their Summaries of Significant Accounting Policies that they currently capitalize sales commissions and amortize them over the noncancelable terms of customer contracts, but do not provide a detailed breakdown of their cost of revenues. Zendesk, on the other hand, states in the same disclosure notes that the cost of revenue includes personnel costs, such as salaries and bonuses, but it does not disclose any deferred salary commissions.

Companies should revisit their current compensation plans and use sales compensation management software to track sales commissions and determine whether contract costs should be expensed in the period in which they are incurred or capitalized and amortized over time. ASC 340-40 allows the incremental costs of obtaining a contract to be expensed as incurred if the related contract period is one year or less.

Threading a Needle

The new, principles-based revenue recognition guidance will bring about substantial changes in the policies and practices of cloud service providers. Public company cloud service providers should now be fully engaged in the transition, while private company providers should be performing impact assessments to determine the changes that will be required to their accounting information systems. As public companies begin to implement the new standard, however, accountants and managers are finding that it is a more complex process than anticipated. System implementations to automate changes have been pushed into 2018, which may slow implementation for public and private companies.

The accounting complexities in revenue recognition for cloud service providers discussed above support a principles-based framework for recording revenue in which substantial amounts of judgment are required. A reporting system based on judgment can be complex and difficult to implement, as preparers are learning; the implementation process is driving costs much higher than originally expected. Guidance on the new revenue standard is still being issued as questions and concerns arise during the implementation process. Regulators will continue to field questions concerning the revenue standard as they look to ensure that the principles-based standard provides managers with an adequate means to use reliable judgments to capture the economic substance of transactions. Cloud computing stakeholders, including managers, board members, providers, and public accountants, should remain informed of the ongoing advice issued by regulators and any potential impact on the internal and external decision-making process.

Nicholas C. Lynch, PhD is a professor of accountancy at California State University, Chico.
Charles R. Pryor, PhD is an associate professor of accounting at Western Illinois University, Macomb, Ill.