The SOW is where the disagreement is stored
A master services agreement decides what happens if somebody sues. The statement of work decides everything else: what gets built, when it counts as finished, who has to do what for it to be possible, and what a change costs. Legal review reads the first document carefully and skims the second, because the second is described as "the technical exhibit" and appears to contain no legal content. That is exactly backwards. Almost every commercial software dispute we have seen described to us traces to a sentence in the SOW that both sides read, both sides understood differently, and neither side thought was worth discussing. The clause is never dramatic. It is usually eleven words long and reads like something a lawyer would leave alone.
What follows is a list of the specific sentences worth stopping on, what each one costs when it goes wrong, and what to replace it with. This is written from the vendor's side of the table. A firm that wanted to preserve its own optionality would not publish it, which is the reason it is worth reading.
You are probably here because
- A vendor sent a SOW and your legal team says it is fine, which is not the same as good
- The last project was declared complete by the vendor and was not usable by you
- Every schedule slip was blamed on something your side owed them, and they were right
- You are about to sign for a model that has to hit an accuracy number and nobody has defined the test
Each red flag below is paired with the sentence to put in its place. None of the replacements are hostile to a good vendor. A vendor who resists all of them is telling you something useful for free.
Red flag 1: deliverables that are nouns
"Vendor shall deliver a customer analytics dashboard." That is a category, not a deliverable. Two competent people can build wildly different things from it and both can defend the result. When the delivered thing is not what you pictured, there is no clause to point at, because you agreed to a dashboard and a dashboard is what arrived.
A deliverable needs three parts: the artifact, the behavior, and the condition under which the behavior is verified. "A dashboard presenting the metrics in Appendix B, refreshed nightly by 06:00 Central, reconciling to the finance close for the three months of test data supplied at kickoff, rendering in under four seconds against the reference dataset." That is longer and it is the entire difference between a project that ends and one that dwindles.
The test to apply to every deliverable line: could a competent stranger, with no access to either party, determine whether this was delivered? If the answer requires a conversation, it will require a conversation, and that conversation happens when the invoice is due.
Red flag 2: acceptance by satisfaction
"Deliverables shall be accepted upon Client's reasonable satisfaction." This sentence sounds protective of the buyer and is a problem for both parties. For you, it invites a vendor to argue that satisfaction is being withheld unreasonably, and "reasonable" is decided by whoever can afford the argument. For them, it means no deliverable can ever be conclusively finished, which is why vendors quietly price defensively against it.
Replace it with an acceptance procedure that has four elements: a written test the buyer performs, a review window with a number in it, a rule for what silence means, and a defined remedy cycle. "Client shall test against the criteria in Section 4 within ten business days. Deliverables not rejected in writing with specific reference to a criterion within that window are accepted. Vendor shall remedy identified failures within ten business days, and the review window restarts for the affected criteria only."
The deemed-acceptance clause is the one buyers instinctively resist and should not. Without it, an internally busy quarter silently becomes an unresolved contract, and it is your own organization that pays for that in leverage later.
Red flag 3: dependencies with no owner and no date
"Client will provide timely access to relevant systems, data and personnel." Every schedule in this industry rests on the buyer supplying things, and this sentence commits you to all of them with no boundary and commits the vendor to nothing about what happens when it slips.
The most expensive version is data access. In a mid-size company, granting a third party access to a production database involves a security review, a data-sharing agreement, a vendor questionnaire, and at least one person who is on leave. Six to eight weeks is ordinary. Proposals routinely assume five business days. When reality asserts itself the team is idle and billing, or is disbanded and reassembled at a cost, and the SOW says the delay was yours.
Write a dependency table into the SOW: each item, the named owner on your side, the date it is due, and what happens if it is late. That last column is the one that changes behavior. "If a dependency is more than ten business days late, Vendor may reallocate the team and the schedule extends by the delay plus one week for re-engagement; standby is billed at 25% of the committed rate for a maximum of two weeks" is a real allocation of a real risk. It is also fairer than the alternative, which is that the vendor prices the risk invisibly and you pay for it whether or not it occurs.
Red flag 4: "best efforts" attached to a fixed price
"Vendor will use commercially reasonable efforts to deliver the functionality described herein." Paired with a fixed fee and a fixed date, this clause means the price is fixed and the outcome is not. You have bought a budget, not a result.
There are legitimate uses for effort-based language: research, discovery, anything genuinely exploratory. In those cases the price should be time and materials, and the deliverable should be knowledge rather than software. What is not legitimate is effort language over a fixed price for a defined build. Pick one. Either the scope is firm enough to commit to, in which case commit, or it is not, in which case bill for time and stage the work so both sides can stop.
Red flag 5: an accuracy number with no measurement protocol
"The model shall achieve 95% accuracy." This is the single most common defective clause in AI and machine learning work, and it is defective in both directions. It gives the buyer no enforceable right and exposes the vendor to an unbounded obligation, so it produces conflict regardless of who is acting in good faith.
Six things have to be specified before an accuracy number means anything.
Which dataset. A held-out set, described by how it was drawn: how many records, from which population, over what time range. Accuracy on a curated sample and accuracy on last quarter's real traffic are different numbers, sometimes by a wide margin.
Who labels it, and when. Labeled by your subject-matter experts, before work begins, and sealed. A test set assembled after development can be assembled to pass, without anyone intending fraud.
Which metric. "Accuracy" is ambiguous on imbalanced data, and most real problems are imbalanced. If two percent of transactions are fraudulent, a model that flags nothing is 98% accurate. Name precision, recall, F1, or the specific rate you care about, and name the operating threshold.
The error you actually fear. Missing a real case and raising a false alarm are rarely equally costly. Say which one the system must minimize and at what expense to the other.
How many attempts. Evaluating repeatedly against the same held-out set degrades it into a training set. Two or three scored evaluations, stated in the document.
What happens if it is missed. A remedy period, a fee adjustment, a reduced scope, or an exit. A threshold with no consequence is a hope with a percentage sign.
Any vendor who resists this is telling you that they do not intend to be measured, or that they have not thought about how they would be. Any vendor who welcomes it has done this before.
| The clause | What it costs when it goes wrong | What to put in its place |
|---|---|---|
| "A dashboard / a platform / an integration" | A finished project neither side can declare finished | Artifact plus behavior plus a verification condition a stranger could check |
| "Client's reasonable satisfaction" | Acceptance disputes with no reference point; withheld invoices | Written test, numbered review window, deemed acceptance, defined remedy cycle |
| "Timely access to data and personnel" | Idle billed weeks blamed on your side, and correctly | Dependency table with owners, dates, and a stated consequence for lateness |
| "Commercially reasonable efforts" on a fixed fee | A fixed budget with an unfixed outcome | Either commit to the scope, or bill time and stage it with exit points |
| "95% accuracy" | An unenforceable promise and a real dispute | Sealed test set, named metric, threshold, attempt limit, stated remedy |
| Change control with no price | Every change becomes a negotiation you enter having already paid | Rate for changes, response time for estimates, written approval threshold |
| Silence on ownership | Paying to build something you licensed rather than own | Explicit assignment of code, models, weights, derived data and documentation |
Red flag 6: change control with a process but no price
"Changes to scope shall be documented in a mutually agreed change order." Every SOW says this and it says almost nothing. It establishes that changes require agreement, which was already true, and leaves out the three facts that matter: what a change costs, how fast you get an estimate, and what threshold requires approval versus what the team can absorb.
Ask for a stated change rate. If it is materially above the base rate, that is information about where the vendor expects its margin to come from, and it is worth raising before signing rather than after. Ask for a response commitment, usually three to five business days for a written estimate, so a change request cannot be used to stall. And set a de minimis threshold below which small adjustments are simply handled, because a project where every four-hour change needs paperwork produces either paperwork or resentment.
Which SOW gaps cause the most disputes — our ranking
Our ranking of how often each gap turns into a real dispute, based on the engagements and rescues we are asked about. Judgment, not a survey — the ordering is the useful part.
Red flag 7: silence on who owns what
If the SOW does not say, the answer depends on the master agreement, the jurisdiction, and in the United States on whether the work qualifies as a work made for hire under a narrow statutory definition that custom software often does not satisfy. In practice, silence favors the vendor more often than buyers expect. This is worth thirty minutes and one clause.
Name each category separately, because they are separate and a single sentence about "deliverables" does not reach all of them: source code, trained model weights, prompts and configuration, data you supplied, data derived from your data, documentation, and infrastructure definitions. Say which are assigned to you outright, which are licensed to you and on what terms, and which the vendor retains.
It is entirely legitimate for a vendor to retain their pre-existing tools and general libraries; that is how firms stay efficient and you benefit from it. What matters is that the retained items are listed rather than described as a category, and that whatever they retain is licensed to you perpetually and irrevocably for the delivered system. A vendor retaining a component with no license grant has a switch they can throw.
On AI work, add one line most SOWs omit: whether your data may be used to train models the vendor uses elsewhere. The default should be no, and a vendor may reasonably ask for an exception for aggregated non-identifying performance statistics. That is a fine conversation to have. It is not a fine thing to leave unsaid.
Red flag 8: no exit, no transition, no handover
"Either party may terminate for convenience upon thirty days' written notice." Perfectly standard, and by itself it means that on day thirty-one you have code you cannot deploy, credentials you do not hold, and nobody who knows why anything was built that way.
Add a transition obligation with substance: source code and infrastructure definitions in your repositories throughout the engagement rather than at the end, documentation sufficient for a competent engineer to operate the system, a written handover session, credentials and account ownership transferred, and a defined number of hours of post-termination support available at the agreed rate. Thirty to eighty hours is a common and reasonable band depending on system size.
The most important word there is throughout. Code that lives in the vendor's repository until final payment is a hostage arrangement, however friendly the relationship. Insist that everything lands in accounts you own from week one. Good vendors do this by default and will not blink at the request.
Own the accounts from day one, not at the end
Cloud accounts, repositories, domain registrations, CI systems and third-party service subscriptions should be in your organization's name with the vendor granted access, not the reverse. It costs nothing at the start and is the single most reliable protection against a bad ending. It also removes an awkward conversation from the end of a good relationship, which is when most of these arrangements are discovered.
Red flag 9: a schedule that only contains the vendor's work
A Gantt chart with twelve weeks of vendor activity and no buyer obligations is not a schedule, it is a marketing artifact. Real projects consume your subject-matter experts, your decisions, your test participants and your environments. If those are not on the timeline with named owners, then every delay caused by your own organization arrives as a surprise and as a change order.
Put your own obligations on the same chart. It is uncomfortable, which is the point: it makes visible the fact that you are committing capacity you may not have, and it is much cheaper to discover that in week zero.
Red flag 10: key people who can be swapped silently
You met three impressive people and the SOW names none of them. If the individuals matter, name them, state the percentage of their time committed, and add a substitution clause: replacements must be of equivalent seniority and require your written consent, not to be unreasonably withheld. This is normal, it is cheap, and it is almost never offered without being asked for.
If the vendor cannot commit named people, that is a real answer and sometimes an honest one for a larger firm. Price it accordingly, and stop treating the people in the sales meeting as evidence about the delivery team.
Red flag 11: everything happens at the end
A SOW where the first deliverable lands in month four is a SOW where you learn nothing about this vendor until you are four months and a substantial payment into the relationship. Restructure it. Something real should be deliverable and testable inside six weeks, with a payment milestone attached and a clean stopping point after it.
This is not distrust; it is how both sides discover whether the arrangement works while the cost of being wrong is still small. Vendors who work this way tend to propose it themselves. A vendor who insists on a long first phase with no intermediate deliverable is asking for something you should not give.
Things buyers forget to ask for
- A named test set, sealed before work begins, on anything with a performance target
- Deemed acceptance after a stated review window, which protects both sides
- Standby and re-engagement terms for when your own dependency is late
- A stated change-order rate and a response commitment, not just a process
- Explicit assignment of model weights and derived data, which "deliverables" does not always cover
- A prohibition on training external models with your data, unless you have agreed otherwise
- Post-termination support hours at the agreed rate, not at whatever is quoted later
- Repository and cloud account ownership from week one, not on final payment
A five-day SOW review
SOW Review
Send the redline as a single package rather than as a trickle. It reads as diligence rather than as difficulty, and it lets the vendor price the whole set at once. Watch which items they accept immediately, which they negotiate, and which they refuse. The refusals are the most informative thing you will learn before work starts.
Before you sign
- Every deliverable names an artifact, a behavior and a verification condition
- Acceptance is a written test with a review window and deemed acceptance
- Your dependencies are a table with owners, dates and stated consequences
- Any performance target carries a sealed test set, a metric and a remedy
- Change control states a rate, a response time and an approval threshold
- Code, models, weights, derived data and documentation are assigned explicitly
- Retained vendor components are listed and perpetually licensed to you
- Repositories, cloud accounts and credentials are yours from week one
- Key people are named with committed time and a substitution clause
- Transition support is defined in hours at the agreed rate
- Something real and testable is delivered inside six weeks
Bottom line
A statement of work is not a technical exhibit. It is the operative document of the relationship, and the sentences that decide the outcome are short, unremarkable, and easy to approve. Undefined deliverables mean no project ever ends. Satisfaction-based acceptance means nothing is ever finished. Unowned dependencies mean every delay is yours. A performance number without a protocol is unenforceable. Silence on ownership tends not to favor you, and no exit clause means a bad ending costs more than the work did.
None of the fixes are adversarial. Every one of them is something a firm that intends to deliver will sign in an afternoon, which is precisely why sending them is worth doing before the work starts rather than after.
Frequently asked questions
Usually not, because the clauses that decide software outcomes are technical rather than legal. Legal review reliably catches liability, indemnity and payment terms, and reliably passes over "the model shall achieve 95% accuracy" because it looks like a specification. Have someone technical read the SOW specifically for whether each deliverable is verifiable and each dependency is owned.
Acceptance defined by satisfaction rather than by a test. It removes the finish line, so the last stretch of the project expands indefinitely, invoices go unpaid, and the relationship degrades before anyone identifies the cause. The fix is a written test, a numbered review window, deemed acceptance if nobody responds, and a defined remedy cycle.
As a protocol rather than a number. Name the held-out dataset and how it was drawn, who labels it and that it is sealed before work starts, the specific metric and threshold, which error type matters more, how many scored evaluations are allowed, and what happens if the threshold is missed. Without those, the number cannot be enforced and can be satisfied by choosing a friendly test set after the fact.
It is reasonable for everything built for you, and unreasonable for a vendor's pre-existing tools and libraries. The workable arrangement is assignment of the custom work — code, models, prompts, documentation, derived data — plus a perpetual, irrevocable license to any retained components used in the delivered system, with those components listed by name rather than described as a category.
Code and infrastructure definitions in repositories you own throughout the engagement, documentation sufficient for a competent engineer who was not involved, a live handover session, transfer of all credentials and account ownership, and a defined number of post-termination support hours at the agreed rate. Thirty to eighty hours is a common range. The key detail is that everything lives in your accounts from week one rather than arriving at the end.