4 Most Common Revenue Recognition Challenges

Revenue recognition has always been complex, and the updated guidance under ASC 606 has introduced some new challenges. In this blog post, we’ll discuss the 4 most common challenges that revenue accountants face in light of ASC 606.

4 revenue recognition problems and solutions

Performance Obligations Are Not Properly Identified

Identifying performance obligations is step two of the 5-step process in the ASC 606 revenue recognition model. The standard defines a performance obligation as a promise to transfer goods or services (or a bundle of products or services) to a customer.

There are two criteria for a good or service to be considered distinct. Once the first criterion has been met, then the second criterion can be considered. The second is more subjective, and accountants will likely spend more time assessing this criterion.

First, a good or service can be considered distinct if the customer can benefit from the good or service on its own or with other resources that are readily available. Determining whether a customer is able to benefit from a good or service on its own is fairly straightforward – when a company regularly sells that good or service on a standalone basis, the product most likely meets this criterion.

The second criterion states the good or service must also be separately distinguishable from other promises in the contract. The objective is to determine whether the nature of the company’s promise is to transfer individual goods or services to the customer, or to transfer combined items as a single performance obligation.

In contracts that contain multiple promises – analysis, critical judgment, and deep understanding of the goods and/or services are required.

When assessing contracts under the ASC 606 standard, accurately determining performance obligations is critical as it directly impacts timing of revenue recognition.

Identifying performance obligations correctly is also crucial as once they have been identified and revenue recognition methodologies are determined, it can be difficult and complicated to change. It is possible that the identification of distinct performance obligations will change the historical patterns of revenue recognition and may require restatement of previously issued financial statements, depending on materiality.

Key Takeaways:
Accurately determining performance obligations is a common problem when implementing ASC 606. Improperly identified performance obligations can be difficult to change and restatement of financial statments may be required.

Incorrect Treatment of Contract Modifications

An objective of the ASC 606 guidance requires accountants to allocate the transaction price of a contract to each performance obligation within the contract. This can be done based on the standalone selling price (SSP) of each performance obligation relative to the total SSP of all performance obligations in the contract. The SSP of a performance obligation is the amount a customer would pay if the distinct goods or services that make up the performance obligation are sold on their own.

SSP is determined during contract origination and is typically not adjusted subsequently. The best evidence of the SSP of goods or services is the observable market price charged for those goods or services when they are sold individually. However, if evidence of a directly observable SSP is absent, the company is required to estimate SSP. When making estimates, accountants should maximize on all observable inputs and consider all available and relevant information (e.g. company-specific information, industry and market information, customer information). In addition, accountants must be consistent when applying the estimation method once the method has been designed and approved.

Contract modifications is a complexity that accountants can face when allocating transaction price and SSP. Contract modifications are changes in the scope and/or transaction price of a contract. A contract modification exists when there are either new or changes to existing enforceable promises and obligations (i.e. performance obligations).

Several ways a company can account for a contract modification:

As a separate contract
As a termination of the existing contract and creation of a new contract
As a part of the existing contract if the remaining goods or services are not distinct (also known as a contract combination)

Accounting for a change in the transaction price after a contract modification depends on the accounting model and estimation method applied to the modification. If some or all of the change in transaction price is allocated to a performance obligation that has already been satisfied (i.e. revenue has already been recognized), the allocated adjustment amount should be reflected as an increase or decrease to revenue, as appropriate, in the period of the adjustment.

Assessing contract modifications requires significant judgment and understanding of the revenue recognition guidance and is crucial as this can change the timing of previously recognized revenue.

Key Takeaways:
Contract modifications are fairly common. Make sure to assess the modification of changes in performance obligations. Ensure that contract modification is properly accounted for as either a separate contract, a termination of the existing contract and creation of a new contract, or as part of the existing contract.

Revenue Disclosures Do Not Match Internal Data

Many public companies report on a metric known as calculated billings. While this is a non-GAAP metric and not required under ASC 606 guidance, many companies will include this calculation based on standard industry practice.

From an accounting perspective, a company’s calculated billings is calculated as revenue + change in deferred revenue = billings. We can refer to this as “financial statement reporting”. However from a company’s internal data perspective, usually owned and driven by Financial Planning & Analysis (FP&A) teams, calculated billings is simply the amount of sales made in a given period. We can refer to this as “internal data reporting”.

Currency revaluation is a challenge that accountants and finance teams can face when properly recognizing revenue. Currency revaluation is the process of converting foreign entities’ financial statments into the currency of the parent entity. The general rule is that any balance sheet account that can be expected to settle within a set amount of time is subject to currency revaluation at period-end.

It is common that calculated billings per financial statement reporting will differ from internal data reporting. This is because internal data billings do not get revalued at each period-end. Rather, cash sales in a given period will retain the FX rate used at the time of the sale. As a result, this can cause a discrepancy in calculated billings between financial statement reporting and internal data reporting.

This discrepancy is especially important for companies that present KPIs and GAAP disclosures in publicly available financial documents (e.g. Press Releases, 10-Q, 10-K). KPIs are based on non-revalued billings, while financial statements are based on revalued billings.

Depending on the company’s ERP or General Ledger system, custom reports can be built and designed to identify the portion of deferred revenue changes period-over-period that are attributable to currency revaluation. This is known as Cumulative Translation Adjustment (CTA). CTA should be added to internal documentation as the key driver or reconciling item causing the calculated billings discrepancy.

Key Takeaways:
If your company has multiple subsidiaries each with different functional currencies, it is likely that the consolidated financial statements will be subject to currency revaluation. Ensure that a Cumulative Translation Adjustment (CTA) report is built into your GL system to ensure easy identification of currency revaluation impacts during month-end close.

revenue recognition problems and solutions

Key Data Lives Separated Across Different Systems

The data necessary for accurate, complete revenue recognition live across siloed solutions. The time when the ERP was enough to handle the needs of Finance has long gone. It’s no longer a single system organizations rely on to get finance data. It’s now a mishmash of homegrown or stand-alone billing and order management systems, numerous payment processors, app stores, and so on. This makes revenue recognition much more complex.

Digital businesses grow faster, and are more operationally flexible, than any that came before. They might start as a subscription business in one country, but within a few years, operate in dozens of countries with different payment infrastructures and currencies, and have added marketplace or merchandise revenue streams.

A single ERP isn’t set up to handle so much complexity and to change so fast, so like in many other business domains, technologists have unbundled once highly-rigid monolithic systems function by function into a vast array of software services.

As a result, revenue recognition becomes this dragged out process of manually gathering data from OMS, billing, PSP, and other solutions in order to piece together the necessary information.

As Leapfin’s JD Bagolor explains in this video:

Key takeaways:

Thanks to a proliferation of operational tools, a number of revenue recognition challenges has emerged:

It’s more difficult to drill down into your summary journal entries
You can link adjustments back to their original transactions thanks to the nature of operational solutions
It’s easy to overwrite internal data and lose its history
If you’re working with millions of transactions every month, revenue recognition in spreadsheets becomes a nightmare

To overcome these challenges, consider implementing a Finance Data Platform that can help you unify data into a single source of truth and process it based on any kind of logic you need.

Leapfin has helped our customers solve these revenue recognition problems mentioned above. If you’d like a free consultation, click here to talk to one of our revenue experts.

Table of Contents