The project finished in March. The final invoice went out in April. In May you are on a call explaining why the third round of changes to the dashboard was billable, and the client is explaining that they always assumed dashboards came with revisions. Both of you are sincere. Neither of you can point at a document that settles it.
That argument is almost never about money. It is about a scope written loosely enough that two reasonable people read it two different ways. Project scope creep is usually blamed on demanding clients. In practice it is a documentation problem that shows up as a billing problem four months later.
Scope creep is a billing failure, not a client failure
Work expands. That is normal and often good. A client who asks for more usually values what you are doing. The failure is not the request, it is that the request never became a priced line and never became a signed thing.
There are three moments where this goes wrong.
The first is at proposal stage, where scope is written as activities rather than deliverables. “Website development” is an activity. “Eight page responsive website, two rounds of design revision, content supplied by client” is a deliverable. Activities cannot be finished. Deliverables can.
The second is mid-project, when a request arrives by WhatsApp and gets done because it is small. Small is the point. Nobody raises a change request for two hours of work. Fourteen requests of two hours each is a week you did not price.
The third is at the end, when the invoice is assembled from what the team remembers doing rather than from what was agreed. If your final invoice line is “balance payment as per discussion”, you have already lost the argument.
Fix the first moment and the other two get much easier.
Write scope as a deliverable list with a bottom edge
A scope section has two halves and most firms only write one. The inclusions are easy. The exclusions are what actually prevent the fight.
For each deliverable, write four things:
- What it is, in the client’s words, not yours. “Attendance module” not “Sprint 3 backend work”.
- The unit and the count. Eight pages. Three user roles. Two training sessions of ninety minutes each.
- What the client owes you before it can start. Logo files, GST details, approved copy, access to the server, a named person who can sign off.
- What done looks like. One sentence, testable by someone who was not in the room.
Then write the exclusions. Five to ten lines, plainly stated. Data migration from the old system is not included. Hosting and domain charges are billed at actuals. Content writing is not included. Post-launch support beyond thirty days is a separate engagement. Printing costs are not included.
Exclusions feel adversarial when you write them and feel like a favour when you read them out later. Clients rarely object to a clear exclusion at proposal stage. They object to discovering one at invoice stage.
A useful test: hand the scope to someone in your team who was not on the sales call and ask them what they would build. If they build something different from what you sold, the scope is not tight enough yet.
Milestone-linked billing, so the invoice writes itself
Once scope is a list of deliverables, billing stops being a negotiation. Each milestone carries a percentage of the contract value and an invoice trigger. When the milestone is approved, the invoice goes out. Not when the project ends. Not when someone remembers.
A workable structure for a six month engagement:
- Advance on signing, invoiced the same day the purchase order lands.
- Milestone one, on approval of design or discovery output.
- Milestone two, on approval of the first functional delivery.
- Milestone three, on user acceptance.
- Retention, released thirty days after go live.
The percentages matter less than the trigger. The trigger must be an event with a date and an approver, not a calendar month. “Invoiced on 30 April” invites the question of what was delivered in April. “Invoiced on approval of milestone two, approved 22 April by the client’s operations head” does not.
This only works if milestones are actually reviewed rather than allowed to lapse in silence, which is a separate discipline worth getting right. Putting a written gate and a named approver on every deliverable is what turns a milestone from a date in a plan into a billing event.
On BizvoraOne, the Projects module carries milestones with review gates, and the Accounting and Recovery module carries the vouchers. The point of having both in one workspace is that the approved milestone and the sales voucher refer to the same object, so nobody has to reconcile a project plan against a ledger by hand at quarter end.
One caution. Milestone-linked billing pushes your cash further out than monthly billing does, especially against Indian ninety day payment cycles. If a milestone slips by three weeks for reasons on the client’s side, your invoice slips with it. That is why the dependency clause below exists.
The change request that takes ninety seconds
Most change control processes fail because they are too heavy. A two page form with a signature block will not be used for a request that arrives at 6pm on WhatsApp. So the request gets done unbilled, and project scope creep continues quietly.
Make the raise cheap. Four fields is enough:
- What is being asked for, one or two lines.
- What it affects: effort in hours or days, cost, and the delivery date.
- Who asked, and on which date.
- Decision: approved, rejected, or parked, with a date.
That is a ninety second job for a project manager who has a rate card to hand. Copy the four lines into an email or a message, get a one word reply, log the reply. The client’s “go ahead” in writing is the approval. You are not asking for a stamped document, you are asking for a record.
Three rules make it hold.
Zero-cost changes still get logged. A change that costs nothing today is evidence tomorrow. It also builds the habit. If the log only contains billable items, the team treats raising one as an act of aggression.
Nothing starts before the decision. The moment work begins on an unapproved change, the change request becomes paperwork instead of a gate. Five minutes of waiting is cheaper than five weeks of arguing.
Every approved change updates the quote. A change that lives only in the change log and never reaches the commercial document will not reach the invoice either. If you are reissuing numbers, do it properly with whole-number versions and a change note on each one, so the client can see exactly which version the final invoice is built from.
By the end of a project, the change log is your invoice annexure. You are not reconstructing history from memory. You are printing a list you have been keeping all along.
The three clauses that prevent the argument
Most project contracts in Indian SMBs are three pages of scope and one page of payment terms. Three clauses are missing more often than any others, and each one costs money by its absence.
The exclusions clause
Covered above, but it belongs in the contract and not only in the proposal. Plain list, no legal register. If it is not listed in scope, it is not included, and the following items are specifically not included. Keep it under ten lines so people read it.
The revision limit clause
State the number of rounds included per deliverable. Two rounds of design revision. One round of report revision. Then state what happens to round three: billed at the standard rate, quoted before work starts. Also define what counts as a round. A round is one consolidated set of feedback from the client, delivered in one go. Six separate messages over four days is not one round, and saying so upfront saves a conversation later.
The client dependency clause
This is the one nearly everybody omits. It says: where the project is waiting on inputs, approvals or access from the client for more than a stated period, say ten working days, the delivery timeline shifts by the same duration and the current milestone may be invoiced as if approved.
Without that clause, a client who goes quiet in July delays your invoice to September at no cost to themselves. With it, you have a stated, agreed and unemotional way to say that the clock is running.
Where this is overkill
Not every job needs this. A two day piece of work for a repeat client does not need a milestone schedule and a change log. Retainers and time and materials engagements bill on time recorded, so the scope question is different and usually smaller.
The structure earns its keep on fixed price work above a few weeks in duration, on anything with more than one stakeholder on the client side, and on any client where the last engagement ended in an argument about the final bill.
What to do first
Open the last project where the final invoice was disputed or discounted. Read the scope section as written. Find the sentence the client relied on and the sentence you relied on, and see how far apart they actually are.
Then do one thing before your next proposal goes out: write ten lines of exclusions and a revision limit. That is an afternoon of work, not a quarter. Milestone triggers and a change log are worth adding next, but the exclusions clause on its own removes most of the arguments you are currently having.
