Archive for the ‘mergers’ Category

Why Valuation methodologies Should be Different in a Merger Than In An Acquisition: A Case Study

Wednesday, October 24th, 2007


Recently we were engaged to help mediate between two closely held companies that were hoping to merge. The companies both produced sophisticated asset tracking software for owners of commercial real estate. The software allowed centralized tracking of the age and maintenance history/schedule for everything from alarm systems to lighting and elevators.

One company, that we will call Established Co. had been in business for more than ten years and had a stable established client base. Their code was legacy code, character based, not even truly Windows software, although it now ran on Windows. They were making few new sales, but made a great deal of profit on maintenance contracts.

The other company, which we will call Upstart Co. had written really fabulous new software that allowed the use of a web interface. Moving the application to the web not only allowed easy access for the landlord’s employees, but allowed tenants to enter and check the status of work orders.

Upstart Co., however, was having trouble making sales. Part of the problem was a lack of sales expertise. Another issue that they faced was that converting from other systems was difficult so the best potential customers, those that saw the benefits of a computerized asset tracking system, were reluctant to switch to a new system.

Established Co. argued that since there were no earnings from Upstart Co, a fair way to value upstart was to total their development cost and value the company based on those costs (a buy vs. build calculation). This would have given a value of approximately $1,000,000 for upstart Co. Since Established had a long history of earnings, they felt that the fairest way to value themselves would be to use a multiple of 4.5 times EBITDA, making their value approximately $9,000,000.

Upstart Co. didn’t feel that a 10% share of the combined company was fair, although they had a hard time articulating why. One point that they raised was that the software had taken them three years to develop and they said that the lead time was worthwhile. Established Co. countered that they believed that by basing new web-based software on their existing product’s code base they could decrease development time to between six and nine months. Upstart believed that existing customers would quickly switch to their software and that the new software, when coupled with an established player’s name and sales force would create a great deal of growth. Upstart viewed itself as the future and as such felt they should own the majority of the new entity.

Both companies wanted the merger to go ahead, because together the two companies were worth substantially more than they were worth separately. However, neither set of owners wanted a deal that was unfair to them. They came to us and asked us to help them make it work.


We reviewed product literature, the software itself, and financial statements from both companies. Then, we spoke to management of Established Co. and pointed out a few basic problems with their methods of trying to value Upstart Co. First, we pointed out that in a buy vs. build calculation you can not just assume that the cost of development that Upstart incurred would be the same costs that Established Co would incur. In large software projects there are significant chances of significant cost over-runs and more serious failures. Upstart Co. brought in a software project on-time, under budget, and (in the opinion of everyone involved) elegantly designed and executed. There could be no guarantee that Established would be able to do the same. I pointed out that while the cost of the winning lotto ticket in my pocket was $1, the value was far greater.

Another issue with the buy vs. build methodology was that both parties recognized that the value of the combined companies was higher than the value of the two companies separately. Since much of the increase in value came from the growth that would come from the new software, it seemed fair that the owners of upstart be allowed to share in that growth.

After warning against creating incentives for one party that might motivate them to do things that were not in the best interest of the merged company, we suggested that measures, such as the rate at which existing customers adopted the new software – which Upstart and Established had wildly different projections for, could be incorporated into the deal. Both companies, however, preferred to keep the deal simple.

We did two valuations, the one for Established used as its primary methodology, the excess earnings method of valuation. The valuation for Upstart included a Buy vs. Build methodology that took into account the risk of outright failure, the savings in lead time, and the almost certainty that the results of a development effort by Established would produce less elegant software. We also calculated the value of Upstart based on discounted future cash flows, both with and without the merger.

Finally, we explained to the owners of upstart that a company with no proven ability to produce profits is generally worth little to most buyers and that in order to capture some of the value of the combined entity that it would be in their best interest to be flexible on price.

Once given the valuations and a new framework in which to look at the deal, Established and Upstart were able to negotiate a merger.