Quotes, estimates and scope creep in software projects

A software quote can stop being accurate well before anyone formally changes the budget. New fields are added in meetings, integrations are assumed in chat, a purchase order is raised for the original amount, and the delivery team keeps moving to protect the timeline. When the invoice arrives, the real dispute is often not about coding at all, but about what was actually included.

The practical answer is to keep one clear commercial record from quote through to invoice: scope, assumptions, exclusions, approval authority, purchase order position, change requests and billing references. That is what helps you show what was priced, what changed and why the final figure moved. For general background, see our guide on managing scope creep in business contracts.

This guide focuses on UK software projects where delivery starts quickly and scope evolves during implementation. It looks at estimates, purchase orders, change classification, approvals and invoice wording from a supplier-side risk perspective.

As a legal starting point, labels such as "estimate", "PO", "approved" or "kick-off" do not settle the issue by themselves. In RTS Flexible Systems Ltd v Müller [2010] UKSC 14, the Supreme Court said that whether a contract has been made, and on what terms, depends on what the parties communicated objectively through their words and conduct in the relevant circumstances. In practice, that is a reason to make the commercial position visible as the project moves, not to assume every informal message is binding.

Build one connected document trail from day one

Many suppliers let the sales quote sit in one place, the PO in another, the backlog in Jira and change requests across calls, chat and email. That fragmentation is where margin disappears. A better approach is to treat the project as one connected record made up of the quote or estimate, the governing terms, the scope or order form, the assumptions and client dependencies, the exclusions, the named approvers, any purchase order, approved change requests, and the milestones and invoice references tied to them.

Each document does a different job. The quote sets the initial commercial position. The scope says what is being delivered. Assumptions explain the basis on which you priced and planned the work. Exclusions mark out what is not included. The change process controls later movement. Invoices then need to map back to that record clearly enough that a finance contact, account manager or adviser can follow the story quickly.

For example, if you are delivering a Shopify build, your file should let a third party see without guesswork that the original scope covered theme customisation, product import and payment gateway setup; that multilingual content entry and subscription billing were excluded; that the client was responsible for supplying approved product data by a stated date; and that later integration work had to go through the change procedure. If your records do not let someone reconstruct that sequence easily, the process is not yet doing its job.

Quotes and estimates need assumptions, not just numbers

Software suppliers often send a figure early because they want to win the work quickly. The risk is not only underpricing. It is sending a number without enough commercial context to show what that number depends on.

If you use estimates, make them operationally useful. Do not just state a budget range or day count. Pair it with the assumptions that explain how the number was reached and the conditions needed for the price and timetable to hold. Typical examples include the client providing access to existing systems and technical contacts within a set period, data being supplied in an agreed format, design revisions being limited to a stated number of rounds, third-party licence costs being excluded unless expressly listed, testing being carried out against defined environments, and work outside standard hours not being included.

These are not decorative clauses. They are the bridge between your commercial offer and your delivery plan. If a client later asks why a timeline has moved, or disputes a charge for extra migration work, assumptions often provide the first practical explanation. They also help separate a true scope change from a delay or re-plan caused by missing client inputs.

It is worth keeping assumptions distinct from exclusions. Assumptions explain what must be true for your quoted price and timeline to remain valid. Exclusions identify work you are not taking on at all unless later agreed. Keeping those categories separate makes later change discussions much easier.

Purchase orders help finance, but they may not define scope

Clients sometimes act as though the purchase order is the definitive project document. Suppliers can make the opposite mistake and ignore it. Both approaches cause problems.

A purchase order may be important evidence in the overall commercial picture. In some software projects, it mainly serves as the client's internal spending authorisation and says little about delivery detail, so check it against the quote, scope and governing terms. It may contain a project title, a figure and a supplier reference, but little useful detail on deliverables, acceptance, dependencies, design iterations or support limits. That means your team should check the PO against the quote, terms and scope before treating it as the practical green light for expanded work.

A common example is a client issuing a PO for "website redevelopment phase 1" matching the original quoted amount, while the delivery team has already discussed additional analytics configuration, SEO migration support and multilingual content handling. If your project manager assumes the PO somehow captures those later discussions, the project may drift commercially before anyone notices.

As an internal control, do not assume a purchase order by itself updates the working scope unless the parties' communications and contract documents support that position. If the PO does not match the latest agreed scope or commercial terms, flag the mismatch in writing and resolve it early. That may be as straightforward as an email noting that the PO appears to cover only the original phase and that later requested items remain subject to separate approval and pricing.

This matters even more where work begins before a long-form agreement is signed. As RTS Flexible Systems shows, starting performance does not by itself answer which terms govern. If the team has already started while paperwork catches up, the written record needs to be cleaner, not looser.

Classify change before you price it

Not every project issue is a chargeable variation. Some items are genuine defects. Some are clarifications of existing scope. Some are consequences of a client dependency slipping. Some are entirely new deliverables. If your team does not classify the issue first, change control becomes noisy and clients lose trust in it.

In practice, suppliers often need four working categories: a clarification of what was already included; a defect or rework within scope; a dependency-driven impact caused by missing client inputs or third-party constraints; and a true scope change involving new, removed or materially altered work affecting effort, cost or timing.

This classification should happen before anyone sends a price or starts building. Otherwise, developers may implement "small extras" that were never assessed properly, and account managers may struggle to explain later why those items appear on an invoice.

Take a SaaS onboarding project. The original scope includes user provisioning, branding and standard reporting. During implementation, the client asks for single sign-on, department-based access controls and a custom export to match a legacy format. That is unlikely to be just a clarification. It is a package of technical and security changes with design, testing and sequencing consequences. It should be classified as a scope change and recorded that way, with the record stating whether the original estimate remains unchanged for the base project and the added work is priced separately, or whether the overall budget and timeline are being revised.

Use named approvals and one approval route

Many disputes are really disputes about authority. The client says its marketing lead never had authority to approve extra spend. Your team says the product manager asked for the feature in Teams and confirmed "go ahead". Both sides may genuinely believe they are right.

The safer operational answer is to define who can approve what, and through which route, before the project gets busy. For example, day-to-day technical clarifications might be handled in the project workspace, while scope changes affecting price or delivery date must be approved by the client's named commercial contact, with supplier-side approval to start the changed work coming from the project lead or account director. Approval might then be treated as valid only when confirmed by email or through the designated change module in the project platform.

This is not a universal legal shortcut. An email is not automatically conclusive in every dispute, and a Slack message is not automatically irrelevant. The point is consistency. A clear, repeated process gives you a better factual record of what was intended and who was acting for each side.

It also helps internally: developers should know they can discuss options, but not commit the business to extra work or revised deadlines.

A workable mini change-request record

Your change record does not need to be long, but it does need to answer the commercial basics: what is changing, why, who approved it, what happens to price, and what happens to timing.

Here is a clearly hypothetical example.

Hypothetical change request CR-04 - Nimbus CRM integration

• Raised: 12 June 2026 by A. Patel, Client Product Manager; assessed by J. Evans, Supplier Project Lead.
• Requested change: Add two-way sync with MailerPro and a CSV export for regional sales reports.
• Classification and reason: New integration and custom reporting, requested after kick-off to replace manual email uploads and provide weekly regional reports.
• Supplier work: API mapping; authentication configuration and testing; export-field workshop; CSV build and QA; updated user documentation.
• Price: Additional fixed fee of £4,800 plus VAT. The original quoted scope and price are otherwise unchanged.
• Timing and dependency: Eight additional working days. The illustrative UAT start moves from 1 July to 13 July 2026, subject to client API credentials by 16 June.
• Approval route: Written approval from the Client Commercial Lead and Supplier Account Director. In this example, L. Green and M. Shah each approve by email on 15 June 2026.
• Invoice reference: "CR-04 MailerPro integration and CSV export" on the July invoice.

The format matters less than the discipline behind it. What you are trying to avoid is a later argument where the technical team remembers one version, the finance team invoices another, and the client recalls something else entirely.

Keep the invoice trail tied to the delivery trail

Even good change control fails if invoices do not reflect it. Many supplier disputes escalate because the billing narrative is vague. The client receives an invoice for "development services" and cannot connect that line item to any milestone or approved change. That invites delay and challenge.

Your invoice trail should point back to the agreed commercial record. If you bill by milestone, identify the milestone. If you bill time and materials, refer to the relevant period, cap or approved additional work. If a line item relates to a change request, use the change request number or title. This is especially important where the original project was sold on a fixed fee but later additions are charged separately. Without clear invoice references, the client may treat the extra items as unsupported overruns rather than approved changes.

For suppliers, good invoice mapping also improves escalation. If payment slows, you can send a coherent pack showing the original quote, the relevant scope, the approved changes, the milestone reached and the matching invoices. That is far more persuasive than trying to reconstruct events from chat logs under pressure.

When the project is already drifting, slow the right part down

Once a project is live, the goal is usually not to stop everything. It is to stop uncontrolled expansion of the affected workstream while keeping the rest of the project moving where possible.

A sensible supplier response is to log the request or issue in one place, even if it arrived on a call or in chat; classify it against the current scope, assumptions and exclusions; assess technical effort, third-party cost and timeline impact; send a short written summary for approval through the agreed route; pause only the affected tasks until approval is clear; and then update the delivery plan and invoice references once approved.

If the relationship is becoming difficult, move the discussion away from informal delivery channels and onto named commercial contacts on both sides. In many software disputes, the real problem is not whether developers can build the requested item. It is that nobody paused to decide whether the request changed price, risk or timing.

At that stage, gather the core documents early: quote, order form or scope, governing terms, purchase order, change log, approval evidence and invoice ledger. If your terms need tightening for future projects, our team can help with a software development agreement aligned to how your projects are sold and delivered.

For suppliers, the key point is practical rather than theoretical: scope drift becomes expensive when the commercial record trails behind the technical work. The fix is not a single clause or label. It is a repeatable workflow linking quote, assumptions, exclusions, approval authority, change classification and invoicing from the start of the project to the final bill.

Key Takeaways

• Treat the quote, scope, assumptions, exclusions, approvals, purchase order and invoices as one connected record, not separate admin steps.
• Use assumptions to show what your price and timetable depend on, and keep them distinct from exclusions.
• Do not assume a purchase order defines or updates scope by itself. Check it against the latest agreed documents and flag mismatches early.
• Classify issues before pricing them: clarification, defect, dependency impact or genuine scope change.
• Use named approval routes and make invoices trace back to milestones or specific approved change requests.

For support with software development terms, statements of work or change-request processes, call 08081347754 or email team@sprintlaw.co.uk.

General information only, not legal advice. Sprintlaw is an online fixed-fee legal consultancy for businesses and is not an SRA-regulated law firm.