Posts

ASC 606 Part 2

A Brief Look Into Revenue Recognition Standards Part 2

/0 Comments/in , /by

It’s hard to sum up the profound effects that the ASC 606/IFRS 15 Revenue Recognition Standard will have on businesses, as the standard affects nearly every department within nearly every business in nearly every industry. If you have a contract with a customer, you will have to make some changes in order to be compliant with the new GAAP, and the deadline is rapidly approaching.

In part one of this two-part series, we introduced you to the basics of the new standard—who it affects, what it changes, and how to learn more. Today, we will be talking about the basics of the five-step revenue recognition process and offer you additional resources to prepare for making the shift.

Five Steps to Revenue Recognition

One of the most important topics of discussion regarding ASC 606/IFRS 15 is the process in which revenue is recognized. The process consists of the following five-step process starting with contract identification and ending with revenue recognition.

Identify Contract(s) with a Customer

In-Depth AnalysisStep 1: Identify Contracts and Thresholds:

A contract is an agreement between two or more parties that creates enforceable rights and obligations. The guidance in this Topic applies to each contract that has been agreed upon with a customer and meets specified criteria. In some cases, this Topic requires an entity to combine contracts and account for them as one contract. This Topic also provides requirements for the accounting for contract modifications. (See paragraphs 606-10-25-1 through 25-13.)

Identify Performance Obligations in the Contract

In-Depth Analysis: Step 2: Identify performance obligations

A contract includes promises to transfer goods or services to a customer. If those goods or services are distinct, the promises are performance obligations and are accounted for separately. A good or service is distinct if the customer can benefit from the good or service on its own or together with other resources that are readily available to the customer and the entity’s promise to transfer the good or service to the customer is separately identifiable from other promises in the contract. (See paragraphs 606-10-25-14 through 25-22.)

Determine the Transaction Price

In-Depth Analysis: Step 3: Determine the Transaction Price

The transaction price is the amount of consideration in a contract to which an entity expects to be entitled in exchange for transferring promised goods or services to a customer. The transaction price can be a fixed amount of customer consideration, but it may sometimes include variable consideration or consideration in a form other than cash. The transaction price also is adjusted for the effects of the time value of money if the contract includes a significant financing component and for any consideration payable to the customer. If the consideration is variable, an entity estimates the amount of consideration to which it will be entitled in exchange for the promised goods or services. The estimated amount of variable consideration will be included in the transaction price only to the extent that it is probable that a significant reversal in the amount of cumulative revenue recognized will not occur when the uncertainty associated with the variable consideration is subsequently resolved. (See paragraphs 606-10-32-2 through 32-27.)

Allocate the Transaction Price to the Performance Obligations in a Contract

An entity typically allocates the transaction price to each performance obligation on the basis of the relative standalone selling prices of each distinct good or service promised in the contract. If a standalone selling price is not observable, an entity estimates it. Sometimes, the transaction price includes a discount or a variable amount of consideration that relates entirely to a part of the contract. The requirements specify when an entity allocates the discount or variable consideration to one or more, but not all, performance obligations (or distinct goods or services) in the contract. (See paragraphs 606-10-32-28 through 32-41.)

Recognize the Revenue When (or as) the Entity Satisfies a Performance Obligation

An entity recognizes revenue when (or as) it satisfies a performance obligation by transferring a promised good or service to a customer (which is when the customer obtains control of that good or service). The amount of revenue recognized is the amount allocated to the satisfied performance obligation. A performance obligation may be satisfied at a point in time (typically for promises to transfer goods to a customer) or over time (typically for promises to transfer services to a customer). For performance obligations satisfied over time, an entity recognizes revenue over time by selecting an appropriate method for measuring the entity’s progress toward complete satisfaction of that performance obligation. (See paragraphs 606-10-25-23 through 25-30.)

There’s More to Revenue Recognition Than That

The full text of ASC 606 can be found in the FASB Accounting Standards Codification (link to the FASB’s Web site; registration required), and additional guidance is continually announced by FASB/IASB on the topic, with the latest guidance released December 2016: ASU 2016-20, Technical Corrections and Improvements to Update 2014-09, Revenue From Contracts With Customers (issued December 2016).

Are There Gaps In Your Revenue Recognition Process?

As the date rapidly approaches, now is the time to act. Under the new ASC 606 standard, contracts are the basis for how organizations must recognize revenue. This places significant pressure on your accounting system. In addition to handling contract-related data, it must support revenue recognition and allocation, revenue reallocation, and expense amortization.

To determine whether your current software fits these requirements or if gaps exist, ensure it can:

  • Handle revenue allocation, revenue reallocation and expense amortization through configurable templates, not custom scripting.
  • Provide flexibility to select the allocation method based on the type of performance obligation specified in a contract.
  • Easily allow you to configure new types of allocation as your business, its contracts and accounting regulations evolve.

Having the right software in place now can help you avoid headaches later, as nearly all of the software on the market today is ill-equipped to handle the needs of businesses under the new standard, says Brian Sommer of Diginomica:

“For those firms that elect to defer a software upgrade, they might confront 1-2 ugly alternatives . . . develop a custom application to support the new requirements . . . [or] create some makeshift functionality via a combination of CRM, financial package software and spreadsheet tools. Those firms that choose this path might find their RevRec ‘solution’ to be a jumble of potentially risky or temperamental spreadsheets.”

Prepare for ASC 606: Related Resources

ASC 606 Compliance starts with having the right information. Learn more about contract and revenue management software built to handle the needs of your business, be sure to download the following whitepapers, Six Rules for ASC 606 and Why Compliance Can’t Wait, and read up on the following to prepare:

Stay tuned for all of the latest by subscribing to the rinehimerbaker e-newsletter.

Types of Software Delivery Models

What are the Different Software Delivery Methods?

/0 Comments/in /by

Last week, we introduced you to the signs that your organization is outgrowing its accounting software: Not having the reporting you need to grow, manual and error prone processes, mediocre-at-best integration, and lack of speed. For those organizations whose growth has outpaced your software’s ability to handle it, congratulations. Knowing this, however, it’s time to start looking toward the future.

As you begin to look toward new software for your company, one of the first questions you’ll be asking yourself is “How will my software be deployed?” If you’re coming from QuickBooks, it is likely that you worked with their desktop model, which, while great for basic accounting, lacked functionality as you grew and needed additional users in multiple locations.

Three Options to Consider

Knowing this, there are three main options to consider: On-premises, Hosted, and Cloud—all with advantages and criticisms.

On-Premises

With this traditional model, you license software and run it on your own servers. When considering this model, be sure to account for the capital and operating expenses associated with deployment, operations, support, customization, integration, maintenance, and upgrades.

While these costs can be too great for small and mid-sized organizations to sustain, on-premises solutions remain a viable option for some larger companies. These organizations often have a built-out IT infrastructure, investment capital, and expertise to support and maintain major software applications.

Hosted

In a hosted environment, the software physically resides at a remote data center operated by an expert third-party hosting provider. Your team would usually use a product like Citrix to access the software over the Internet and see the screens being generated at the hosting provider. This model eliminates the responsibility of maintaining hardware infrastructure, and therefore can help you avoid large upfront capital expenditures.

But it works by providing you with a unique “instance” of your financial system on a dedicated server. That means you would still face the same costs for customizations, upgrades, integration, and support and service

Multi-Tenant

Also known as “software as a service” (SaaS), these applications offer direct, always-on access to the solution, typically paid for on a per-user/per-month subscription basis. They are multitenant, which means you can unlock only your own data, but you work from a shared system—a single set of resources, application infrastructure, and database.

There are no upfront fees, capital investments, or long-term commitments because you do not buy, license, or manage the underlying hardware, software, or networking infrastructure. Upgrades are performed at no cost to you. Even if you make extensive changes to the system, your customizations “roll over” to work with the new upgrade.

Questions to Ask

When deciding on which delivery model you intend to pursue, it is important to ask yourself and the company who’s helping you choose a few important questions:

  • How long will implementation take?
  • Will customizations be affordable and easy, or time-consuming, painful, and costly?
  • Does the platform and model allow for easy integration?
  • Will the user interface be easy to use for beginners, yet feature rich for power users?
  • How often does the software update?
  • After upgrading, will updates maintain credibility with integrations?
  • Who’s doing the support? How much will it cost?
  • Who’s in control?
  • Do I own my data?
  • Will I need to make a hardware purchase?
  • If I’m using the cloud, how much uptime is guaranteed?
  • If in the cloud, what protections are taken with data?

These are some of the base level questions you’ll need to ask, but not the only ones. Be sure to get everything in writing as part of the service-level agreement. Stay tuned for a comparison of cloud, hosted, and on-premises and their ability to answer each of these questions in a future blog.

The Buyer’s Journey

Making the decision to upgrade accounting software is no small task, and should be taken with the highest gravity. For more information, please download the Buyer’s Guide to Purchasing Accounting Software from our friends at Intacct.