How to Spot a Software Vendor Without Surprise Invoices
Summary: A software vendor that will not send surprise invoices has a written change-control procedure: any work outside the agreed scope needs a change request, a written quote with schedule impact, and your approval before anyone starts. This article covers the four steps, the contract clauses that make them enforceable, and the red flags to look for in a quote.
Contents
- Where do extra costs in a software project come from?
- What steps does a written change-control procedure include?
- What should the contract say to make the procedure binding?
- Which red flags in a quote signal extra charges ahead?
- How does VAON handle scope changes?
- What does this procedure not solve?
- FAQ
1. Where do extra costs in a software project come from?
Extra costs in a software project usually come from one place: the line between "in scope" and "a change" was never written down. When that line exists only in each side's head, the final invoice is where two readings collide.
There are three familiar sources. First, you genuinely change your mind: a new feature, a different process after the requirements were agreed. Second, the requirement was always there but described vaguely, and the vendor treats the unclear part as "out of scope". Third, something is asked for in a chat or a meeting, gets built on the spot, and later shows up as its own line on an invoice.
The first is normal in any project. The other two are paperwork problems. The second starts before the contract is signed, with the quality of the specification, as described in why offshore development really fails.
2. What steps does a written change-control procedure include?
A change-control procedure (変更管理) has four steps, and every one leaves a paper trail.
- Raise a change request. Any work outside the agreed scope is recorded on a change request form (変更依頼書), raised by you or by the vendor.
- Get a written quote and schedule impact. The vendor states the cost and whether the delivery date moves, including effects on other items.
- Approve in writing. Someone with authority on your side confirms before anyone starts work.
- Do the work. Only after step 3.
Step 3 produces a short rule: no approval, no work; no work, no charge. You can decline a change after seeing the price, and the project continues with the original scope.
None of this is one vendor's invention. The model contract published by Japan's Ministry of Economy, Trade and Industry (METI) and IPA, 「情報システム・モデル取引・契約書」, contains a change-control clause (Article 37 in its first edition). Its commentary describes that procedure as the place where both sides discuss the rework that is truly needed and each side's fair share of the cost. The model is written for waterfall-style development of critical systems, so you would not copy it verbatim into every project, but it shows the practice is standardized.
3. What should the contract say to make the procedure binding?
The contract should spell out the items below, because a procedure agreed only verbally gets skipped when a deadline looms.
| Clause | What to include | Why |
|---|---|---|
| Scope definition | Reference a specific requirements document (version, date), not "all necessary functions" | Without a reference point you cannot tell a change from an original requirement |
| Who can raise and approve changes | Job titles on each side | Stops ad hoc agreement in chat by people without authority |
| Contents of a change request | Description, cost, schedule impact, impact on other items | You decide with full information |
| Quote deadline | Maximum working days for the vendor to respond | Avoids long waits followed by pressure to agree |
| If you decline | Original scope and price stay as they were | The right to refuse is real |
| Change vs. defect fix | Product defects do not go through change control; they follow the warranty clause | Stops bug fixes being billed as new requests |
| Urgent work | A fast approval route (for example, email from a named role) | The procedure does not get abandoned for being too slow |
The "change vs. defect fix" row deserves a close read if AI helps write the code. Responsibility for defects in AI-written code is its own topic; see who is responsible when AI-written code fails, and what to put in the contract.
4. Which red flags in a quote signal extra charges ahead?
A quote can signal extra charges from its first page. Here are six places to push back.
| Red flag in the quote or meeting | Question to ask |
|---|---|
| Price clearly below other quotes, plus "details to be settled later" | Which parts are not yet in the price? |
| Fixed price, but no requirements document exists | What document is the price based on, or what assumptions? |
| Scope written as "includes necessary functions" | Where is the concrete list of functions? |
| Changes not mentioned, or only "we'll discuss when it comes up" | How are changes quoted and approved? |
| Agreeing to changes by chat or phone is enough | What do I get in writing before work starts? |
| Change quotes show cost only, not delivery date | How far does this change push delivery? |
A smooth answer that leads to no document is also a signal. Ask early about technical limits as well, because limits that surface late tend to bring large changes with them; the article on five questions about technical limitations before you sign covers this.
5. How does VAON handle scope changes?
VAON handles scope changes with the four steps in section 2: work outside scope gets a change request, VAON gives a written quote and schedule impact, you approve, and only then does work begin. No approval means no work and no charge. For Japanese clients, VAON puts it in one sentence: 「ご承認いただいていない作業の請求書をお送りすることはありません。」 (We do not send invoices for work you have not approved.)
Two other practices support it. The first is the Spec Lock Phase (仕様確定フェーズ), where requirements become a document and the build phase gets a fixed-price quote before it starts, so "scope" has a concrete reference. The second is day-to-day working. Projects move in short pieces of one to two weeks, each with something running for you to see. The weekly report includes a "decisions needed from the client" section, so the need for a change tends to surface early, when it is cheap, instead of piling up at the end.
When you share a rough budget range, VAON offers two options: one within the budget and one broader. You compare them before choosing, rather than accepting added items midway.
6. What does this procedure not solve?
Change control does not remove the cost of change. A reasonable change still costs money and time; you simply know the number before you agree. If the budget has no room for any change, the problem is in the plan, not in the procedure.
Other limits:
- The procedure takes your time. Each request needs someone with authority to read and approve it. If that person is often away, agree on a deputy from the start.
- It does not replace a good specification. A vague specification blurs the scope line, and the argument moves to "is this a change?". That is why VAON runs the Spec Lock Phase first.
- "No surprises" applies to the agreed scope. Changes caused by outside conditions, such as a legal change or a third-party system altering its interface, usually go through the same procedure too.
- VAON has not published figures on how often change requests occur or their average value. This article gives none.
7. FAQ
Does a fixed price mean there will never be extra costs? No. A fixed price means the price is locked for the scope written in the document. If you ask for work outside that scope, a cost arises, but only after you have seen the quote and approved it in writing.
If I ask for a small favor in chat, will I be charged? At VAON, out-of-scope work begins only after a change request is raised and you approve the quote in writing. A chat request is logged in our feedback file or turned into a backlog task, then sent to you to confirm, with price and impact, before any work starts. If you decline, the work is not done and not charged.
How long should a change-control clause be? It does not need to be long, but it should cover the items in the table in section 3: who raises, who approves, contents of the request, quote deadline, and what happens if you decline. A short clause with job titles, dates, and a reference document beats a long vague one.
Can this work if the project is still vague and has no requirements document? Hardly. Without a document there is no boundary to call something a "change". In that case, run a Spec Lock Phase first to get a requirements document and a fixed-price quote for the build, then apply the change procedure.
Comparing quotes from several software vendors? Bring the quotes and a draft contract to VAON's first session. It is 60 minutes, our CEO attends, and there is no obligation. Book a free 60-minute consultation
Author: Đặng Văn Luân, Founder & CEO, VAON. HEDSPI graduate (Hanoi University of Science and Technology). Worked at FPT Software, spent five years at Digital Plus in Tokyo on a system with 10 million users, then eight years as COO of a 120-person IT outsourcing company, building its ISO 9001 and ISO 27001 management system. 15 years in the industry.
References
- METI and IPA, 「情報システム・モデル取引・契約書」 (first edition and addendum; commentary on the change-control procedure, Article 37 of the first edition): https://www.ipa.go.jp/archive/digital/model/ug65p90000001lgm-att/000079617.pdf (checked Oct 17, 2026)
- IPA, 「情報システム・モデル取引・契約書（第二版）」: https://www.ipa.go.jp/digital/model/model20201222.html (checked Oct 17, 2026)
