SaaS Customer Agreements: Key Clauses Every Australian Software Startup Needs

SaaS Customer Agreements: Key Clauses Every Australian Software Startup Needs

Most software startups spend months building their product and weeks preparing their pitch deck. Then, when it comes time to actually sell the thing, they copy a set of terms of service from a US competitor’s website, change the company name, and call it done.

This is a mistake. Your SaaS customer agreement is the legal foundation of every customer relationship you’ll ever have. It governs what you’re promising to deliver, what happens when things go wrong, and who bears the risk. Getting it wrong doesn’t just create legal exposure — it creates commercial problems when a customer churns, a data incident occurs, or an enterprise buyer’s legal team red-lines your entire document during procurement.

Here are the clauses that matter most, and why Australian startups need to think about them differently.

1. Licence Grant and Scope of Use

A SaaS agreement is not a sale. You are granting a licence to access and use your software, not transferring ownership of anything. This distinction matters, and your agreement needs to make it explicit.

Your licence grant should clearly define:

  • What the customer is getting: access to a hosted software platform, delivered as a service over the internet.
  • The scope of permitted use: how many users or seats are included, whether usage is limited to a particular entity or extends to affiliates, and any restrictions on how the software can be used.
  • What the customer is not getting: no ownership of the underlying software, no right to sublicence, no right to reverse-engineer, decompile, or create derivative works.

This last point catches startups off guard. Without an explicit restriction, a customer could argue they have implied rights to modify or on-sell access to your platform. Spell it out.

If you offer tiered plans with different feature sets, the agreement should reference the specific plan or order form rather than trying to describe every feature in the contract itself. A well-structured SaaS agreement separates the general terms (which apply to all customers) from the order form or subscription details (which are customer-specific).

2. Subscription Term, Renewal, and Termination

SaaS businesses live and die by recurring revenue, so the mechanics of how subscriptions start, renew, and end deserve careful attention.

Most SaaS agreements operate on either a month-to-month or annual subscription basis, with automatic renewal unless one party gives notice before the end of the current term. If you use auto-renewal, your agreement needs to clearly state:

  • The initial term and any minimum commitment period.
  • How and when the subscription auto-renews (e.g., for successive 12-month periods).
  • The notice period required to prevent renewal (30 days is standard).
  • Whether pricing can change on renewal, and how much notice you’ll give of price increases.

On termination, both parties should have the right to terminate for cause — typically for material breach that isn’t cured within a defined period (14–30 days is common). You should also consider whether you want a termination for convenience right (the ability to walk away without cause), and if so, whether it’s mutual or one-sided.

One critical point: spell out what happens to customer data after termination. Best practice is to give the customer a defined window (30–60 days) to export their data, after which you delete it. We’ll come back to this under data handling below.

3. Service Levels and Uptime

Enterprise customers will expect a service level agreement (SLA), and even SMB customers increasingly ask about uptime guarantees. Whether you include a formal SLA in your agreement or publish one as a separate policy, you need to think about what you’re committing to.

A typical SaaS SLA promises a percentage uptime target — 99.9% is the industry standard for most B2B platforms. But the devil is in the detail:

  • How is uptime measured? Monthly? Annually? The measurement period affects how much downtime is actually permitted.
  • What counts as downtime? Scheduled maintenance windows, third-party outages, and force majeure events should be excluded from the calculation.
  • What’s the remedy? Service credits (a percentage of the monthly fee credited to the customer’s account) are the standard remedy for missing an SLA target. Avoid agreeing to refunds or, worse, uncapped damages for downtime.

If you’re an early-stage startup that isn’t yet ready to commit to formal SLAs, that’s fine — but say so. Don’t leave it ambiguous. Silence on uptime doesn’t mean you have no obligations; it means a court will have to decide what a “reasonable” level of service looks like.

4. Intellectual Property Ownership

This clause should do two things: confirm that you own the platform, and clarify who owns the data.

On the first point, the agreement should state unequivocally that the provider retains all intellectual property rights in the software, including any improvements, updates, or new features developed during the term. If a customer provides feedback or feature requests that you incorporate into your product, make sure the agreement includes a feedback licence — an irrevocable, royalty-free licence for you to use that feedback without restriction.

On data ownership, the position should be equally clear: the customer owns their data. You have a licence to host, process, and store that data solely for the purpose of delivering the service. This isn’t just good legal practice — it’s a commercial necessity. No serious customer will sign an agreement that gives the provider ownership of customer data.

Where it gets more nuanced is aggregated and anonymised data. Most SaaS providers want the ability to use de-identified, aggregated data for analytics, benchmarking, and product improvement. This is reasonable, but it needs to be disclosed. Include a clause that permits use of aggregated, anonymised data that cannot identify the customer or any individual.

5. Data Handling and Privacy

If you’re handling personal information — and almost every SaaS product does — your agreement needs to address obligations under the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs).

At a minimum, your customer agreement should:

  • Identify who is the “APP entity” with primary responsibility for the personal information.
  • Specify where data will be stored and processed (especially if you use cloud infrastructure hosted outside Australia — cross-border disclosure under APP 8 requires either consent or reasonable steps to ensure the overseas recipient complies with the APPs).
  • Require you to implement reasonable security measures to protect customer data.
  • Commit to notifying the customer promptly in the event of a data breach (noting your separate obligations under the Notifiable Data Breaches scheme in Part IIIC of the Privacy Act).
  • Set out what happens to data on termination — the export window and deletion commitment mentioned above.

If you sell to enterprise customers, you’ll also need a standalone Data Processing Agreement (DPA) that deals with these issues in greater detail. Some customers — particularly those subject to GDPR through their own international operations — will require a DPA as a condition of procurement.

6. Limitation of Liability

This is the clause that keeps founders up at night, and rightly so. Without a properly drafted limitation of liability, a single customer dispute could expose your startup to damages that dwarf your total revenue.

A well-drafted liability clause in a SaaS agreement typically has three components:

  1. Exclusion of indirect and consequential loss. Both parties exclude liability for loss of profits, loss of revenue, loss of data, and other indirect or consequential damages. This is mutual — it protects you from a customer claiming their lost revenue from a platform outage, and it protects the customer if they breach the agreement.

  2. A liability cap. The total aggregate liability of each party is capped at a defined amount, commonly the fees paid (or payable) by the customer in the 12 months preceding the claim. This gives you a predictable maximum exposure tied to the commercial value of the relationship.

  3. Carve-outs. Certain obligations should sit outside the general cap — typically, a party’s indemnification obligations, breaches of confidentiality, wilful misconduct, and the customer’s obligation to pay fees.

A critical note for Australian startups: you cannot exclude or limit liability for the consumer guarantees under the Australian Consumer Law (Schedule 2 of the Competition and Consumer Act 2010 (Cth)). If your SaaS product is supplied to a “consumer” within the meaning of the ACL — which includes small business purchases under $100,000 — the statutory guarantees (including that services will be provided with due care and skill and will be fit for purpose) apply regardless of what your contract says. Any clause that purports to exclude these guarantees is void.

Since November 2023, unfair contract terms in standard form contracts with consumers and small businesses also attract civil penalties. The ACCC has flagged this as an enforcement priority for 2025–26. If your SaaS agreement is a standard form contract (and almost all click-through terms of service are), every clause needs to be defensible as reasonably necessary to protect your legitimate interests.

7. Governing Law and Dispute Resolution

For an Australian SaaS startup selling primarily to Australian customers, the governing law clause is straightforward: the agreement is governed by the laws of your home state (New South Wales, Victoria, etc.) and the parties submit to the exclusive jurisdiction of the courts of that state.

Things get more complicated when you sell internationally. You might be tempted to adopt US-governing law (particularly Delaware or California) to appeal to American customers, but this creates a mismatch with your Australian consumer law obligations and can make disputes significantly more expensive to manage. The better approach for most Australian startups is to keep Australian governing law and address international customers’ concerns through other mechanisms — like a clear dispute resolution process, a mediation step before litigation, or (for enterprise deals) agreeing to arbitrate under a neutral set of rules.

Getting It Right

Your SaaS customer agreement will be reviewed by every enterprise customer’s legal team, scrutinised by every investor during due diligence, and relied upon every time something goes wrong. It’s not a document you want to rush, copy from a competitor, or treat as an afterthought.

The clauses above aren’t an exhaustive list — acceptable use policies, indemnities, confidentiality, and force majeure all matter too — but they’re the ones that create the most friction when they’re missing or poorly drafted. Getting them right from the start is significantly cheaper than fixing them after a dispute.

If you’re building a SaaS product and need a customer agreement that actually reflects your business model and complies with Australian law, get in touch. We draft these for startups at every stage.

Recent Articles

blog-image
SaaS Customer Agreements: Key Clauses Every Australian Software Startup Needs

Most software startups spend months building their product and weeks preparing their pitch deck. Then, when it comes time to actually sell the thing, they copy a set of terms of service from a US …

blog-image
Equity Crowdfunding in Australia: How CSF Works and Whether It's Right for Your Startup

Most founders thinking about raising capital default to the same playbook: angel investors, venture capital, maybe a convertible note from someone they know. But there’s another option …

blog-image
Cap Table Hygiene: How to Keep Your Startup's Share Register Clean for Investors

Fundraising delays don’t usually start during the pitch. They start during due diligence, when your investor’s lawyer asks for a copy of your share register and cap table — and what comes …