Why missed
The project scope isn't clear yet
At signing, the full list of deliverables may not be determined. The answer isn't to leave it blank — it's to define what's known and reference a statement of work for specifics that will be agreed later.
A deliverable is a concrete artifact with a format, a deadline, and an acceptance criterion. Without all three, "done" is whatever the client decides it is — today.
Free. No registration. No card. No catch.
What it means
A deliverables clause lists the specific outputs the provider will produce: the format of each, the deadline for each, and how the client formally accepts or rejects each one. It transforms "the project" from a vague concept into a list of concrete, checkable items.
Deliverables are the specific things you hand over at the end: a 3,000-word blog post in Google Docs, a logo in SVG and PNG format, a functional mobile app on TestFlight. The clause names each item, its format, its deadline, and the acceptance process.
Any project where you produce a tangible output — documents, designs, code, videos, reports, plans. The deliverables clause is what connects your work to your payment terms: you're owed the next payment when a specific deliverable is accepted.
Without defined deliverables, "the project" is whatever the client imagines it to be. The scope expands silently, acceptance is never formalized, and final payment is attached to a moving target. Clients can always say the project isn't complete.
Why it's missed
Why missed
At signing, the full list of deliverables may not be determined. The answer isn't to leave it blank — it's to define what's known and reference a statement of work for specifics that will be agreed later.
Why missed
Designer assumes Figma source files. Client assumes print-ready PDFs. Developer assumes Git repository. Client assumes hosted app with documentation. What's obvious to each party is different.
Why missed
Small-business contracts rarely include formal acceptance procedures. But without them, the client can hold final payment by simply not responding — and "not responding" has no contractual consequence.
What can go wrong
You delivered the logo in JPEG. The client needed a vector file for printing. You believe the format was implied. They believe they're entitled to a redo. Without a format specification, both claims are arguable.
Client receives the deliverable, uses it, and never formally accepts. Six months later they claim it wasn't what they agreed to. Without a defined acceptance process and deemed-acceptance clause, you have no defense.
Payment is tied to "delivery of final deliverable" but the client claims delivery isn't complete. Without objective acceptance criteria, this argument is decided by who has more leverage — usually the client.
The deliverable list doesn't mention training, documentation, or handoff. The client expects all three. Without defining what's included in each deliverable, anything adjacent gets absorbed into it.
Red-flag wording
These phrases appear in deliverables clauses constantly. Each one leaves a gap that disputes walk through.
Red flag
Completed by whose definition? The deliverable must be the thing, not a characterization of its state.
Red flag
Final which files? In what format? At what resolution? Source files or exports only? "Final files" says everything and specifies nothing.
Red flag
"Related" is a spectrum. The client will define related broadly. Without a specific list, you'll spend hours delivering things you didn't price.
Red flag
If there's no mechanism to deem delivery accepted absent a response, the client can stall indefinitely by simply not signing off.
Safer pattern
A strong deliverables clause combines a specific list with format specifications, a delivery timeline, and an acceptance mechanism that includes a deemed-acceptance provision — so silence from the client can't hold your payment hostage.
BizDraft builds deliverables clauses from your project description, with format defaults appropriate to your industry and a deemed-acceptance window calibrated to your review cycle.
Where it appears
Template
The standard vehicle for deliverables clauses. Every service with a tangible output needs them specified.
See template →Template
Software deliverables — code, documentation, deployment — need particularly careful specification. "Working software" is not a deliverable definition.
See template →Template
Creative work produces files. What files, in what format, with what rights — all must be specified or the deliverable is whatever the client decides it is.
See template →Free. Five minutes. Yours to keep.
Draft your agreementRelated clauses
Clause
The window the client has to accept or reject each deliverable — and what happens if they don't respond.
Read →Clause
The deliverables clause specifies the outputs; the scope of work clause defines the work required to produce them.
Read →Clause
When ownership of each deliverable transfers — typically on acceptance and payment in full.
Read →