Your PM sent the change order. The client said "looks good." Work started Monday.
Three months later, the client disputes the invoice. Their legal team says the change order was never formally executed. Your PM's "looks good" email doesn't count. The extra $47,000 in work is now a negotiation, not a receivable.
This happens more than anyone admits. Change orders get generated, sent, verbally approved, and acted on — then challenged at billing time when the relationship has soured. The reason they're challengeable is almost always the same: the change order itself wasn't constructed to be enforceable.
What Actually Makes a Change Order Enforceable
A change order is a contract amendment to your Statement of Work (SOW). For it to hold up, it needs the same elements as the original contract: offer, acceptance, and consideration. Most organizations have the offer (here's the work and the price). Most fall apart on acceptance and consideration.
Acceptance means a person with actual authority to bind the client has agreed in writing. "Looks good" in a Slack message from your day-to-day contact is not acceptance — unless your SOW explicitly says it is. If your SOW says changes require written approval from a named contract authority, that's the only signature that counts.
Consideration means something of value is exchanged. In a change order, that's usually obvious — additional work for additional pay. But if your change order says "we'll absorb this additional work as a courtesy," you've just volunteered labor with no consideration, and that language sets a precedent for the next three requests.
The Four Clauses That Kill Enforceability
There are four failure patterns that show up repeatedly in IT consulting change orders.
No expiration date
A change order with no expiration can be "accepted" at any time — including after the work is already done and the client is unhappy with the outcome. Add an explicit acceptance window. Something like: This change order must be executed by [date] or it is void. Without it, you've created an open offer with no closing mechanism.
Scope described in functional terms only
"Update the reporting module" is not a scope description. It's an invitation to dispute. Enforceable change orders describe deliverables, not intent — what gets delivered, in what format, verified how. If the client can point to any reasonable interpretation of your scope language and argue their request is covered, your change order will not hold.
Missing the SOW reference
Every change order should explicitly reference the original SOW by name and date, and state which section or clause it amends. Without that anchor, it reads as an independent document with no connection to the governing contract. That gap is easy to exploit in a dispute.
Wrong signatory
The person who signs needs authority to bind the organization. This is especially dangerous in enterprise engagements where your PM contact is two levels below procurement. If your SOW specifies a contract authority for amendments, that is the only signature that counts. Your PM's "approved" email is goodwill, not a contract.
What Your SOW Should Say About Change Orders
The cleanest approach specifies all of this in the original SOW before anyone signs it. The change control clause should cover:
- → Who can authorize changes (title, not just name — people change roles)
- → What form authorization must take (written, via email from named authority, via formal CO document)
- → What information a valid change order must contain (scope, price, timeline impact, SOW reference)
- → What happens to work performed before a change order is executed
- → Response window: how long the client has before the request lapses
Most SOWs don't specify any of this. They say something like "changes must be agreed in writing" and leave every other question unanswered. That language will protect you in the obvious cases. Nothing else.
The Practical Test
Before you start any out-of-scope work, ask: if this relationship ends badly tomorrow, could I take this change order to a judge and win?
That means signed by the right person, scope described precisely, dollar amount clear, SOW referenced, expiration date present. If the answer is no, you're doing speculative work. Sometimes that's a business decision worth making. But it should be a deliberate choice, not an oversight.
SOWaudit flags change control clause weaknesses before you sign — vague authorization language, missing scope definitions, and signature authority gaps all surface in the audit.
Run a Free Audit on Your Own SOW →