ASC 606: Can You Recognize the Revenue?
At the end of 2018, the IASB (International Accounting Standards Board) has said it will close the remaining revenue-recognition loopholes in GAAP for recurring revenue. This will occur through its issuing IFRS 15 globally, and ASC 606, which is specific to the U.S. Both laws equate to tighter rules around recognizing revenue. They apply more rigor to the tests than earlier laws and they must be understood by companies providing services over a period of time — as opposed to transactionally.
These laws have definite implications for MSPs. Rather than go deep into accounting considerations, this post is intended to present, at a high level, the issues that can affect you as an MSP and how they may impact your current accounting treatment of these term contracts.
Broadly, ASC 606 covers five key points when deciding how to recognize term revenue:
- Identifying the contract: Ensuring there is a formal contract in place which specifies the goods or services being delivered in exchange for payment.
- Identifying performance obligations: Within that contract, ensuring there is clarity over the performance of the supplier from a service and timing perspective.
- Determining the transaction price: Again, within the contract, identifying the pricing schedule.
- Allocating the transaction price-to-performance obligations: Combining the price with the performance obligation in a clear contractual sense.
- Timing of the recognition of revenue: Clarifying the timing of the performance obligation so that revenue is only recognized at the point that the payment obligation is evidenced as being delivered.
Admittedly, this is all pretty dry stuff. Why is it so important to an MSP?
It’s simple: This legislation spells the end of spreadsheet-based accounting, where it is easy to edit the answer in response to management pressure to achieve a particular result. All the articles I’ve read about the new legislation discuss the end of hand-crafted revenue models and the need for dependence on contract-to-revenue software to control behaviors with a clear audit trail.
Your software should be able to document these five key points in a continuous business-flow model, but ideally, it should automate revenue recognition in an IFRS 15 and ASC 606-compliant manner — meaning it has the capability to recognize both revenue and cost directly tied to the delivery of performance obligations.
Here are some tips that correspond to the key points above:
- Your contracts with your customers should (ideally) be produced directly by your PSA tool so that the terms are modeled in the PSA database and able to control contract management and revenue recognition. As a minimum, a copy of the executed contract must be loaded into your PSA against the customer record. If you don’t issue formal contracts, you will be in breach.
- The performance obligation needs to be tracked in your PSA. Obviously this is made easier by a system that can generate the contract automatically; if not, the performance obligation needs to be clearly stated and used to acknowledge recognition of revenue.
- The pricing schedule must be contained in the contract. If you are not operating contracts, but only have a set of standard terms, the customer’s acknowledgement of those terms must be evidenced in some way.
- When defining the performance obligation (however you choose to do it), it must link to payment and revenue recognition in a formal manner.
- You can’t use the revenue recognition spreadsheet any more. Your PSA or accounting software has to provide editable evidence showing the link between delivery of the performance obligation and income. This is easier to manage with a PSA tool that also models the work process than it is in an accounting system.
To meet compliance standards, most of us who build PSA software have had to make some significant upgrades to our products. This sort of exercise is required of software makers on a regular basis, but when it comes to compliance with new laws like ASC 606, make sure your PSA software is up to the task, or you may find yourself answering to a government authority, in addition to your customers.
In a career that began in offshore engineering, migrated into investment banking and ended up with the co-founding of a software company 10 years ago, Steve Duckworth, CEO of Harmony PSA, has devoted his career to developing solutions solving project, accounting and business process problems.