Software Contracts: 10 Devilish Details

You're about to sign a contract for a core application. You've already reviewed the software's current and future capabilities, performed due diligence on the depth and knowledge of the vendor and its staff, checked references, and assessed the vendor's financial stability.

In my last column, I discussed the key terms and conditions your software vendor must include or define in the contract. So now you're all set to sign on the dotted line, right? Not yet. This column will discuss several other critical criteria you'll need to cover first.

1. Warranties and maintenance liability
What warranties or maintenance guaranties are expressed or implied in the contract? Be certain that they're clearly defined.

2. Regulatory changes and compliance
The contract must explicitly state that the software vendor is responsible for all regulatory compliance within the scope of its application.

[Looking to improve your digital business? Read Top 10 Retail CIO Priorities For 2014. ] 

Remember that such compliance includes state as well as federal regulations. Your vendor might not have previously sold its applications in your state. This requirement is of particular importance with certain kinds of applications, such as payroll, credit card, and consumer-loan processing.

3. Computational errors
The contract should specify responsibility for computational errors (not input errors); for example, incorrect rounding. The contract must define computational errors, how soon your company needs to identify them, and the extent of financial compensation the vendor must pay in the event it makes computational errors.

4. Ownership of code
Does the vendor supply you with only the object code? If so, what's your position of ownership if your vendor reorganizes, files for bankruptcy protection, or goes out of business? Your company must retain complete rights to the source code.

Image: Wikipedia.

5. Software interfaces
The contract should clarify the effect, if any, of other software interfaces on the vendor's system. For example, your company might want to develop, internally or through a contract programming firm, its own interfaces to other applications, such as general ledger and customer information systems.

Non-vendor interfaces might nullify parts of the warranty, particularly responsibility for computational errors.

6. Vendor releases
Does the vendor specify the number of releases it will issue during a given period of time? This contract provision usually isn't necessary, as long as the vendor upgrades in a timely manner. However, it's wise to include provisions that the vendor will provide software releases to meet federal and state regulatory changes and to keep current with market conditions.

Who's responsible for installing the releases? This issue is particularly important if your company intends to develop its own interfaces or modify the software. The last thing you want is your version to be "out of sync" with the vendor's standard.

1 of 2