Where does liability start and end for software as a service contracts? And when should you accept different levels of liability caps in your contracting process? Negotiating software as a service liability caps is a minefield, especially when it comes to selling to enterprise customers. Understanding options for SaaS liability caps will help you navigate this minefield. When it comes to enterprise customers they tend to have higher than usual demands, this is particularly true when your product deals with the customers intellectual property or personally identifiable data. So when do you agree to different levels of liability? Liability is a very individual thing, it will shift depending on the type of product you offer, the customer that you’re selling to and the value of the contract. There is no one size fits all way to think about liability and for this reason people avoid giving advice on what you should accept. With this in mind the following is not legal advice, nor is anything on this blog. This is an outline of what we’ve send in the world of software as a service B2B contracts.
What is a liability cap clause and what does it look like?
An average liability clause will be tacked away under a heading such as Limitation of Liability in a SaaS contract. There can be a lot of ways this will be written but here is a simple, standard example:
To the maximum extent permitted by law and under this agreement, in no event will either party’s aggregate liability for any claims in connection with this Agreement exceed___________________.
The amount which is stipulated in this cap is generally a representation of the amount of risk that the parties in the contract are looking to offset. There can be a number of ways that this cap is broken down, including but not limited to carve outs for certain types of liability. These can be great ways to negotiate the liability that you are agreeing to.
Contract Value Liability Cap
A liability cap linked to the value of the contract is a very common limit to liability in software as a service contracts. This is quite often what SAAS companies will have as their default option if they haven’t set a cap of no liability at all. This level of liability is often linked to the total fees paid in the twelve months period prior to any incident. Below is a boilerplate sentence of what this looks like:
“The total fees actually paid by you under this agreement during the twelve-month period immediately prior to the event giving rise to the liability”
The advantage of putting a cap like this in place is that it gives your customers piece of mind in having a cap that will cover anything that they have invested in purchasing your product and it allows the cap to scale up or down depending on the value of the contract between the two parties. The disadvantage of this type of cap is mostly for the buyer who, depending on the way in which they use your product, may not see it as enough protection for their company.
Dollar Value Liability Cap
In terms of options for SaaS liability caps a dollar value cap is a very straight forward way to set a value on liability caps. Many enterprise companies will lead with this because they have internal policies that are set telling them levels of liability that are allowable for their procurement of new tools.
The issue with dollar value liability caps is that they are often a catch all for procurement teams and by applying a catch all cap there are a lot of disadvantages for smaller vendors. If you’re selling into a company with a contract value in the low ten’s of thousands a one million dollar liability cap probably doesn’t make sense. A lot of the time you are able to push back on this by stating that it is ‘not fit for purpose’ and outlining the use case of your product in your SaaS contracting process. Other times enterprise companies will take a hardline approach to this which can make negotiating difficult. One of the best ways around this is to work closely with your champion or buyer to have a clear outline of what your product does and why such a high liability cap is unreasonable for this type of product.
Mixed Liability Cap
A mixed liability cap of either a number or a value aligned with the contract is often seen as a way of splitting the difference for enterprise companies. It doesn’t really work in the favor of the supplier at all as you are effectively agreeing to a high liability cap and agreeing to further raise this if your contract expands. An example of this is below:
“The higher of $1,000,000 or the total fees actually paid by you under this agreement during the twelve-month period immediately prior to the event giving rise to the liability”
This type of cap should really be treated the same as a dollar value liability cap unless you foresee a very large land and expand opportunity.
Unlimited Liability Cap
Unlimited liability is not really one of the options for SaaS liability caps that you should agree to but there are some circumstances that warrant it. Often if you are selling into a large enterprise company that works with high levels of intellectual property protection or has need for strict adherence to data protection themselves they may ask for an unlimited liability clause in their contract like the one below:
“The supplier’s liability under the indemnity clauses (Intellectual Property) and Data Protection shall be unlimited.”
A lot of the time you can negotiate this down when you have a common sense driven conversation with opposing council, but sometimes it’s just a hardline of “unlimited liability or the deal won’t happen”.
So, when should you agree to accept unlimited liability? Although we cannot and will not advise you on this, what we have seen in the past is agreement to unlimited liability when a software as a service company is in its very early stages of ramping up. The logic being that taking on a high level of risk to get early traction in the market is sometimes something that you have to do. This can be dependant also on the value of the contract and the logo that you are bringing on. Ultimately this is a commercial decision that needs to be made by the business.