Case Study: Software and Postcontract Customer Support (PCS)

By September 21, 2016Case Study

Many software license sales also include other services such as phone support and periodic software updates, collectively referred to as postcontract customer support (PCS). Under Accounting Standards Codification (ASC) 985-605, unique PCS accounting treatment was explicitly defined and exclusive to the software industry. ASC 606 on the other hand, treats the distinct elements of PCS like other performance obligations within a contract and does not subject PCS to industry-specific guidance. Because the accounting treatment under ASC 606 is potentially different from that of ASC 605, this case study will follow a typical software license sale through each of the five steps of the revenue recognition process, from first identifying the contract through to revenue recognition. Links to other RevenueHub articles are cross-referenced at the end of the article under the heading, “Other RevenueHub Articles Central to Case Analysis,” for further reading on various related topics.


Background Information

ArCADecture Corporation (ArCAD) develops software suites for design professionals and architects. Its flagship software package, ArCADecture, is a robust software program that allows architects and engineers to design all aspects of a building, from structure to plumbing to cosmetic interior design. ArCADecture is an off-the-shelf software suite, with no end-user customization. Periodically, ArCAD provides bug fixes and minor updates on a “when-and-if” basis, traditionally occurring over the three years following the initial version release. There is no set pattern for these releases—some updates are released within a few days of each other, while others are months apart. ArCAD has historically established vendor-specific objective evidence (VSOE) for these bug fixes and updates at $500. A completely new version of ArCADecture is released every two years. The newest version, ArCADecture V, was released on November 1, 20X0 and currently sells for $5,000 per package, which includes $4,500 for the perpetual software license and $500 specifically for bug fixes and updates. ArCAD generally gives a 4% discount to firms that buy large quantities of licenses at a time—there is no official policy, but historically single sales of 100 or more licenses have merited the 4% discount. ArCAD offers a 24-hour priority phone support subscription for $100 per license to any ArCADecture user. This priority phone support is available for purchase at any time, but is only valid for the three years after the initial version release. Like most companies in its industry, ArCAD does not track phone support usage data of its customers relative to the initial purchase of ArCADecture software. ArCAD has a December 31 year-end.

Frank, Lloyd, & Wright LLP (FLW), a prominent Chicago architecture and structural engineering firm, was so impressed with ArCADecture III over the past 4 years that it decided to upgrade to the newest edition. The contract is outlined in the following table:

1.2

FLW purchased goods and services under the contract for a total price of $2,500,000 on February 1, 20X1. The sales contract was negotiated to include 500 perpetual licenses of ArCADecture V along with the priority 24-hour phone support for each license. Also included in the sale was one terabyte (TB) of proprietary ArCADecture cloud storage per license for two years to facilitate file sharing. ArCAD only offers cloud storage to large corporate clients, such as FLW, when included as part of a high-volume purchase. Due to ArCAD’s business practices, FLW has a valid expectation of bug fixes, periodic updates, and priority support through November 1, 20X3, three years from the initial ArCADecture V release. FLW purchased implementation services from a third party provider.

Accounting Analysis

Because this sale will result in revenue from a contract with a customer, ArCAD must use the five-step approach outlined in ASC 606 to recognize revenue.

Step One: Identify the Contract

ArCAD and FLW signed a legally enforceable contract that meets all the ASC 606 requirements of a contract, detailed in the preceding paragraphs. Given this information, ArCAD identifies this transaction as a contract with a customer.

Step Two: Identify Distinct Performance Obligations

Once the contract is identified, ASC 606 requires ArCAD to identify the goods and services transferred to FLW and group them into distinct performance obligations. ArCAD identifies the following promised goods and services as part of the transaction:

  • 500 ArCADecture V perpetual software licenses
  • Periodic updates and bug fixes through November 20X3
  • Priority 24-hour technical support through November 20X3
  • One TB of cloud data storage per license for two years

ArCAD must identify performance obligations composed of these goods and services. If any good or service is not (A) capable of being distinct or (B) distinct within the context of the contract, the goods or services must be combined until both these requirements are met.

(A) Capable of Being Distinct

A good or service is capable of being distinct if it provides a benefit to the customer either on its own or in conjunction with something that is readily accessible to the customer. The ArCADecture V software provides its own benefit; the updates, cloud storage, and phone support each provide separate benefits in conjunction with the ArCADecture V software, which will be delivered immediately and thus is readily available. Therefore, each of the four goods and services is capable of being distinct.

(B) Distinct Within the Context of the Contract

Although these goods and services are capable of being distinct, ArCAD must ensure that they are distinct within the context of the contract. ASC 606-10-25-21 provides three factors that may indicate that a promised good or service is not distinct within the context of the contract.

  1. If a good or service is used as an input to produce an output, such as screws and wood (inputs) when building a house (output), the goods and services are not distinct within the context of the contract. We see that none of the four promised goods or services are inputs to any other output. All four are individual outputs that FLW expects to receive.
  2. If one of the goods or services significantly modifies another good or service in the contract, they are not distinct. Phone support enhances software usability, but does not modify anything. The bug fixes and periodic updates may slightly modify the ArCADecture V software, but not significantly—the software would still be functional without the updates. None of the four promised goods or services significantly modifies another.
  3. If any of the goods and services within the contract are highly dependent upon or highly interrelated with each other, they are not distinct within the context of the contract. While each of the four goods or services are related and meant to be used together, none of the goods or services would lose core functionality or utility if the other items were removed from the contract. In the context of these facts and circumstances, none of the goods or services are highly interrelated or interdependent.

Because each of the four items are both capable of being distinct and distinct within the context of the contract, ArCAD determines that each is a separate performance obligation. In this sense, PCS is somewhat of a misnomer; under ASC 606, the distinct elements of “postcontract customer support” are actually part of the contract itself. For the remainder of this case study, the following numbers and names will be used to identify the four performance obligations:

  • 500 ArCADecture V perpetual software licenses
  • Periodic bug fixes and updates
  • 24-hour priority phone support
  • 1 TB cloud storage per license

Step Three: Determine the Transaction Price

The total consideration to be paid by FLW to ArCAD is $2.5 million, in exchange for the previously mentioned goods and services. Therefore, the transaction price is $2.5 million. The full $2.5 million is made up of fixed consideration; that is, there is no variable consideration.

Step Four: Allocate the Transaction Price

The $2.5 million total transaction price must be allocated to each of the four performance obligations based on their relative standalone selling prices. If a standalone selling price (SSP) is not directly observable, ASC 606 allows for any reasonable estimation method that results in a justifiable and accurate representation of standalone selling price. ASC 606 does, however, explicitly give three estimation methods that should be considered: (A) Adjusted Market Assessment Method, (B) Expected Cost plus Margin Method, and (C) Residual Method.

(1) 500 ArCADecture V perpetual software licenses

The standalone selling price of the ArCADecture V software is directly observable: $4,500 per license. However, as noted in the case facts, ArCAD historically gives a 4% discount to customers that purchase licenses in large quantities. Therefore, the standalone selling price of 500 ArCADecture V licenses is estimated to be 96% of $4,500 x 500 licenses, or a total of $2,160,000.

(2) Periodic bug fixes and updates

The standalone selling price of the bug fixes and updates is also directly observable: $500 per license. The 4% volume discount is also applicable to this performance obligation. The standalone selling price of the bug fixes and updates for 500 software licenses is estimated to be 96% of $500 x 500 licenses, or a total of $240,000.

(3) 24-hour priority phone support

This standalone selling price is observable because it is sold separately to other customers for $100 per license. Therefore, the standalone selling price for priority support for 500 licenses is $50,000.

(4) 1 TB cloud storage per license

Because ArCAD only offers cloud storage to high-volume customers, there is no directly observable standalone selling price, and ArCAD must make an estimate. Using the adjusted market assessment approach, ASC 606 requires entities to reference existing observable markets for an initial estimate of standalone selling price, then adjust the initial estimate for an entity’s or market’s specific circumstances. ArCAD has found a number of companies offering cloud storage services. For example, 1TB of storage for 1 year is available through Macrofirm for $85 and through Dumpbucket for $99. ArCAD uses these prices as a benchmark, and determines that $100 per user per year for 1TB of storage seems reasonable for its business in a non-cloud storage industry. The standalone price for this performance obligation is estimated at $100,000 (2 years x 500 users x $100).

The sum of the individual standalone selling prices, or $2,550,000, exceeds the transaction price of $2,500,000. The transaction price must be allocated to performance obligations based on their relative standalone selling prices. The following table illustrates the allocation:

table-2

Step Five: Recognize Revenue

When recognizing revenue, ArCAD must first determine if the revenue allocated to each performance obligation should be recognized at a point in time or over time. If revenue is recognized over time, the pattern of revenue recognition must also be established.

Over time vs. Point in time

A performance obligation that meets any one of the three criteria in ASC 606-10-25-27 must recognize revenue over time. The criteria are (A) the customer simultaneously receives and consumes the benefit as the entity performs the obligation, (B) the customer controls the asset as the entity creates or enhances it, and (C) the entity has no alternative use for the asset and the entity can enforce their right to payment for the performance completed to date.

(1) 500 ArCADecture V perpetual software licenses

The first performance obligation to deliver 500 ArCADecture V perpetual software licenses is a “right to use” license, not a “right to access” license. For more information on these types of licenses, see RevenueHub article “Licenses for Intellectual Property.” Thus, ArCAD recognizes revenue when ArCAD transfers control of the software licenses to FLW upon delivery, which occurred at the time of sale. For information on determining transfer of control, see the RevenueHub article “Determining Transfer of Control.”

(2) Periodic bug fixes and updates

The nature of this promise is a “stand-ready” obligation, the revenue of which is recognized over time. The benefits of the periodic bug fixes and updates are concurrently received and consumed. For added clarity on this point, ASC 606-10-55-6 suggests that ArCAD consider whether or not another entity would need to “substantially reperform the work that [ArCAD] has completed to date if that other entity were to fulfill the remaining performance obligation to the customer.” Another entity could continue to release bug fixes and updates at any time without substantially reperforming the work ArCAD had completed to date, and therefore this benefit is received and consumed simultaneously. The periodic updates performance obligation should be recognized over time because at least one criterion is met.

(3) 24-hour priority phone support

The third performance obligation, 24-hour priority support, is also a “stand-ready” obligation. The benefit received by FLW is the ability to use the support service when needed through November 20X3. This benefit is received and consumed simultaneously, and the first criterion is met. This performance obligation meets at least one of the criteria, and the revenue must be recognized over time.

(4) 1 TB cloud storage per license

The fourth performance obligation, cloud storage for 2 years, meets the first “over-time” criterion as well: FLW consumes the benefit, which is the ability to store and access files on a remote server, as the benefit is received. The revenue from the cloud storage must be recognized over time.

In summary, only the ArCADecture V perpetual software license revenue is recognized at a point in time: when control of the software transfers from ArCAD to FLW. The remaining performance obligations are recognized over time.

Pattern of Recognition

ASC 606 allows entities to use either the input method or the output method when determining the recognition pattern, and the method must be true to the substance and economics of the transaction. A reliable measure of performance obligation completion must also be used with each method. Similar performance obligations within a contract and between contracts must use the same method. For example, if the software updates between ArCAD and FLW use the input method with time as a measure, then ArCAD must use the same method and measure for all other ArCADecture V updates with any customer. For more information on using and deciding between these methods, see the RevenueHub article “Input versus Output Methods.”

(1) 500 ArCADecture V perpetual software licenses

A pattern of recognition analysis is not applicable given that the software license revenue is recognized at a point in time.

(2) Periodic bug fixes and updates

The periodic updates are provided on a when-and-if basis and expected to occur through November 1, 20X3, as a “stand-ready” obligation. There is no way of knowing at contract inception how many updates will be released and at what times, so the output method using the number/timing of update releases as a measure is impractical. FLW receives the benefit of this “stand-ready” software updates obligation continually over the 33-month period. The revenue from this performance obligation should be recognized using the output method with time as the measure. This results in recognizing revenue on a straight-line basis from contract inception until the time that updates are expected to cease, or for a total of 33 months (Feb 1, 20X1 through Nov 1, 20X3).

(3) 24-hour priority phone support

Alternative 1. The 24-hour priority phone support performance obligation is also available through November 20X3. FLW receives the benefit of this stand-ready service continually over the 33-month period. The output method is appropriate with time as a measure. ArCAD will recognize revenue from the priority phone support on a straight-line basis over 33 months.

Alternative 2. ASC 606 does allow for a new pattern of recognition that was not available under ASC 605, provided that ArCAD has collected relevant data. If ArCAD were to track phone support usage data for all similar contracts, it may be able to accurately predict when customers actually receive the benefit of support over the 33-month term. For example, ArCAD may find that as customers are still learning the software, the need for phone support services may be greater in year one and could decrease in years two and three. While a customer receives the benefit of this stand-ready obligation for a period of 33 months, ArCAD may be able to show that a customer receives more benefit during the period in which the customer’s employees use the support service more often, or in the first 12 months. Thus, ArCAD may determine that the output method and the historical usage data measure most accurately depicts the performance of this phone support obligation. Assuming the newly collected data supported an 80/20/0 pattern of usage during the first year, second year, and remaining period, 80% of the allocated transaction price will be recognized on a straight-line basis for months 1 through 12, and 20% of the allocated transaction price will be recognized on a straight-line basis for months 13 through 24, with no allocation to months 25 through 33.

Recommendation. We recommend that ArCAD compare the costs of tracking phone support usage data to the benefit of potential acceleration of revenue recognition for future contracts. ArCAD may find that a justifiable acceleration of revenue more accurately represents the substance of the transaction, and they may conclude the benefit is enough to warrant the added data collection costs. However, because that information is not currently available to ArCAD, time should be used as a measure, instead of usage, to recognize the phone support revenue on a straight-line basis over 33 months. This would also likely decrease operational burden and audit risk associated with justifying and supporting the accelerated approach.

(4) 1 TB cloud storage per license

The cloud storage performance obligation is also a stand-ready obligation. FLW receives the benefit of storage equally throughout the 24-month subscription period. Therefore, the revenue for the cloud storage service will be recognized on a straight-line basis over 24 months, using the output method and time as the measure.

The following section summarizes the entire transaction.

Transaction Summary

table-3

Diversity in Thought

Some practitioners and accounting firms are exploring an approach where all PCS elements with similar service periods (e.g. each service is provided for 24 months) are a single performance obligation. Their reasoning is that PCS, including updates, maintenance, and technical support, is really a single package of integrated services to the customer – the nature of which is a stand-ready obligation over the maintenance term. Drawing on what the practitioners and firms believe to be an analogous situation in the professional services industry, a firm would not split professional services into individual components such as planning, configuration, quality control, etc. Instead, these services would be treated as a single performance obligation because the services are sold and packaged as a single, integrated service. In this case, they are not distinct within the context of the contract.

Additionally, Transition Resource Group (TRG) Memo 48 regarding “customer options for additional goods and services” uses an example that may be analogized to Software and PCS contracts. The example in the TRG memo describes a situation where a business has contracted with an IT outsourcing company to perform a variety of activities for the business. Activities include computer processing on a remote server, managing a software portfolio, and other employee support functions. TRG memo 48, paragraph 31 states, “The staff (and many stakeholders in this industry) view the type of arrangement above as being a single performance obligation (each of the underlying activities are not distinct) for the entire contract term. The staff and those stakeholders think that the nature of the promise is to provide a single continuous integrated service for the contract term” (emphasis added). According to this example, the various activities may be a single performance obligation because they are not distinct within the context of the contract. In many cases, PCS is also made up of multiple promised activities, but sold as a single, continuous, integrated service along with the main software. The example in the TRG memo suggests that PCS may still be viewed as a single performance obligation, as it was under ASC 985-605.

If this perspective were to be used in the case of ArCAD’s software sales to FLW, the accounting treatment may change. ArCAD may group the phone support and updates into a single performance obligation, as they each last for 33 months and may be indistinguishable elements of an integrated support service called “PCS.” ArCAD likely has established observable SSP for the PCS of $680 per license under ASC 605, or $340,000 total. The cloud storage would be separate, as the contract period is 24 months, and the standalone selling price would remain $100 per year. The software license itself would also be a separate performance obligation, but ArCAD would likely view the price as $5,000 – $680 = $4,320 per license. With the 4% discount, the allocation of the transaction price and revenue recognition are as follows:

table-4

table-5

Comparison to 605

Many differences exist between ASC 605 and 606 when accounting for software. Under ASC 605, Software and PCS have industry-specific guidance, whereas in ASC 606 they do not. Under ASC 605, ArCAD must acquire VSOE to determine that PCS is separable from the software license, and this VSOE amount is used to allocate revenue to PCS. Assuming VSOE is obtained and PCS is separable, ArCAD would recognize revenue on a straight-line basis over time. Under ASC 606, ArCAD treats each distinct element of PCS as a separate performance obligation, resulting in more performance obligations. ASC 606 provides multiple methods for estimating standalone selling price and, potentially, multiple patterns of revenue recognition over time rather than simply straight-line as required by ASC 605. Finally, under ASC 605 the residual approach is generally used to allocate revenue to the software license element after fair value has been allocated to the undelivered items. In contrast, the residual method may be used as an estimate of SSP for any performance obligation (not exclusively delivered elements) under ASC 606, provided certain criteria are met.

Other RevenueHub Articles Central to Case Analysis

Identifying Promised Goods and Services

Stand-Ready Obligations

Distinct within the Context of the Contract

Standalone Selling Prices

Revenue Recognition over Time

Licenses for Intellectual Property

Determining Transfer of Control

Input versus Output Methods

SEC Makes TRG Discussions Authoritative


Resources Consulted

mm

Author Cole Moffat

Cole was born and raised in the northern suburbs of Chicago. He loves music; Cole started studying piano at the Music Institute of Chicago when he was four and currently sings in the BYU Concert Choir.

More posts by Cole Moffat