How to Write Terms and Conditions for a Freelance or Service-Based Business

A generic terms and conditions template is written for a website: it covers browsing the site, buying something from a cart, and a limitation of liability if the product breaks. A freelancer or service business isn't selling a product off a shelf. You're agreeing to do specific work, for a specific client, delivered over time, and most of the disputes that actually happen (a client who wants "just one more revision," an invoice that goes unpaid for six weeks, a disagreement over who owns the logo file after the project ends) never show up in a template built for e-commerce. This guide covers the four sections a service business's terms and conditions actually need: scope of work, payment and late fees, IP ownership of deliverables, and client acceptance, in language specific enough to hold up when a client pushes back on it.

Why a website ToS doesn't cover a service engagement

A typical website terms and conditions page is built around a transaction: someone visits, maybe buys something, and the terms govern that visit and purchase. A freelance or service engagement is a relationship that unfolds over days, weeks, or months, with deliverables, revisions, milestones, and payments spread across that timeline. None of the standard boilerplate (acceptable use, cookies, a generic limitation of liability) says anything about what happens when the client asks you to redesign the whole thing after you've already delivered it, or when an invoice sits unpaid past its due date. If you've been operating on a one-page terms and conditions borrowed from a product template, it's worth treating the service-specific sections below as additions to that document, not a replacement for it, since you likely still need the standard sections too.

Scope of work: the section that prevents the most disputes

Almost every dispute between a freelancer and a client that isn't about money is actually about scope: the client believed a task was included, the freelancer believed it wasn't, and neither side wrote down where the line was. The terms and conditions document is where that line gets drawn in advance, separate from (and reinforcing) whatever's in your proposal or statement of work.

A workable scope clause does three things. It states what's included, specifically enough that a third party reading it could tell whether a given task is inside or outside the agreement, rather than a category name like "website design" that could mean almost anything. It states what's explicitly excluded, the tasks clients commonly assume are bundled in but aren't (ongoing hosting, content writing, stock photo licensing, post-launch bug fixes past a stated window). And it states how a change in scope gets handled: a defined change-order or amendment process, in writing, with its own price and timeline, rather than new requests quietly absorbed into the original quote until the project stops being profitable.

The specific version does more work than it looks like at first glance. It gives the client a concrete list to check their expectations against before the project starts, and it gives you language to point to, rather than argue from memory, the moment a request arrives that falls outside it. "May incur additional charges" on its own decides nothing, since it never says which requests trigger that clause or how the charge gets calculated.

Payment terms, deposits, and late fees

Payment disputes are the second most common source of friction, and they're almost always a language problem rather than a client acting in bad faith: the terms never said when payment was due, what happened if it was late, or whether work stopped in the meantime. A service business's terms and conditions should state a deposit or retainer requirement if you use one (commonly 25 to 50 percent up front for project work), the payment schedule for the remainder (on delivery, at defined milestones, or net 15/30 from invoice date), the late fee that applies once an invoice passes its due date (a flat fee, a percentage per month, or both, and check your state's usury limits before setting a percentage), and whether work is paused or deliverables withheld while an invoice is outstanding.

That last point is the one freelancers most often leave implicit and regret it. Stating plainly that final files, source assets, or ongoing work are withheld until payment clears gives you actual leverage the moment a client goes quiet on an invoice, instead of a document that never said withholding was an option in the first place.

The point of writing this out isn't to threaten a client on day one, it's to make the escalation path predictable for both sides before money is on the line, the same way a refund policy for a coaching or consulting business works out its own escalation path for partial delivery before a dispute forces the question.

Who owns the deliverables: IP ownership language

Intellectual property ownership is the clause freelancers get wrong most often, usually by leaving it out entirely and assuming "they paid for it, so they own it" is obvious. It isn't legally automatic. Under US copyright law, the person who creates a work generally owns the copyright unless the work qualifies as a "work made for hire" under a narrow statutory definition, or the creator assigns those rights to the client in writing. A freelancer's terms and conditions need to say explicitly which of three models applies, because a client assuming full ownership and a freelancer assuming a license are two very different deals wearing the same invoice.

Assignment on final payment is the model most service businesses actually want, and it's worth stating the trigger explicitly: ownership transfers to the client once the invoice is paid in full, not on delivery. That single distinction is what gives you leverage if a client tries to use unpaid work while disputing the invoice. It's also worth naming what you retain regardless of which model applies, most freelancers keep the right to display finished work in a portfolio, reuse general techniques or non-client-specific code, and retain ownership of any pre-existing tools, templates, or frameworks the deliverable was built on top of, since none of that should transfer to the client by default just because it appears inside the final file.

Revisions, approval, and what "acceptance" actually means

A scope clause tells the client what's included; an acceptance clause tells both sides when the project is actually done. Without one, "done" tends to mean whenever the client stops asking for changes, which for some clients is never. The fix is a defined revision limit (two rounds is common for design work) stated alongside a deemed-acceptance mechanism: if the client doesn't respond with specific, written feedback within a stated window (five or ten business days is typical) after a deliverable is submitted, it's treated as accepted, and the project moves to its next phase or closes out.

That deemed-acceptance line matters more than it looks, because without it a freelancer can be technically obligated to hold a project open indefinitely while a client's review sits in their inbox unanswered. It also gives you a defensible answer when a client resurfaces three weeks after silence to ask for changes to something they never formally rejected.

Termination, kill fees, and liability

Round out the document with what happens if either side wants to end the engagement before it's finished. State a notice period for termination without cause (ten to thirty days is common for ongoing or retainer work), whether a kill fee applies for terminating a fixed-scope project mid-delivery to cover work already completed, and what happens to any deposit already paid, refundable, partially refundable, or forfeited, mirroring whatever position your deposit clause already took. Pair that with a standard limitation of liability capping your exposure at the fees actually paid for the engagement, which is boilerplate most product-focused templates already include, just make sure the version you're using is written broadly enough to cover a service engagement and not narrowly worded around "goods purchased."

Putting it together

A freelance or service-business terms and conditions document needs four things a generic website template doesn't have by default: a scope clause specific enough to draw a real line between included and extra work, payment terms with a stated escalation path for late invoices, explicit IP ownership language naming which of the three models applies and when ownership transfers, and an acceptance mechanism that defines when a project is actually finished. Everything else, acceptable use, governing law, limitation of liability, can stay close to what a standard template already provides.

Our terms and conditions generator builds the service-specific sections directly: it asks whether you're a freelancer, agency, or consultant, what your payment and deposit structure looks like, and how you want deliverable ownership to work, then assembles a document around those answers instead of a product-sale template with "client" swapped in for "customer." If you're also deciding between a terms and conditions page and a separate client contract for each engagement, our guide on terms of service vs. terms and conditions covers how those two documents typically divide the work.

The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.