What to do when a client approves work, then changes their mind later

You got the approval. The client said yes, in writing, maybe even with "looks perfect, go ahead." Then three weeks, or three months, later, they come back: "Actually, this isn't what we wanted. Can you fix it?" The approval you were relying on suddenly feels worthless, and you are not sure if you are supposed to redo the work for free, push back, or just quietly give in to avoid conflict.

This happens more than most freelancers admit, and it is worth separating two different things that get confused in the moment: what an approval record protects you from, and what it does not. Getting that distinction right decides whether the conversation that follows is calm and factual, or a drawn-out argument about who said what.

What an approval actually proves

A dated, written approval proves one specific thing: that on a given date, the client reviewed a specific version of the work and agreed it met the brief as discussed. That is it. It is not a guarantee the client will stay happy with that decision forever, and it is not a waiver of every future request. What it gives you is a reference point — a fixed moment you can both point back to, instead of relying on memory or impressions of how the project "felt" at the time.

That reference point is powerful precisely because it is specific. "You approved this" is a weak argument. "You approved version 3 on March 14, the one with the revised homepage layout, in this email" is not an argument at all — it is simply true, and there is nothing to debate about the fact itself. The debate, if there is one, moves to what happens *because* that is true, which is a much easier conversation to have.

What it does not protect you from

An approval does not stop a client from being unhappy with their own earlier decision. Clients change their minds for reasons that have nothing to do with your work: a stakeholder weighed in late, user feedback came back negative, priorities shifted, or they simply look at it again with fresh eyes and like it less. None of that means the approval was invalid — it means circumstances changed after the approval, which is a different problem with a different solution.

It also does not cover work that was never shown as part of the approved version. If a client approved the homepage but now wants changes to a page you never submitted for sign-off, that is a new request, not a reopening of an old approval — treat it as such from the first reply.

Step 1: Pull up the record, calmly

Before responding, find the exact approval: the date, the version or file sent, and the words used ("approved," "looks good, go ahead," a signed-off PDF, whatever it was). You are not pulling this up to win an argument — you are pulling it up so the next conversation starts from facts instead of impressions. Most of the tension in these situations comes from vagueness on both sides about what was actually agreed. Removing the vagueness usually lowers the temperature by itself.

Step 2: Separate "new request" from "you didn't deliver what was approved"

This is the real fork in the road, and it changes everything about how you respond.

If the delivered work matches what was approved — same version, same content, nothing missing — then what the client is asking for now is a change, not a correction. Say so plainly but without blame:

Hi [Name], happy to look at this. For context: this matches what was approved on [date] ([link/screenshot of the approval]). What you're describing now would be a change beyond that version — I'm glad to scope it, estimated at [price/time]. Want me to send a quote?

If the delivered work does not match what was approved — a different file went out, a step got missed, something broke after handoff — that is a mistake on your end (or a tooling/delivery issue), and the approval is irrelevant to it. Fix it as part of the original scope, apologize for the mix-up, and move on. Do not hide behind "but you approved it" when the thing they actually received wasn't the thing they approved.

Step 3: Offer a path forward, not just a boundary

Pointing to the approval and stopping there reads as rigid, even when you are technically right. Pair the boundary with an actual option:

I understand the layout isn't landing the way you hoped now that it's live. Since this is outside the approved scope, I'd suggest treating it as a short revision phase — I can put together 2-3 options for [the specific thing] at [price]. Alternatively, if budget's tight right now, we can note it for a future update. Which works better?

This keeps the relationship intact. Most clients are not trying to get free work — they are reacting to something that looks or feels wrong to them now, and want to know there's a reasonable way to address it. Giving them one, on terms that protect your time, usually resolves it without a fight.

Step 4: When the client pushes back on the approval itself

Occasionally a client will argue they never really approved it, or that approval "didn't count" for some reason ("I was just being polite," "I didn't have time to look closely," "someone else needs to sign off too"). Don't get defensive — restate the fact plainly and let it stand on its own:

I hear you — just to be clear on the record, the approval was sent on [date] in [this email/this message], and it specifically referenced [version/detail]. If there's a sign-off process on your side that wasn't followed, that's worth fixing for next time, but it doesn't change what was agreed here. Let's figure out the best way to move forward from where we are now.

If the client has a genuine process gap — someone on their side who should have reviewed it but didn't — that is useful information. Suggest naming a single approver for future rounds so this doesn't repeat.

The real fix is upstream: specific approvals, not vague ones

A lot of "the client changed their mind" disputes are really "the approval was too vague to mean anything later" disputes. "Looks good!" sent over Slack about an attachment is much weaker evidence than "Approved version 3 (homepage, final copy, blue header) as final, per your email dated March 14." The more specific the approval record, the less room there is for a later disagreement about what it covered — and the shorter these conversations become.

Build the habit before you need it

You cannot go back and fix a vague approval after the fact, but you can make sure the next one is specific enough to settle any future disagreement in one message instead of a week of back-and-forth. The Client Approval Log + 50 Client Messages pack gives you an Excel log that records exactly what was approved, when, by whom and with what evidence, plus ready-to-paste messages for requesting approval, confirming it in writing, and handling exactly this kind of "actually, can we change it" conversation after the fact.

Get the Client Approval Log + 50 Client Messages ($9)