The invoice went out on Friday, the same day the team closed the last item in Phase 2’s scope. Per the contract: the reporting module delivered, acceptance tests passed, status green.
On Tuesday, one sentence came back from the client: “this isn’t what was supposed to be built, we can’t use it.”
Both sides were right. That’s the part that’s hardest to explain to anyone who wasn’t in the room.
Two different kinds of “done,” and neither one is fake
It’s worth separating this from what usually gets discussed under Definition of Done. That argument happens inside a team, between a developer and a PM, about whether a card on the board really meets the criteria written on it. It’s a dispute over a shared vocabulary.
This is something else. The delivery team’s “done” is defined by a document: the scope in the contract, the functional spec, the acceptance criteria signed off at the start of the phase. The client’s “done” is defined by something no document ever covers — a picture of how their business will run once all of this actually works. That picture formed months earlier, during the sales conversation, in a sentence like “and then our accounting team won’t have to retype all of this by hand anymore.” Nobody wrote that sentence into the spec, because it sounded like an obvious given, not a requirement. This is the same gap that makes scope and product value pull in different directions if nobody names it early.
So when the reporting module lands exactly as specified, and accounting still has to retype something by hand because the export comes out in a format nobody pinned down, the vendor is right about the letter of the contract. The client is right about the entire reason they ordered it in the first place.
This dispute only ever explodes at the contract boundary, never before
Inside a project, among people who talk to each other every day, a mismatch in definitions surfaces early and cheaply, because someone asks about it at standup or during a sprint review. At the contract boundary, between two organizations, something different happens: for weeks or months, both sides communicate through documents, status reports, and emails rather than direct working conversation. The gap doesn’t surface, because nobody has a natural moment to check for it — until the moment something is actually supposed to happen: sign-off, payment, go-live.
That’s why this problem always detonates in the same place: at the end of a phase, at the invoice, at the signature on the acceptance protocol. Not because nobody noticed the difference earlier. Because until that moment, nobody had to name it — both sides could go on living with their own, separate version of what was being built.
Who on the client’s side even gets to say “done”
There’s a second thing that sets this apart from the internal team version of the dispute: on the client’s side, “done” is almost never one person’s opinion. The sponsor who signs the acceptance protocol may be satisfied, because they see the contracted scope delivered. The team that actually has to use the thing day to day may be furious, because nobody asked them whether it works the way they need it to.
Picture a service-ticket system rollout. The client’s sponsor accepts the project because the system does exactly what the spec said: intakes tickets, assigns them to technicians, generates a monthly report. A month later it turns out the field technicians are still calling the dispatcher directly, because the mobile app is too slow on weak signal — a condition nobody tested for, because the spec said “mobile access,” not “mobile access on weak signal in the field.” The protocol is signed, the invoice is paid, and the project is still considered a failure inside the client’s company, because the people who were supposed to benefit from it are loudly saying nothing has changed.
To the vendor, this looks unfair — they formally did what they were asked to do. To the client, this looks like confirmation that the vendor delivered a document, not a solution.
What I do to have this conversation earlier, not at invoice time
There’s one thing I now build into every major phase before work even starts: I ask the client for one sentence, written in future tense, describing the day after go-live from the point of view of the person who will actually use the thing — not from the sponsor’s point of view. Not “ticket system deployed,” but “a field technician reports an issue from their phone and sees confirmation within a minute, even on weak signal.”
That sentence almost always surfaces something no document had, because it forces the sponsor to go talk to someone who’ll actually use it, before that conversation happens anyway, in a much worse moment.
The second thing: at phase acceptance, instead of asking “does this meet the spec,” I ask “who specifically on your side should test this before we sign the protocol, and has that person already seen it.” If the answer is that they haven’t, that’s exactly the moment to push the signature out by a week, instead of pushing the whole relationship out by a quarter once the problem surfaces on its own.
One honest note before you go
This doesn’t close the gap between sales and delivery down to zero. Some of what a client imagined during the sales conversation genuinely can’t be predicted until the product is actually running in their day-to-day reality.
What it does is lower the cost of the moment the gap surfaces. A conversation about what’s missing, held a week before the protocol is signed, is cheaper than the same conversation held a month after the invoice, when one side feels cheated and the other feels unfairly judged.
Try it at your next phase acceptance. Before anyone signs the protocol, ask who’s actually going to use this — and whether that person has already seen it with their own eyes.
All situations described in this article are based on real events, but contain no company names, no individual names, and no data from any specific project.
