Construction Change Order Template: Fields and a Worked Cost Example
A construction change order template records an agreed change to project scope, price, or time. It gives the team a clear record of what changes and how that change affects the existing agreement. A useful form needs more than a scope description and a signature line.
This guide has fields you can copy and a sample construction change order. It walks through the cost and time math, then shows which records to attach and who needs to approve the change. It also explains the billing handoff. Use the form with the real contract and project process.
What a change order should accomplish
First, name the original agreement and the exact change. The form should explain what the team will add, remove, or revise. It should also show the agreed financial and time effects without hiding them in broad wording.
Procore’s guide to construction change orders explains how changes affect project scope, cost, and schedule. Keep those three dimensions clear in the record. A change can affect one, two, or all three.
However, a request for a price is not the same as an approved change order. A contractor may need to assess a request before the approved parties accept it. Use clear statuses so a draft does not appear to authorize work.
Also, use the form with the contract, rather than in place of it. Check who can sign, when notices are due, how to price changes, and who can direct work. Then follow the project team’s agreed route.
Copyable construction change order template fields
Begin with form identity and agreement details. Then separate the scope narrative, pricing math, schedule effect, and approval. That structure makes the record easier to review and less likely to conceal a missing decision.
| Section | Fields to copy into your form |
|---|---|
| Identity | Project, change order number, date, version |
| Agreement | Original contract reference and parties |
| Related records | Request, drawing revision, instruction, quote |
| Scope | Added work, removed work, changed requirements |
| Cost | Additions, deductions, net change, price basis |
| Contract totals | Original amount, prior approved net changes, revised amount |
| Time | Agreed extension or reduction and revised milestone |
| Assumptions | Access, sequence, exclusions, validity where applicable |
| Authorization | Required parties, names, roles, dates, approval evidence |
| Status | Draft, under review, approved, rejected, or superseded |
Use stable IDs for attachments rather than phrases such as “latest drawing.” A later drawing revision can make that phrase unclear. Name the document, revision, and needed area so a reviewer can find the same evidence.
Next, distinguish the change number from its revision. Change CO-007 revision two should not become a second approved change with the same amount. Keep the history, but count only the version that the proper process accepts.
Write scope so the field team can act on it
Describe the affected location, quantity, specification, and work limits. Explain what replaces the original scope. If the change removes work, name it explicitly rather than recording only a negative amount.
For example, “add outlets” leaves several questions open. A clearer detail names the room, agreed quantity, drawing ID, and affected work package. It can then refer to an attachment for detailed technical requirements.
Also, record dependencies that affect delivery. A change may need access, a design decision, or prior work from another trade. Give each open item an owner before the team commits to the proposed sequence.
An RFI template can help record a request for project clarification. However, the answer to an RFI does not by itself prove agreement on a price or time change. Keep the clarification and the approval record linked but distinct.
A sample change order with additions and deductions
Take a sample project with an original contract amount of $100,000. Earlier approved changes have a combined net value of $6,000. The current proposed change adds a task and removes another task from the original scope.
The invented figures below show the math. They are not market rates or recommended fees. The example excludes tax and assumes the terms permit the stated pricing method.
| Item | Example amount | Meaning |
|---|---|---|
| Added material and labor | $4,800 | Supported added-work cost |
| Removed original work | -$1,200 | Agreed deduction |
| Net direct cost change | $3,600 | $4,800 less $1,200 |
| Agreed markup | $360 | 10% of the stated net cost basis |
| This change’s net price | $3,960 | $3,600 plus $360 |
| Previous approved contract amount | $106,000 | $100,000 plus $6,000 |
| Revised amount after approval | $109,960 | $106,000 plus $3,960 |
Keep the pricing basis beside the amount. In this example, markup applies to the net direct cost. Another agreement may use distinct rules for additions, deductions, overhead, fees, or subcontract work.
Therefore, do not reuse the example’s percent without checking the real method. Also, check whether the underlying rates already include costs that a separate line would add again. Correct math cannot fix duplicate cost recovery.
Match the contract total carefully
The revised contract amount should start from the original agreement and approved net changes. Do not include pending proposals merely because the estimator expects approval. A forecast can track pending exposure in a separate field.
For example, a rejected $2,000 proposal should not remain in the approved total. Likewise, an approved deduction reduces the net value. A change register needs signed amounts, not just a list of positive additions.
Next, match the register with the individual approved records. If a correction replaces an earlier version, the register should not count both. Keep a clear link to the record that supersedes the old version.
Our guide to job costing software explains how project cost records support financial review. Keep approved contract value separate from real costs and pending change estimates. Those figures answer distinct questions.
Assess the schedule effect separately
Record whether the change affects a milestone, finish date, or work sequence. Explain the basis for the proposed time change. Added cost does not automatically prove extra time to finish, and extra time does not always need new work quantities.
For example, the team may agree that a change adds three calendar days to a named milestone. State the planned and revised dates, plus the needed assumptions. Do not turn “three days” into a new date without checking the agreed calendar.
Also, weigh how the changed task connects to other work. A task may fit within available time, or it may affect a sequence that controls the finish date. Give the schedule reviewer enough detail to assess the claim rather than relying on a broad rate.
The Anomoz article on construction scheduling programs covers tools for tracking project timing. A software update should reflect the approved decision and its basis. It should not silently replace the formal time agreement.
Attach evidence that matches the math
Keep quantities, rates, labor assumptions, supplier links, and needed drawings with the proposal. The reviewer should trace a cost line to its basis. Avoid a large attachment pack that gives no clue which evidence supports which amount.
For example, link the supplier quote beside the material line. Then state what the quote includes and excludes. If the proposed cost uses labor hours, name the task, role, rate basis, and scope covered.
Next, check that evidence and narrative describe the same version. A quote for one material can remain attached after a design revision changes the specification. That mismatch should trigger review before approval.
Also, use same-day field records when needed. Our construction daily report template explains how to record site work and conditions. A report can support the history, but it does not replace the needed change approval.
Approval needs a defined route
Specify who reviews scope, cost, and schedule, then name who can authorize the change. A project contact may acknowledge receipt without having authority to approve a contract amendment. Name the decision and assigned role clearly.
The AIA instructions for G701 explain the purpose and use of that contract document. Use the correct licensed form when the project needs it. The generic fields in this article do not copy or replace an AIA form.
Also, keep the real approval evidence and date. A checkbox that says “approved” without a source does not show who accepted the change. The record should let an approved reviewer inspect the needed signed or accepted version.
If urgent work follows a separate contract instruction process, record that process and its limits. Do not relabel each instruction as an agreed change order. Resolve the final price and time status through the proper route.
Move approved changes into execution and billing
After approval, communicate the scope and current attachments to the people who will perform the work. Update the needed project records with the approved value and timing. Keep a note of when the handoff occurred and who received it.
Next, align the billing record with the approved change and applicable payment process. An approved contract increase is not itself an invoice due for payment. Billing may depend on progress, milestones, supporting documents, or other agreed conditions.
For example, the sample $3,960 change increases the contract total after approval. It does not mean the entire revised $109,960 is due at once. Keep prior billings, payments, and current amounts due in their own records.
Also, stop superseded instructions from circulating. If an approved revision changes the scope again, alert the field team and update the controlled attachment list. A correct office record cannot help a crew working from an outdated printout.
Check the form before release
Review project identity, contract reference, scope limits, attachments, and version first. Then trace the net cost, markup basis, and revised total. Finally, check the schedule statement and needed approval evidence.
Look for vague claims such as “all related work” that conceal scope disputes. Also, inspect blanks that could imply no time effect when the team has not assessed it. Use “pending review” only where the process permits it, and keep that status clear.
Before closing the record, match its outcome with the register. A rejected request, withdrawn proposal, and approved change need distinct statuses. Keeping that distinction makes later project review far more useful.
Keep a clear record when parties disagree
A disputed proposal needs its own status and review history. Record the exact item under dispute, the parties’ positions, and the next decision owner. Do not describe the whole change as agreed when only part of the scope or amount has acceptance.
For example, the parties may accept a scope description but still disagree about a time extension. Keep those decisions distinct. Follow the contract’s process for any direction to proceed and keep the evidence of that direction.
Also, separate the contractor’s forecast from the approved contract register. A forecast may include an expected outcome for planning, but that expectation should carry a clear label. It should not appear in billing as an agreed entitlement merely because the office entered it in software.
After resolution, link the final decision to the earlier proposal and supporting records. Then match the register, schedule, and billing handoff. Closing the status without those updates can leave distinct teams acting on distinct outcomes.
Frequently Asked Questions
Can one change order reduce the contract price?
Yes. A change can remove work or create an agreed deduction. Show the signed net amount and use it consistently when calculating the revised approved contract total.
Does an RFI response approve a change order?
Not by default. An RFI can clarify details, while the terms may need a separate route for scope, price, or time changes. Link the records and check the real approval.
Should pending changes appear in the revised contract amount?
Keep pending amounts separate from the approved total. They may belong in a forecast or exposure report, but they should not appear as agreed changes until the needed process accepts them.
Start with one change and trace each effect
Use the construction change order template to connect a clear scope decision with cost, time, evidence, and authority. Test one record from request through approval and billing. A traceable change is easier for the office, field team, and client to act on.