Article Real-time SaaS Financial Reporting for Fundraising with Mike Lemberg, CFO Aurora Payments

Our CTO and Co-Founder Jason Dubaniewicz recently sat down with Mike Lemberg, former CFO of Partnerize, to discuss key transitions that many companies experience.

These include moving from a commission-based model to a SaaS model, implementing pricing tiers based on transaction volume using historical data, and facing challenges in reporting during fundraising. The need for accurate #pipeline metrics and point-in-time reporting has never been so clear!

Partnerize: Background & Operational Cleanup

Jason Dubaniewicz: Good afternoon, and welcome to the TrueRev FinOps podcast. Today we have Mike Lemberg talking about his time as CFO at Parnerize. Welcome to the podcast Mike!

Mike Lemberg: Glad to be here.

JD: Let's dive right in. Can you give us a little background on working through the different phases of growth at Partnerize?

ML: Sounds good. When I joined Partnerize it was a mid to late stage venture - we had some really cool products and great customers, and it was growing with them. Operationally, it needed a lot of TLC. Phase one was fixing the P&L and go-to-market pricing. After that, we were able to double the growth rate and then get to break even. We then raised money initially to buy a company, ended up raising money and buying a different company. All in all, over that time we grew three folds through a combination of M&A and organic growth.

JD: Okay, and that was three folds over how long of a time period? Four years?

ML: Yeah. Through M&A and organic, that wasn't all organic growth.

JD: Nice. Digging into that cleanup of operations phase. What processes and tools did you evaluate and/or implement? When you came in, what was the "lay of the land" in terms of what was implemented and tracked?

ML: Partnerize is a unique company in the sense that it has a mixed revenue model. Some of the accounts were variable transactional revenue, and some were subscription. There was an "interesting" ERP system in place that I'd never heard of. Some metrics were done in Excel, but many weren't being tracked yet. We made a strategic decision to convert from variable revenue to SaaS. We wanted to create our KPI dashboards, like it was a SaaS company. There's a little art and science on how you translate transactional revenue into ARR.

JD: Got it, and the ERP solution - was that the general ledger, the CRM, like an all-in-one?

ML: It was the general ledger, and then we had Salesforce for all the pipeline kind of information.

JD: And when you were in that M&A process, were there new systems that came kind of onboard with those companies?

ML: Yes. We stayed with Salesforce. We raised the capital on the legacy system and then we acquired two companies: one was on Quickbooks, the other was on NetSuite. For reference, when I left we were doing about 80 million in ARR. So, you know, not huge but certainly big enough to implement NetSuite and then migrate the Quickbooks instance.

JD: How long did that migration take?

ML: It was probably nine months.

Conversion from Usage-Based to Subscription Pricing

JD: Got it. Let's hear more about the approach to converting the usage-based revenue to recurring. At first, it was pure usage-based?

ML: When I got there it was about 25% SaaS and we were converting it pretty quickly. We understood how to use unit price discounting to convert from variable to subscription. We were able to do that relatively quickly. We got it up to about 65%, acquired a company that was probably back in the 20% SaaS range, and then when I left the combined entities were back to around 65-70% recurring revenue.

JD: Can you explain an example of how that kind of unit price discount conversion works?

ML: The variable revenue model we grew up in is called affiliate marketing, and that business had been around literally since the dawn of the internet on a pay per click basis. Then it changed to a pay per action, which in most cases is a successful sale of a good or service like when a customer buys a hotel room on Expedia, or yoga pants, etc. It's a little more complicated though, because you actually have to have a completed sale in order to pay for performance. You have to track that you don't earn the commission until after the customer stays in the hotel room, or in retail, after the 30 days to return your goods. The commission is not earned out until another event after the user clicks "Buy".

The historical model is that one side (seller) was aggregating users from the other (platform) and paying a percentage of the commission. For example: you're a consumer on Ebates, or Rakuten and you're getting a cashback reward. Historically, the cashback reward would be like 10% of the value of the good, and then the platform (i.e. Ebates) would get a percent of that percent. We changed this at Partnerize. Instead of commissions on the reward, we moved it to 2% of the value of the good that was sold. We felt that was tying the platform more directly to the value creation, as opposed to an expense category.

Ok, let's say that you’re Athleta and you’re paying us 1.5% of the value of the yoga pants. So if it was $100 yoga pants, Partnerize is making $1.50. The way we did our SaaS was we set up tiers based on the aggregate total transaction volume. Athleta would pay a subscription of $X/yr for up to $100,000 in yoga pants sales. If you did more than that, you would fall into the next year. If in CPA you were paying 1.5%, we would give you an effective rate of 1.25% to convert to SaaS. We would build in further pricing discounts as they moved up the tiers.

JD: Great explanation, thanks. So, you used all of your historical data to help dial-in those pricing tiers? How did you find the sweet spot there?

ML: I mean, this is the challenge. What we did with the data is a lot of importing and V-lookups to connect points. You know, our Salesforce was like many - Okay, but not great. So we didn't necessarily have that unit pricing. So yeah, I would say it was an ad-hoc set of analyses using and sometimes having to cleanse (...) data in Salesforce, excuse me, "bad" data in Salesforce.

Importance of Point-in-time Funnel Metrics

JD: Excellent, so let’s talk about the fundraising side. You have existing investors and you're getting ready to go out and raise again - did you get any pushback or other issues around how you're reporting and how you changed to SaaS?

ML: So this is where I get a little biased on it :) When we got the business to break even we went out and started raising money and we were graduating from venture into early stage private equity - growth private equity. A lot of the reporting was actually not available in our ERP or Salesforce. So we built a methodology. We created an Excel database and knowing the source data was bad we built a reconciliation table. Because really, what you need to do is stand up to due diligence. And due diligence frequently involves someone who's going to work 90 hours a week trying to break whatever you send them. We built the ARR database. We had to cleanse up some of the information, we had to marry Salesforce with the General Ledger data.

At the time, our Salesforce was set up as a transaction-based system. So one of the first things I did when I joined is started having the team take a weekly snapshot of Salesforce to track the pipeline over time. This was a good first step, but it didn’t solve all of our problems. You still have to get it right in the Salesforce process itself, right? Making sure everyone has agreement on how stages work, getting stages consistent. For example, our business in Asia, especially in Japan, was all over the place. And so it seemed like every time they missed the quarter, the salespeople would go in and put in crazy opportunities. That was confusing the trended pipeline data.

We ended up raising money from a leading private equity firm but, before that we got to a pretty late stage with a different private equity firm that was actually looking to do a buyout, as opposed to growth equity. I think the current investors were more aligned to sell. But, as we got fairly late in the process, they wanted to understand how the pipeline metrics had evolved over time. We couldn’t show them. We had only started taking those snapshots a couple quarters back. We didn't have enough visibility. They wanted to go back and say, "Okay, tell me about your win rates, tell me about your sales cycle, time per stage…" They wanted to see that over the past two or three years to see how it had improved over time. We couldn't get them that information. We didn't have it. There's only so much you can cleanse, you know, so they ended up backing out of the process.

JD: Okay, wow - that’s kind of a tough lesson to learn! I didn’t realize that Salesforce doesn’t just do point-in-time reporting automatically.

ML: There are definitely solutions in the app store that will do it for you. But, how we had it set up it wasn’t great for being able to go back and say - tell me what the pipeline was on this date. Everything was just "the record is updated" as opposed to "create a new copy" and that info was lost.

JD: Note to self: set up point-in-time reporting on the sales pipeline early

ML: That’s what I would do.

JD: So to wrap it up, let’s talk tools - You created these snapshots and you assembled this ARR picture using Excel, were you using any other tools or was it mostly ad-hoc?

ML: Actually, yeah, we were using this software called "Axle"

JD: Oh, I haven’t heard of Axle - what’s that?

ML: Sorry, just a bad joke :) As far as tools that I would like to see… So, I'm helping the guy out on due diligence and trying to merge two smaller companies. To me, I’d call it "BI in a box". It’s all micro datasets. I'm not a technical person, but I want to be able to have an easy way to create a controlled database environment, so you can't fat-finger it. I want some basic reporting without having to go to absorb from the database and stick Power BI on top. For example: What's my customer acquisition costs? What's my bookings? What's my ARR? What're my retention rates? I want to simply use a platform that lets me import data, validate data and to protect and lock data.

JD: That’s exactly what we've got for you at TrueRev Mike :) Thanks a lot for taking the time to chat with me today.

ML: My pleasure, thanks for having me.