How to get client sign-off on a master

Mastering is the easy part. The part that eats your evenings is getting the client to actually approve the thing, cleanly, once, on the version you both mean. Most engineers run this on email and good faith, and it works until it doesn't: a casual "yeah that's perfect" is not something you can point to when the story changes. This guide is about turning that soft yes into a sign-off you can stand on, without making the client jump through hoops.

What "approval" actually is (and why "sounds good" isn't it)

An approval is a record, not a reply. Three things make it real, and an email reply usually has none of them:

• A specific version. "It sounds great" doesn't say whether they mean v2 or the v3 you sent an hour later. An approval names the exact master.
• An identity and a timestamp. Who approved it, and when. This is what a sign-off is for.
• A link to the actual file. The approval points at the exact audio that will ship, not "the mix" in the abstract.

When you have those three, something quietly important happens: responsibility for the master moves from you to the client. Before the sign-off, a problem is your problem. After it, the version they accepted is the version of record. That line is the whole reason approval is worth doing properly, and it's exactly what a "thumbs up" emoji can't give you.

A sign-off isn't bureaucracy. It's the line between "the version we agreed on" and an open-ended revision loop.

Why loudness quietly corrupts approval

Here's the trap almost nobody accounts for. When a client compares two versions and one is even slightly louder, the louder one sounds better for the first few seconds, whether or not it actually is. It's a well-known perceptual bias, and it's the reason mix engineers gain-match plugins before deciding anything. Your client isn't doing that. So if you send "v2" and "a slightly hotter v3," you've quietly stacked the deck toward the hotter one, and they may sign off on the wrong master for a reason that has nothing to do with the music.

The fix is to compare versions at matched loudness, so the only difference the ear reacts to is the work itself. You can sanity-check any two files yourself with a loudness-matched A/B before you ever send them, and when the client reviews, they should be hearing the versions level-matched too. If you want the background on why level and loudness are different things, the streaming loudness guide covers it.

The workflow that ends the revision loop

Four steps. One link. No account for the client, which matters more than it sounds: every login you ask a client to create is a reason for them to stall.

1. Share a review link for one version

Send a single link pointed at the version you want signed off. The client plays the master losslessly in the browser, no download, no MP3 standing in for the real thing. Approving a lossy preview means approving something they won't actually receive, so the review has to be the real audio. (The mechanics of sending the master itself are covered in how to send a master to a client.)

2. Take feedback pinned to the waveform

Vague feedback is what makes revisions expensive. "Bring the vocal up in the second chorus" costs a round-trip just to find the spot. When the client pins a comment to an exact timecode, your revision list becomes a set of points instead of a paragraph to decode. Precise notes are faster to act on and far less likely to spawn a follow-up "no, the other chorus."

3. Capture an explicit sign-off on that version

This is the step everyone skips, and it's the one that matters. Don't settle for "looks good." Ask for an approval of the specific version, and capture it: which master, the client's name and email, and the time. Now the round is closed, on the record, against a named file. If nothing else in this guide sticks, make this the habit.

4. Set revision scope up front

Approval loops usually aren't a tooling problem, they're an expectations problem. Decide the number of revision rounds before you start, and say it plainly: most mastering work includes one or two rounds, with further passes billed separately. The exact number matters less than naming it, because it turns a fourth revision from an argument into a simple paid change. Tie each round to a version the client signs off, and "which pass was final" answers itself.

Handling revisions so the sign-off sticks

Revisions are where an email thread frays completely: three attachments called master_final, master_final2, master_FINAL_v3, and no memory of which note applied to which. Instead, upload each new version against the same track, so the client can A/B the versions at the same timecode and hear exactly what changed, loudness-matched so a level bump doesn't masquerade as an improvement. Open feedback should carry forward to the new version, so a note from round one isn't lost in round two. They approve the version that's genuinely final, and you deliver that one.

What a good approval record contains

If a dispute ever surfaces, this is what you want to be able to show, and it's worth keeping even when everything goes smoothly:

• The version. Not "the master," but the specific version number that was accepted.
• Who and when. Name, email, timestamp. The identity of the person who signed off.
• The exact file. Ideally the deliverable is the same file that was approved, so what shipped provably matches what was accepted.

None of this is about distrusting the client. It's about removing the one ambiguity that turns a finished job into a stalled one: which version, approved by whom. Answer that in a record, and the loop has nowhere to form.

The short version

Stop treating "sounds good" as a sign-off. Share a review link for one version, take feedback on the waveform, and capture an explicit approval of that specific master with a name and a time. Compare versions at matched loudness so nobody approves the louder one by accident, agree the revision count up front, and deliver the exact version that was signed off. That's the difference between a clean handoff and a revision loop with no exit.

Frequently asked questions

What counts as client approval of a master?

Real approval is a record, not a reply. "Sounds great" in an email isn't a sign-off, because it doesn't say which version and it can't be pointed to later. Approval means a specific version is marked as accepted, with the client's name, the timestamp, and the exact file it applies to. That record turns "I never approved that" into a non-issue and marks the moment responsibility for the master transfers to the client.

How do I get a client to sign off on a master?

Send one review link tied to a specific version, let the client hear it losslessly and leave feedback pinned to the waveform, then ask for an explicit approval of that version rather than a casual "ok". When the approval is captured (version, name, email, time), the round is closed. Agreeing the number of revision rounds up front keeps the process from drifting into an open-ended loop.

How many revisions should a mastering job include?

Most mastering engineers include one or two revision rounds in the price and bill further rounds separately. The exact number matters less than stating it up front, so a third or fourth pass is a paid change rather than an argument. Tie each round to a version the client approves, so it's clear which pass was the final one.

Why do clients keep approving the louder version?

A louder version sounds better for the first few seconds, even when it isn't, so a client comparing two masters at different levels tends to pick the louder one for the wrong reason. Comparing them at matched loudness removes that bias, so the approval is about the master and not the volume. You can check this yourself with a loudness-matched A/B before you send the versions over.

How do I prove which version a client approved?

Keep an approval record that captures the version, who approved it (name and email), and the timestamp, alongside the exact file it applies to. When the deliverable is the version that was signed off, a later "that's not what we agreed" has a clear answer, and the sign-off marks where responsibility moved to the client.