Today, I'm here with Elena Sidelnikova, a corporate development executive with 15 years of M&A and finance experience. She has led M&A teams that startups to fortune 500.
She has set up new corporate development functions, establish relevant processes and structures. Elena has M&A deal experience in technology, healthcare, financial services in tech and infrastructure.
She was previously at Deutsche Bank and JP Morgan. Today we're going to talk about how to identify potential risks during software transactions.
We can kick things off if you can just tell us a little bit about your background and experience.
I started my career off at JP Morgan. I started in their investment banking program where I did your typical investment banking role.
After that, I also work for the office of the CFO of JP Morgan's asset and wealth management team where I did a lot of budgeting and forecasting and comparing against actuals and also helping the company file their 10 Ks and other public filings. Up to that point I got my MBA.
So I got my MBA at Wharton and went back to finance where I spent 10 years at Deutsche Bank. In the last two years of my career at Deutsche Bank, I was in their corporate finance M&A team.
So this was not actually the team that covers clients as you would as an investment banker doing M&A, but this is Deutsche Bank's internal corporate development function for Deutsch itself, so doing deals for which as a principal.
I was also at a corporate development role at a company called Conduent. So Conduent is a fortune 500 company, they provide tech-enabled services and they spun off from Xerox a few years ago.
So when they spun off, they actually didn't have a corporate development function really at that time, so it was still in the process of being set up. My role there was to really come in and help that effort.
So some get that corporate development function started, got the deals, the pipeline flowing, set up the proper procedures, all the infrastructure, the team.
Everything that's approval flow, everything that has to be done to really get the corporate development effort off the ground. And then I would also just mention, in my most recent role, I was in a much smaller environment.
It was a roll-up type situation, similar to a private equity model where you would have an investor group come in, put up some capital and then focused on roll-ups , in the healthcare space.
What is technical due diligence? What are the steps of it? And I know our theme today is more specific on software deals.
A couple of points that are very important when you're doing technical due diligence that I like to focus on. One is a code audit, and I'll explain a couple of points that are important about that. And the other one is cyber securities.
With the code audit what is important is to focus on two aspects of it.Sometimes it can be done with internal resources. Often the company may not have that kind of bandwidth or internal folks to do that. It might need to be done by a third party.
But what they're focusing on is to check on the quality of the code and for any open-source site issues. So the quality of the codes is self-explanatory.
You want to make sure that the code is well written, that it's scalable, especially if you're buying a company that's smaller than the company that you're representing and you're trying to then transition their product and their software code into a much bigger context.
Where are you going to add new clients and existing clients? It's very important that the code is scalable and can be leveraged well that potentially for other uses that you can later add to realize your synergies.
And then you want to make sure that it's well documented so people who might've written the code have left, you're able to trace them, make changes and you know how that works.
And then the second point that I mentioned is the open-source check. So usually it's done by the same types of folks, often a third party, where they run checks to make sure that none of the code or at least not very large portions of the code are sourced from open source resources.
And so for folks who are not familiar with it, why is this important to focus on it? This is because if you have open-source, which is things that are out there on the internet, anyone can find it for free and incorporate it.
The problem with that is that if you do incorporate that kind of code into yours, then you might be required by law to provide your software out in the public. So whatever your output is then, so then you may not be able to have clean ownership rights and potentially might have to share.
You might be forced to share your code with everyone out there. Even the stuff that's value added that you've designed, just because of that input that you took advantage of.
So it's very important, in many cases you'll see some portions of it that are derived from open source. You just have to be very careful that it's not the very critical parts or perhaps some parts that are around that are less important or you can badger on.
That's very important. And then I would just say that the other piece that I always look at is the technical team review.
You'll definitely want your business sponsor and the IT leaders to come out, to look at the code to really test it out, to make sure that it's working the way they want it.
Everything's working out how they were expected to do, there's a backup process, what is the service situation? Are they using cloud and how is that set up? Making sure that that's all very well understood.
The last point I would mention is very important to look at your cybersecurity setup. And possibly test out what the cybersecurity gaps could be.
So in some cases, you would actually have a team trying to hack in to the target and pressure testing these. In some cases, you will just have other means to identify these cybersecurity gaps.
I've had a situation where we had identified a vulnerability and a potential target. And that was one of the issues that ended up being very critical in due diligence.
And a plan had to be provided for how to fix that. Something that the board and the senior leadership was very focused on. So definitely that has to be done very carefully.
If you're doing tech diligence on our company, we do an annual pen test and we have a SOC 2 audit. Do those cover the check boxes and we simply provide those reports? While you're looking for that first of all, and then are you still doing your own pen test and assessment as well?
Yes, you do both. You'll ask for those kinds of things, any kind of audits, internal audits, external audits that you might've done. That wouldn't be enough though.
Like we would have to still look at your set up and check your settings and things like, do people forget to change default passwords on some of the hardware and so on.
There's definitely things that the technical team would look at and make sure that there is some gap that maybe people might've overlooked.
What people challenges have you seen that are specific to the software company workforce?
On people, in addition to all, a lot of the standard things that you look at in HR and people diligence. When you talk about software specifically, you have to understand your life cycle for onboarding developers and also salespeople.
Some of the things I've seen in some cases, it takes a really long time to quote, onboard a developer, right.
And by onboarding, I don't mean just handing them that laptop and having them set up in systems. It's really more, how long do they take to get productive?
To get up to speed on how the company writes code. And that could take sometimes six months, even more than a year where that life cycle or that learning cycle, rather I should say, can be very long.
The same thing is for salespeople, for the salespeople to learn the software, learn that the technical aspect of the product can take in some cases six months, a year I've even seen longer.
You have to be very cognizant of what your current workforce is. And then making sure that you're able to motivate them, they are able to stay, or you have a plan to hire, and then you have to build them on time.
And it could be very extended periods of time as I mentioned, for getting them set up and being productive, making sure that they're operating on a high level.
Software industry is no stranger to acquiring foreign talent. What risks come along with hiring employees who require visas?
You'll see a few things. So you'll see folks on visas, various types of visas, and you always have to check. What is the status? Is this person going to be impacted by an M&A deal?
Sometimes when you're doing an asset deal where you buy just the assets of the company, you will then actually terminate the employees and then you will hire them at the new company.
So that could cause issues for some people because you haven't done the paperwork or you may take some time to do the paperwork for that person to be transferred or the visa to be adjusted.
So that's something that has to be done well ahead of time so then you're not impacting those people. They're not losing their eligibility to stay in the country.
The other point is some companies, especially smaller companies, can be lax about checking work papers and using the E-Verify, which is the online system that the government lets you check someone's right to work in the United States.
So that's something I've seen, in some cases, you have to poke around, maybe do some random checks. Well, you have to, in some cases, if you have doubts about the strength of the check, you might have to do the checks yourself.
The other point I've seen, which doesn't come up as much, but every once in a while, you'll see popping up is that for certain kinds of visas you'll have the employees are required to have a certain amount of years under their belt in order to qualify for those types of work permits.
And then people will run these employees or classify them as being employed in a couple of different subsidiaries at once.
Lawyers can debate pros and cons of that and the risks of that but that's something that I've seen as well, that has to be flagged and talked through in terms of risks that can arise from that.
Have you ever come across a situation where you're doing an asset deal and the outcome is potential people aren't going to be able to get their visas renewed with this organization?
I haven't had that happen. So we've usually been able to figure that out or it hasn't been enough of an issue, there's been enough time to get those folks squared away. Nobody had to be let go for that reason.
It just might be time, you might need some time between signing and closing or building in that cushion for those kinds of things.
Any other ride flies or things you look for when looking at the people side of these types of software deals?
One of the most important and critical pieces is making sure that the founders of the management team is motivated and excited to join your company and wants to continue contributing and dedicating their full efforts to that.
And then by identifying the right people and who are the critical people. So beyond the first layer of founder, CEO, and maybe a couple others who is the next level down. And then maybe who's the next level down from that.
So then who are the most important people that we need to make sure that they're motivated. So potentially looking at retention strategies for them from compensation and other types of motivational strategies that you can think of.
So just focusing on that is very important. It's because of that knowledge base, and software clients are obviously key. And we'll talk about that later as well, but in terms of employees holding that knowledge base about that code and how it works is very important.
I'm curious to know if you have this approach to get beneath that to get a real sense that this person to fight risks, are they really going to stick around?
To your point. You can't tell, it's hard to tell what somebody's motivation is. Especially if you don't know them very well and you don't get access to that second layer until way later in the process for confidentiality reasons.
So it's hard, but I think what you can do is set up proper incentives, make it attractive enough and have the right kinds of incentives with metrics and targets that they're motivated to stay around and have a vast over time, those types of things.
Let's talk about how tax issues affect deals? What kind of tax issues affect deals?
So this is why tax deals are actually one of my favorite topics. I come from structured finance and tax was always a big deal there.
I know most people, their eyes can glaze over when they hear about taxes, but can actually be quite important. And so where, and sometimes deal-breakers even more can be nearly deal-breakers.
So the kinds of things I've seen, for example, You'll have a corporation. It's a kind of corporation that is a flow through, it's called an S-corporation.
The owner just reports the income from it on their tax return. They have to be set up in a very, very specific manner. Document A has to be filed before document D with the IRS.
Otherwise your whole set up could be in danger and you may not even know that you haven't done it the right way. So what I've seen is sometimes a founder thinking they're starting a mom and pop shop and they're not sure they think they're going to get that they do the filings themselves online.
And then 20 years later, it's a huge company with a lot of revenue, a lot of employees. And then you only find out when you're doing an M&A process, that you actually didn't file the document D after document A.
That should be in the right order and your whole setup is completely at risk. So instead of an S-corporation where you have your income flowing through to you and you're not paying taxes on the corporate level.
You could be in danger of being deemed a corporation, like a C-corporation, where you would actually have to pay taxes at that level. And also you could have, if you're doing a special kind of transaction where you might be doing a stock deal, but want to treat it as an asset deal for X purposes, we refer to it as a 338H10 exchange.
It cannot be done if you didn't file your S-corporation documents in the right way. So what can happen in the practical sense is that you're either not allowed to treat it, but tax purposes here at 338H10 election is completely not available.
Which can change the economics significantly to you as a buyer or the founder can be deemed to be owing all these taxes going back, let's say 15, 20 years to whenever they founded the company, which could be depending on what their revenue could be tens of millions of dollars.
It could be, it could be even more than that. So a huge issue and very difficult to solve.
I also find that sometimes I've seen cash flows between related entities where people pay management fees from the left hand to the right hand, when you're in a small environment, it can be fine.
But when you're dealing with a larger corporation, acquiring them, this kind of thing will be scrutinized by the IRS.
So you have to be an acquirer that is very cognizant of that because this could be audited and could be then reversed and then as an acquired, if you're acquiring the assets of the company, especially if you're acquiring stock, but even if you're acquiring the assets of the company, these liabilities can follow you around.
So you definitely want to make sure that that's mitigated by various means. And then I would just mention very briefly, I've seen a lot of state and local tax issues with software companies especially.
It's an interesting one because you might be selling software to a client in a different state and haven't filed your local income tax returns, or maybe didn't file them in all the States that you're supposed to.
And again, that could be over years and years and years could adapt to some significant money as well.
You actually reminded me of a conversation I had with the CEO earlier this week, where they're growing to the mid size company size. And as they're doing business in different States, some States require you to pay taxes on software sale. And this sort of whole wayfarer judgment has really thrown things off with that tax liability. And that now they have States that come back and say, "Hey. No, we want to see all the transactions you've done with the state."
Yeah, that's right. And it will come back like, and again, thinking as an acquire, this is something will follow you around.
Definitely, I know as a stock purchase, even as an asset purchase, you would deem to be buying all of the assets or substantially all of the assets, they will follow you around.
So it's something that you have to understand and just whatever the statute of limitations, usually seven years, six years, something like that.
And then just add up those taxes that they haven't paid and figure out what that amount is. Potentially that's something you'd have to be cognizant that potentially could be the risk you're taking for that state.
How do you mitigate this? How do you end up dealing with that?
So it depends on very different fixes depending on the situation. So, but the example I gave where the S-corporation, in some cases you can actually go to the IRS and ask for forgiveness essentially.
So there's a program that these kinds of things where it was an honest mistake and you didn't do it on purpose, you treated yourself as a mask, so you never meant to do it any other way. They will actually give you grain to amnesty.
So that's something that can be done.
And the other thing is there's this whole industry that developed over the last few years about tax insurance for M&A deals specifically.
So there are folks that will underwrite these types of risks.
So for example, this escort situation, your solution is you're going to go to the IRS and you're going to identify this program and you're going to file for this amnesty and probably in six months you will get your amnesty . So that's what your tax counsel is telling you, but there's risk, not a hundred percent that they'll get it to you.
You can actually buy tax insurance from certain providers that will underwrite this type of risk and many other tax risks. So in some cases, this can be very useful because otherwise, sometimes these deals will fail.
If someone says this is a big dollar number and we can make an escrow for it, let's say, but your escrow would just have to be so large that you couldn't be workable. In those cases, you can take advantage of some of those insurance products.
And then for state and local taxes, no, you can do something similar or you can usually those are much smaller and you can set up escrows for that. Let's say for a couple of years, nothing happens then escrow releases to the seller.
Who do I need on my M&A team to be that subject matter expert to identify those risks?
So usually you would have someone who is knowledgeable about federal taxes and state and local taxes. In a larger company, it would probably be your head of tax and their team who would have that knowledge.
They would usually have the expertise or at least to check the federal setup as well as state and local. In many cases though, because the tax department is small or just doesn't have enough capacity, that would be a part of your financial due diligence.
So you would be hiring a third party to do your financial diligence, quality of earnings and so on. And then part of that, you can negotiate to have a tax module as part of that. Those kinds of things could be addressed by one of the bigger accounting firms of whoever's doing the financial diligence. They could definitely dig into that.
Sometimes it's done by your legal team. So as part of your legal due diligence, these kinds of things come up as well. So a combination of lawyers looking at it as well as finance slash stocks folks.
What's important to understand about a software company's client base?
This kind of question goes directly to your financial rationale and how valuable this company is to you. So you will have to understand if you have, especially if you have a concentrated client base.
Then how concentrated is it? And also how sticky are those software clients? And even though software tends to be relatively sticky, because it takes a lot of time and effort to implement a new system, new software for your company, especially the press clients.
That said, however, there can be various degrees of attachment to the founder and the current management team or those guys that are at risk for leaving. Then you might have clients leave as well.
So it's something that you want to diligence and usually I like to do it for any concentrated big clients via client calls.
Either right before signing, or maybe at some point late in diligence, you might have client calls where you set up a time with important clients and you talk to them about what's their relationship with the company.
How happy are they? What are the issues? Just try to gauge how engaged they are and how likely they are to continue with that product and with you as a company.
What about some backdoor access to due diligence or other angles to get a sense of what the com, obviously there's online reviews and things like that.
You're a little bit limited to what you can do depending on what stage you're in the deal process. You may still be the highly confidential phase. You can dig around and ask people if you know any employees of that company, which can be tricky.
Or just trying to figure out what people think about their product and what their general reputation is. It's useful to try to do that. It's hard to do though, without giving it away.
What about in the customer contract itself? Are there any particular things to look out for?
Customer contracts, number one thing, and not specific to software, are any kind of triggers that are M&A related or change of control related. So this is something that's very important in software because most companies that are implementing a system, like a very big effort, very big expenditure for them.
So they tend to put a lot of those clauses in. And so I want to make sure that if there are any kind of change of control where the customer has the right to consent or get out, I want to understand what those are.
You also have situations and I've seen where customers, some of the larger customers have even rights to buy a copy of the code on change of control. So this is something that can be very tricky for a deal.
If you're buying your company, your target and your code is really cheap asset of that company. And so if you have different versions of the code flying around, the customers maybe having licenses, perpetual licenses on it, you have to make sure that you fully understand those types of issues.
What type of IP issues have you seen in software deals?
In addition to the code audit and the clear title and the open source that I mentioned. I would also say that this other example that I mentioned about people selling different versions of the code to others, that may be floating out there, is definitely one that I would take a look up. In some cases it can prevent a M&A deal all together.
In one situation, we were negotiating to buy a company. It turned out that they sold copies of this code to others, so that wasn't going to work. And then in that case, you might be able to, instead of a M&A deal, you still want that capability for your business.
Maybe it's better to do a licensing arrangement instead, that could derail an M&A deal, but it could also bring up potentially even a better alternative through licensing.
How do you look at it as a risk? Can somebody else could come to market with the same kind of solution?
It depends on what the licensing deal is but potentially if you're not buying the whole company, maybe you're doing a carve out. You're just buying that particular asset but there could be related codes or versions of the code that that company keeps whoever the seller is.
And then tries to launch products with that other version of the code that's somewhat different but not different enough for you.
And that causes you to then compete against that potentially. Or they could, maybe they're not doing it now, but then they have a potential to develop a product that's similar to yours or similar enough to yours.
What are some other aspects of due diligence that come up a lot in the software M&A?
So the other thing I would also note is accounting. This is something that has been in process for a while. So there's a new or relatively new, several years old accounting standard called SCS606 and that is a different way to stake your revenue.
Many companies have already shifted to it over time. There's been some extensions because of COVID and for smaller companies and so on.
So you just have to make sure that somebody is giving your financials, especially at a very early stage, when you're just browsing or you're just having the initial conversations that you are making sure that they are using the 606 or if they're not, then you know how to restate that.
These could be very material changes. I've seen most of it did that, disappear from the year that you're forecasting and then in the black hole because it's been swallowed up by the prior years.
And so all of a sudden you're looking at a much smaller company even though nothing really changed. The company is still the same product, but the way it's accounted for has changed.
So your valuation shouldn't really change, it's just the accounting.
However, the multiples are different now and it can be a different exercise to forecast, different exercise to sell it because you're looking at a much smaller EBITDA that's something that people can underestimate the impact of.
Seemingly it's just an accounting change, but visually it can have a big impact for people.
What advice would you give to one of those traditional manufacturing companies that's doing their first acquisition of software, in terms of getting them to really think about what are the unique nuances that they should be thinking about in doing that deal?
The most important thing is managing expectations of your internal stakeholders and educating them about software M&A processes and very importantly, software multiples.
So a lot of companies and your example of manufacturing, or perhaps some other more stable let's say not as high growth type businesses, maybe not as high margin.
They tend to not trade nearly as high in terms of multiples as a software company with them. So it causes a sticker shock.
When you go for approvals. Folks are saying, you want to pay how much for this, and we're trading at this and you want to pay that and making numbers work, making it creative can be challenging though, in those situations.
So I think it's doing that work with your M&A strategy with your strategy with your executive decision makers to prepare them for that agenda.
So making sure that you're clear, you have a mandate, you have your very clear M&A strategy and you understand that if your M&A strategy includes software purchases, then people understand what that means.
They understand that those kinds of companies can be some heavy multiples, and there's not going to be sticker shock as a result.
When you mentioned strategy, should this organization really demise a specific strategy to go after the software company or if they start seeing some things?
I don't think you necessarily need a specific software or technology strategy, because it would be a part of your M&A strategy.
So usually, what happens is that you have a business line that has adjacencies that let's say this particular product can be helped, you can enter a higher growth segment, you can expand into a different marketplace, maybe you're picking up higher margins.
Other attractive characteristics may be geographic reach, and so on. It's really just part of your overall M&A strategy that you have to be really clear.
And then once you have your M&A strategies set up, then you'll have to make a list of targets that fit that criteria. Then you have to educate folks and have it be known, these are the types of companies that you're going after.
So there are no surprises later on when you have done all that work, having done diligence and you come for approvals, and so it's not a surprise.
Anything else that you think of would be unique for this company to really consider or prepare for outside of what they would do and the traditional approach of doing diligence?
Other than these they would be the typical things you would always look at in diligence, which is your HR type topics and compensation and benefit plans and financial diligence and making sure your quality of earnings is there.
So all of the typical things you would look at, those are the main points that I would highlight as a specific due diligence work stream for software.
Other components would be interesting would be looking at culture side between two unique industries and how that may combine or not combine.
That's actually a good point. So that's something that's usually something you would look at in every deal and definitely a big one with technology where you would have often you're buying a smaller company that has been operating very well as a smaller company, and they've been able to do things.
So let's say often in a much more agile way, they're able to feed up and do stuff and run around without doing too much overhead and approvals.
And then.you're getting a bigger company to swallow them up. You might have approvals that have to be done for certain things. So it's definitely something you want to test out.
I don't think that's a huge deal usually. I haven't seen deals failing for that reason. It's usually more of the hard things that I mentioned in the code, the tax, the accounting, the other stuff. Cultural issues, I haven't seen those fail, but it's something you definitely want to understand and it's a little bit hard to test.
What's the craziest thing you've seen in M&A?
Yes. So I'll give you an example. I've seen tons of crazy things. This one's a public example that I'll talk about a little bit more. This was a divestiture that I did, a relatively significant one.
We signed a deal and several days afterwards the buyer of the deal was one of their directors, who was accused of tax fraud by the department of justice.
We had a situation, potentially that the impact of that was that we would have some of our purchase price that they were going to pay us, be tainted by the person who was, had an ownership stake in that company.
So that was, the timing of that, that was really crazy. Literally days after signing the deal.
Thank you for taking the time to explore the world of M&A with our podcast.
Please subscribe for more content conversations with industry leaders. If you like our podcast, please support us by leaving a five star review and sharing it. I enjoy hearing feedback and connecting with our listeners.
You can reach me by my email. It's email@example.com M&A science is sponsored by DealRoom, a project management solution for mergers and acquisitions.
Additional educational content is available on DealRoom's blog at dealroom.net/blog. Thank you again for listening to M&A science.