In this series on the decision making around supporting ASC 606 with revenue recognition automation software, the project manager assesses the third identified issue, the revenue teams heavy reliance on IT. With a single person assigned to manage the homebuilt ASC 605 system and to work alongside finance, the single point of failure posed a very high risk. Given that finance and accounting is a risk adverse department this issue needed to be addressed.
Choosing to buy over build: mitigation of IT risk
“The single point of failure was one of our biggest concerns. The second one is when you write internal code, you don’t have a SOC 2…”
Q: What legacy systems do you currently have?
Originally we built our own system for ASC 605. It was probably in its fifth iteration. It wasn’t ever really finished being written. That’s the real answer! Initially it took two or three programmers, five to six months for the first iteration. But each couple of months we kept adding on more and more requirements as our contracts become more complex. Our fixes were for; maybe a bug, or some new guidance came out, or the first time we sold a contract with a specific type of unbundling. It was always being tweaked to some extent. We were pretty reliant on IT.
Q: How did you run reports with these legacy systems?
Our home grown solutions were our prime systems. A lot of the reporting out of our own revenue recognition tool was done in another homegrown reporting tool. The reporting tool is really just extracting the data from our revenue recognition tool, and then we would write each of the reports ourselves. Having some of the reports standardized and coming out of RevStream is so much nicer. Accountants always love Excel, and so Excel is our favorite friend. In the past a lot of our systems in the revenue space were created around those tools.
Q: What were your frustrations with your home grown solution?
Some of the frustrations of the home grown solution are the technology it is based on. And also the very limited number of people that absolutely know how it was written. We had an example of when the person that initially wrote it left our company. After he left, to get another person up to speed on the language, or rather methodology that he used to write the code, took a while. The person had to look at the code, understand what it was doing, and figure out the person’s logic so that they could make adjustments. The single point of failure was one of our biggest concerns. The second one is when you write internal code, you don’t have a SOC 2, so you can’t rely on that. You have to have additional certifications or controls to make sure the tool is doing what it is supposed to do. What we have to do is create a lot of manual processes to verify that it does what it is supposed to.
Q: How did you update your accounting rules, or make system changes?
In order to make any changes to our system it was a fairly complicated process. We would create an online ticket, which would go to the IT department. They put it on our priority list, and determined where it fits in with other things. If it is a change because there was a problem with the amount of revenue that is being recognized, such as an error – that is typically fixed almost immediately. Assuming it is an easy fix. If it was an enhancement, say that now we are going to be able to automate something we typically do manually, they took a little bit longer because they are not customer facing or customer impacting, and those items usually take the highest priority.
Continue the story:
Audit risks and the need to control errors and build for compliance
Download the full series of Issues Revenue Management Teams Face – ASC 606
