Sell a Software Company - The Valuation Dilema

One of the most challenging aspects of selling a software company is coming up with a business valuation. Sometimes the valuations provided by the market (translation - a completed transaction) defy all logic. In other industry segments there are some pretty handy rules of thumb for valuation metrics. In one industry it may be 1 X Revenue, in another it could be 7.5 X EBITDA.

Since it is critical to our business to help our information technology clients maximize their business selling price, I have given this considerable thought. Why are some of these software company valuations so high? It is because of the profitability leverage of technology?

A simple example is what is Microsoft's incremental cost to produce the next copy of Office Professional? It is probably $1.20 for three CD's and 80 cents for packaging. Let's say the license cost is $400. The gross margin is north of 99%. That does not happen in manufacturing or services or retail or most other industries.

One problem in selling a small technology company is that they do not have any of the brand name, distribution, or standards leverage that the big companies possess. So, on their own, they cannot create this profitability leverage. The acquiring company, however, does not want to compensate the small seller for the post acquisition results that are directly attributable to the buyer's market presence. This is what we refer to as the valuation gap.

What we attempt to do is to help the buyer justify paying a much higher price than a pre-acquisition financial valuation of the target company. In other words, we want to get strategic value for our seller. Below are the factors that we use in our analysis:

1. Cost for the buyer to write the code internally - Many years ago, Barry Boehm, in his book, Software Engineering Economics, developed a constructive cost model for projecting the programming costs for writing computer code. He called it the COCOMO model. It was quite detailed and complex, but I have boiled it down and simplified it for our purposes.

We have the advantage of estimating the projects retrospectively because we already know the number of lines of code comprising our client's products. In general terms he projected that it takes 3.6 person months to write one thousand SLOC (source lines of code). So if you looked at a senior software engineer at a $70,000 fully loaded compensation package writing a program with 15,000 SLOC, your calculation is as follows - 15 X 3.6 = 54 person months X $5,800 per month = $313,200 divided by 15,000 = $20.88/SLOC.

Before you guys with 1,000,000 million lines of code get too excited about your $20.88 million business value, there are several caveats. Unfortunately the market does not care and will not pay for what it cost you to develop your product.

Secondly, this information is designed to help us understand what it might cost the buyer to develop it internally so that he starts his own build versus buy analysis. Thirdly, we have to apply discounts to this analysis if the software is three generations old legacy code, for example. In that case, it is discounted by 90%. You are no longer a technology sale with high profitability leverage. They are essentially acquiring your customer base and the valuation will not be that exciting.

If, however, your application is a brand new application that has legs, start sizing your yacht. Examples of this might be a click fraud application, Pay Pal, or Internet Telephony. The second high value platform would be where your software technology "leap frogs" a popular legacy application.

An example of this is when we sold a company that had completely rewritten their legacy distribution management platform for a new vertical market in Microsoft's latest platform. They leap frogged the dominant player in that space that was supporting multiple green screen solutions. Our client became a compelling strategic acquisition. Fast forward one year and I hear the acquirer is selling one of these $100,000 systems per week. Now that's leverage!

2. Most acquirers could write the code themselves, but we suggest they analyze the cost of their time to market delay. Believe me, with first mover advantage from a competitor or, worse, customer defections, there is a very real cost of not having your product today.

We were able to convince one buyer that they would be able to justify our seller's entire purchase price based on the number of client defections their acquisition would prevent. As it turned out, the buyer had a huge install base and through multiple prior acquisitions was maintaining six disparate software platforms to deliver essentially the same functionality.

This was very expensive to maintain and they passed those costs on to their disgruntled install base. The buyer had been promising upgrades for a few years, but nothing was delivered. Customers were beginning to sign on with their major competitor.

Our pitch to the buyer was to make this acquisition, demonstrate to your client base that you are really providing an upgrade path and give notice of support withdrawal for 4 or 5 of the other platforms. The acquisition was completed and, even though their customers that were contemplating leaving did not immediately upgrade, they did not defect either. Apparently the devil that you know is better than the devil you don't in the world of information technology.

3. Another arrow in our valuation driving quiver for our sellers is we restate historical financials using the pricing power of the brand name acquirer. We had one client that was a small IT company that had developed a fine piece of software that compared favorably with a large, publicly traded company's solution. Our product had the same functionality, ease of use, and open systems platform, but there was one very important difference.

The end-user customer's perception of risk was far greater with the little IT company that could be "out of business tomorrow." We were literally able to double the financial performance of our client on paper and present a compelling argument to the big company buyer that those economics would be immediately available to him post acquisition. It certainly was not GAP Accounting, but it was effective as a tool to drive transaction value.

4. Financials are important so we have to acknowledge this aspect of buyer valuation as well. We generally like to build in a baseline value (before we start adding the strategic value components) of 2 X contractually recurring revenue during the current year.

So, for example, if the company has monthly maintenance contracts of $100,000 times 12 months = $1.2 million X 2 = $2.4 million as a baseline company value component. Another component we add is for any contracts that extend beyond one year. We take an estimate of the gross margin produced in the firm contract years beyond year one and assign a 5 X multiple to that and discount it to present value.

Let's use an example where they had 4 years remaining on a services contract and the last 3 years were $200,000 per year in revenue with approximately 50% gross margin. We would take the final tree years of $100,000 annual gross margin and present value it at a 5% discount rate resulting in $265,616. This would be added to the earlier 2 X recurring year 1 revenue from above. Again, this financial analysis is to establish a baseline, before we pile on the strategic value components.

5. We try to assign values for miscellaneous assets that the seller is providing to the buyer. Don't overlook the strategic value of Blue Chip Accounts. Those accounts become a platform for the buyer's entire product suite being sold post acquisition into an installed account. It is far easier to sell add-on applications and products into an existing account than it is to open up that new account. These strategic accounts can have huge value to a buyer.

6. Finally, we use a customer acquisition cost model to drive value in the eyes of a potential buyer. Let's say that your sales person at 100% of Quota earns total salary and commissions of $125,000 and sells 5 net new accounts. That would mean that your base customer acquisition cost per account was $25,000. Add a 20% company overhead for the 85 accounts, for example, and the company value, using this methodology would be $2,550,000.

After reading this you may be saying to yourself, come on, this is a little far fetched. These components do have real value, but that value is open to a broad interpretation by the marketplace. We are attempting to assign metrics to a very subjective set of components. The buyers are smart, and experienced in the M&A process and quite frankly, they try to deflect these artistic approaches to driving up their financial outlay.

The best leverage point we have is that those buyers know that we are presenting the same analysis to their competitors and they don't know which component or components of value that we have presented will resonate with their competition. In the final analysis, we are just trying to provide the buyers some reasonable explanation for their board of directors to justify paying 8 X revenues for an acquisition.