Identifying Opportunities for Growth While Remaining Compliant with ASC 606
Topic ASC 606, Revenue from Contracts with Customers, put in place by the Financial Accounting Standards Board (FASB), significantly changes how companies will recognize revenue. ForgeRock needed to understand the importance of their data and the accuracy in revenue recognition to track the overall health of their business to remain compliant and identify opportunities for growth.
They knew that they had a tight timeline to get the ASC 606 implementation completed, and with a lack of resources, time and budget, it was clear these obstacles would delay the project from moving forward. ForgeRock realized they needed a middleware solution that was flexible enough to ensure revenue could be recognized consistently across their business while complying to the new Revenue Recognition Standard (ASC 606). Further, accurately implementing ASC 606 required digging through several years of financial reporting over several years of financial reporting.
Implementing a One-to-one Solution Drastically Improves Business Workflows
ForgeRock was using the Intacct contract module, which has been developed especially for ASC 606. Even before considering ASC 606 requirements in implementing Intacct, the business logic in the Intacct solution would have forced significant logic changes within Salesforce. Changing their entire operating mode and sales process within Salesforce was not acceptable, because it ties directly into Salesforce as a one-to-one. In order to avoid these unwanted changes, ForgeRock had to keep the two systems separate. However, they needed to rely on an API platform that could take all the business logic, combine it and place it in the API service to use it.
This was extremely complicated because ForgeRock has between 10-12 entities in which they have payroll. All of these entities have a capitalization of commissions and a consolidated functional currency. Due to the complexities of their entities, they would need to be divided up between product, SKU’s and terms, and flow through the middleware to be managed properly. There were many moving parts in the design, requiring work flows which included API calls splitting SKU’s into two, then applying a complex residual Standalone Selling Price (SSP), as well as cost accounting.
DIAGRAM: Forgerock RevRec data flow.
On a Data Path to Comparable Historic 606 Reporting
Another large and challenging part of the project was re-stating historical data. They needed to flush, pull out details, and then reconfigure historicals in order to provide comparable historic ASC 606 revenue recognition reporting.
“We had to go all the way back to 2012 because our cost analysis under the life period we chose is four-years. We had to look at everything we were restating. Originally we were restating for 2015 and adopting in 2017, and there was so much information, such as contracts and commissions that needed to be reviewed in order to fully comprehend what the deferred and asset balance as of December 31, 2015 would be under ASC 606.” said John Fernandez, ForgeRock’s chief financial officer.
Bracing for Significant Near-term Revenue Recognition Changes
Clearly, the change in revenue recognition under ASC 606 can materially impact the amount of revenue recognized in any given period, thereby impacting the year-over-year growth rates of a company.
The VC community is still learning about the impact of ASC 606. They are used at SaaS companies in many respects, but the conversations aren’t really happening around this yet. Those that are coming into play are struggling to understand the dramatic impact of the numbers.
“On our numbers, it’s a new world and we will need to perform a complete historical view on year-over-year trending to better understand performance as a company. We need to make sure we understand how to examine the numbers to improve our predictions and what the P&L impact will be with respect to commissions and capitalizing. There’s been a big change, and a lot of resource, money, and work has gone into getting this right” said John Fernandez.
“Eventually, this will all be water under the bridge and everyone will have adjusted to the new standards, but until then, I believe that some investors may be confused. If companies do not do this correctly, then there could even be material restatements and that will certainly be unpleasant for an impacted company. Right now it’s very complicated, at a time when technologies and processes should be getting simpler.”
Many Pain Points Without the Right Platform
“Lots of companies may take a shortcut and hard-code everything, but when they make the initial change they soon find out their methodology is flawed and they may have even missed one of the connections they need to make in accounting, or in the system itself. Errors will arise because they do not have the appropriate piece of middleware that will help them move through it. We looked at other iPaaS solutions; they had similar functionality to do API calls and segmentation but we couldn’t get the use case we wanted from them in a simplistic way.” said John Fernandez
Even with point-to-point, there isn’t a way to queue the messages needed. There would be zero visibility of what is happening on the other end and there would be a lingering question regarding the status of each endpoint. If the API message is generated from the source system and it comes up as an error, and the other system is down, that becomes a big problem. You will need to reprocess, which is another issue in itself.
If ForgeRock hadn’t addressed this with an API integration platform, they would’ve faced many obstacles. For example, they would have to write the APIs for Salesforce and Intacct and develop it on both ends to change the data package. This project couldn’t have been accomplished with ForgeRock’s existing technology providers and they didn’t want to hire an army of developers to build the APIs since that approach is costly, time-consuming, and overall not scalable.
If you break down the total cost of six resources over the course of six months, the project may have reached a spend of one million dollars or more. The Jitterbit platform allowed ForgeRock to meet strict deadlines, stay within budget and not use up valuable resources that are needed for other projects.
“It is tough to imagine not having a platform to help us achieve what we needed to do. We started in June and it was scheduled for completion in September. We would have needed about six resources to meet that deadline.” said Anil Madithati, Senior Manager, Business Applications and Architecture.
You Need a Platform That is Powerful, Fast, Scalable & Reliable
With Jitterbit, ForgeRock is creating a custom API for Intacct; they have a lot of business logic that needs to be implemented around the API. Now it is extremely simple to extract data from one system to another system so that data is readily packaged, updated automatically and moved rapidly to wherever it needs to live.
“You need a platform that can handle the reprocess mechanism. It’s not just about getting it done but also how you scale. If something fails you need a platform that will help queue, auto-processes, and quickly notify an administrator to take immediate action. With Jitterbit everything is automated and creating APIs is a much more simplified way process.” said Anil Madithati.
The company currently has an API for Intacct and another API for Visual Compliance – which is ForgeRock’s legal auditing compliance application – that is used for legal auditing. Contacts, leads and accounts are audited by this system. They also have a dedicated API that extracts on a periodic basis for compliance and then processes it to Salesforce. In total, ForgeRock has four APIs – Intacct, RevSym, Visual Compliance, and Salesforce, with more to come. Jitterbit is acting as the middleware between the Intacct ERP system as well as Salesforce. ForgeRock leverages the Jitterbit API to extract information, such as sales invoices, and sales order data and sends it to RevSym, for ASC 606 compliance, which is implemented through Jitterbit.
ForgeRock is the digital identity management company transforming the way organizations interact securely with customers, employees, devices, and things.
- Lost time and resources due to complexity
- Manually pull data through RevSYM
- Needed a system that could split SKUs into two parts – the license and support components
- Lack of visibility to quoting, pricing and back office
- Salespeople spent too much time chasing data vs. interacting with customers
- No simple, streamlined lead-to-customer-install process
- Each lead required 4 people to turn into a customer install
- Manual order management processes
- Error prone data processes and data duplication
- Concerns about implementing and learning new platforms
- Leverage Jitterbit API to extract sales invoice and sales order and send it over to RevSYM, for ASC 606 compliance
- Achieve compliance without requiring manual intervention to modify business logic or sales processes