Skip to main content
Out of Scope

is a client reopening an approved deliverable out of scope?

Yes — reopening a deliverable the client already approved and paid for restarts work you'd already closed out, so it sits outside the original engagement. The one exception is a warranty or correction clause that covers defects you introduced, which is repair, not revision.

Why this answer

Final approval is the moment a deliverable stops being yours to keep refining and becomes the client's to use. It's a contractual hinge: before sign-off you owe iteration, after sign-off you owe nothing further on that line item. When a client circles back days or weeks later wanting fresh changes, they're asking you to reopen a chapter the contract has already closed. The practical reason this matters is that you almost certainly priced the deliverable around a bounded set of revision rounds, and approval is what stops that meter running. Reopening it means restarting work you'd budgeted, scheduled, and mentally archived — often after you've moved your attention and capacity to other clients. The framing that helps clients understand it: approval is a checkpoint they chose to cross, not a soft pause. They gave the green light, you delivered against it, and the obligation closed. New direction after that point is a new request with its own price, not leftover work from the old one.

When the answer flips

Three situations soften the Out of Scope read. First, if you shipped a genuine defect — a broken link, the wrong logo file, a typo you introduced — fixing it is correction work and belongs to you regardless of approval status; a sound contract treats that as warranty, not revision. Second, if your agreement carries a stated post-approval adjustment window (some contracts allow minor tweaks for a week or two after sign-off), small changes inside that window are owed, though anything substantive still isn't. Third, if 'approval' was never clearly captured — no email, no sign-off, no payment milestone tied to it — the client can reasonably argue the deliverable was still open, which pulls the situation toward Ambiguous until you can point to a concrete approval record.

What to do next

Anchor the conversation to the approval itself. Find the message, the sign-off, or the paid invoice that marks the deliverable closed, and reference it plainly: 'You approved this on the 12th and we invoiced against it, so it's wrapped — happy to take the new changes on as a fresh piece of work.' Separate the two cleanly so the client doesn't feel you're refusing to help: a correction (something you got wrong) you'll fix at no charge; a change of direction (something they now want different) you'll quote. Put the new request into a short change order with its own scope and fee, priced as a small standalone task rather than buried in the old project's number. If the client resists, offer the honest choice between keeping the approved version as-is or commissioning the update — and resist the urge to absorb it 'just this once,' because that quietly teaches them approval is reversible.

Settled reads your contract and gives you the exact verdict for this situation — try it free →

Frequently asked questions

What if the client says they approved it before they really had time to review it?+

That's a process regret, not a scope reversal. Approval is the signal you're entitled to act on; if a client rubber-stamped something without reading it, the cost of that lands with them, not you. Be gracious about it — you can offer a discounted rate on the reopening as goodwill — but don't treat a hasty approval as if it never happened. On future projects, build in a stated review window before sign-off counts, so nobody feels rushed into a green light they later regret.

Does it matter how long ago the approval happened?+

It matters for tone, not for the underlying answer. A change request the day after approval feels more forgivable than one a month later, and you may choose to flex on the recent one as a relationship gesture. But contractually, approval closes the deliverable whether it was yesterday or last quarter. The longer the gap, the stronger your position actually gets, because you've demonstrably moved on and re-engaging carries a real switching cost you're entitled to price for.

The client already paid the final invoice. Doesn't that mean I owe them changes?+

Payment confirms the opposite — it's the clearest evidence the deliverable was accepted and the engagement closed. Paying the final invoice settles the account for the work as delivered; it doesn't buy an open-ended right to keep editing it afterward. If anything, a paid final invoice is the strongest single artifact you can point to when explaining why new changes are new work. Frame it warmly: the account's square on the original piece, and you'd love to take the next iteration on as its own job.

How do I tell a correction apart from a new revision after approval?+

Ask whether the deliverable does what was agreed. If something is broken or wrong against the brief you both signed off on — a misspelled name, a file that won't open, a feature you promised that's missing — that's a correction you owe. If the deliverable does exactly what was agreed but the client now wants it to do something different or look another way, that's a new revision. The test is the original spec: corrections restore it, revisions move past it.

Can I avoid this whole situation with better contract language?+

Yes, and it's two sentences. State that approval — by email, sign-off, or payment of the linked milestone — closes the deliverable and exhausts the included revision rounds. Then add that changes requested after approval are quoted as new work, except for corrections of defects you introduced. Those two lines turn an awkward 'I thought this was free' conversation into a clause you can simply point at, which clients respect far more than an argument made up on the spot.

What if reopening one deliverable would force changes across others I've already finished?+

Then the stakes of holding the line go up, and so should the price. A change to an approved foundation that cascades into adjacent finished work isn't one small edit — it's a chain of reopenings, each with its own cost. Map the cascade explicitly for the client so they see the full footprint: 'Changing this means revisiting these three things that depend on it.' Often the act of seeing the real scope is what makes a client decide the approved version was fine after all.

Related reading

Answer scope creep from your actual contract — not a template.

Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.

Try it free →Read the scope creep guide