Disclaimers and Liability Caps in New Zealand SaaS Contracts

If you run a SaaS business in New Zealand, the liability clause in your contract can decide whether a bad outage becomes a manageable commercial issue or a business-threatening claim.

Founders often make the same mistakes: they copy overseas wording that does not sit neatly with New Zealand law, they cap liability at a number that does not match the real risk, or they promise too much in sales conversations and then assume a disclaimer will fix it later.

That usually does not work. A disclaimer cannot always erase obligations created elsewhere in the contract, in marketing statements, or under New Zealand law. A liability cap also needs to be drafted carefully, especially if you want it to cover data loss, service interruptions, third party claims, and subcontractor issues.

This guide answers the practical questions New Zealand SaaS providers and customers ask before they sign: what disclaimers and liability limits really do, where they commonly fail, what legal issues you should check, and how to avoid the drafting traps that cause arguments later.

Overview

Disclaimers and liability caps are risk allocation tools, not magic shields. In a SaaS contract, they work best when they match the service you actually provide, the promises you have made during sales, and the legal rules that still apply even if your contract says otherwise.

A sensible SaaS agreement usually separates operational risk, payment risk, privacy risk, and third party risk, then applies different rules to each. That is often more effective than trying to push every type of loss into one broad exclusion clause.

• Check whether your disclaimers line up with your product description, service levels, support commitments, and any promises made before you sign.
• Check whether the Consumer Guarantees Act, Fair Trading Act, privacy obligations, or other mandatory rules may limit how far your exclusions can go.
• Check whether the liability cap is a fixed dollar amount, fees paid over a set period, or a different cap for different claim types.
• Check which losses are excluded, such as indirect loss, loss of profits, loss of data, and loss of business opportunity, and whether those categories are defined clearly.
• Check which liabilities are carved out from the cap, such as confidentiality breaches, privacy breaches, intellectual property infringement, fraud, or unpaid fees.
• Check whether indemnities, service credits, termination rights, and insurance arrangements fit with the disclaimer and liability structure.

What Disclaimers Liability Limits for SaaS Business Means For New Zealand Businesses

For New Zealand businesses, disclaimers and liability limits decide who carries the cost when software does not perform as expected. They matter just as much for an early-stage startup selling subscriptions as they do for an established SME buying software to run finance, operations, or customer data.

A disclaimer usually says what the provider is not promising. For example, it may say the service is provided on an "as is" basis, that uninterrupted access is not guaranteed, or that the provider does not warrant compatibility with every third party system.

A liability cap usually sets the maximum amount one party can recover from the other if something goes wrong. The cap might be limited to fees paid in the previous 12 months, a fixed amount, or separate amounts for different categories of claim.

Why SaaS contracts need more than a standard template

SaaS risk is not just about software defects. It often includes customer data, hosting providers, integrations, cyber incidents, implementation work, and reliance on the platform for day-to-day operations.

This is where founders often get caught. A simple clause copied from a foreign template may exclude liability for service interruptions, but say nothing useful about data export on exit, losses caused by a subcontracted hosting issue, or whether the provider is responsible for statements made during a product demo.

If you are the provider, your contract should limit exposure to business risks that are hard to predict or outside your control. If you are the customer, you want to make sure key risks are not pushed back onto you without warning.

How New Zealand law affects these clauses

Contract wording matters, but it does not sit above everything else. New Zealand businesses should think about several legal rules before they accept the provider's standard terms.

The Consumer Guarantees Act 1993 may imply guarantees into services supplied to consumers. In a B2B context, parties can often contract out of the Act if both are in trade and the contracting out is fair and reasonable, but that needs proper written terms and the facts still matter.

The Fair Trading Act 1986 also matters. If a SaaS provider makes misleading claims about uptime, security, functionality, integrations, or compliance, a broad disclaimer may not undo those representations. Sales decks, proposals, onboarding emails, and verbal statements can all matter.

The Privacy Act 2020 is also relevant where personal information is handled through the platform. A liability clause that tries to push all privacy risk onto the customer may not be commercially acceptable, especially where the provider controls storage, processing, or security settings.

General contract law principles also apply. Clauses need to be clear, brought to the other party's attention, and read in the context of the whole agreement. If a limitation clause is buried in inconsistent terms or clashes with an express promise elsewhere, disputes become more likely.

What these clauses usually cover in a SaaS deal

Well-drafted SaaS contracts usually deal with several separate questions.

• What warranties are given about performance, availability, support, and security.
• What warranties are expressly excluded.
• What losses are excluded altogether.
• What total amount can be claimed if liability does arise.
• Which claims are carved out from those exclusions or caps.
• Whether service credits are the customer's sole remedy for downtime or support failures.

Those points sound technical, but they affect ordinary founder decisions. Before you sign a contract, you should know whether one month of subscription fees is the maximum recovery for a week-long outage, whether the provider is liable if customer data is corrupted, and whether an intellectual property infringement claim sits outside the cap.

Legal Issues To Check Before You Sign

Before you sign, the main legal question is not whether your contract has a liability clause. The main question is whether the clause actually allocates the risks your business faces.

1. Are the disclaimers consistent with the promises in the deal?

A provider may try to disclaim all warranties, but then promise specific uptime, integrations, onboarding support, or compliance features elsewhere. If the operative clauses and the commercial promises do not match, the disclaimer may not achieve what the provider expects.

Check all deal documents together, including:

• the master services agreement or SaaS terms
• order form or proposal
• service level commitments
• statement of work for implementation
• security schedule or privacy notice
• pre-contract emails, demos, and sales statements that the customer relied on

If you are the customer, ask for key promises to be written into the contract. If you are the provider, remove vague marketing language from the legal commitment unless you are prepared to stand behind it.

2. Does the contract properly deal with New Zealand mandatory laws?

A clause is weaker if it ignores laws that cannot simply be written away. In New Zealand, this often means checking whether there is a valid business-to-business contracting out clause for the Consumer Guarantees Act, and making sure the agreement does not create Fair Trading Act risk through exaggerated claims or inconsistent wording.

If the platform handles personal information, also check whether the privacy wording reflects the actual data flow. The party deciding why and how personal information is used may carry different obligations from the party storing or processing it on instructions.

3. Is the liability cap commercially sensible?

A liability cap should reflect the value of the contract and the seriousness of the risk. A cap based on fees paid in the last 12 months is common, but it is not always fair or practical.

For a low-cost self-serve SaaS product, that structure may be acceptable. For enterprise software that sits at the centre of payroll, logistics, healthcare workflows, or customer records, the same cap may be heavily negotiated.

When setting or reviewing a cap, think about:

• the annual contract value
• the customer's dependency on the service
• the cost of replacing the service or restoring data
• whether implementation fees are included in the cap base
• whether the cap applies per claim or in aggregate
• whether separate caps apply to privacy, confidentiality, or IP claims

4. Which losses are excluded, and are those exclusions clear?

Many SaaS contracts exclude indirect or consequential loss, but those labels can be argued about. It is often clearer to list specific excluded categories as well.

Examples often include:

• loss of profits
• loss of revenue
• loss of anticipated savings
• loss of business opportunity
• loss of goodwill
• loss or corruption of data, unless caused by a specified breach

The real issue is whether those exclusions leave the customer with any meaningful remedy. If every serious business impact is excluded and the liability cap is low, the customer may be taking almost all practical risk.

5. What sits outside the cap?

Most negotiated SaaS contracts do not apply one cap to everything. Certain liabilities are often carved out because they are too important, too blameworthy, or too insurable to be treated the same way as ordinary service failure.

Common carve-outs include:

• fraud or wilful misconduct
• breach of confidentiality
• privacy breaches and security incidents
• intellectual property infringement
• death or personal injury where relevant
• the customer's obligation to pay undisputed fees

The parties do not always agree on every carve-out. Providers often resist unlimited liability for data incidents, while customers often resist a cap that leaves them exposed after a serious privacy or security failure.

6. Do indemnities cut across the liability cap?

An indemnity can shift risk in a more direct way than an ordinary damages claim. That is why you should always check whether indemnities are subject to the same exclusions and cap, or whether they sit outside them.

For example, a provider may indemnify the customer for third party IP infringement claims. A customer may indemnify the provider for unlawful content or misuse of the platform. If the contract is silent on how indemnities interact with the cap, there may be room for dispute.

7. Are service credits the only remedy for outages?

Some SaaS contracts say service credits are the sole and exclusive remedy for downtime. That can be acceptable for minor service level misses, but it is a different question if the outage is prolonged, repeated, or tied to a larger breach of contract.

Before you rely on a verbal promise that "we always make customers whole", check what the signed terms actually say. If service credits are the only remedy, recovery may be much smaller than expected.

8. Does the contract deal with data return, deletion, and transition risk?

For many SMEs, the biggest cost of a SaaS dispute is not the subscription fee. It is the disruption of getting data back out, moving systems, and rebuilding operations.

Your liability and contract review should sit alongside clauses covering:

• data export formats
• exit assistance
• retention periods after termination
• deletion timing
• backup arrangements
• customer responsibility for local copies

A broad data loss disclaimer looks very different if the provider also offers reliable export rights and sensible transition support.

Common Mistakes With Disclaimers Liability Limits for SaaS Business

The most common mistake is treating the liability clause as boilerplate. In SaaS deals, that is often the part of the contract that most directly affects your real downside.

Copying offshore clauses without adjusting for New Zealand context

US and UK templates often use terminology, statutory references, and risk assumptions that do not translate cleanly to New Zealand. They may also be drafted for a much larger provider with a very different insurance position and bargaining power.

This can leave gaps around business-to-business contracting out, misleading conduct risk, or privacy obligations under local law.

Setting the cap too low to be credible

A very low cap may look attractive if you are the provider, but it can slow down sales and trigger redlines in every serious negotiation. It can also create a trust problem if the customer is being asked to hand over important operational data or rely on the platform for mission-critical functions.

A cap should be defensible. If you cannot explain why the figure makes sense, expect pushback.

Trying to disclaim what the contract expressly promises

If the agreement says the software will perform a defined function, meet a service level, or comply with a specified standard, a later clause saying all warranties are excluded may not solve the contradiction. Courts and negotiators read contracts as a whole.

This is especially common where a sales team has promised a feature roadmap, integration outcome, or compliance result that legal terms do not support.

Ignoring pre-contract statements

Founders often focus on the signed document and forget what was said during the sales process. If your customer relied on a statement about uptime, security certification, or product capability, that statement can still create risk.

Internal alignment matters. Your legal terms, proposal, and sales language should point in the same direction.

Leaving privacy and security risk in vague wording

General exclusions are often not enough where the platform handles personal information or commercially sensitive data. Customers will usually want clearer language on security obligations, incident notification, subcontractors, and liability for unauthorised access or disclosure.

Providers also need clarity so they are not accepting open-ended responsibility for customer misconfiguration, weak passwords, or third party systems outside their control.

Forgetting that subcontractors and hosting providers are part of the risk chain

Many SaaS businesses rely on cloud infrastructure, payment providers, messaging tools, analytics vendors, and implementation partners. Your customer will usually still look to you first if one of those suppliers causes disruption.

The contract should make clear what responsibility you accept for subcontractors, and whether any specific third party dependencies sit outside the service commitment.

Not matching insurance to contractual liability

Liability drafting and insurance should be considered together. A provider may agree to carve-outs or higher caps without checking whether its insurance would realistically respond.

That does not mean insurance should dictate every clause, but the mismatch is a common problem. Businesses should discuss cover and exclusions with their broker or insurance adviser.

FAQs

Can a SaaS provider exclude all liability in New Zealand?

No. A contract can limit liability significantly, but not every exclusion will be effective in every situation. Mandatory laws, misleading statements, and the wording of the rest of the contract can all affect the result.

Is a liability cap based on 12 months of fees standard?

It is common, but not automatically fair. Whether it works depends on the size of the deal, the customer's reliance on the software, the sensitivity of the data, and which liabilities are carved out.

Do privacy breaches usually sit outside the cap?

Sometimes, but not always. Some contracts make privacy and confidentiality claims subject to a higher separate cap rather than unlimited liability. The right position depends on the service, the data involved, and each party's bargaining power.

Do disclaimers protect a provider from misleading sales claims?

Not necessarily. If the customer relied on statements made before signing, a general disclaimer may not neutralise that risk, especially where the statements were specific and commercially important.

Should service credits be the customer's only remedy for downtime?

Only in limited circumstances if that allocation makes commercial sense. For minor service level misses, service credits may be acceptable. For serious outages or repeated failures, customers often seek termination rights or broader remedies.

Key Takeaways

• Disclaimers and liability caps in SaaS contracts are about allocating specific business risks, not just inserting standard boilerplate.
• New Zealand SaaS contracts should be checked against the Consumer Guarantees Act, Fair Trading Act, Privacy Act, and the actual sales promises made before you sign.
• A workable contract usually separates warranties, excluded losses, liability caps, carve-outs, indemnities, and service credits rather than relying on one broad clause.
• The best cap depends on the contract value, the customer's dependence on the software, the sensitivity of the data, and the likely cost if the service fails.
• Founders commonly get caught by inconsistent drafting, vague privacy language, offshore templates, and pre-contract promises that the legal terms do not properly address.
• Before you accept the provider's standard terms, check data return rights, subcontractor responsibility, and whether service credits are the only remedy for outages.

If you want help with SaaS contract drafting, liability cap negotiations, privacy and data risk clauses, consumer law and fair trading issues, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.