Latest / The Diary of a CFO / Solving Revenue Recognition Nightmares for SaaS Companies, with Apurv Bansal

Transcript

Solving Revenue Recognition Nightmares for SaaS Companies, with Apurv Bansal · The Diary of a CFO

0:04
Welcome back to the Diary of a CFO podcast, the
0:06
podcast where finance leaders share the lessons,
0:09
challenges, and wins that shape their careers
0:11
as well as their organizations. This episode
0:14
is brought to you by Zenskar, the AI -powered
0:17
order -to -cash platform built for modern finance
0:19
teams. With Zenskar, you can automate revenue
0:22
recognition journal entries, as well as billing,
0:25
collections, and SaaS metrics. Visit zenskar
0:27
.com slash upgrade to learn more. The link is
0:30
also in the show notes. I'm your host Wassia
0:33
Kamon, and today I'm super delighted to have
0:35
with me Apurvv Bansal. He is the co -founder
0:38
and CEO of Zenskar. Prior to Zenskar, Apurv
0:42
held leadership roles at Google, where he experienced
0:45
the building and rev -rec pain points firsthand
0:48
and realized the need for flexible software that
0:52
can automate and simplify this. He took this
0:56
as a mission and build and scale Zenskar to streamline
0:59
billing and revenue recognition at the highest
1:02
level today. Welcome to the show, Apurv. Thanks
1:06
for having me, Basia. Awesome. So why don't you
1:09
start telling us about your journey and all the
1:12
twists and turns along the way and what brought
1:14
you to where you are now with Zenskar? Sure.
1:17
Yeah, I mean. I started my career at college
1:21
was an engineering degree. So I'm an engineer
1:24
by qualification. Okay. After studying engineering,
1:27
I realized that that's not what I wanted to do
1:30
for a living. So I pivoted in my career. I did
1:34
management consulting for a couple of years.
1:36
I was a Benin company. I was 22 at that point.
1:40
I felt the itch to start a company. So left my
1:42
job and started an e -commerce company. Ran that
1:45
for a few years, eventually, you know, sold that.
1:48
After that, I decided to do my MBA. So I went
1:50
to Harvard Business School, after which I went
1:52
to Google. I was there for a couple of years
1:54
and that's kind of where I, you know, I kind
1:56
of closely experienced the pain points related
1:59
to billing and RevRex that we're now kind of
2:02
solving with Zansker. So that was kind of a tipping
2:04
point in my journey. I did work with a VC firm
2:07
after Google for a couple of years. I was investing
2:08
in FinTech startups, FinTech SaaS startups. By
2:12
then, you know, I realized that, you know, I
2:13
wanted to be an entrepreneur again. and solve
2:17
the problem that I had seen very, very closely
2:19
at Google, because I saw how much time it was
2:22
draining for finance teams, despite having all
2:25
the engineering resources that a company like
2:26
Google has. That's what kind of led to the birth
2:30
of Zanskar about three years ago. Wow, that's
2:32
awesome. And it also puts in perspective, right?
2:36
We think that when you hear the name Google,
2:38
everything is perfect. Like we think that when
2:41
it's only a small company problems or a medium
2:45
sized company problems when you think about billing
2:49
and revenue recognition. So what was that moment
2:53
for you where you were like, something like Zenskar
2:56
need to be created? What I see was, you know,
3:00
that, you know, they were And again, this is
3:02
not specific just to Google. This happened at
3:04
a lot of companies. Companies build in -house
3:07
tooling to automate billing, rev -rack, other
3:10
financial operations. The reason they build in
3:12
-house tooling is because third -party tools
3:14
available in the market are not able to capture
3:18
or automate the custom use cases that a company
3:20
might have and then they feel the need to build
3:22
something in -house. They dedicate engineering
3:24
resources to building these tools. What I noticed
3:27
was that despite having the best in -house tooling,
3:30
finance teams were kind of spending a lot of
3:33
time just still on spreadsheets, whether it came
3:36
to, you know, sending invoices or falling up
3:38
for payments or recognizing revenue. And the
3:41
reason for that was that, you know, sales teams,
3:44
obviously they get creative to close deals. As
3:48
sales teams go and close more deals, you know,
3:51
the in -house tooling that was built is not able
3:54
to keep up pace with how sales team want to structure
3:57
their deals. And that then kind of puts the onus
4:00
on finance teams to get the job done through
4:03
spreadsheets or manually, because at the end
4:04
of the day, you have to send out the invoice
4:06
at the end of the month, whether you can do it
4:08
through your automated tool or you send it out
4:11
manually. That is the high tech of the finance
4:13
team. This is the era of AI where, you know,
4:16
cars drive themselves and you know, you have
4:18
robots doing pretty much all kinds of stuff.
4:21
And here I was like, why are people still kind
4:24
of sending out invoices manually? The reason
4:27
that was happening was because most of the tooling
4:29
that existed in the market was built like 10,
4:32
15 years ago in an era where software pricing
4:35
was more per user per month, per seat per month,
4:38
but even like a more straight forward license
4:40
fee. As software has evolved, you know, with
4:43
the advent of AI, there's more consumption based
4:46
pricing with sales led notions. You have all
4:48
kinds of, you know, fancy ways of structuring
4:51
contracts, whether it's discounts, or peers,
4:53
or ramps, or milestones, or, you know, early
4:56
payment rewards, or leaping. We saw a gap in
4:58
the market when it comes to having tooling that
5:01
can tackle these use cases and automate billing
5:04
in Revelec. So that's kind of what led us to
5:05
start Zanskar. Okay. And so what part of billing
5:09
and revenue recognition have you automated with
5:12
Zentscar, right? Because when we think of SAS
5:15
company, especially when 606 came in, the accounting
5:18
standard about revenue recognition and all the
5:21
milestone and you get money doesn't mean it's
5:24
revenue. It's quite complicated. Yeah. Yeah.
5:27
So which part were you able to automate? The
5:30
end to end. So basically our vision was that
5:32
all we need to know is what is the contracts
5:37
signed by our customer with their customers?
5:41
I'll go back to the example of Google. Let's
5:43
say Google was using Zanskar. And Google had
5:45
to send an invoice to their customers. Google
5:48
had to recognize revenue based on the contract
5:50
signed with their customers. All Zanskar needs
5:53
to know is the information in the contract. This
5:57
is a contract signed between Google and their
5:58
customers. It determines how their customers
6:00
pay them, whether it's a subscription fee, it's
6:03
a, you know, tiered fee, there's a discount.
6:06
Along with the contract, there could be some
6:08
elements of usage, how much data was stored,
6:11
how many API calls were hit, how many emails
6:14
were sent. As long as Zanskar has the information
6:17
in the contract and information about usage,
6:21
everything else downstream is automated. The
6:24
generation of invoices, the sending of invoices,
6:27
the application of payments, the sending of kind
6:31
of follow -ups for payments, Based on the contracts,
6:35
you know, on 606 or IFRS 15, creating your revenue
6:39
schedules, recognizing revenue, creating your
6:41
journals, creating your journal entries, posting
6:44
your journal entries into your ERP. That end
6:47
-to -end process is fully automated. Again, the
6:50
vision was that we live in an era where machines
6:53
can do pretty much anything. So this entire function
6:57
should be able to run by a machine using AI.
7:00
Now we're an AI native platform, you know, we
7:03
use AI in every part of our stack. All we need
7:06
is the information on the contract and the information
7:09
about users and everything downstream is fully
7:11
up. That's awesome. And it brings me back to,
7:16
I know this is a great tool, but, and I know
7:18
you talk with a lot of CFOs, right? And we often
7:22
come in and we either inherit a great tool that
7:25
was now well implemented. The thing can have
7:29
all the good thing it can do, but the implementation
7:33
is such like, it's like you're buying a Mercedes
7:35
and you're driving like a golf cart. It's painful,
7:38
like you said, because sales team go out, they
7:40
do deals and accounting and finance, we're trying
7:43
to catch up. So what would be your, you know,
7:46
maybe your framework or your advice really for
7:48
implementing any tool and make sure that we're
7:51
using it to its full potential? Again, we've
7:55
seen, we've done countless implementations. So
7:57
I do have a few lessons to share. I'd say first
8:00
of all, just knowing exactly the entire, like
8:03
getting all stakeholders in the company on the
8:05
same page about implementing a new tool, whether
8:09
it is, you know, the sales team, whether it is
8:11
the engineering team, whether it is the finance
8:13
team, implementation should not be done in silo
8:16
with one team. Others should be kept in loop
8:18
from day one that here this tool is coming in.
8:21
Understanding. everything that the tool has to
8:23
offer, not necessarily using everything that
8:25
they have to offer. You could choose to use a
8:27
few specific modules, but at least knowing that,
8:31
hey, this tool can do these five things for me.
8:34
And internally, all stakeholders aligning one.
8:36
Okay, we'll start with using module number one
8:38
and module number two. Let's see, we're using
8:40
Ranskerl. You want to start with billing, start
8:42
with the dev rec. You don't want to use collections
8:44
today. You don't want to use, you know, reporting
8:46
today. That can be a phase two or a phase three.
8:49
You may choose to never use that. So just having
8:50
full clarity on what the tool offers and what
8:54
different stakeholders in the company expect
8:57
from automation. The tool could offer, let's
9:00
say, an integration with your CRM, which is HubSpot
9:03
or Salesforce. But if the sales team tells you
9:07
that, hey, the CRM hygiene is not very good.
9:09
I don't have information in a good way or shape
9:12
in HubSpot or in Salesforce. Then the finance
9:15
team trying to get Zanskar connected to the CRM
9:18
is just a useless. It doesn't make any sense.
9:21
You might as well just have the PDF of the contract
9:23
uploaded to Zanskar and have that kind of read
9:26
it. That's why it's important to have all internal
9:29
stakeholders aligned on, you know, what data
9:31
do we have? Where does it live? and making sure
9:34
the vendor that you work with gives you like
9:37
a detailed implementation plan broken down by
9:40
phases on what will happen on day one week one
9:44
month one. How long will it take? What are the
9:46
different phases? What is needed from different
9:49
stakeholders in the company at what point in
9:51
time doing all of this takes two to three days.
9:54
It gets different stakeholders on the same page.
9:58
It saves so much headache later because we've
10:01
seen places where you know The finance team starts
10:04
implementing the tool and they'll be like, you
10:06
know what, you can just extract the consumption
10:08
data from my snowflake. They've not spoken to
10:11
engineering and then three weeks later engineering
10:13
says, you know what, we're not going to give
10:14
access to the snowflake. Even read -only access
10:17
will not be given. We need to use the APIs to
10:19
send data. And that increases the implementation
10:23
timeline because they were not looped in on day
10:25
one. So getting everybody looped in on day one
10:27
is very, very important. I love it. I love that
10:30
approach because I can see how it prevents a
10:33
lot of headaches. I've seen and I feel like we
10:35
all learn implementation the hard way. Now you
10:38
have an engineering background. How do you think
10:41
it really helped you coming into making the lives
10:45
of finance people easier? Honestly, the engineering
10:49
background helps because I understand the fundamentals
10:51
of technology. I understand how the software
10:54
works. the intricacies of it, not just what outcomes
10:57
it delivers for the end user, which is, you know,
11:01
somebody in the finance team, but also how the
11:04
software works under the hood. So when I'm in
11:07
a conversation with somebody and, you know, they're
11:09
like, Hey, can you get data from this stable
11:13
in a warehouse? And can it be aggregated in a
11:16
certain way? Or, you know, can I have my revenue
11:19
distributed based on usage or can it be more
11:21
straight mind? Given that I understand how the
11:24
tool works from an engineering perspective, the
11:28
ability to connect the how, which is the tech
11:32
layer, with the what, which is the outcome that
11:35
is being produced, which is the invoice of the
11:37
journal entry. There's no disconnect because
11:40
I understand both of those parts and thereby,
11:42
you know, I'm able to kind of marry those two
11:44
and give a very solidified holistic perspective
11:47
to the end user. That's awesome. And I think
11:50
in addition to You coming from an engineering
11:54
background. You also come from another country
11:56
That's like the top in how many engineers I think
12:00
was square mile So what was that transition for
12:04
you? I'm curious coming to the us and learning
12:08
Because you knew already the engineering by the
12:11
working with people because that's what finance
12:13
business partners are today With ai with so many
12:17
things the hard work for us is more and more
12:20
becoming dealing with people. So what is your
12:23
take on it? What has helped you in bringing people
12:26
on board with AI, with different technology and
12:29
just work in general? Yeah, I mean, I think it
12:32
just boils down to understanding the culture,
12:35
which I came to the US for my MBA, which was
12:39
about nine, 10 years ago. So at that time, of
12:42
course, I was a little bit of a cultural difference
12:45
but you know I made good friends with all of
12:47
my classmates at business school understood the
12:50
cultural nuances understood you know how people
12:53
what people like what they dislike how they talk
12:56
what they like to eat you know where they like
12:58
to go what music they listen to you know what
13:01
sport they watch and uh as I kind of became more
13:05
ingrained with the culture it helped me kind
13:07
of build a rapport honestly it wasn't that hard
13:11
because The cultural differences aren't that
13:13
significant. It didn't take that long to kind
13:17
of assimilate. It was maybe like a few weeks,
13:20
a couple of months here and there. Now, obviously,
13:23
you know, you mentioned AI and getting people
13:25
on board with AI. There's like a mixed bag. Some
13:28
people like want to incorporate AI. Some people
13:31
are like scared of AI, not just because of, okay,
13:35
it may eliminate jobs, which it is, but also,
13:37
you know, how safe is it? How secure is our data?
13:39
Is our data being used to train models? Once
13:43
you understand what people think about the latest
13:46
technology, what they're looking forward to,
13:49
what they're skeptical about, especially what
13:51
they're skeptical about, which could be security,
13:53
privacy, you know, elimination of jobs, accuracy,
13:57
and knowing how it works under the hood, you're
14:00
able to kind of paint a true holistic picture
14:02
of, okay, your data will be used in so -and -so
14:05
way. it's going to be used to automate your workflow,
14:08
but it won't be used to train a model that's
14:10
helping to automate somebody else's workflows.
14:12
And the data is not being exposed outside the
14:16
environment that's meant for you. It's safe,
14:19
it's secure, and just understanding people's
14:22
apprehensions and understanding how technology
14:24
works helps you alleviate those apprehensions
14:26
much better. Yes, yes, definitely. I like how
14:30
you said understanding, but also it means being
14:33
open, right? Because when we think about the
14:36
modern CFO tech stack. We used to what, having
14:39
an accounting system, maybe a FPNA software,
14:44
and we should be good. Well, in reality, it's
14:48
a bit more complicated than that. Like what has
14:51
been your experience and what do you think the
14:54
ideal CFO tech stack should look like? See, I
14:57
mean, the CFO tech stack can be as fragmented
15:00
as you'd like it to be. and, or you could consolidate
15:03
everything in one place. I feel like it's hard
15:06
to consolidate all the functions into one tool.
15:09
You do need specialist tooling for different
15:11
functions. So whether it's your code to cache,
15:15
which is where Zanskar comes in, whether it's
15:17
let's say your receivables function, you need
15:20
that tooling for FPNA for your planning and forecasting
15:23
and coding. You need an ERP of course. You need
15:25
a a payroll provider, you need a expense management
15:29
tool, a payables management tool, of course a
15:32
closing tool, tags. There's like tools for, it's
15:36
so easy to spin up a tool today. There's tools
15:38
for literally every part in the function. I think
15:40
the ideal stack varies for every company. It
15:43
depends upon the stage of the company, the maturity
15:46
of the company. You don't need to automate everything.
15:50
You should automate things that are becoming
15:52
a pain to do manually. Automation is important,
15:56
but not for everything until it becomes a pain
15:58
point. So it's important to understand, okay,
16:00
these are the different parts of this tech. What
16:03
are the key pain points for me today? Like, you
16:05
know, is my business is growing. The volume of
16:08
customers is increasing. I don't want to run
16:10
billing manually, but if you only have 10 customers,
16:14
do you really want to implement the billing tool?
16:16
You can, and let's say they're all on Android
16:17
Invoicing. You could send out 10 invoices on
16:20
email. It takes you 10 minutes. You don't need
16:22
to automate that. So it's very contextual. but
16:25
say the various parts of the stack. And today
16:28
I think the one other fundamental question is
16:31
how much of AI should I be using in my tech stack?
16:35
AI is evolving so rapidly, the pace at which
16:38
things are changing is so transformative that
16:41
what you have today versus what you have in the
16:43
year will be so different. So you want tools
16:44
that are AI natives and are using the latest
16:49
technology to make sure the business is huge
16:50
because we have competitors. have an edge over
16:53
you let's say using outdated tooling and your
16:55
competitors are using tooling that helps them
16:57
do a lot more with the same amount of headcount
17:01
and the same amount of investment in tooling
17:03
that they're going to kind of be more productive
17:05
than you and they can do a lot more they'll move
17:07
ahead of you so that's what's also important
17:08
to have you know so if i kind of broke it down
17:12
code to cache of course there's nscar ftna there's
17:15
tools like drive crane there's mosaic ERP for
17:19
SaaS companies. Of course, you have the QuickBooks
17:21
in the NetSuite, but you also have the more wage,
17:24
you know, campfires and rivets. Closing, of course,
17:27
there's tools like Floca's. Tax, you have Avalara,
17:30
but you also have tools like Android and SaaS
17:33
Focus. Yeah, again, it also boils down to kind
17:37
of figuring out what parts of my stack do I want
17:40
to automate, but also what parts of my stack
17:42
do I want to eliminate. like you may have a manual
17:45
closed checklist that could be eliminated. You
17:48
may have static board decks. You don't need static
17:50
board tests anymore. Those could be eliminated.
17:53
At one point you talked about AI native. What
17:57
is the AI native tool? What does it look like?
18:01
What does it do? Why is it valuable? An AI native
18:05
tool is a tool that leverages the latest in AI.
18:12
To solve the same problems that you have been
18:17
solving for decades, either manually or through
18:21
more legacy tooling. An example of that would
18:24
be, let's say you're using a billing tool where,
18:27
let's say you're a company that sells contracts,
18:30
that has a sales led motion. Your contracts are
18:33
not in a CRM because your sales team has poor
18:36
data hygiene. Your contracts are in... Google
18:40
Drive, you have 200 customers, you have 200 contracts
18:43
in a Google Drive. Let's say you implemented
18:46
a billing tool. Now, if the tool was not AI native,
18:50
you would have to open every contract, read the
18:54
information on the contract and manually punch
18:56
it into the billing tool. And once the contact
18:58
is in the billing tool, the billing tool generates
19:00
the inputs. So this is an example of a non AI
19:04
tool. An AI native tool will solve the same problem,
19:07
but instead of you having to read the contract
19:10
200 times and manually punch in the data, you
19:13
can upload the contract to the AI native building
19:16
tool. It would be able to extract the terms in
19:19
the contract, read them automatically using AI,
19:23
the latest in AI, and then generate your ring
19:26
voices. So again, you're solving the same problem,
19:28
but with the AI native tool, you're saving more
19:30
time because AI has now done the job that you
19:34
were doing. of manually inputting data into the
19:37
tool. That's a very small example. But what I
19:40
mean by an AI native tool is it is leveraging
19:43
AI to solve a lot of the manual workflows that
19:49
still exist despite you having to use software.
19:53
Another example could be, you know, let's say
19:55
you are again having a billing tool. You wanted
19:59
it to kind of reconcile which invoices got paid
20:03
and which didn't get paid. Now you connect it
20:06
to your ERP, the ERP is connected to your bank.
20:09
They tell the payment information syncs in, and
20:12
now you have to kind of manually apply the payments
20:15
to every invoice to see what the schedule does
20:17
not say. The AI native pool will take away that
20:20
manual step because it will be smart enough to
20:24
understand who the payment was came in from.
20:27
Let's say I have three invoices for a customer
20:29
for. $100, $150, $200. And there was one payment
20:33
that came in from the same customer for $450.
20:37
AI is smart enough to know, okay, this $450 is
20:40
for both three invoices. So let this be applied
20:43
as opposed to you have to do it manually. So
20:45
that's what I mean by AI native tool. Oh, great.
20:48
This is very helpful. And in terms of company
20:53
maturity, you said something about how depending
20:56
on where your company is, you will decide to
20:59
automate certain things, right? When you think
21:02
about a SaaS company, because I know you work
21:05
a lot with SaaS companies, at which point do
21:08
you think they should focus, like when you look
21:10
at their maturity curve, when they're starting,
21:13
and when is the peak versus when they're mature,
21:17
at which point do you think they need to automate
21:19
certain things? that cycle like what things typically
21:23
become a pain point so people can also be Proactive
21:27
so that the CFO that are let's say at a startup
21:29
How can they be proactive knowing that they will
21:32
need different things at different stages of
21:35
their companies? Yeah, I mean I think the best
21:38
way to do this is just to see what is starting
21:41
to become a time sync and Whatever is starting
21:44
to become a time sync instead of waiting for
21:48
the problem to blow up before you automate it
21:50
you kind of proactively take that action immediately.
21:55
So again, let's say, again, it's not just a function
21:58
of company maturity, but it's also a function
22:00
of some other company in one. So let's say, you
22:02
know, you are two companies, both had 200 customers.
22:06
One company had every contract just like a flat
22:10
annual see a recurring revenue yearly. Now for
22:14
them to recognize the revenue, all the 200 contracts
22:16
are just kind of. straight line over 12 months.
22:20
There's no fancy distribution happening over
22:22
there. So they probably don't need to automate
22:25
it until the number blows up to say 500 customers
22:28
because it's not taking that long with even 200
22:31
customers. It's the same rule, similar spreadsheet
22:34
template. However, if you had usage -based pricing,
22:37
now you have to recognize revenue based on when
22:39
the usage happened. And now the rule based on
22:44
which the revenue has to be distributed or recognized
22:47
is no longer the same for every customer. You
22:50
have to marry it to the consumption data. This
22:53
can become a pain point at even 50 customers,
22:55
forget 200 customer. So you have to then start
22:58
to automate it much sooner. So it's not just
23:01
a function of company scale. It's also very nuanced
23:04
based on the company's business model and the
23:06
company's pricing and the company's go -to -market
23:09
motion. Is it more sales led? Is it more product
23:11
led? Is it hybrid? Is it across multiple geographies?
23:15
Is it all local in the US? the closest proxy
23:18
to me is okay which of my functions whether it
23:21
is billing or collections or recognition of revenue
23:24
or you know reporting or planning or budgeting
23:26
or forecasting or payments which of these is
23:32
progressively month on month the time investment
23:35
is increasing significantly that starts tell
23:38
you which of these needs to be automated sooner
23:42
than later but yeah Realistically, I would say
23:46
companies, they automate billing before they
23:49
automate RevREC because RevREC is more internal,
23:53
billing is more external. You want your invoices
23:57
to go out on time. If you recognize revenue one
24:00
or two days later, it's still more internal.
24:02
I can live with that. So those are the kind of
24:05
factors that come into play when deciding when
24:07
to automate. I love it. It's very simple, very
24:11
practical. So thanks for sharing that. But I
24:14
love the way you understand the pain of doing
24:18
revenue recognition after the fact. Okay. So
24:21
some of our listeners may not understand the
24:24
complexities of SaaS companies when it comes
24:26
to revenue recognition, right? Cause I feel like
24:29
when I was going to school, a lot of the examples
24:32
in the textbook for accounting was a manufacturing
24:34
company. You are selling a pen. And so when you
24:37
sell the pen, you get the money, you recognize
24:40
revenue, big deal. But for SaaS company, it is
24:43
not the same. So maybe share a story about what
24:48
it means to do rev rec. in that complicated schedule
24:52
of you have a customer in the contract, there
24:55
is a usage, there is a customer, there is a log,
24:59
there is a lot of things that can happen. So
25:01
can you speak to the pain points you probably
25:04
heard from CFOs going through that where billing
25:07
is okay, we're sending the bills on time, and
25:10
then revenue is like, eh, we don't know. Let's
25:15
take a quick break to talk about a problem most
25:17
SaaS finance teams run into. Sales closes a deal
25:21
with flexible pricing and custom terms, but the
25:24
accounting system isn't built to handle it. So
25:27
finance ends up juggling manual fixes, prep sheets,
25:30
working with developers just to bill and recognize
25:33
revenue correctly. That's where today's sponsor
25:36
comes in. With ZenScar, all you have to do is
25:39
send your contracts and usage to the platform.
25:42
The AI power platform automates everything downstream,
25:45
billing, revenue recognition, collections. and
25:48
SAS metrics. The best part is Zenskar scales
25:51
with you, and their team is hands on every step
25:54
of the way. So if that sounds like an upgrade
25:57
your team needs, visit zenskar .com slash upgrade
26:00
to learn more and book a demo. The link is also
26:03
in the show notes. Now let's get back to the
26:05
episode. Yeah, no, it can get pretty hairy pretty
26:09
quickly. So I'll take an example of a company.
26:12
You know, there's a customer of ours. I won't
26:14
take their name, but they have The pricing model
26:17
is more subscription based but they also have
26:20
some elements of usage with every contract and
26:23
then they also have this interesting milestone
26:26
based pricing. The first milestone is when the
26:29
implementation is over and then they have a couple
26:32
of other milestones based on when the service
26:36
is delivered and what phases you know phase one,
26:40
phase two, phase three are different milestones
26:42
when it gets completed. So they have these different
26:45
types of pricing and if some customers could
26:47
just be on usage, some could just be on subscription,
26:50
some could be on usage plus subscription, some
26:53
could have a milestone based pricing. And so
26:56
they had like 250 customers and they had this
27:00
multiple spreadsheets with one tab for every
27:03
customer. So across multiple spreadsheets, they
27:05
have 250 tabs because every customer is a separate
27:10
spreadsheet tab. And now Given that the contract
27:13
for every customer is different, the way the
27:15
revenue is recognized for every customer, the
27:17
template is different, the rules are different.
27:20
So some of the customers, you know, I think 30,
27:23
40 of them are very simple, just like straight
27:25
line across 12 months. So there was just the
27:27
same rule. But in some other cases, when usage
27:30
came in, they had to then get a download of the
27:34
usage data from their engineering team every
27:36
month. And then they had to, you know, upload
27:39
it into the spreadsheet. it was linked to a cell
27:43
in the Rebrecht template where, okay, this is
27:46
the users that came in with the data which it
27:48
comes in. And the rule for users is of course
27:51
different because let's say the usage happened
27:53
this month. I recognize the revenue for that
27:56
usage this month. I'm not gonna straight line
27:58
it over 12 months because the usage happens this
28:00
month. And then sometimes they had, you know,
28:02
minimum commitments. And let's say the, if the
28:06
contract with a minimum commitment of $10 ,000.
28:09
So for four months, you know, there was no usage.
28:12
So I'm just like, you know, taking the minimum
28:14
of 10 ,000 and straightlining it over four months.
28:17
And now suddenly in month five, I have a lot
28:18
of usage and the usage exceeds $10 ,000. So now
28:22
my minimum goes for a toss. And now I have to
28:24
make a judgment call on, you know, the previous
28:27
period is already closed. I can't go back and
28:29
change the way the revenue was optimized for
28:32
that period. So now. period, do I front load
28:36
it? Do I kind of distribute it equally? Do I
28:38
back load the difference? All those nuances require
28:41
manual judgment. And each of these is kind of
28:44
put into a formula and a spreadsheet. And that
28:46
just made it a living mess. Like when you saw
28:48
that spreadsheet, I was just like, holy. I'm
28:52
in 257. When I think about it, because I've seen
28:57
how internally the sales team will come up with
29:01
those great ideas of making it flexible and easy
29:05
for the customer. You can do this option, this
29:08
option, this option, but every option is a hurdle,
29:12
a roadblock for the financing when it comes to
29:15
revenue recognition. So how would you say life
29:19
is being easier between both finance and sales
29:22
team when they're in sync from the beginning
29:25
on the revenue recognition and billing? I mean,
29:29
if they're in sync, That would mean that, you
29:31
know, finance has told sales that, hey, please
29:35
don't go and sell anything outside these types
29:38
of contracts. Because if you sell something that
29:41
is, let's say, finance has created templates
29:43
to recognize revenue for five different types
29:45
of contracts. Now they've told sales, hey, you
29:48
know, please don't sell a sixth type of contract.
29:51
That is what it means for finance and sales to
29:54
be in sync. That will not work, though, because
29:57
sales has to go close deals, rightly so to drive
30:00
revenue for the company. When that happens, finance
30:04
is happy because revenue came in, but they're
30:07
also like, okay, now I have a new type of contract
30:09
that I hadn't created a template for and I have
30:12
to go back and create a new template and this
30:14
is going to increase the time that it takes me
30:17
to recognize the revenue and close my books.
30:20
But the simplest cases that both teams live in
30:23
harmony is when there is, you know, not too much
30:26
creativity happening in the sales process. They
30:28
have a very set way of selling. Finance has already
30:31
accommodated for all those days of selling, and
30:33
there's nothing new happening in the business.
30:35
But that really happens, honestly. Businesses
30:37
grow, they launch new products, they launch new
30:39
pricing models. As you go upmarket, right, as
30:43
you go acquire enterprise customers, they demand
30:46
more creative ways in which they want to purchase,
30:49
rightly so. They're paying you a lot of money,
30:51
so they want to have flexibility so that... Harmony
30:54
is not as easy to find unfortunately Yeah, yeah,
30:59
so I was hoping you said with AI it's easier
31:02
to add that six contract Like when they go and
31:05
they do five and six is easier. Maybe maybe Absolutely.
31:10
So that's why that's why I said AI native tooling
31:13
like Zanskar makes it easier for sure than if
31:18
you had to do it on spreadsheet or if you had
31:20
to do it in a tool that was and a more legacy.
31:24
The point was there's very few companies where
31:27
there is this harmony. So given that sales teams
31:31
will get creative, I think the easiest ways of
31:33
finance to adapt tooling that does not need them
31:36
to push back to sales and they can be they can
31:38
tell sales team say throw whatever you want to
31:40
throw at me. I got it. I'll take care of it.
31:44
For that you need flexible modern AI native tooling.
31:47
For sure. What would you say is a recent trend
31:50
or shift that you think leaders are not paying
31:53
enough attention to? Right because I know we
31:56
talk a lot about AI and I feel like with AI Came
32:00
also an increase in fraud and cyber security
32:03
issues, right because everybody's getting smarter
32:06
What have you seen? How are you staying ahead
32:08
of things like this? This is not new like every
32:13
time the new technology comes there will be security
32:17
issues there will be fraud and then cyber security
32:21
will also beef up to the next level like it's
32:24
the it's a game between the fraudsters and the
32:28
cops for the lack of a better word as to who's
32:30
kind of ahead in the technology race with all
32:34
the changes in AI of course there are security
32:36
concerns you have to you know take a measured
32:40
approach as to okay how much is the risk is the
32:45
risk worth the return that I'm getting in some
32:50
cases it's not in which case you should not take
32:54
the risk but you know in some cases if what's
32:57
at risk is let's say proprietary customer data
33:00
you could fear your data being leaked to be used
33:04
to train some other model and giving away key
33:07
business IP that's a risk you cannot live with
33:11
okay let's say I'm trying to create my board
33:13
deck I got AI to do some projections Now, there's
33:16
a risk I could do the wrong projections, but
33:19
it would do it much faster. And that's a risk
33:23
I'm okay taking because you know what? It's still
33:26
more internal. It's a projection. I got it wrong
33:30
because of a risk that I took. But, you know,
33:34
if I got it right, I was able to do it much more
33:36
smartly, much more sooner with a lot less time
33:39
investment. And over there, the risk is not less
33:42
than the return. So it's That's kind of how I
33:44
look at the risk versus reward trade -offs. Okay,
33:47
it's pretty much a balance and how you can mitigate
33:50
what comes up. Okay, last few questions. I will
33:54
say what was the best career advice you've ever
33:57
received? I'd say one was just like always think
34:01
long -term. I feel like people underestimate
34:04
how much the power of long -term thinking can
34:07
help on a day -to -day basis when you as an entrepreneur
34:11
are worrying about Hey, my revenue is not going
34:14
fast enough, or, you know, some very important
34:18
team member decided to leave and I'm feeling
34:20
bad about it. If you start to take a long -term
34:23
lens and you're like, okay, it's a long journey.
34:26
We're building company here. Boom wasn't built
34:28
in a day. And, you know, it's like running a
34:31
marathon. You fall a couple of times. You get
34:33
up, you go back crying. It's, it's okay. And,
34:35
you know, that long -term vantage point really
34:38
helps me. Like, you know, if you tell yourself,
34:41
hey, I have a lot of time. to achieve my goal.
34:44
I'm not running a sprint where I have to do things
34:46
in a short period of time. It just like puts
34:49
things in perspective. So for me, the best advice
34:52
was incorporate long -term thinking in how you
34:55
make every decision. An example for that would
34:57
be I could choose to kind of work with, I have
35:01
two options, get a more, you know, a cheaper
35:04
option versus a more secure option. Again, depending
35:07
upon the risk versus the reward, in some cases
35:09
I choose the most secure option because that's
35:11
a long -term right thing to do. Even like, you
35:14
know, working with customers, thinking about,
35:17
hey, my reputation compounds long -term. Short
35:20
-term, it's okay if I had some losses here and
35:22
there, but long -term thinking really helps.
35:24
Yes. And especially today, when I think about
35:27
social media and people comparing themselves
35:30
of where you are in your career, but then you
35:33
realize it's long -term. It's the long term,
35:36
you know, you know, you're not chasing shining
35:37
out a long term. I love it. My last questions.
35:40
What is the career advice you usually give people?
35:45
I tell people to follow their gut. Lots of nice
35:47
young people come to me and they're like, hey,
35:50
should I start a company? Should I, you know,
35:53
switch my role? I'm not enjoying marketing. Should
35:56
I think of doing sales? Should I go for an MBA?
35:59
You know, will it help? Will it help? You know,
36:02
what's going to make me more money? my advice
36:05
is always say just follow your gut your gut usually
36:07
knows what there's no like right or wrong decision
36:11
that's how i made a lot of my decisions my gut
36:14
told me to start a company it wasn't the most
36:17
logical decision to make but it just felt right
36:19
i advise often i often am as equal to follow
36:22
their gut when they're stuck and not try to like
36:25
over optimize like it's funny that day this some
36:29
someone called me he's like you know what i've
36:32
gotten admitted into Harvard Business School
36:35
and Stanford. Which one do I choose? I'm like,
36:39
dude, you're like one of X people who's gotten
36:42
into both. It's like both of those decisions
36:47
are going to be okay. Just like, you know, go
36:49
with, it's like, you know, but if I get a better
36:51
job, where do I make more money? Is Boston a
36:54
better city or should I live in the Bay Area?
36:57
And he was like trying to kind of, you know,
36:59
create a spreadsheet based decision making framework.
37:03
So I'm like, no, that's not how you can make
37:05
those decisions. Follow your gut. Yes. Yes. Oh,
37:10
wow. I think we have so much information these
37:13
days. It's easy to get bogged down by too much
37:17
information. So love that advice as well. Well,
37:21
thank you so much, Apoor, for being on the show.
37:24
I really enjoyed the conversation and the insight
37:27
you shared. No, it's great. Great. Thanks for
37:29
having me. And, you know, looking forward to,
37:32
you know, having more of these. And that's it
37:36
for today's episode of The Diary of a CFO. Thank
37:39
you so much for tuning in. If you enjoyed the
37:41
show, don't forget to like, review, subscribe
37:44
and share with others. Our website is TheDiaryOfACFO
37:48
.com. That's where you can find all the episodes.
37:52
access all the guests' profiles, see their bios
37:55
and their social media links. It is also the
37:58
place where you can apply to be a guest on the
38:00
podcast and have information about how you can
38:03
sponsor the show. As always, if there is any
38:06
topic you would like me to cover in the future,
38:08
just email me at ask at the diary of a CFO .com.
38:13
Again, the email is ask at the diary of a CFO
38:16
.com. See you soon.