Approve project scope changes before work and billing

A client asks for an extra item during a progress call. Someone adds it to the team's task list. The project moves forward, but the agreed price and completion date stay unchanged. When the invoice arrives, everyone has a different understanding of what was included.

A project change register can give each request a clear path from proposal to authorized work. The useful record connects the original agreement, the exact change version, its cost and schedule effects, and the decision made by someone entitled to approve it.

Start with a baseline people can actually find

Identify the scope currently authorized for the project. Link to its agreed deliverables, exclusions, price basis and schedule, with the version and approval date. Keep that baseline available even after later changes are accepted.

A request should explain how it differs from the baseline. Is the client adding a deliverable, replacing a specification, removing work or asking for something already included? Resolve that classification before calling everything an extra charge.

Separate the requester from the approver. A person attending a project meeting may suggest changes without having authority to commit the client to extra cost. Your team needs an agreed approval route and a substitute when the usual decision-maker is unavailable.

Make each register entry useful to delivery and finance

A spreadsheet may be enough for a small operation if someone maintains it. A custom workflow could enforce the same record structure and decision gates when more people or systems are involved.

For each request, record:

• A change reference, requester, date and responsible internal owner.
• The baseline version and the affected deliverables or locations.
• The proposed change, exclusions and change-document version.
• Cost effects, including additions, deductions and pricing assumptions.
• Schedule effects, affected milestones and dependencies.
• The authorized decision, decision-maker, date and supporting evidence.
• Work-release status and the later evidence required for billing.

Unknown cost or time effects should remain visibly unresolved. A blank field is too easy to mistake for “no change.” If assessing the request itself needs chargeable work, agree on that assessment separately instead of quietly starting the full change.

Present the whole trade-off before asking for approval

Consider a hypothetical office fit-out project. The approved baseline includes four storage units. A request adds two more. Change CR-014, version 1, proposes an additional ₱24,000 and two working days, subject to the stated material availability and tax treatment.

The client then asks for a different finish. The team prepares version 2 with a revised amount and delivery effect. An approval of version 1 cannot authorize version 2 merely because both documents share the same change reference.

Give the approver a readable summary of what they are accepting. Show the price adjustment and the resulting project total under the same accounting basis. Explain whether two extra working days actually move the completion date or can fit within the existing schedule. Let the responsible finance team confirm tax presentation and document requirements.

Keep the decision attached to the exact version

Use decisions such as approved, rejected, deferred and revision requested. Preserve the reviewed version and its supporting attachments. A later edit should create a new version requiring a new decision where the agreed content changes.

A comment such as “please explore this” should remain a request to investigate. Silence should not become approval unless an applicable agreement has explicitly established that rule and the responsible reviewer has confirmed its use.

Rootscratch's client portal MVP guide explains version-linked file approvals. For changed project scope, the decision also needs to cover commercial and schedule effects before anyone releases the additional work.

If work has already started on an approved version, a revision needs a record of what is complete, what must stop and any rework cost. Do not overwrite the earlier approval to make the history look simpler.

Release additional work deliberately

The register should tell delivery staff which approved change they can act on. A scoped system could prevent a proposed or rejected change from being issued as an authorized work item, while leaving unaffected baseline work available to continue.

Decide who checks prerequisites such as a deposit, purchase authorization or access date. Scope approval may be necessary without being sufficient to start immediately.

Urgent exceptions need a named authority and a recorded basis under the business's agreed policy. “We already did it” should not turn an unauthorized request into a retrospective approval. Where emergency work is permitted, record the authorization and limits when the decision is made.

Keep work approval and billing eligibility distinct

An approved change establishes the agreed addition or deduction. Whether it can be billed now depends on the contract: perhaps a deposit is due, a milestone must be accepted or measured work needs verification.

Finance should be able to trace a billed item to the approved change version and the evidence required for that billing stage. The register should also show amounts previously claimed and later adjustments so a revised entry does not get billed twice.

Before commissioning a workflow, test a rejected change, an outdated approval link, a version revised after work starts and a deduction issued after an earlier claim. Ask delivery and finance to identify the authorized scope and billable amount independently.

Rootscratch's project contracting and billing service can scope these connections around your contracts and approval roles. Bring an anonymized change request and its route to an invoice when you discuss your project workflow.

Cover image: AI-generated editorial illustration; not a real client, deployed product, or product screenshot.