Revenue is an important indicator of financial stability and health for any business. For software companies, revenue is usually earned by entering into and completing customer contracts. Since revenue is such an important factor for investors and contracts can last for years, most software companies would prefer to recognize revenue as it is earned, rather than deferring revenue until the contract is complete. However, revenue recognition can only occur if collectability is reasonably assured.
Created by Bi101.com
Within the current revenue recognition framework, collectability is an extremely powerful requirement. Based on rules established by SAB 104, collectability can act as an on/off switch for revenue. If collectability from a customer is assured, then revenue recognition can be flipped “on” and recognized as it is earned, assuming completion of the other criteria. If collectability is not assured, then revenue recognition is flipped “off” and all revenue needs to be deferred until the actual payment is received.
Software companies should determine collectability based on a customer’s credit worthiness. This should be done by evaluating the current financial stability and payment history of a customer. If the payment history is positive, then more weight should be given to the probability of collection. If the payment history is negative, then collectability becomes more questionable and revenue may have to be deferred.
Courtesy of dalcollects.com
In our current economic environment, often times a customer may appear credit worthy but subsequent changes in the business environment may cause that to change. If revenue was recorded under the assumption of customer creditworthiness and this assumption has subsequently changed, revenue should no longer be recognized. It needs to be written off as bad debt.
As we have mentioned previously, if collectability is questionable for the company, then revenue for the entire contract must be deferred until it is collected. For example, a contract contains both a software and PCS component. The software component is prepaid but the PCS will be paid over the life of the contract. Since the customer has questionable credit, even the software sale cannot be recognized until the PCS payment is collected.
This approach seems a little draconian. If the obligation on the software is complete, why can’t revenue be recognized? If this frustrates you, there is hope. As we have mentioned previously, the FASB and IASB have issued a jointed standard on revenue recognition. The new standard removes the power of collectability to be the on/off switch for revenue recognition. Instead, it proposes that collectability focus on the underlying economics of a transaction.
Collectability would now be associated with “performance obligations,” or what we currently refer to as deliverables. Instead of evaluating the collectability of the overall customer, companies would measure the collectability for each separate performance obligation and then recognize revenue as these obligations are completed.
The new standard also changes the rules regarding the amount that can be recognized on each deliverable. Software companies will be required to estimate the payment they expect to receive from a contract using a weighted cash flow analysis that takes into account the probability of payments under different outcomes.
Courtesy of valuationapp.info
These new revenue recognition standards are coming soon and companies need to be prepared. If you would like to discuss how to prepare for the coming changes, please contact us.
[subscribe2]
