SaaS agreements in Australia, a clause-by-clause guide

Somewhere between the first demo and the first invoice, every software business hits the same moment. The standard terms need to be written, or a customer's procurement team sends back a marked-up draft with changes. Whether you are the provider drafting the agreement or the customer being asked to sign it, that document decides what the subscription actually promises, who owns what, and who pays when something goes wrong.

A software as a service (SaaS) agreement is the contract for hosted, subscription access to software. It does not sell the software itself. The customer pays for the right to use a service for a term, and the provider keeps ownership of the platform and code. The agreement sits inside a small stack of related documents: a service level agreement (SLA) for uptime and support, a privacy policy explaining how personal information is handled, and, where the provider processes personal information for customers, a data processing agreement (DPA) setting out each side's obligations. Terms of use govern visitors to the website. The SaaS agreement governs paying customers, and it is the document that will be enforced when the relationship sours.

The core clauses

What you are actually selling

The services clause is the reference point for every other clause in the agreement. It should name the platform, describe the modules and features included, and cover any implementation or onboarding work the provider will do. Just as important, it should say what is not included: custom development, third-party fees, hardware. It should also set out the customer's responsibilities, such as providing accurate data and maintaining a suitable internet connection.

Two drafting choices matter here. First, tie the scope to an order form or feature schedule that can be updated as the product evolves, rather than freezing a description of features into the body of the agreement. Second, decide how to treat features that are still in development. Language that describes the service "as available" protects the provider; language that promises a roadmap creates an expectation customers can enforce. The variant customers push for is a fixed list of features with a promise that each one will keep working, which quietly turns the list into a warranty of every item on it.

How the price is calculated

Pricing clauses have to survive contact with real usage. If the service is priced by seats, API calls, or storage, define the metric precisely and explain how it is measured and billed, otherwise every overage invoice becomes a dispute.

What to define: subscription tiers, usage metrics and how they are counted, overage charges, billing cycles, invoicing and due dates, late payment consequences, and how GST is handled.
GST: most supplies of digital services to Australian customers are taxable supplies carrying GST at 10%, and a provider needs to account for it. Where a service is sold to an overseas customer, or supplied by a business outside Australia to an Australian consumer, different cross-border rules apply under the ATO's guidance on imported services and digital products.
The trap: a clause that lets the provider change prices at any time with no notice. A price increase is only safe if the customer gets genuine notice and a realistic chance to walk away, and a one-sided right to raise prices is exactly the kind of term that attracts scrutiny under the unfair contract terms rules discussed below.
The variant the other side pushes for: a fixed price locked for the full term, including renewals. A reasonable middle ground is a price review at renewal with notice, or a cap on annual increases.

How long the deal runs

The term clause sets the initial period, whether it is monthly or annual, and what happens at the end. The most common drafting is automatic renewal, where the agreement rolls over for another period unless either party gives notice before a stated cut-off date.

Three things deserve attention. The notice period must be realistic: a customer who must give 60 days notice to avoid an annual renewal can easily miss the window. The clause should say what happens to unused prepaid fees on early termination. And trials need their own mechanics, including what happens when a trial converts to a paid subscription, whether card details are taken at sign-up, and whether trial data survives conversion. From the customer's side, the renewal mechanics should be checked before signing, not when the invoice arrives.

What happens when the service is down

Support expectations are usually split between the agreement and a separate SLA. The SLA sets the availability target, planned maintenance windows, support channels and hours, and response times by severity level. It also sets what the customer gets if the provider misses those targets, typically service credits against the next invoice.

Drafting minimums: the SLA needs a defined measurement method, a cap on credits (usually a percentage of the monthly fee), and a list of exclusions such as customer-caused outages, scheduled maintenance, and events outside the provider's control.
The trap: promising 99.9% uptime before the infrastructure can deliver it. An ambitious SLA converts into automatic credits the moment it is missed, so the target has to match the actual architecture.
The variant the other side pushes for: credits as the customer's exclusive remedy for downtime, so the customer cannot also terminate or claim damages for a major outage. If the credits are the only remedy, the customer should at least have a right to exit where availability falls below the target for a sustained period.
What lawyers argue about: whether service credits are a genuine pre-estimate of loss or a penalty, and whether the exclusion of all other liability for outages survives the consumer guarantees.

What happens to customer data

The customer's data is usually the most valuable thing in the relationship, and the agreement has to say who owns it, what the provider may do with it, and what happens to it at the end.

The starting position is that customers own their content, and the provider gets a licence to use it only to operate the service. Anything broader, such as a right to use customer data to train models or build products, needs to be disclosed clearly rather than buried in a services clause. Where the provider collects personal information about its own customers, the Privacy Act 1988 (Cth) applies through the Australian Privacy Principles. Most businesses with an annual turnover above $3 million are covered, and the OAIC's small business guidance explains that some smaller businesses are covered too, such as those that trade in personal information or handle it under a Commonwealth contract. Where the provider processes personal information on behalf of business customers, a DPA should set out the roles, security measures, sub-processors, and international transfers.

What to cover: a clear statement of data ownership, the licence the provider needs, data residency (where data is stored), backup and retention periods, and the process for returning or deleting data on exit.
The trap: a retention clause that conflicts with the deletion promise. If backups are kept for 90 days, the clause that promises immediate deletion on termination is not accurate.
The variant the other side pushes for: providers often ask for a broad licence to use customer data to "improve the service". That is defensible for aggregated, de-identified usage data, but not for identifiable customer content without consent.

What security you are promising

Security commitments turn the provider's actual practices into contractual promises. The clause should set out baseline measures such as encryption in transit and at rest, access controls, and vulnerability management, and it should state who is responsible for what. Customers also carry responsibilities, such as maintaining strong passwords and managing their own user access.

The incident response part of the clause matters because of the notifiable data breaches scheme in Part IIIC of the Privacy Act 1988 (Cth). Where an entity has reasonable grounds to believe there has been an eligible data breach that is likely to result in serious harm, it must notify affected individuals and the Office of the Australian Information Commissioner as soon as practicable. A provider that stores customer data therefore needs a clear process for assessing and disclosing incidents, and an agreement that lets it meet those obligations without waiting for permission.

There is also a newer reason to take security drafting seriously. A statutory tort for serious invasions of privacy, introduced into Schedule 2 of the Privacy Act 1988 (Cth) and in force since 10 June 2025, lets individuals sue for serious, intentional or reckless invasions of their privacy, including misuse of their information. For a business that holds personal information, that is a direct exposure that sits alongside the regulator's powers.

What customers cannot do with the platform

An acceptable use clause sets the boundaries: no illegal content, no malware, no abusive behaviour, no scraping beyond what is permitted. A fair use policy protects system performance where heavy users threaten the experience of everyone else.

The suspension right is the enforcement mechanism. It should be reserved for serious or repeated misuse, exercised with prompt notice, and paired with a clear reactivation path so a customer is not locked out of their own data over a misunderstanding. A clause that lets the provider suspend at will, with no notice and no defined trigger, is the kind of one-sided drafting that gets struck down as unfair.

Who owns what

The intellectual property clause has to do three jobs. It confirms the provider owns the platform, code, and content, and grants the customer a limited, non-exclusive licence to use the service for internal business purposes. It confirms the customer owns its own content and the provider's use of that content is limited to running the service. And it addresses third-party components, including open-source software whose licences may impose conditions that flow through to the customer.

Two points usually get negotiated. Providers often want a licence to use customer feedback to improve the service, which is reasonable if it is limited to feedback rather than customer content. Customers often want confirmation that any restrictions on reverse engineering or decompiling do not prevent them from extracting their own data. The clause should also handle what happens to the licence if the customer stops paying, and whether the provider can audit the customer's use to check licence compliance.

What happens if something goes wrong

This is where the agreement meets the Australian Consumer Law (ACL), which sits in Schedule 2 of the Competition and Consumer Act 2010 (Cth). Where services are supplied to a consumer, the ACL implies guarantees that the services will be rendered with due care and skill, will be reasonably fit for any purpose the consumer made known, and will be supplied within a reasonable time (ss 60 to 62). These guarantees cannot be excluded, and a business buying services priced above $100,000 is generally not a consumer for these purposes, which is why enterprise deals can negotiate more freely than consumer products.

The unfair contract terms regime then constrains the rest of the clause. Under s 23 of the ACL, a term of a standard form consumer or small business contract is void if it is unfair, and proposing or relying on such a term now attracts penalties. A small business contract is one where a party employs fewer than 100 people or has turnover below $10 million (s 23(4)), so most of the businesses reading this are protected. A term is unfair where it causes a significant imbalance in the parties' rights, is not reasonably necessary to protect the legitimate interests of the advantaged party, and would cause detriment (s 24). The effect is that a liability cap, indemnity, or exclusion clause that heavily favours the provider in a standard form agreement is vulnerable, and the provider bears the burden of showing the term is reasonably necessary.

Warranties: keep them balanced, such as a promise that services will be provided with reasonable care and skill, and state expressly that nothing excludes rights a customer has under the ACL.
Liability cap: cap liability at a multiple of fees paid or a fixed amount, and carve out the categories that cannot be limited by law. The cap has to be high enough to look defensible; a cap at the value of one month's fees in a contract where a data breach could cost the customer far more is a prime UCT target.
Indemnities: use targeted indemnities, such as for third-party intellectual property claims or for customer misuse, rather than broad indemnities that make the customer insurer of last resort for everything.

How either side gets out

Termination for cause covers the obvious triggers: material breach that is not remedied, non-payment, and insolvency. Some agreements add termination for convenience with notice, which suits long-term subscription relationships where either side may simply want out. Suspension rights deal with urgent situations such as a security risk or suspected illegal activity, and should be temporary pending investigation.

The exit mechanics are the part most often skipped and most often regretted. The agreement should promise data export in a usable format, such as CSV or via an API, within a defined timeframe, and should say what happens to copies after export, including when backups are purged. It should also deal with fees for extended assistance during offboarding. From the customer's side, the ability to walk away with the data intact is the difference between a subscription and a hostage situation. From the provider's side, a clear exit process prevents offboarding disputes from becoming chargeback disputes.

How the contract changes

Subscription products change constantly, so the agreement needs a process for change. Product changes and feature deprecations should come with notice, and material changes should give the customer a window to review. Changes to the terms themselves need the same treatment: notification in advance, a stated effective date, and a right for the customer to terminate without penalty if a change is materially adverse.

A clause that lets the provider rewrite the terms at will, with changes taking effect immediately and no exit right, is a classic unfair contract term. The drafting that survives scrutiny is a variation clause with notice, a delay before effect, and a termination right for the customer. It is also worth deciding whether acceptance of a material change is by notice, by continued use, or by an explicit click-through, because continued use as acceptance is harder to defend in a consumer or small business context.

Optional clauses that earn their place

The clauses below are not essential in every deal, but each earns its place in the right agreement:

Beta features: if the provider ships preview features, label them as beta, supply them as is, exclude them from the SLA and support commitments, and give customers an easy way to opt out without affecting their core service.
Sub-processors and subcontractors: where the provider relies on hosting providers or other sub-processors, a clause that lists them, requires notice of changes, and confirms the provider remains responsible for their performance saves hours of procurement friction.
Dispute resolution: an escalation process with good faith discussions and mediation before litigation, plus a governing law clause, usually choosing the provider's home state such as New South Wales, keeps disputes cheaper and predictable.
Security assurance: enterprise customers increasingly want evidence of security, such as SOC 2 reports or penetration test summaries, and an audit or assurance clause that commits the provider to producing them on request.
Non-solicitation: for key account deals, a clause preventing each side from poaching the other's staff during the term and for a period afterwards protects the team that built the relationship.

How an Artificer Legal lawyer would review your SaaS agreement

A lawyer's value in a SaaS agreement is mostly in knowing which clauses get attacked and in what order. We would start with the commercial terms, because scope, pricing, and term drive everything else. We would then move to data and security, checking that the privacy promises match the actual data flows and that the incident response obligations line up with the notifiable data breaches scheme. Liability and indemnities come next, where we would push back on caps that are too low to survive the unfair contract terms test, on broad indemnities that shift the provider's own risks onto the customer, and on "exclusive remedy" language that tries to contract out of the consumer guarantees. Finally we would check the document stack, because a beautifully drafted agreement is undermined when the SLA promises 99.9% uptime the infrastructure cannot deliver, or the privacy policy describes practices the product does not have.

For a provider, we would insist on defined usage metrics, an SLA that matches real capability, a defensible liability cap with clear carve-outs, and a variation clause that gives customers notice and an exit right. For a customer, we would insist on data export commitments with defined timeframes, a real notice period for renewals and price changes, and a suspension clause that cannot be used to lock you out of your own data. If you are about to sign a standard form agreement, or about to publish one for customers to sign, an Artificer Legal review of the template against the current law is a short engagement that prevents the expensive version later.

The clause that decides who pays when the service fails

The clause that most often decides the outcome of a SaaS dispute is the liability cap, because it determines who carries the loss when the service fails, and because in Australia its enforceability is decided by the unfair contract terms test. A cap that is defensible under s 24 of the ACL, with sensible carve-outs and transparent drafting, protects the provider. A cap that is set too low, or an indemnity drafted too broadly, gets struck out as unfair in a standard form agreement, leaving the provider exposed to the full loss it was trying to avoid. The drafting choice that separates agreements that work from agreements that collapse is therefore not any single clause in isolation, but the balance across the warranties, the cap, and the carve-outs, tested against the ACL before the dispute happens, not after.

The practical shape of a good SaaS agreement is simple: a clear scope tied to an order form, defined usage metrics with a defensible pricing clause, a realistic SLA with capped credits, clean data ownership and security promises that match actual practice, a liability cap that survives the unfair contract terms test, and exit mechanics that let customers leave with their data. Australian law overlays that structure with the consumer guarantees, the privacy regime, and the unfair contract terms rules, and it is those overlays that make a template copied from overseas, or from a competitor, a liability rather than a shortcut. Drafted properly, the agreement does what it is for: it lets both sides know what they are getting, and it keeps a service failure from becoming a lawsuit.