I work in a software development team where a single task typically goes through several people and stages:
- Product documentation
- Refinement / analysis meetings
- Development
- First code review
- Second code review
- QA / delivery
- Build and deployment
So a single task can involve 4–6 people and significant engineering hours.
The problem is that our client has recently stated that they will only pay once for a task that is successfully completed and accepted. They will not pay for bug-fixing/rework, especially for newly developed features.
For example, if a task takes 15 hours across several people, but after delivery a bug is discovered and another 5 hours are spent fixing it, those additional 5 hours are considered non-billable. In some cases, the original effort effectively becomes a financial loss for our company.
The bigger problem is that some tasks go through multiple reviews and still come back with bugs. We currently have a significant number of these tasks, so the accumulated non-billable effort can become substantial.
I'm trying to understand how other software companies handle this situation.
Some questions I'm particularly interested in:
How do you distinguish between a genuine bug and a change in requirements/acceptance criteria?
Who should financially absorb the cost of rework?
Do you include an expected defect/rework rate in project pricing?
How do you measure the financial impact of defective tasks?
What processes have actually reduced rework — better QA, acceptance criteria, code review, technical analysis, automated testing, or something else?
How do you handle this contractually with clients who refuse to pay for bug fixes?
Is it reasonable for a client to pay only for the final accepted task regardless of how much internal work was required, or should the contract explicitly define a warranty/bug-fix period?
I'd especially like to hear from people who have managed software teams or client projects under a fixed-price or per-task billing model.
What would you change in this process?
Top comments (2)
If the acceptance criteria changed after they signed off, those extra hours belong on a second invoice / change-order — not on the original "completed tasks" bill. Keep a one-line warranty vs change split on the invoice itself, and put a calendar due date instead of "Net 30."
Happy to sketch the two-line invoice if you want.
The question that actually decides this is your first one — bug vs. changed acceptance criteria — and it's a documentation problem long before it's a contract problem. If acceptance criteria are written in a refinement meeting and live in someone's memory, every dispute defaults to the client's interpretation, and you eat the rework. Written, client-signed AC per task, before development starts, is the single change that shifts the most hours back to billable.
Two things that have worked for teams I've seen in this spot:
A defined warranty window instead of open-ended free fixes. "Defects against the agreed AC are fixed free for 30 days after acceptance; anything outside the AC or after the window is a new task." That's a normal, defensible term — you're not refusing to stand behind your work, you're bounding it. Open-ended rework isn't a warranty, it's an uncapped liability.
Track rework hours as their own category from day one, even while they're unbillable. You can't renegotiate on "it feels like a lot" — you can renegotiate on "18% of delivered hours last quarter were rework, and 60% of those traced to AC changes, not defects." That number is also what tells you whether to price in a defect rate or fix the process upstream.
On who absorbs it: under per-task fixed pricing, the vendor does by definition — that's the risk premium fixed pricing is supposed to buy. If the client wants zero rework exposure, the per-task price has to carry the expected defect rate. Right now you're pricing as if it's T&M and being paid as if it's fixed-price, which is the actual mismatch.
Worth noting your pipeline has two review stages and QA and bugs still land. That usually means reviews are checking code quality, not acceptance criteria. Adding an explicit "does this satisfy the written AC" gate before delivery tends to catch more than a third reviewer would.