Software for Revenue Recognition
Software for Revenue Recognition has never been more important. Since the FASB and IASB issued a (nearly) united set of standards for Revenue Recognition in May 2014, virtually all entities will need to be aware of the changes to account for revenue correctly. The implementation of these standards gets complicated when you consider there’s really three sets of guidelines: the current rules, the future rules, and the transition to get there. Since Revenue Recognition spans multiple periods by its nature, requiring a change means a single revenue contract may last long enough to be accounted for multiple ways over its life.
The AICPA issued a great guide covering the step-by-step considerations to get started with the new standard. The standards go into effect in 2018 for public companies and 2019 for privately held entities.
At its core, the changes make sense. The FASB has said:
“The core principle is that an entity should recognize revenue to depict the transfer of goods or services to customers in an amount that reflects the consideration to which the entity expects to be entitled in exchange for those goods or services.”
… and has summarized the 5 steps for recognizing the revenue:
- Identify the customer contract
- Determine the obligations of the contract
- Identify the transaction price of the contract
- Allocate price to performance obligations
- Recognize revenue as the performance obligation is met.
Easy! Right? Well, how about an example.
A “Simple” Example
Imagine you’re a software company (ahem) and you sell a license good for 1 year. So far so good: we know the length of the contract is 12 months and we can recognize the revenue over that time. Here our example should be over and we should high-five as we cheerfully watch our debits equal our credits. But the complexity in implementing these standards stems, in part, from the complicated real-world scenarios that tend to creep in.
Imagine in that same software example that the customer buys another license 2 months into the contract. Hmm, so that revenue would need to be spread over the remainder of the contract, wouldn’t it? What if paid-support is rendered to resolve a bug or implement the software? Would that need to be spread over the remainder of the contract also? (Probably not, as it turns out, since services can be treated as a separate obligation.) But what happens if the contract terms change along the way? All these examples are possible on any contract and perhaps not so bad to handle individually. But if your industry is built on contracts life suddenly got complicated.
And lest we forget, there’s still that pesky matter of making the transition. If you’re using spreadsheets today, that’s not easy. If you’re running Intacct – the preferred accounting software of AICPA Business Solutions – you’re in good shape.
Intacct announced an update to the Contract and Revenue Management components to handle the headaches imposed by ASC 606 and IFRS 15. By being fully compliant with the new standards and cleverly using the multiple journals that already exist, Intacct is able to automatically book entries based on the contract that are simultaneously compliant with both the old and the new standards.
Seriously, that’s impressive.
