Project change orders must reach billing intact

A project change can be operationally real before it is commercially authorised. Billing needs the approved scope, price, effective boundary and evidence of completion before the change becomes a charge.

The safest hand-off preserves the request and every decision that followed. It does not turn a delivery note or chat message into billing authority by implication.

Capture the request

Record what changed, who requested it, the affected deliverable or period and the expected timing.

Keep the customer's language where possible. A summary should not remove conditions that matter to approval.

Separate scope and price authority

Delivery approval confirms what the team will do. Commercial approval confirms the amount, rate or schedule that may be billed.

Name both decisions when different people own them. One should not silently stand in for the other.

Set the effective boundary

State which work, milestone, time period or future cycle uses the changed terms.

Avoid applying a new rate retrospectively unless the agreement and approval explicitly require it.

Connect delivery evidence

Retain accepted milestone, approved time or other agreed trigger against the change record.

A broad project progress update cannot replace the specific event that authorises the charge.

Review the outgoing line

Show the change as a clear invoice line or supported adjustment with the correct customer, entity, currency and reference.

Preserve the original agreement and change history so the reviewer and customer can reproduce the amount.

Define the change before it enters billing

A project change order should identify the customer, project, original agreement, changed scope, commercial effect, currency, effective date, delivery impact, billing rule and authority. A chat request or task update can start the discussion, but it should not become an invoice line until the governed approval condition is met.

Separate no-cost scope clarification, additional fixed work, rate change, quantity change, schedule change and cancellation. Each class affects billing differently. Record the decision required and keep uncertain commercial impact held rather than translating every project change into an estimated charge.

Preserve contract and change-order versions

Link the approved change order to the exact contract and project baseline it modifies. Retain the prior scope, amount, rate and schedule. Use effective dates so completed work and issued invoices continue to point to the terms that governed them, while future billing uses the approved new version.

Do not overwrite a project budget or rate card and rely on edit history alone. Record the requester, approver, reason and affected milestones, time categories, retainers or recurring schedules. The invoice workflow should receive a clear versioned input rather than reverse-engineer the commercial decision from current project totals.

Map the change to billable events

Translate the approved change into specific future evidence: a new milestone, additional approved hours, revised rate, quantity rule, recurring schedule or one-off charge. Name the first eligible period and prevent overlap with the prior rule. A change order is not itself always the invoice trigger; it defines how later work becomes billable.

Keep approved but unused scope separate from delivered or accepted work. If the change creates an immediate authorised charge, document that condition explicitly. Otherwise wait for the milestone, time approval, quantity or schedule event identified in the new commercial version.

Work a mixed change-order case

Assume a project adds a $6,000 accepted deliverable and raises the rate for future specialist time from $200 to $225 on 15 September. Create a new milestone for the $6,000 scope and an effective-dated rate version. Do not reprice hours approved before 15 September unless the authorised change explicitly requires retrospective treatment.

When ten eligible hours are approved after the effective date, the supported added time is $2,250. Preserve the milestone and time as separate source lines even if they appear on one $8,250 invoice. Each component keeps its own acceptance, rate evidence and correction path.

Handle work started before approval

Record work performed while the change order remains pending without representing it as billable. Name the commercial owner, decision deadline and exposure. If approval later becomes effective retrospectively, route the treatment through the approved policy and retain the actual decision time and stated effective scope.

If the customer rejects the change, preserve the work record for project management while excluding it from customer charges unless another authorised basis exists. Do not delete the work to make billing reports balance. Operational effort and supported receivable value are different facts.

Propagate the approved change safely

Update only the affected project controls, schedules, rates and invoice candidates using stable identifiers. Notify source owners and the outgoing reviewer of the new version. Confirm customer entity, purchase reference, currency and delivery details where the change altered the commercial relationship.

Send the governed identifiers and amounts to accounting without making billing authoritative for ledger treatment. Reject mapping failures and duplicate change applications as owned exceptions. Verify customer portal and statement views after issue so the revised scope is not shown beside obsolete amounts without explanation.

Close the change-order hand-off

Retain the original and changed commercial versions, authority, actual approval time, effective date, mapped billing events, first affected invoice, outgoing approval and delivery. Record pending or rejected components with owners and next dates. This lets another reviewer reproduce both what changed and when it became chargeable.

Sample retrospective approvals, overwritten rates, duplicate milestone creation and invoices with no linked change evidence. Repair the project-to-billing interface where the same ambiguity recurs. A good hand-off makes authorised change visible without turning informal project activity into unsupported customer charges.

Decision summary

• Version the authorised change against the project baseline.

• Map the change to explicit future billable events.

• Apply rates and scope from their approved effective dates.

• Keep unapproved work valid but outside customer charges.

• Trace the first affected invoice back to the decision.

Verify the first affected invoice and the next source event

Compare the first affected invoice with the approved change version, actual effective date and mapped milestone, time, quantity or schedule events. Confirm prior work retained its earlier rule and the change was applied once. Record the population checked and reviewer before release.

Then test the next expected source event. A correct first invoice can still leave an obsolete recurring schedule or rate active for the following period. Close the hand-off only when the durable source rule is correct, not when one manually adjusted document happens to show the intended amount.

Put the control into practice

Choose a recent change order and trace it from request to invoice. Any missing authority, date or delivery condition is a control gap to resolve before the next project change.

Run the review on a real case

A client requests additional work during delivery and the team begins immediately. Keep the work operationally visible, but do not invoice it until scope, commercial authority, price and effective boundary are approved under the agreed change process.

Trace the change from customer request to scope decision, price approval, delivery evidence and invoice line. Preserve the previous agreement and the person responsible at every hand-off.

Case-review checklist

• Original request is retained

• Scope and price decisions are separate

• Effective boundary is explicit

• Delivery evidence matches the change

• Invoice line keeps the reference

Whether work can proceed or be billed before formal execution depends on the agreement. This workflow preserves facts and approvals without interpreting contractual rights.