What Counts as a Revision vs. a New Request in Your Video Contract

"Can we just swap the music, it's a small thing" is one of the most expensive sentences in freelance video work, not because a music swap is hard, but because "small thing" is doing an enormous amount of unpaid labor in that request. A different track means re-timing cuts to new beats, re-checking sync points, sometimes re-exporting half the timeline, and if your contract never defined what counts as a revision in the first place, you're now negotiating scope in real time with a client who genuinely believes they're asking for nothing more than a tweak. This is the fight almost every freelancer and small studio has eventually, and if you've ever sat there rewording an invoice explanation three times before hitting send, you already know the feeling. At the end of the day it's completely avoidable with the right handful of sentences in your contract.

Why "revision" is the most contested word in a video contract

Most freelance video contracts say something like "includes two rounds of revisions" and then never define what a revision actually is, which means the definition gets negotiated project by project, client by client, argument by argument, and usually in the client's favor because you're the one who wants to keep the relationship friendly. That vagueness feels harmless when you write the contract, since of course everyone knows what a revision means, until the first client asks for a full alternate version with different messaging and calls it "revision three." At that point you're stuck choosing between eating the extra work or having an uncomfortable conversation you could have avoided entirely with three clear sentences up front.

The line that actually separates a revision from a new request

The cleanest test we've found, and the one we recommend to every freelancer and studio who asks us this, is whether the change modifies something that already exists in the approved cut or introduces something that didn't. Adjusting the pacing of an existing scene, trimming a shot, fixing a typo in a lower third, swapping a color grade note, those are revisions because they refine work already delivered. Adding a new scene, requesting an entirely different messaging angle, swapping the music bed, or asking for a new aspect ratio version, those are new requests because they require new creative decisions and often new source material, not adjustments to decisions already made.

Where this test gets genuinely fuzzy

Some requests sit right on the line, and it's worth naming those explicitly in your contract rather than leaving them to a judgment call mid-project. A music swap is the classic example, sometimes it's genuinely minor if the new track has a similar tempo and the edit barely needs to shift, and sometimes it forces a near-total re-cut. Adding "b-roll" is another one, one extra shot in an existing sequence is a revision, an entirely new sequence built around new footage is a new request. The honest answer is that you can't pre-write a rule for every possible edge case, but you can pre-write the principle, and a principle stated in the contract gives you something to point to instead of relitigating the definition from scratch every time.

What about mistakes that are actually yours

There's one category of change that doesn't belong in either bucket, and it's worth naming so nobody wastes energy arguing about it: if a client is asking you to fix something you got wrong, a misspelled name in a lower third, an outdated logo, a caption that doesn't match what was actually said on camera, that's not a revision and it's definitely not a new request, it's just a correction, and it shouldn't count against the round cap or the price at all. Treating an honest mistake as billable work erodes trust fast, because the client can tell the difference between refining the work together and paying you to fix your own error. One line noting that corrections of the editor's own mistakes are free and don't count toward the cap is usually enough.

Sample contract language you can adapt

Something close to this tends to hold up well: "A revision is defined as a change to material already included in the current approved cut, such as pacing, timing, color, or minor text edits. Requests for new footage, new scenes, alternate messaging, additional deliverables, or format changes not specified in the original scope are considered new requests and will be quoted and billed separately before work begins." That single paragraph does most of the heavy lifting, because it gives both sides a shared definition to check any ambiguous request against, rather than relying on tone or goodwill in the moment.

We've watched this exact clause defuse a dispute in real time more than once. A freelancer we talked to had a client ask, three days before delivery on a two-round package, for the entire voiceover script rewritten around a different value proposition in the second half of the video, framed casually as "just a revision note." Because the contract defined a revision as a change to material already in the approved cut, the freelancer could point to that line, explain plainly why a new value proposition counts as a new creative direction rather than a refinement, and send a same-day quote for the extra work instead of absorbing two unpaid days of rewriting. The client agreed within the hour, because the definition made the boundary obvious to both sides at once.

Pair that definition with a clear round cap so the two pieces work together rather than in isolation, we've written a full breakdown on setting that cap fairly in pricing extra revision rounds, since a strong revision definition and a reasonable overage price solve two different halves of the same problem.

Common gray areas worth naming by name in the contract

Beyond music and b-roll, a few requests come up often enough that it's worth listing them explicitly rather than trusting the general principle to cover them cleanly. Changing the video's aspect ratio or delivering it in a second format, say a vertical cut of a horizontal video, is a new deliverable, not a revision, even if the client frames it as "just resizing it." Rewriting the script or messaging after the edit is underway is a new creative direction, not a tweak, even when only a few lines change, because it usually cascades into pacing and visual changes throughout. And adding a stakeholder who wasn't part of the original review, then incorporating their fresh notes on an already-approved cut, functions as a new round of revisions even if nobody explicitly asked for "more revisions," which is worth flagging specifically if you're working with clients who tend to expand their review committee mid-project. If group approval chaos is a recurring issue for you specifically, we go deep on managing exactly that in getting a marketing committee to agree on one final cut.

Localization is worth naming too if you work with clients who might eventually want a video in a second language. Swapping the voiceover into Spanish and re-timing captions to a new dialogue pace functions as a new deliverable in practice, even when the visuals barely change, because it needs new source audio and a fresh sync pass. Clients sometimes assume a dubbed version is covered under the same two rounds simply because "it's the same video," so naming localization alongside aspect ratio changes saves you a fight in a language you never budgeted for.

How documentation prevents "you never said that" disputes

A contract clause only protects you if you can actually show what was approved and when, which is where most disputes really get ugly, not over the definition itself but over whose memory of the approved cut is accurate. This is a big part of why freelancers running client reviews through Approvals run into far fewer of these arguments, because every version is timestamped and every round of comments is tied to a specific cut, so when a client says "I never approved that scene," you can show them exactly when they did. PlayPause keeps that full history by default, which means the contract language and the visible record work together instead of you having to rely on one or the other alone.

• Define "revision" explicitly as a change to existing approved material
• Name common new-request examples directly in the contract
• Require written approval and pricing before starting anything outside scope
• Keep a timestamped version history as your record of what was approved
• Review your definition annually as your typical project types shift

What to do when a client disputes the definition anyway

Even a well-written clause won't stop every disagreement, because some clients will genuinely believe their request qualifies as a revision even after reading a clear definition, and treating that as bad faith right out of the gate usually makes the conversation worse, not better. The calmer move is to walk through the definition with them directly, pointing at the specific language they agreed to and explaining plainly which side of the line their request falls on and why, "this changes the messaging in the second half, which is outside the revision definition since it's a new creative direction rather than a refinement of what's already approved." Most clients accept this once it's explained clearly, because they're not usually trying to get free work, they genuinely didn't realize where the line sat, which is exactly the gap the contract language exists to close.

For the rare client who keeps pushing after that explanation, offer a small, controlled path forward rather than a flat no, something like "happy to make this change, it falls under a new request so I'll send a quick quote before starting, should take about a day once approved." That response holds the line on the definition while still being genuinely helpful, and it reinforces that new requests aren't refused, they're just priced and scheduled like the separate piece of work they actually are. Over time, clients who work with you repeatedly start to internalize the distinction themselves, and you'll notice the disputes basically disappear by the second or third project together, because the definition stops being a rule you're enforcing and starts being simply how the two of you work.

Building this into your process, not just your paperwork

A contract clause is only as strong as the workflow that backs it up, and that's really the deeper point here, the freelancers who stop having this fight aren't the ones with the cleverest legal language, they're the ones whose review process makes the approved version, the revision history, and the current request all visible in one place. No Film School has covered how much scope confusion costs independent editors over the course of a project, and the pattern matches what we hear constantly from freelancers on PlayPause, the dispute almost never comes from a client trying to cheat you, it comes from a genuinely fuzzy line that nobody wrote down clearly enough to check against.

Write the definition into your next contract before your next project starts, not after the next disputed request lands in your inbox. PlayPause gives you the version history and timestamped comments to back that definition up in practice, and if you want help thinking through your own revision clause, Contact PlayPause or explore PlayPause pricing to see how a flat, per-workspace plan supports freelancers building exactly this kind of clear, defensible process.