Identifying Risks in Software M&A

Hello M and A Friends. This podcast is brought to you by dealview. M&A is coming back. Would you like to avoid wasting hundreds of hours managing Excel Trackers and building PowerPoint reports? Do you want to make your process more efficient? Well, I have great news for you. Deal Room is MNA management software that saves you time, headaches and improves collaboration so you realize value faster. Learn more@dealroom.net here's to the deal.

I'm Kisam Patel and you're listening to M and A Science, where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals.

Foreign.

Welcome to M and A Science Live. Putting together companies is complicated and taking them apart is even more complicated. We take lessons from real practitioners and enable them through education and technology. In this podcast series, we interview leading M and A practitioners to learn lessons from their experience. Learning proven techniques is key to optimizing your M and A practice. If you're interested in learning more, connect with us on our networking events or access our educational resources@mascience.com I'm your host Kisam Patel, CEO and founder of Dealroom. Today I'm here with Elena Sedilnikova, a corporate development executive with 15 years of M and A in finance experience. She has led M and A teams at startups to Fortune 500. She has set up new corporate development functions, established relevant processes and structure. Elena has M and A Deal experience in technology, healthcare, financial services, fintech 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. Elena, if we can kick things off, if you can just tell us a little bit about your background and experience.

Yeah, sure, I'll be happy to. As you mentioned, I started my career off at J.P. morgan. I started in their investment banking program where I did your typical investment banking role where I did a lot of Excel and PowerPoint and modeling and so on in their leveraged finance group. After that I also worked 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 10Ks 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. So of those 10 years, the first seven years I was in structured finance, so doing very hairy deals, so to speak. Where There would be derivatives structured in or commodities, physical underlying, sometimes there would be all kinds of tax accounting and other issues that your client or Deutsche bank would have to solve. Around the last three years of my career at Deutsche Bank, I was in their corporate finance M and A team. So this was not actually the team that covers clients as you would as an investment banker doing M and A, but this is Deutsche Bank's internal corporate development function for Deutsche itself. So doing deals for Deutsche as a principal. So there I did transactions on behalf of Deutsche bank, primarily in the financial services, but also in the infrastructure space. After that I moved to another role, also a corporate development role at a company called Conduent. So conduent, the 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 the time. So it was still in the process of being set up. My role there was to really come in and help that effort just get that corporate development function started, get the deals, the pipeline flowing, set up the proper procedures, all the infrastructure, the team, everything that 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 small 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 focus on roll ups in the healthcare space. So that's my background.

You've worked on all sides of the deals from some pretty angles there.

That's right. Both as a banker and as a corporate development principal as well.

What is technical diligence? What are the steps of it? And I know our theme today is more specific on software deals.

So in terms of when you're thinking about a software deal, since that's what we're focusing on this podcast, a couple of points that are very important when you're doing technical due diligence that I like to focus on. One is a quote audit and I'll explain a couple of points that are important about that. And the other one is the cybersecurity with the code audit. What is important is to focus on two aspects of it. And what I like to see is first, when we do a quote audit and 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 type issues. So quality of the code, it's 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 you're going to add new clients and add existing clients. It's very important that the code is scalable and can be leveraged for that and potentially for other uses that you can later add to realize your synergies. Then you want to make sure that it's well documented. So if people who might have written the code have left, you're able to trace and make changes and 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. Right? 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 decided just because of that input that you took advantage of. So, so it's very important. 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 patch around. That's very important. And then I would just say that the other piece that I always look at is the technical team review. So the technical team, your internal folks, hopefully have some expertise with what they're looking for. But 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 is working out how they were expected to do there's backup process. What is the server situation, are they using cloud and how's that set up? Making sure that that's all very well.

Understood, really looking for the quality of the code. I like the view on making sure things are documented because I think that's really important that you have a sort of collaborative type of code where somebody else can pick it up and utilize it and know what's going on, not spaghetti. And the other was open source and checking for that, which I think is really important because that's something come up in our own business where as we look to utilize open source technology, that's a big part of the consideration is what are we obligated to, if we continue to take this technology, evolve on it, and we do make it something more of a proprietary, are we responsible for contributing that back to this open source community? And then that sort of led to like, well, we're better off licensing the commercial product instead and just having some clear licensing agreement. And that way it's part of it. It's interesting because I think software gets more complex and you have to look at it from these different views because it's not just one app anymore. Everything's a lot of little things working together.

The last point I would mention is very important to look at your cybersecurity setup and possible 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. This is a very important one. I've had a situation where we had identified a vulnerability and a potential target. And that was one of the issues that was 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.

Now if you're doing tech diligence in our company, we do an annual pen test and we have a SOC 2 audit. Do those cover the checkboxes and we simply provide those reports. Are you looking for that first of all? And then are you still doing your own pen test and assessment as well?

Yeah. So you do both. You'll ask for those kinds of things. Any kind of audits, internal audits, external audits that you might have done. That wouldn't be enough though. Like we would have to still look at your setup and check your settings and things like did 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 have overlooked.

Got it. What people challenges have you seen that are specific to the software company workforce?

On people, in addition to 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. And by onboarding, I don't mean just handing them the 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 technical aspect of the product can take in some cases, six months, a year, it even seems 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're able to stay, or you have a plan to hire and then you have to build in 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 at the high level.

The 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 and 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 and they're not losing their eligibility to even 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, or 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 it 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 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.

That's interesting. 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 or 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.

Okay. So there tends to be a path to make that transition.

It just might need time, you might need some time between signing and closing or building in that cushion for those kind of things.

Any other red flags or things you look for when looking at the people side of these type of software deals.

So overall, the founders obviously very important. One of the most important and critical pieces is making sure that the founders or the management team is motivated, is excited to join your company and wants to continue contributing and dedicating their full efforts to that and then 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 is 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 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 are holding that knowledge base about that code and how it works is very important.

Well, how do you like dig in past the superficial? Yeah, we're really excited to really know, especially if I am on the management team and I'm going to get paid well from this transaction. And of course I'm going to be. Yeah. Put a facade up about being excited for the deal. I'm curious to know if you have this approach, just get beneath that to get a real sense of this person, the flight risk, 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 guest over time, those types of things.

Good post close incentive plan.

Right.

Let's talk about how do tax issues affect deals? What kind of tax issues affect deals?

So this is a dummy. So actually one of my favorite topics, I come from structured finance and tax is 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 in software and sometimes deal breakers even or can be nearly deal breakers. So the kinds of things I've seen, for example, you have a corporation, it's a kind of corporation that is a flow through. It's called the Nest 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 B with the irs. Otherwise your whole setup could be in danger and you may not even know that you haven't done 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 big. They do the filings themselves online. And then 20 years later it's this huge company with a lot of revenue.

A lot of employees.

And then you only find out when you're doing an M and A process that you actually didn't file that document B after document A. It should have been 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 at the corporate level, you could be in danger of being deemed a corporation like the 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 you want to treat it as an asset deal for tax purposes, we refer to it as a 338H10 exchange. It cannot be done if you didn't file your escorporation documents in the right way. So what can happen in the practical sense is that you're either not allowed to treat it for tax purposes, your 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 could be. No, it could be even more than that. So 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 smaller 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. Very cognizant of that because this could be audited and could be then reversed. And then as an acquirer, 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 through 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 add up to some significant money as well.

I'm writing a lot of notes down to talk to our accountant about, by the way, a couple thoughts. You're actually reminding me of a conversation I had with the CEO earlier this week where they're growing the mid sized company size and as they're doing business in different states, some states require you to pay taxes on software sale and then this sort of whole wayfair judgment has really thrown things off with that tax liability and that now they have states that come back and say, hey, we want to see all the transactions you've done within the state. And then they're going back for those taxes. You have this pretty significant recourse that they can demand the taxes on all these invoices that you've transacted with companies in their state. And then you can't go back to a client, say, hey, five years ago we didn't know.

Yeah, that's right. And it will come back like. And again, thinking as an acquirer, this is something we'll follow you around. Definitely. I know as a stock purchase, even as an asset purchase, you deem to be buying all of the assets or substantially all of the assets, they will follow you around. So it's something 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. And potentially that's something you just have to be cognizant that potentially could be the risk you're taking that state.

And that's where I want to get at. How do you mitigate this? Because you gave some really good examples of these tax situations that are hidden and that could potentially surface as some really big liabilities. How do you end up dealing with that? The S Corp person didn't have it in there. Hey, you identified it. Hey, look, if this is a potential risk here, then what do you do?

So it depends on very different fixes depending on the situation. So with the example I gave with the S Corporation, in some cases, you can actually go to the IRS and ask for forgiveness, essentially. So there's a program that for these kinds of things where it was an honest mistake and you didn't do it on purpose, you've treated yourself as a master, so you never meant to do it any other way. They will actually give you, grant you 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 and A deals specifically. So there are folks that will underwrite these types of risks. So, for example, this S Corp situation, your solution is you're going to go to the IRS and you're gonna identify this program and you're gonna 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 100% 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 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. If nothing happens, that escrow releases to the seller.

Wow, those are good ideas on how to overcome that. Have you seen like a specific example when you saw a tax issue severely impact the outcome of a deal?

There was one example where a founder set up a dynasty trust like a family trust. The company was actually held through a trust. One of the founders, there were actually three founders and one of them was a non US citizen at one time. And that founder is out of the picture now. They have nothing to do with the company. But when we're set up and so we had a situation where that person's not being US Citizen had to that actually busted that whole stock setup, you didn't have it treated the right way. So again like similar situation to where you can have the companies that tax structure completely impacted by some technical issue when it wasn't set up the right way, it could get fixed and there was. You could unwind some of these trusts and do steps to mitigate that as well. I don't think I've ever done a deal. But they weren't tax problems. So always, always fascinating subject.

Who do I need on my m and 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 the larger company you would probably be your head of tax and their team who would have that knowledge. They would usually have the expertise 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 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. 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 or whoever is doing a 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. It's a combination of lawyers looking at it as well as finance slash tax.

Folks, whether internal or external. Make sure there's a tax expert there.

So usually a combination varies on company set up and the resources you can get. Most cases you would at least have some external components because it's rare that you'll have all these state and local experts of the right expertise to apply on those kinds of things.

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 it is. 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 enterprise clients. That said, however, there can be various degrees of attachment to the founder and the current management team. Those guys are at risk for leaving, then you might have clients leave as well. So it's something that you want a 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 to 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.

Can you give me examples of questions you would ask them?

You would set up a time, you would have a relationship manager call them actually whoever the relationship manager or the salesperson that normally talks to them, explain the situation, explain that this is in the context of M and A deal and it's we're looking to get some diligence done and trying to understand because they're an important client. And then the kind of questions you would ask is just how long have you been with this company? And confirming kind of the things that you found in diligence. How engaged do you feel that your users are with this product? Are you looking to continue using this product? Are you like on a scale from 1 to 10 how happy you are with this product, other features that are missing. So those kinds of things to get an idea of their engagement. A lot of times you can tell by tone as well. So even if before you ask anything or while you're asking, it's really important, you can tell what the dynamic is between the relationship manager and the client. And also how easy they are to get on the phone as well. Tells you volumes as well.

So get the good and bad. Now these are staged interviews. What about some backdoor access to due diligence or other angles to get a sense of what the com. You know, 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 a highly confidential face. You can dig around and ask people if you know any employees at that company. It can be tricky or just trying to figure 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.

In the ecosystem, we go to the same trade conferences and everybody knows each other. Can I go to the other vendors and be like, hey, what do you think of that company? Or what do you hear about them? Maybe not exactly a customer, but other partners in the ecosystem.

Absolutely. And then you will also get a lot of intel from your business team. Whoever's on the front lines doing the selling, operating the business. They will often go to those kind of conferences and they'll know. They'll hear rumors, they'll go to drinks and they'll know stuff as well. Often you'll hear things like that off the cuff from them. Those are the folks that are really useful to talk to as well. They're losing deals all the time to that competitor. Then they're probably something you could potentially be interested in or look at as an M and a target.

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, is any kind of triggers that are M and 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 and 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 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 at. In some cases it can prevent an M and A deal altogether. 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 Monet deal, you still want that capability for your business. Maybe it's better to do a licensing arrangement instead. That could derail an M and A deal. But it could also bring up potentially even a better alternative through licensing.

It's interesting because even our business we've been approached by like white labeling the product in that circumstance. Obviously there's some variables around it because is it just a pretty tight knit deal that it's here's a single version, who's managing it and so forth. So I can see some complexities around that in terms of who's got rights to what and do you actually have some proprietary IP or maybe not?

Yeah.

Or do you have it but others have copies of it you don't necessarily have control over how tight are those licensing agreements, those kind of things? Exactly.

Well, how do you look at that as a risk? Is it 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 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.

Cool. Keep tight grain on the ip. Make sure it's clear in terms of who's got access and rights to what. And understand that when you are doing deals with other companies, what may be a potential issue for somebody that is looking at your business down the road? What are some other aspects of due diligence that come up a lot in the software M and 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, relatively new, it's 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's giving you financials, especially at a very early stage when you're just browsing or you're just having 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. This could be very material changes. I've seen most of EBITDA disappear from the years 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 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.

The accounting practices. That's really interesting. I didn't think about that.

Well, that's another one of those topics that it sounds dry but it can be fascinating just because it can have such a big outsized impact on deals.

Yeah. So through this interview you've made it apparent that it's much harder to do these software deals with all these little components around it. I'm thinking of a scenario and I've seen this more frequently and I think this is just the direction the world is turning to go towards software. Mark. And Drayson Software is eating the world and I'm seeing more and more non traditional manufacturing company, for example that are acquiring software companies. And it makes sense. The strategic objective is very sensible. I'm curious on your thoughts around 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?

I think the most important thing is managing expectations of your internal stakeholders and educating them about software, M and a process and very importantly software multiples. So a lot of companies, in your example, 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 would. And so it causes 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 accretive can be challenging in those situations. So I think it's doing that work with your M and 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 and A strategy, and you understand that if your M and 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 ticker shock as a result.

So the economics are different. So they need to understand that. When you mention strategy, should this organization really demise a specific strategy to go after the software company or if they start seeing some things? I'm just curious, what do you think about the thinking behind that?

I don't think you necessarily need a specific software or technology strategy. It could be part of your M and A strategy. So usually what happens is that you have a business line that have an adjacency that, let's say this particular product can be helped, you can enter a higher growth segment, you can expand it to a different marketplace, maybe you're picking up higher margins. Other attractive characteristics may be geographic reach, so on. It's really just part of your overall M and A strategy that you have to be really clear. And then once you have your M and A strategy set up, then you 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 haven't done all that work having done diligence and you come for approvals and so it's not a surprise.

And you're going to pay a lot of money for those companies.

If people are not used to those kinds of things, it can be tough. It's something that takes time to educate and get used to and understand the value proposition.

I think there's a lot of organizations that are making these moves to essentially disrupt their own business organization to really stay relevant with the fast changing times. So that sort of tends to be part of it as well. And then once they commit to doing that, saying, hey, we got to make these changes, we're going to make this investments and get past some of the economical differences in the transaction itself going through that process or is there anything going through even diligence and things. And I know you've highlighted some specifics around how do you look at the IP and the code, audits and things like that? Anything else that you think of would be unique for this company to really consider or prep for outside of what they would do in the traditional approach of doing diligence.

Those are probably the main things 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.

It's the other component 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. Yeah, so 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, 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 yeah, you're getting a bigger company to swallow them up. And then you might have approvals that have to be done for certain things. So it's definitely something that 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 the hard things that I mentioned, the code, the tax, the accounting, the other side 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.

Yeah. I was gonna say, from what I've seen, corporate people don't fail deals for culture integration. People might, but not corporate people.

And I think it's important to keep. Right. To make those folks very welcome, give them that attention as they join. So that's gonna be part of your onboarding, part of your transition, HR transition as well. Just getting them even set up in the systems and helping them navigate the stuff around, even how to sign up for benefits and other things like that really helps.

What's the craziest thing you've seen in M and A?

Yes. So I'll give you an example. I mean, I've seen tons of crazy things. This one's a public example. Talk about it a little bit more. This was a divestiture that I did. Relatively significant one. We signed a deal, and several days afterwards, the buyer of the deal was one of their directors was accused of tax fraud by Department of Justice. We had a situation. Potentially the impact of that was that we would have some of our purchase price that they were going to pay us be tainted by that person who had an ownership stake in that company.

So that was.

The timing of that was really crazy. Literally days after signing the deal.

Wow.

Yeah, I mean, it's been in the news a lot. It definitely was a saga for sure.

Yeah. Talk about being dramatic on that. Wow. Yeah, that was crazy. Got any other stories? You got a lot in your head. Just don't name.

Yeah, I do. Yeah.

This one, I mean, this is the only public one that I can really talk about. Many others that are more confidential in nature.

Awesome. Well, I'm curious because I know you have the banking background as well, that tends to lend to all kind of interesting views and what you see in the deals.

Yeah.

Had all kinds of things, like people holding up deals literally at the altar because they thought there would be some damage to be gained, all kinds of stamina. It's just part of the nature of the M and A is drama and things happen.

You overcome it.

There's always some excitement, for sure.

Awesome. Elena, thank you so much for your time. I really appreciate you sharing your experience with us today.

Sure.

Dr. San, it's really nice chatting with you. Thanks for having me on. Take care.

Here's to the deal. Thank you for taking the time to explore the world of M and A with our podcast. Please subscribe for more content and 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 Kison K I s o n dealroom.net M&A Science is sponsored by Dealroom, a project management solution for mergers and acquisitions. Additional educational content is available on Deal Room's blog@dealroom.net blog. Thank you again for listening to M and A Science. See you next time. Time Views and opinions expressed on M and A Science reflect only those individuals and do not reflect the views of any company or entity mentioned or affiliated with any individual. This podcast is purely educational and is not intended to serve as a basis for any investment or financial decisions.