Recurring Billing System Implementation

What do you focus on first when you start a recurring billing system implementation?

Steve Keifer:

Max, I imagine we have a variety of folks listening, some of which may be considering implementing a recurring billing system this year, some of which might just be more interested about how this stuff works, but maybe you could just give us a high-level view of what’s involved in that kind of project. There are three, four, and five kinds of major phases of things that folks need to do.

Max Rosenberg:

When we first kick off a project the main goal is to identify the use cases and solve these use cases. When we have these initial discussions, we really ask clients to think about how can they bucket their existing customers into similar groups? Do you have one group that’s monthly recurring and then another that is usage-based and then another that has tiered pricing? We’re looking for specifics so that we can solve one use case and then it basically rolls into the other dozens or hundreds of customers that are similar. We solve it once and then we can use it for the rest.

Something else that we really get into, especially with these first implementations is what’s the difference between their legacy business and where they want to be. Switching to a new billing system really gives an opportunity to standardize and provide some more structure for how they want to close these deals going forward. We have a lot of young companies that are very flexible with their pricing. It’s good because it makes it easier to win new businesses you’re trying to grow. The challenge for the billing and the accounting team is, you know, how do we deal with this? How do we automate sending out these invoices or automate the rev rec when every deal is unique? It makes it really hard. Those are the conversations that we have initially. We need to solve for your existing business because we will load all of your in-flight subscriptions. If you’re one year into a three-year contract, then for years two and year three, you will want your billing system to send out those invoices and recognize that revenue. Also, if you sign a new deal in six months, you want it to be set up to have whatever that future state structure is. Depending upon where a business is coming from and where they want to be, it can be very complex. It can be a lot more standardized. It really depends where they’re coming from and where they want to be.

In terms of the initial phase, going back to these buckets we’ve seen so many implementations. We know that if a customer starts to talk down a certain path, we can anticipate what they’re actually gonna wanna do. So we’re pretty good about asking the questions to validate what we think that a customer’s saying. A lot of the nomenclature going from one system to another, you might use the same words, but they might mean something different. Billing, does that mean you’re charging the credit card or does that mean you’re sending the invoice

There are nuances like this that we really get into. Throughout the whole process, there are little bits of training.  We want to make sure that the customer knows how Ordway works. The better that the customer is with Ordway, the more that they are going to bring to us what is relevant.  That is as opposed to us trying to tease out what is relevant. Once we identify these buckets, we have the client bring real-life contracts.

We recreate them in Ordway historically. This is the validation and the proof that what Ordway is going to do from the billing invoice creation perspective, and from a rev rec perspective, matches what they’re expecting. Once we have those structures good, the client can really go live at this point with new business. We have some clients that want to go live only with new business.  The universe of in-flight subscriptions, we do as a second phase. However, sometimes we do have clients that want to go live with everything at once.

How do you go about implementing the future state design that you develop in the initial phases?  What types of data migration, system integration, and functional testing are required? 

Steve Keifer:

So to recap, you document the current state for invoice-to-pay and then identify what the future state should look like.  What happens next?

Max Rosenberg:

The next phase of the project is more of a data collection transformation exercise where we’re pulling the customer data, the existing subscription data, the open invoices data, all of that, and loading it. It is really just about getting the data, making sure it’s clean, and bringing it into the system. Again, it can be easy and straightforward if there’s clean data. If there isn’t clean data, sometimes some of the challenges that we see are in the CRM, whether it’s Salesforce or HubSpot. The deal that’s closed isn’t what was actually billed. In those situations, the client typically has to go back and explore the Salesforce data correct? Or do they may have to go into their QuickBooks, NetSuite, or Sage Intacct to see what were we actually invoicing for and do some work to give us the right data. At the end of the day, if the subscription goes in incorrectly, then the word the invoices the rev rec is not going to be correct either. The cleaner the data is, the easier, the faster that the implementation goes.

Once we have all this data and itis loaded into Ordway, then we move to Go Live. At this point, we do an exercise to align deferred revenue. We review customer by customer. Within Ordway, we can see in the future post-go Live, which revenue is going to be recognized, which revenue going to be invoiced. Based on Ordway’s data, we know deferred revenue should be X for this customer. There’s an exercise where we compare that deferred revenue to what the client was previously tracking for each of these customers. There might be a little variance, for example, it might be due to a proration on rev rec. If a contract starts on the 15th of the month, then a lot of clients will just book a full month’s worth of rev rec. Ordway, because it’s all automated, we’re going prorate for a half month of rev rec, and as a result there might have a little variance.

However, sometimes there are recurring rev rec journal entries that are set up in the GL. If there is a subscription change, like an upsell mid-contract, and the recurring revenue entry isn’t also updated, then you might have an expanding variance that increases over time. Going through this implementation, we’ll catch those. We’ll be able to fix them and go live. The other big action is on the AR side.  We will bring in all the unpaid invoices into Ordway. This will make sure that Ordway’s AR and aging match what the client’s expecting. It will also allow Ordway to send out statements, dunning and collections notices for these open invoices.  It ensures that the billing and collections team can live fully out of Ordway. They don’t have to live out of Ordway and their legacy system at the same time.

How long does it take to implement a recurring billing system?

Steve Keifer:
That’s a pretty long list of stuff. If I put my consulting speak on sort of current state design, future state design, data migration, integrations, testing, reconciliation, data cleanup not only for billing, but in a lot of cases, the same systems being used for rev rec, accounts receivable, all that stuff. So my next question is, how long does it take for a recurring billing system implementation? How many years does it take to go live? What’s a typical kind of project length you see, let’s say it’s a hundred million dollar SaaS company or 10 million dollar SaaS company, and beyond the data migration, like what are kind of the key things that slow it down the most, if any?

Max Rosenberg:
We target three months start to finish. There are a combination of factors that impact the project length – most important is client availability. The more that we’re able to meet in the beginning, the faster we get to that solution and the use cases. Then we can move more to working offline for the data validation and the data loading. We don’t need one-on-one calls for that as much. If a client is able to meet every day of the week, we can solve the use case in a week and be done with it. Then we just move on to the data portion after that. But in most cases, clients have their regular day job, and this is just part of that. If we can meet two or three times a week for an hour and a half, two hours, we could probably get the use cases solution within the first two weeks.

What are some of the biggest issues that might delay a recurring billing system implementation project?  CRM and ERP integration?

Steve Keifer:
Three months is really fast.  I was at a company recently which deployed Netsuite’s billing system and the project took several years to go live.  What are some of the things that can go wrong and delay a recurring billing system implementation?

Max Rosenberg:
The timing depends a lot upon the integrations.  If we’re integrating with Salesforce, clients either have an in-house Salesforce admin or Salesforce consultants. Now, we’re coordinating schedules with additional people. On the Salesforce side, typically clients have an existing process and there’s a whole discussion about how flexible are they with their existing process. Do you want sales reps to have no changes to thie process? In which case it’s a little more work on our side to tie everything. It’s a data mapping exercise, but if order we need a piece of data, and that data doesn’t exist in Salesforce today, then clearly we need to either create a field or a flow, something automated that’s going to populate that sort of it can receive it.  If a client wants no change, it’s a little more work on the Salesforce side.  If the client is a little flexible on the Salesforce side, then we have a really good out-of-the-box solution. We call it plan picker. It’s basically a menu that sales reps can choose these products.  We can customize what they’re able to change and what they’re not able to change. For example, maybe you don’t want to allow a sales rep ever to be able to change the list price if they want to change the price. Instead, they have to add a discount. Then it’s easier to track who’s giving discounts as opposed to just a lower list price. It’s all customizable. Obviously, there’s a little bit of training that goes into anything like that.

On the GL side, integrating with QuickBooks, Intact, Xero, NetSuite, the integration is not as complex. It’s less users doing stuff and it’s more just data transition. At a high level, we can either integrate by sending the actual transaction objects, so an invoice is created in the order of way, and that invoice is created in NetSuite. Or we can sync journal entries. Where is the system of record for the actual transactions and the journal entries associated with all of this transactions?  That’s what would get integrated with the GLs. It really depends on what’s happening – which systems we’re integrating with and what the flexibility is. Going back to how long does this take? Integrating with a GL that might be a one call thing. But if there’s a consultant that manages their GL, it might take a week to schedule that call. It might need to go through some level of approval for which of these two solutions do we want to use.

On the GL side, integrating with QuickBooks, Sage Intacct, Xero, NetSuite, the integration is not as complex. It’s less users doing stuff and it’s more just data transition. At a high level, we can either integrate by sending the actual transaction objects, so an invoice is created in the order of way, and that invoice is created in NetSuite. Or we can sync journal entries. Where is the system of record for the actual transactions and the journal entries associated with all of this transactions?  That’s what would get integrated with the GLs. It really depends on what’s happening – which systems we’re integrating with and what the flexibility is. Going back to how long does this take? Integrating with a GL that might be a one call thing. But if there’s a consultant that manages their GL, it might take a week to schedule that call. It might need to go through some level of approval for which of these two solutions do we want to use.

We target three months at the end of the day. The fastest that we’ve done is two and a half, three weeks for someone that was ready to go. They had their data and it’s totally manageable. For larger projects, occasionally it does go longer, for example, if you have multi-entity. We’ve had clients that have six or seven entities. They want to go live one entity at a time. In that scenario, you really can’t go live in three months with all entities. We’re live with at least one of the entities in the first three months, but then it’s probably one entity a month after that just to stagger it.

Steve Keifer:

Resource availability, integrations, and data quality are all factors. I imagine that they’re simultaneously implementing a new ERP system or CPQ or something that adds just even more complexity to it. You mentioned something really interesting, though, about the availability of the resources and like the Salesforce administrator. So let’s drill into that a little more like.

Who is typically on the project team for a recurring billing system implementation?  Is it primarily accounting and finance?

Steve Keifer:

Who’s the project team? Because most of the small SaaS companies I’ve been at, you’re lucky if there’s one full-time person working on billing in AR. It’s usually a fraction of a person in finance. So as you mentioned, this is a part of people’s day jobs. Like who’s the core team? Who’s kind of the extended team that typically get involved in these projects?

Max Rosenberg:

We see a variety and that’s part of those initial calls to figure out who’s the owner of what. As part of our kickoff, we have a checklist of who on the client side is responsible for making decisions on things like billing. Who’s going to validate that the invoice and cadence is correct? Revenue recognition? Who’s going to validate that the revenue schedules in Ordway are correct? Who’s going to provide the correct chart of accounts?

Typically there is a project manager. They are responsible for making sure that we’re going to go live on time and that everyone on their team is showing up and deliverables are being met. The project manager may also be the billing expert. They might have multiple roles. For example, we just kicked off a client where they have one project manager running the calls, but they have another person who is a project manager on the customer side.

It’s really good because it’s a small number of people, you know, it gets more challenging when you have more people just because of the coordination of who’s available for what call. What are we going to discuss on this call? We can go use case by use case.  We need the revenue person when we’re validating this stuff. If it’s the same person, great. But at the end of the day, typically there is a billing person and there is typically a finance/accounting person. Those are the two most important people. Without them, we’re stuck because we can’t validate that the billing and revenue schedules are accurate. We can give our two cents our best guess it but we cannot say without the client giving the thumbs up that yeah, this is correct.  Billing and accounting/finance. And then that’s really it.

What other teams outside of finance and accounting might be involved in a recurring billing system implementation? 

Steve Keifer:

How about rev ops, product management, and customer success? Do those folks ever get involved in the implementation project or is it more after it goes live?

Max Rosenberg:

Rev ops a bit more. They all have their two cents in terms of when we’re doing the Salesforce integration, they might have a say there. But a lot of that, like the customer success, we try to have those conversations during implementation because customer success often has additional requirements that come. We love to get those before it go live, but sometimes they come in after.

An example would be we want to run a report on aging, but we want to group it by customer success manager. If Ordway doesn’t have a custom field for customer success manager, we obviously can’t run the report yet. It’s a simple exercise in this example. We create the custom field, load the data for CSM by customer, and then we can run the report. But the sooner we have these people involved with their two cents, a lot of it ends up being reporting requirements. We want to have that data coming from Salesforce. Does that field exist in Salesforce? If it doesn’t now it also needs to be created in Salesforce and map it to Ordway. We have a different client right now where it’s not two people, it is 12 people that are involved. It’s a little more challenging because we really need to drill in who is the decision maker. We know we’re going to have a lot of opinions. We’re going to have a lot of people that have comments and would like things to be one way or the other. But at the end of the day, if we don’t have one person that says, this is what we’re doing, then it gets a little challenging.