How a controller at a series-D company thinks about finance data

How a controller at a series-D company thinks about finance data


When our customers share their finance data journeys with us, warts and all, they are understandably sensitive about their imperfections being in the public eye. Today, we’re sharing a Q&A we had with one of our customers. To protect their privacy, their name and company, and a few minor details have been changed.

This is a part of our series: “Notes from the front lines.”

Donna* is the controller at Series-D SaaS company DoubleTrouble*

What were your pain points when you started looking for a solution?

We were using another software system for revenue recognition that was tied to our payment service provider, but it was a black hole. We trusted the data, but it was hard to investigate or reconcile gaps.

As we grew to thousands of invoices per month, and adding custom contracts with many different scenarios, it just wasn’t sufficient.

Why wasn’t that a good approach?

Our ERP has some performance problems. Whenever we change screens or enter data, it can take several seconds to react. We knew that if we went from summary data to thousands of transactions in the ERP, performance would get much worse, and worse yet, we’d be hit by heavy data storage charges.

What advantages did you see in Leapfin’s approach?

Leapfin gives us transaction level data that we can easily summarize and import to the ERP at the end of the month. We can finish revenue at the month-end close in a day. And it doesn’t impact usage or performance of the ERP.

When we need to dig deeper into different revenue accounts, or accounts receivable, or uncollected — it’s all there as granular as we need to go very easily.

What else did you look for in the solutions you considered?

We wanted something easy enough to use that would minimize the impact on our ERP usage.

We needed to be able to apply our own revenue recognition rules and a reporting structure and presentation of data that let us differentiate different types of revenue. For example, we might sell an annual subscription alongside a three-month implementation services contract. We needed to recognize those in separate accounts and amortized over separate schedules.

Why did you disqualify other alternatives?

We looked at using the revenue recognition module of our payment service provider. But it wasn’t a fit because of the number of custom rules we needed and the lack of flexibility and detailed reporting. As an offshoot of a PSP, it wasn’t a system built for accountants.

The PSP revenue recognition system would have required us to make those adjustments manually before importing transactions into our ERP. And again, we knew that posting transaction data to the ERP wasn’t viable.

If you could go back and give yourself advice a year ago, anything else you’d recommend thinking about?

Yes, I’d also think about how you report revenue for internal purposes (like mid-month decision making). It’s never going to reconcile perfectly when you’re using partial data from operational systems running through a data team. Leapfin actually allows us to have clean, reconciled revenue data every day, so we have the opportunity to redesign the way our data teams report internally, but haven’t yet done so. If we’d included them in the discussions up front, we might have already fixed that.