The Ledger

A modern finance blog

The Ledger

Posted by Meagan Mujushi

Build vs Buy: Revenue Automation to Manage ASC 606

A closer look at revenue recognition automation for a public network technology company

Large enterprise companies often deal with high value contracts that span years at a time and contain complex performance obligations and bundling of offerings. While this caters well for a customized sales pitch, it often ends up being difficult to manage in the revenue department. Add in the complications of ASC 606 compliance and the rev rec team is feeling the heat.

We interviewed the Senior Manager of Revenue Assurance at a major public telecom company, discussing his role as Project Manager for the company's ASC 606 project. Part of this project involved consideration of revenue automation using an out-of-the-box revenue management solution over upgrading their existing home grown systems.

 Click for a focused business case analysis download on why they chose RevStream.

 The revenue team at this company existed in a high touch environment. The team relied on a home-grown revenue management solution, supported by internal IT. Over time, the solution was becoming cumbersome for this growing $2.6 billion public company. With the addition of ASC 606 compliance, the accounting team needed a revenue recognition solution that could handle their complex, multi-element arrangements and bundling. This is the buy vs. build story that many large companies face.


We focused our interview with the Revenue Manager around the specific pain points and needs within his company, and how this impacted their decision making:

1. Growing revenue stream pressures in a high touch environment

2. Increasing contract complexity

3. Heavy reliance from finance on IT for system configuration

4. Audit risks and the need to control errors and build for compliance

5. Board of Directors (BOD) and stakeholder concerns around compliance

6. Inefficient financial planning and reporting

Issue 1: Growing revenue stream pressures in a high touch environment

The choice to automate to manage ASC 606

 Q: How much of your revenue is affected by ASC 606?

The revenue affected by 606 is actually a relatively small percentage of our overall revenue. Say 10 to 20%. The problem is, it's in an area of our business that we expect to grow significantly. Traditionally we were a hardware and services company. As we have grown, and expect to grow, much of that is in the software space. The problem with the software component is that it is high touch, a small percentage of revenue but a lot of work. And the percentage is only going to grow.

Q: How did ASC 606 impact your business from a revenue point of view?

Originally we didn’t know what the impact of 606 was. After some research and consulting dollars, we understood it was going to affect the software aspect of our business. Not so much the hardware. 606 is going to pull forward software revenues and affect some of the installation work on big projects. That’s the biggest revenue impact but also commissions and some other minor ones too.

"The appetite to redo the process wasn’t as great for the business, as it is now ...You have to comply with 606 and we couldn’t sustain this without some automation." 

Q: Had ASC 606 not come around, would you have automated?

Without moving to RevStream (their choice for automation), 606, I think, just exacerbated the different ways we sell the product. There is a strong case for automation. We would have automated, just not as quickly. We have, over the last 5 years, brought in companies to see what different offerings they had for revenue recognition. But the appetite to redo the process wasn’t as great, for the business, as it is now. Now, we have to. You don’t have a choice. You have to comply with 606 and we couldn’t sustain this without some automation. Our existing tool would have needed to be substantially tweaked in order to do that. Our thought was, would you rather spend the resources on modifying an existing, old tool or spend the resources to bring in a tool that is state of the art, or at least more state of the art than what we currently use.

One of the times we made an acquisition that was going to double our revenue, that was tough to integrate. Now, if that happens again, we can expand quickly by having everything in the cloud. We’ve had revenue coming from multiple tools and piecing it together. With RevStream we’re most excited about about having the revenue all in one tool.

Issue 2: Increased contract complexity

Business transformation to reduce contract complexity

"Our customers are fairly large. They spend large dollar volumes. They have contracts specifically based around their needs."

Q: As your company has expanded has the revenue growth come from business sales growth or is there another driver?

Our revenues have gone up very significantly, but so has the complexity of our contracts. In a perfect world we would have loved to have become more efficient in our use of resources - in an economies of scale approach. Some of the increase is natural because our sales volume went up, but we also do believe a percentage of it went up because the contracts became more complex.

Some of that is our internal doing. Instead of standardizing our product offerings, or unbundling offerings, we have customized them on a customer by customer basis. Each contract, for instance, may have a unique unbundling instead of following a similar pattern to the previous one.

Q: Do you think this contract complexity trend will continue or will you be able to influence the business team to simplify?

Our customers are fairly large. They spend large dollar volumes. They have contracts specifically based around their needs. Some of the things we offer on one contract are materially not different than another contract. And so to the extent that we could offer them something equivalent - that we have already configured our system for - might be a better solution. That is what we are hoping for the future. With RevStream we will be able to point out more specifically to our sales teams what the impact of having these different arrangements means to our business. We are hoping (over time) to get some normalcy to the contracts we offer.

Issue 3: Heavy reliance from finance on IT for system configuration

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.

Issue 4: Audit risks and the need to control errors and build for compliance

BOD and stakeholders push for automation to manage compliance

Q: Did your Board of Directors have any comments on ASC 606? 

Members on our board want to reduce the risk (of manual systems) to the business, just as any accountant would, and we believe introducing a tool that is formulated specifically for revenue recognition would reduce some of the risk areas around revenue recognition. Even when we explain to the market (investors) that our costs may be up due to implementing a new tool, they understand, they kind of expect it, and they understand it. The same as our board.

Q: Do you think that your Board of Directors' interest in compliance helped the push for automation?

I think it helped. Yeah, I do. They brought it up in our board meetings, they wanted to understand what we were doing, how we were doing it, and also they were more than interested to hear if we were going to automate it in someway. That RevStream is actually going to give our management visibility to our revenue numbers quicker than our existing tool does is key. Our existing tool is more of a batch processing system that happens once a period, at period end. With RevStream, it is more of a day by day where we will be posting transactions and we will have a fairly good view of where our revenue management is at a single point in time.

Issue 5: BOD and stakeholder concerns around compliance

Leveraging audit risk concerns to implement a solution

"Introducing a tool that is formulated specifically for revenue recognition would reduce some of the risk areas around revenue recognition."

Q: Did you use projected growth potential as the reason to automate revenue now, or was there another factor, perhaps ASC 606?

One of the areas was exactly that, so that we can handle some of the new guidelines while also handling projected growth. With the new guidance coming out we figured right now would be the time to look at our tool and see if it's better to maintain our home grown solution or see if there was a better solution off the shelf. If you look into it right now with 606, many companies are going towards more of an automated tool. But 606 may not be the real driver, for us, it is something that has been needed for a while.

Issue 6: Inefficient financial planning and reporting

A single source of truth enables efficient financial planning and reporting

"We’ll be able to comply fairly easily with the SEC requirements."

Q: You mentioned reporting capabilities earlier, how will automation affect your reporting?

With the new 606 there are some fairly significant reporting requirements. Most of the historic data should be able to come directly from reports that we had manually created. The good news is these are standard and are part of RevStream. The data is all in one system. We’ll be able to comply fairly easily with the SEC requirements. And, the CFO is excited by the daily reporting, He is looking forward to real time posting of actual revenues, that’s the biggest piece for him.

Q: How will this impact your day-to-day work? 

My day-to-day is making sure the SEC reports are filed timely and accurately. I do believe this tool will assist us in both areas. The timeliness, if we can speed up our close by one week, even if we don’t file a week earlier, it gives us one more week to verify that the information we’re getting is correct and a week earlier to our auditors, and accuracy obviously. If we have a system that is SOC 2 compliant it gives you just a little bit more security that the data you are publishing is 100% accurate. Not that we have ever had a problem with our previous data but it just gives you a little bit of reassurance.

The telecom company involved had the knowledge and resources to build a viable revenue recognition software program. After fair consideration however, they chose to buy an out of the box solution, mitigating areas of concern expressed both internally and from their BOD. Buy over build, enabled them to move quickly, become self reliant in terms of change management, and have an audit approved system.

Management teams, and even more so in public companies, need dependable, accurate information that they can produce in a timely fashion. Automation does this. 

Further ASC 606 resources:

Start preparing for revenue automation - checklist, worksheet & timeline

Factors to consider when choosing a transition method

Read more:

What is your backup plan for ASC 606? 

How a scalable solution automates bundled contracts

View more: 

Customer Success stories here

Why RevStream  

Share Tweet about this on Twitter Share on LinkedIn Share on Google+ Share on Facebook Email this to someone