Deliverables vs milestones, and which one you invoice.

A deliverable is something you hand over that the client keeps, such as a document, a set of files or a finished page. A milestone is a dated point the project passes through, and nothing changes hands when it arrives. The difference matters for one commercial reason above all the others: you can invoice against a deliverable because there's something for the client to accept, and you generally can't invoice against a milestone because there's nothing for them to check. Mix the two up in your scope and you reach week eight of a project with two invoices nobody believes are due.

Most explanations of this stop at tangible versus intangible, which leaves you with a definition you can repeat and can't bill against. That's fine inside a large company, where both words only ever describe how far along something is. It's a problem for an agency sending invoices, because here one of the two words is a promise about money and the other is a promise about the calendar, and only one of them survives a client who goes quiet for three weeks.

What separates a deliverable from a milestone?

A deliverable is an object the client ends up owning, and a milestone is a moment the project passes through. The cleanest way to tell them apart is to ask what the client would still be holding if the two of you parted ways that same afternoon.

Finish a brand strategy document and they have a file they can open a year from now, or hand to whoever replaces you. Reach the point where the design direction has been chosen and they have a decision, a calendar entry and probably a confirming email, but nothing they could pass to another agency and get value from. The first is a deliverable and the second is a milestone, and no amount of importance moves either one across that line. Choosing the design direction might be the single most consequential hour of the whole project and it still isn't something anyone can own. The longer version of that definition, covering the types, the count and the acceptance rule, sits on its own page: what project deliverables are and what makes one billable.

The second test is whether the thing can be accepted. A deliverable can be reviewed, compared against what the scope promised, and either approved or returned with comments. A milestone can only be reached or missed. There's nothing to approve about a date, which is exactly why an invoice attached to one has nothing underneath it the moment a client asks what they're paying for.

Which one can you actually invoice against?

Invoice against deliverables, because milestone dates belong on the schedule and a schedule on its own doesn't create an obligation to pay anybody.

Picture the two invoices landing in the same inbox. One says "Milestone 2: design phase complete, $5,200" and asks the client to take your word that the phase is finished, because there's nothing on their side of the exchange to weigh it against. The other says "Logo suite, accepted 14 August, $5,200" and arrives while the vector files sit in a shared folder they opened yesterday. The second turns any disagreement into a specific one about whether those files match what section two of the scope described, which is a question with an answer, and the first one just invites a phone call.

There's one honest exception, and it's the deposit. A payment due on signature isn't tied to a deliverable or a milestone. It's tied to the engagement starting, and both sides read it as booking the time rather than buying an output. Past that first payment, every remaining invoice on a fixed-price project should sit on top of something the client can open.

If a stretch of your plan runs six weeks with nothing the client can hold at the end of it, that isn't an argument for invoicing a milestone instead. It's a signal that one deliverable is carrying too much and should be split into two that can be accepted separately, which is the same instinct behind writing a scope of work clients can't misread in the first place.

What do the two look like across one eight-week project?

Five milestones, four deliverables and three invoices, and the fact that none of those three numbers match each other is the entire point. Here's an $18,600 rebrand and packaging project for a food brand, written out the way it would appear across sections two, three and five of the scope.

Three of the five milestones have a deliverable sitting under them and two don't. M3, the week the logo direction gets chosen, is a genuine turning point that produces nothing Northgate can keep, since all that happened was picking one of three routes in a two-hour call. M4 depends on a printer neither party employs, so hanging money on it hands your payment date to a third company's production queue.

D2 and D3 share an invoice because the packaging artwork can't be finalized until the logo is settled, so they get reviewed in the same week and accepting one without the other never happens in practice.

A milestone with nothing underneath it is a status update, and status updates don't get paid.

One more number is worth writing down while the scope is still open. Dividing the $6,300 packaging line across four SKUs comes to $1,575 each, which becomes the most useful figure in the document the moment Northgate mentions a fifth flavor in week six.

What should the payment line in your scope actually say?

It has to name deliverables as the trigger and say in the same paragraph that milestone dates trigger nothing. Both halves are load-bearing, and the second half is the one nearly every scope leaves out.

The final sentence is the one worth copying into your own template tonight. Leave it out and a client reading a timeline with five dated rows on it can fairly read those rows as the payment plan, because most of the paperwork they've signed elsewhere works that way. You then spend week five explaining a distinction you never wrote down, which always sounds like a rule you invented after the fact.

The five business days carry as much weight as the trigger itself. A deliverable that counts as accepted only when the client explicitly says so puts your whole payment schedule inside somebody else's inbox, and a marketing director on vacation becomes a cash flow problem. Acceptance by silence, with a stated window and a record of when you sent the files, keeps the schedule yours. The project scope template uses the same clause on its deliverables.

What happens when a milestone slips because the client was late?

Every date after it moves and your fee stays the same, provided you wrote that down before the project started. On agency work the review queue is almost always the bottleneck, not the production, so this is the clause that gets used most and gets written least.

The whole clause fits into one sentence. Milestone dates move by one business day for each business day a review runs past its stated window, and the fixed fee doesn't change. That line converts a vague grievance into arithmetic: Northgate takes eleven days on the strategy review instead of five, so every milestone from M3 onward moves six business days, and the week eight handover becomes a week nine handover without anybody negotiating.

Without it, the six extra days quietly come out of your production time, because the client still expects artwork at the printer in week seven and the calendar hasn't grown. You absorb the delay, the last two weeks get compressed, and the whole project reads to them as an agency that struggled at the end. The clause covering a client's own missed deadlines costs one sentence and saves that entire sequence.

Is a new client request a deliverable or a moved milestone?

If it produces something the client keeps, it's a new deliverable and it carries a price. If it only shifts a date, it's a schedule change that usually costs nothing except the dates behind it.

Northgate asking for a fifth SKU in week six is the first kind. It produces artwork that didn't exist before, it costs $1,575 by the figure already sitting in the scope, and it needs a written yes before anyone starts drawing. Northgate asking to push the printer handoff by two weeks because their supplier slipped is the second kind. Nothing new gets made, so nothing new gets charged, but every date after M4 moves and you confirm the new handover date in writing the same day rather than assuming it's understood.

The requests that cause trouble are the ones dressed as schedule changes that are really new work. "Can you show us the packaging in a second color way before we commit" sounds like a small delay and is actually a deliverable that nobody priced. The test doesn't change: if somebody has to make something new, it's a deliverable, whatever the request sounded like. Handling scope creep without losing the client is mostly the habit of running that test out loud, and a change request form is where the answer gets recorded.

Can a milestone and a deliverable ever be the same thing?

They frequently land on the same day, and they're still worth writing as two separate lines. Week 8 in the Northgate plan is the handover milestone and the acceptance point for the brand guidelines at once, which makes merging them look like tidying up.

The two behave differently the moment something goes wrong, which is the only time the distinction earns its keep. If the guidelines come back on week eight with a page of comments, the milestone still happened, because M5 recorded that you delivered on the day you promised. The deliverable isn't accepted and the $3,200 isn't due yet. Collapsing those into one row turns an argument about whether the file was good enough into an argument about whether the date was met, and those two questions have different answers, different evidence and different consequences for your invoice. Keeping the timeline and the deliverables in separate sections, as the scope of work format does, makes that easy to hold to even when the two lines describe the same Tuesday.

Why every milestone in your plan should have a deliverable under it

Go back to the Northgate plan and the number that teaches you something isn't five, four or three. It's two, the count of milestones with nothing sitting underneath them, and knowing that before the project starts is what stops you from writing a payment schedule with two hollow rows in it.

A milestone with a deliverable under it is a date you can defend, because there's a file with a timestamp on it and a five-day window that either passed or didn't. A milestone with nothing under it is a report on how things are going, and reports don't get paid. Deleting the empty ones isn't the fix either, since M3 and M4 are real coordination points that keep everybody honest about the calendar. The fix is knowing which is which while the document is still a draft, instead of discovering it in month two when one of them has an invoice stapled to it.

Docket picks up where the plan leaves off. When Northgate asks for the fifth SKU in week six, the request, the $1,575, and the written yes end up in one record attached to the project instead of spread across a month of email. The scope tells you what a change is worth, and the record tells you whether anyone actually agreed to it, and what scope creep costs an agency over a year is mostly made of changes where the first half existed and the second half didn't.

Frequently asked questions