Why vendors resist negotiating software maintenance fees

I've been coming down pretty hard lately on certain software vendors for escalating costs of software maintenance contracts as well as the lack of value and flexibility in maintenance programs. I'm not alone in this criticism, as other bloggers, such as Vinnie Mirchandani (aka, Vinnie Maintenance), Ray Wang, and Dennis Howlett have voiced the same concerns.

One thing that has puzzled me for a long time, however, is why vendors are not willing to negotiate software maintenance fees in the same way that they negotiate upfront license fees. One of my associates the other day referred to maintenance fees as the "third rail" of ERP deals--it seems you can't touch it. But vendors often discount the license fees to close the deal. Why aren't they willing to negotiate maintenance fees?

They easy answer is, because that's where they make their money. Although that's no doubt true, I've recently learned that there is another reason.

Issues with revenue recognition
A Spectator reader, who will remain unnamed, recently contacted me about this matter. He is the CEO of a privately-held Tier II ERP company and a veteran of the industry. He'd been observing my rants about vendor maintenance fees and thought it might help me to see the situation from the vendor's perspective, specifically from the accounting side.

He points out that accounting standards for revenue recognition in the software industry have been evolving over the past several years. "Revenue recognition" simply refers to the policies that govern when a company can book sales dollars as earned revenue.

For enterprise system vendors, revenue recognition involves a number of issues. For example, suppose a vendor closes a deal for 100 users, plus implementation services, plus hardware, plus maintenance fees.

• When is the vendor allowed to record the revenue for the software licenses? Does he count it all as revenue as of the date of the invoice, the date the software is shipped, the date the software is installed at the customer's location, or the date that the implementation is complete?

• The implementation services are a bit simpler, as they typically are billed and recognized as revenue as of the date of service. But what if the implementation is performed as a fixed fee? When should the revenue be recognized?
  

• What about the first year's maintenance fees? Should they be recognized as revenue at the time of sale, or amortized over the 12 months? Can the vendor recognize revenue for maintenance in months prior to the software being operational?
  

• And what about the hardware? Should the sale of the hardware be recognized at the time the hardware is shipped, at the time it is installed at the customer site, or at the time that the complete system goes live?

A little thought about questions like this and you can see why the accounting for enterprise system deals can be difficult.

Potential for abuse
Furthermore, if the customer wants to structure the deal differently (e.g. for financing purposes), can the vendor move money between different parts of the deal? For example, can he charge more for the software licenses and take it out of maintenance fees? Or, can he take money out of the implementation services and put it in hardware?

What if moving this money around also lets the vendor recognize revenue earlier than he would have been able to if he had structured the deal as he normally does? Isn't that cheating? It sure could be.

Because moving money from one part of the deal to another may affect revenue recognition (and therefore, tax obligations), a large body of regulations have been promulgated to provide accounting standards for software deals. The most significant of these standards is AICPA's Statement of Position (SOP) 97-2, Software Revenue Recognition (later amended by SOP 98-9). According to The CPA Journal, a publication of NY State Society of CPA's:

SOP 97-2 provides that revenue should be recognized in accordance with contract accounting when the arrangement requires significant production, modification, or customization of the software. When the arrangement does not entail such requirements, revenue should be recognized when persuasive evidence of an agreement exists, delivery has occurred, the vendor’s price is fixed or determinable, and collectibility is probable.

The rules get really complicated when contract accounting is not required. In such cases (which cover many enterprise software deals), the rules require that the vendor’s fee be allocated according to something it calls "vendor-specific objective evidence (VSOE)" of the fair value for each element of the deal. The CPA Journal article explains:

VSOE is limited to the price charged by the vendor for each element when it is sold separately. This requires the deferral of revenue until VSOE can be established for all elements in the arrangement or until all elements have been delivered. If PCS [postcontract customer support] is the only undelivered element in the arrangement, however, the entire fee can be recognized ratably over the term of the PCS contract. In addition, recognition of revenue must be deferred if undelivered elements are essential to the functionality of any delivered elements.

This brief explanation, as complicated as it is, does not do justice to the complexity of these accounting standards. Read the entire CPA Journal article to get an idea of the problems facing software vendors in accounting for sales. You can also read this article from CFO Magazine, which illustrates what happens when a company runs afoul of these regulations.

To further complicate things for publicly held companies, different auditors may have slightly different interpretations of the rules and may force vendors to restate earnings if they do not agree with the interpretation of previous auditors.

Why vendors resist negotiating maintenance fees
But what does this have to do with negotiating maintenance fees? As patiently explained by my CEO reader, software vendors spend a lot of time structuring their pricing for each element of the typical deal so that it will pass muster with their accountants and auditors. Change the structure of the deal, and it is likely that the vendor will have a huge accounting problem.

Therefore, if the vendor appears unwilling or unable to negotiate changes to the maintenance fees, it's not just that the vendor is greedy. It is at least partly, if not largely, due to the accounting considerations.

I believe this explanation and think it is important to keep this in mind when negotiating with software vendors. It does not explain, however, why software maintenance fees are so high to begin with.

As confirmed by my source, rather than try to negotiate a lower percentage on maintenance fees, a better approach would be to negotiate harder on software license fees. As most vendors are now basing their maintenance charges as a percentage of the discounted price of the software, any discount won will pay off in terms of lower maintenance fees over the life of the contract. In addition, negotiating a maximum increase over multiple years is also advisable.

Update, Nov. 28. I contacted Stephen Guth, author of the Vendor Management Office blog, for his take on this post. He spends a lot more time on these matters than I do, so I was interested in his perspective. He writes back:

I think software account reps tick through an ordered list of reasons as to why they want to resist negotiating fees (high margin, annuity stream, etc.), and I think revenue recognition and having to deal with their Controller are somewhere on the list. I used to work for a vendor, and it was always easier for us to go to our special pricing folks than to go to our CFO/Controller. We avoided the Controller like the plague. We would be willing to do deals through our special pricing folks but rigorously resisted any deal elements that required us to go to the controller for approval. I suspect it's the same elsewhere and your contact's perspective confirms my suspicion.

I guess the point is that buyers need to look at the TCO and their own accounting treatment (e.g., capital of a license vs. the expense of maintenance). In some cases, and it sounds crazy, a buyer may want to (as a trade-off) offer to load a software license fee as a concession for a dramatically lower maintenance fee. Again, all about the TCO. And all you and I can do is try to equip people with our perspective so that they can make their own informed decision.

In other words, Stephen confirms that from the vendor's side there are some negotiation points that can be handled through "special pricing" and some that require sign off by the vendor's CFO/Controller. Knowing when you are treading into the second area is key to understanding why vendors resist changing maintenance terms, conditions, and pricing structures. These points may be well-known by those that work on the vendor side of the table, but they are not widely realized by typical buyers that I deal with.

To negotiate successfully, buyers need to understand the needs of sellers. At the risk of repeating myself: software revenue recognition issues are not an excuse for recent escalations in software maintenance fees by certain vendors. But the issues around accounting compliance do explain why, once maintenance program structures, terms, and conditions are established, vendors resist changing them on a case by case basis.

Related posts
Pushing back on software vendor maintenance fees
SAP maintenance fees: where is the value?
SAP under the spotlight for "broken promises"
Vendor software maintenance programs: top 10 wish list
Mad as hell: backlash brewing against SAP maintenance fee hike
Oracle confirms: maintenance fees are virtually all profit
Oracle profits strong, thanks to your maintenance payments
Vendor maintenance fees: just say no
High software maintenance fees and what to do about them