Standard Software as a service contracts are designed to protect your IP
As a software as a service company your primary asset is your intellectual property. This is what the company is built on, valued on and how it provides service it its customers. This type of company is specifically created to build a product that can be used to service tens, hundreds or thousands of people at once. Service being the key word. You’re selling a service at scale and because of this you need an appropriate contract that protects your ownership of your startups intellectual property. The key language that these contracts have in them is language around licensing the software, not owning the software.
What should the structure look like?
Typically a SaaS contract comes in one of either two structures, dependant on your customers.
I’m selling an off the shelf B2C product or a B2B product that is aimed at small businesses
Great! This is a spot that allows you to have a high volume of customers who pay you a smaller amount of money. With this there is generally very little the customer can demand in terms of contract variations. You are most likely in a position where you can have your startups website terms and conditions and privacy policy and customers agree to these simply by using your product.
I’m selling into larger SME’s and enterprise customers who have procurement teams
This is where things get a bit stickier. Generally these customers have some contract negotiation power and want some custom terms for the use of your product. Usually you’ll start off with a master service agreement which will contain your overarching SAAS terms and conditions. Within that you’ll have statements of work or work orders which will define the work that will be provided to the customer as part of the contract.
Who does GDPR apply to in SaaS?
GDPR applies to any organisation that is operating and collecting data in the EU. This applies to any organisation that is collecting data from users or customers who are EU citizens whether or not your organisation is based in the EU. So does it apply to you? If you have customers or end users in the EU who you are collecting data from, for example email addresses or cookie based browsing information then GDPR applies to you.
GDPR in the procurement process
If you’re operating a B2B business in the EU you will no doubt be coming up against GDPR compliance issues. This is because of the concept of two types of data handlers that are set out by the regulations, that of data ‘processors’ and ‘controllers’.
Ultimately the data processor is the company providing services. The processor is responsible to maintain records of personal data and how that data is used. The data controller is generally the company that is being provided services (your customer). The data controller is required to ensure that the processor is in compliance with GDPR.
At the end of the day this is why companies you are selling to are asking you to complete GDPR documentation. They are responsible for ensuring that companies that provide them services are GDPR compliant.
Core Components of a Standard SaaS Contract
SaaS contracts have a lot of components that are similar for almost all SaaS companies. These include clauses such as limitation of liability, service level agreements, warrants, jurisdiction and the parties to a SaaS contract. Let’s look at a couple of key ones.
What is limitation of liability in a SaaS Agreement?
The limitation of liability clause in a SaaS agreement is the clause that sets a cap on the amount that a party (usually your startup) can be held responsible for in case of any damages or losses caused by their service. This might be a fixed amount, often the amount paid by the customer in a certain time period (like the past 12 months which is an industry standard for liability), or it might exclude certain types of damages entirely, such as indirect, special, or consequential damages. This clause helps manage risk and protect the SaaS provider from large claims. However, exceptions are usually made for intentional misconduct or gross negligence.
Billing terms for Standard SaaS contracts
Billing terms for B2B standard software as a service contracts can vary a lot depending on the service, the size and stage of the business, and the specific arrangement between the vendor and the customer. However, there are several standard practices:
- Subscription Model: Most SaaS contracts are based on a subscription model, where the customer pays a recurring fee to use the service. The fee could be monthly, quarterly, or annually. Often, discounts are given for longer-term commitments.
- Usage-Based Billing: In some cases, billing can be based on usage. For example, the fee could be tied to the number of users, the amount of data used, or some other metric that reflects the value the customer gets from the service.
- Payment Terms: Standard payment terms are Net 30 days from the date of the invoice, but this can vary. Late payment fees may apply.
- Automatic Renewal: Many B2B SaaS contracts include an automatic renewal clause, meaning the contract will automatically renew at the end of the term unless the customer actively cancels it.
- Price Changes: The contract often includes a clause that allows the vendor to change the price, usually at the time of renewal. Notice of price changes are typically sent to the customer 30 to 60 days before the changes take effect.
- Cancellation and Refunds: SaaS contracts often stipulate that customers can cancel at any time, but they won’t be refunded for the remaining term of their subscription. If the customer is on an annual plan, they often won’t get a refund if they cancel before the year is up.
