The Difference Between a Revision and a New Requirement

Revisions are part of the job. New requirements are a scope change. The contractor who cannot tell the difference will always lose money on fixed-price projects.

The Blurred Line That Costs Money

Every contractor who has worked on a fixed-price project has experienced the moment: the client reviews the delivered work and says "one more thing." Sometimes "one more thing" is a correction — the output does not match what was agreed. Sometimes it is an addition — the output is correct, but now they want something else too.

Both arrive in the same form: feedback. The difference in economic terms is significant.

A revision is work that brings the deliverable into alignment with the original, agreed scope. A new requirement is work that expands that scope. The first is included in the contract. The second is not.

When contractors cannot reliably distinguish between the two — or choose not to push back on the distinction — they do increasing amounts of uncompensated work.

The Test That Separates Them

One reliable way to identify which situation you are in: does the original scope document describe what is being requested?

If the scope said "build a user authentication system with email and password login" and the client says "the password reset email is showing the wrong template" — that is a revision. You agreed to deliver a working password reset flow. It does not work as expected. Fix it.

If the scope said the same thing and the client says "can you also add Google SSO?" — that is a new requirement. Single sign-on was not part of the agreed scope. It is additional work.

The scope document is the reference point. Without one, every conversation about what is included and what is not becomes a memory contest.

Why Clients Do Not Always Know the Difference

Most clients are not trying to exploit contractors when they make this mistake. They genuinely do not always know where the original requirement ended and the new one begins. They remember a conversation in which something was discussed, and they assume that conversation became part of the scope.

Or they have refined their understanding of what they actually need as the project has progressed — which is natural, but has a cost.

This is not bad faith. It is the predictable consequence of building things before requirements are fully clear.

The contractor's job is to hold the line professionally — not with hostility, but with clarity. "That's outside what we defined in the original scope — let me put together a quick change order for it."

The Language That Maintains the Relationship

Managing this distinction does not have to create conflict. The framing matters:

• "That's a great addition — I'll scope it as a change and get you an estimate."
• "That's a bit different from what we originally agreed. If we add it now, it'll affect the timeline by about X days and add Y to the fee."
• "Happy to include that — let me confirm it's outside our original scope first, and then I'll follow up with what it'll take."

Each of these acknowledges the client's request, avoids making them feel accused of bad behavior, and protects the contractor's economics by treating the distinction as a process rather than a confrontation.

The Structural Safeguard

Clear scope documents with explicit out-of-scope lists are the best protection against this confusion recurring. The more specific the original scope, the easier it is to answer "is this a revision or a new requirement?" clearly and without ambiguity.

If you are starting a project and the scope document feels incomplete, that is the moment to add specificity — not when the first revision request arrives.

A well-written scope document is not a legal weapon. It is a shared understanding that both parties return to when the conversation gets complicated.

Revisions are expected. New requirements are legitimate. Treating both as the same thing is where projects stop being profitable.