Software Contract Considerations

Software contracts present unique challenges for customers and are rarely the result of an “arm’s length” negotiation. Instead, potential customers are confronted with the supplier’s “standard” contract language, designed by the vendor’s lawyer to be repeatedly used with little room to negotiate more favorable terms, much like the residential lease contracts used by property management companies. A software contract is often described as a “License Agreement,” which is essentially a lease to use the software over a specified time period and under specified conditions. Before signing a contract (or recommending that someone else does), you must read it and familiarize yourself with the details. Below are examples of frequently encountered terms and considerations to help you understand and negotiate favorable terms in your software technology contracts.

This Best Practices sheet is also available as a PDF.

Guidance

Due Dilligence

Potential customers should thoroughly evaluate the potential vendor’s product(s), as well as the vendor itself. Ask yourself:

Does this product sufficiently meet your needs?
Are other clients of this vendor successfully using this product?
Does the vendor have a proven trackrecord over a meaningful time period?
Is the vendor actively investing in developing, refining, upgrading and enhancing its product(s)?
Is the potential vendor organizationally and financially stable?
Does the potential vendor have the resources to adequately address your needs during the lifespan of your expected use of their product?

Entire Agreement

These provisions specify that the signed contract is what will govern your relationship—not the salesperson's pitch, not a response to a Request for Proposal, not a memorandum of understanding and not earlier drafts of the contract—only the signed version. If there was something of importance discussed weeks or days ago, ensure it is included in the contract language.

Entities/Properties

Consider whether the appropriate entities are identified in the contract. Will the ability to utilize the contracted software or services extend broadly to directly owned, indirectly owned, jointly owned and managed and acquired properties and communities?

In addition, verify whether there is any element of the contract that would require consent by a lender or joint owner. While these consent requirements are less likely to apply to software contracts than leases or easements, the question should still be considered.

Assignability & Termination

Ideally, a contract should be assignable at the owner/manager’s option on a property-by-property basis and overall. Many software and service providers will resist this, particularly without their consent and, more particularly, to a competitor. Ensure the contract addresses what will happen if you sell a community subject to the contract. You should address what happens when you sell/stop managing a given community in your portfolio, stop using the software with respect to that community and cessation of future payments based on use for that community.

Term

The term of the agreement dictates how long you will be doing business with this vendor. Generally, shorter terms benefit the customer because it makes it easier to “change partners” once the term ends. However, consider the term length of licenses of software that is critical to your business and/or enterprise software. Carefully review any provisions that call for “automatic renewal” of the same contract term unless written notification is given by a specified time (30 to 90 days) prior to the contract expiration. Keep a careful record of any such deadlines in the contracts you supervise to never miss a termination notice deadline.

Limitations on Warranty

This somewhat archaic term derives from a party’s promise (or “warrant”) that a product would perform in a specified way or fulfill a particular purpose. For custom software, carefully identify the specifications for the development in the contract and associated warranties as to key custom functionality. For commercial software, you should be looking for a warranty that the software performs materially in accord with its established specifications and/or documentation. Note that in the context of most commercial software agreements, vendors typically disclaim statutory and/or implied warranties including “merchantability” and “fitness for a particular purpose”—warranties that typically automatically attach to consumer (and some commercial) transactions.

This is where you ask the question, “What happens if it does not work?” Discuss and evaluate the vendor’s support and maintenance process and capabilities. Have the software representative describe the process if a variety of things go wrong.

Scope of Work

These provisions are often attached as an exhibit to the “standard contract” and allow the parties to specify the particulars of performance, typically implementation/training and similar ancillary services. The customer has more leverage to extract specific performance goals in these provisions. The implement scope document should clearly describe how the software will be configured to meet the customer’s needs. For complex systems that are integrated with other platforms, the implementation design/scope documentation is a critical component. If something goes wrong, that’s the first place one would look to determine the responsibility for correcting it.

Payment

To the extent possible, shop for comparable prices from comparable vendors. A Request for Proposal process may yield some data that might be helpful in negotiating a price. Another component is timing. Vendors will often “front-load” a software contract to extract a larger portion of the contract price to be paid in the beginning. You retain more leverage if you can make smaller payments over time.

Also consider limits on cost escalations. Does the contract price increase based on the number of users, are there annual increases, or both? It’s preferable that the price be locked in for the duration of the agreement, with a maximum escalation for renewals.

Determine if the contract is set up as an overall license, or does it provide licenses based on users or another metric. Which licensing model depends on the vendor and your specific needs. Consider licenses that are based on a role versus individual users; this allows for licenses to be transferred easily upon personnel changes.

Disputes

Although most business disputes result in settlements, there is consensus that mediation as a pre-cursor to litigation is a potentially less expensive route for all concerned. Commercial contracts often specify that all disputes be resolved in the vendor’s hometown (where its expenses will be the lowest).

Insurance

Many contracts contain provisions requiring your company to add the contractor as an “additional insured” to your company’s policy. Sometimes, the proposed contract will specify a benefit amount. Each policy also carries a “deductible” amount requiring the insured (your company) to pay the first dollars applied to a potential claim. These factors all influence the price of the insurance premiums paid by your company.

Discuss with your employer the current premiums paid, policy limits or deductible to determine what the contract's “additional insured’s” language is going to cost. Never agree to an insurance clause unless you have determined the cost.

Additionally, consider whether the software service provider has the insurance coverage required by your management agreement and that the contract contains the language to document this requirement.

Intellectual Property Indemnification

The agreement should contain a representation by the vendor that the software and/or services do not violate the intellectual property rights of any third party (e.g., patent or trademark rights) and/or an undertaking to defend and indemnify you without limit in the event of any claims or damages to the contrary.

Data Security Provisions

When contracting with a software provider that handles sensitive information, consider data security provisions. NAA has retained legal counsel to provide you with key information that you and your counsel should be aware of concerning the patchwork of data privacy legislation affecting the rental housing industry. The legislation includes the California Consumer Privacy Act (CCPA), the European Union General Data Protection Regulation (GDPR) and mounting pressure for a national standard. Links to guidance:

If the software gathers, uses or holds private information of residents, prospective residents or associates, the contract must contain provisions that require the provider to take measures relating to security. This should include applicable encryption, record retention, controlled access, secure destruction of data when no longer needed and an obligation to comply with relevant privacy and data security laws. The contract should specifically address the provider’s responsibility in the event any such data is wrongly accessed, lost or misused.

Data Ownership

The contract should specify that you own the data and your right to obtain and/or transfer data to a destination of choosing. This is crucial should a provider increase pricing terms, go out of business or suffer a breach.

Sarbanes Oxley (SOX) Considerations

Should your software contract involve the management of financial data, and you are a SOX-obligated entity, the software contract may have SOX implications. Please consult with your accounting professionals to ensure the appropriate language is included. At a minimum, verify that the software or service provider has appropriate internal controls, including a SSAE18 audits of those controls.

Software as a Service (SaaS) Escrow

Customers ask for SaaS escrows as a precaution in case the vendor goes out of business and critical SaaS will dissolve. The parties solve this problem by giving the software running SaaS app to an escrow agent, who will release it to the customer if the vendor goes out of business. Be aware that unless the SaaS is easy to install and operate, the escrow may not be helpful.

Service Level and Compatibility

There are many service level and compatibility requirements to consider:

For remote web-based solutions, the expected minimum standard is 99% uptime. Also, consider liquidated damages (or “penalties”) for failure to meet this requirement.
Ensure the contract addresses compatibility with certain versions of other programs your company relies on.
The contract should identify the vendor’s responsibility to maintain or repair the software.
Ensure the contract specifies the support and training obligations of the vendor and any associated costs. Wait until the customization of the platform is complete to pay for maintenance, support, etc.
Many companies aim to partner with providers that will support single sign-on standards.

Acknowledgements

Baker McKenzie
Karen Hollinger, Senior Vice President, Strategic Initiatives, Avalon Bay Communities
Womble Bond Dickinson