Freelance contract essentials: what every contract should include

Most freelancers write their first contract by copying one from a friend, a forum post, or a template they found online, then never look at it again. That's fine until a client asks for "just one more small thing," or a project ends and nobody agrees on who owns the files. A good contract isn't about looking professional. It's the document you pull up when something goes wrong, so every clause needs to do real work. Here's what it should contain, and why one section causes more fights than every payment dispute combined.

Scope of work: the clause that prevents the most disputes

If you only fix one section of your contract, fix this one. Scope of work disputes, not late payments, are the most common source of freelance conflict. Payment problems are simple: the client owes a number and either pays or doesn't. Scope disputes are messier: both sides can honestly believe they're right: the client thinks "redesign the homepage" includes the mobile version, you thought desktop only. Neither of you is lying; the contract just never said.

A scope section that prevents this is specific enough to answer "is this included?" without a conversation. That means:

• A numbered list of deliverables, not a category. "Website redesign" invites scope creep. "Homepage, About page, Contact page, desktop and mobile, up to 6 total page templates" doesn't.
• What's explicitly excluded. If copywriting or stock photos aren't included, say so, because the things you assume are obvious are exactly what ends up disputed.
• The number of rounds or meetings included, if the work involves collaboration: three feedback rounds, two strategy calls, whatever fits.
• A defined process for anything outside that list, so "one more small thing" gets a change order, a new quote, or an hourly add-on, instead of happening for free because nobody wants to be difficult.

Vague scope doesn't just cause arguments. It causes unpaid work, since every "quick addition" feels small on its own and saying no feels petty. A written scope gives you something neutral to point to instead of a judgment call.

Payment terms and schedule

This is the clause most freelancers write well, because it's the one that scares them most. Still, get specific about these, not just the total:

• The total price or rate, and whether it's fixed, hourly, or milestone-based.
• The payment schedule (due on delivery, 50/50 split, monthly for retainers), written as actual dates or triggers, not "as we go."
• How the client pays and what happens if a payment method fails.
• Net terms (Net 15, Net 30, due on receipt), stated as a number of days, not "promptly."

If you're unsure which structure fits, freelance payment terms explained walks through when a deposit-plus-milestones structure beats a single lump sum. Whatever you land on, put it in the contract the way you'll invoice it. If the contract says Net 30 and your invoice says Net 15, that mismatch becomes the client's excuse later.

Deposit and cancellation terms

A deposit isn't just cash flow. It's what makes a cancellation clause mean anything: without one, a client can walk away mid-project and leave you holding unbilled time.

Cover three things:

• The deposit amount, typically 25% to 50% of the total for project-based work, due before work starts.
• Whether it's refundable, and under what conditions. Most freelancers make it non-refundable once work begins, which is the point of taking one.
• What happens if either side cancels partway through: what's owed for work completed, whether the deposit is forfeited or credited, and how much notice either side owes.

This clause matters more for longer or higher-value engagements: a one-week logo project can absorb a cancellation, but a four-month retainer that ends in week two, with no deposit and no notice period, can't.

Revision limits

Revisions are where scope creep sneaks in disguised as normal collaboration. Nobody objects to "one more round of feedback." It's only after the fifth round that anyone notices the project has doubled in size.

State a specific number of included revision rounds, define what counts as one ("a single consolidated round of feedback," not five separate emails over two weeks), and set a price or rate for anything beyond that. This isn't about being rigid with reasonable clients. It's about having a pre-agreed answer ready for the client who isn't, instead of inventing a boundary on the spot while frustrated.

Intellectual property and ownership transfer

This is the clause freelancers most often get backwards: the default assumption, for both sides, is that the client owns the work the moment it's delivered. Don't let that be the default in your contract.

Ownership should transfer only after final payment clears, not on delivery. Write it explicitly: "All rights transfer to Client upon receipt of final payment in full." Until then, you retain ownership, real leverage if an invoice goes unpaid, since you can withhold source files, high-res exports, or the final product without breaching the contract.

A few things to spell out alongside this:

• Whether you keep the right to use the work in your own portfolio.
• Whether any tools, templates, or reusable components you built stay yours for future projects, even though the client owns the deliverable.
• What happens to work-in-progress files if the project ends early.

Skip this clause, or leave the transfer date vague, and that leverage disappears by the time the invoice is overdue.

Confidentiality

Most freelance work involves seeing something the client wouldn't want public: pricing, internal processes, unreleased products, customer data. You don't need a ten-page NDA to cover this; a short clause stating you won't share or use the client's non-public information outside the engagement covers the realistic risk for most engagements. Save the longer, lawyer-drafted NDA for ones that involve sensitive IP, financials, or regulated data.

Termination clause

Every contract should say how either side can end it before the work is finished. Without this, "can we just stop" turns into an ambiguous mess about what's owed and what isn't.

Include:

• Notice period: how many days' notice either side has to give.
• What's owed on termination: payment for work completed, typically calculated hourly or by percentage of milestones hit.
• What happens to deposits and any prepaid-but-undelivered work.
• Grounds for immediate termination without notice, like non-payment on your side or a client requesting illegal or unethical work.

A termination clause protects you as much as the client. It's what lets you walk away from a relationship that's gone bad without it becoming a breach-of-contract argument.

Quick reference: what to check before you send a contract

• Scope of work lists specific deliverables, not categories
• Scope explicitly states what's excluded
• Payment schedule is written as dates or triggers, not "as we go"
• Net terms match what you'll actually put on the invoice
• Deposit amount and refund conditions are stated
• Cancellation terms cover partial work and notice period
• Revision rounds are numbered, with a rate for anything beyond
• Ownership transfers only on final payment, stated explicitly
• Confidentiality clause covers non-public client information
• Termination clause states notice period and what's owed

If you're setting this up alongside your client process, a signed contract is just step one. See client onboarding checklist for freelancers for what should happen between "contract signed" and "first invoice sent," including where freelancers often start work before either is settled.

Once your contract has these clauses, the harder part is enforcing them when a client tests one: a scope boundary pushed past, or an invoice left to slide. What to do when a client won't pay an invoice covers the escalation path for payment, but the contract itself is what keeps those conversations short instead of open-ended.