A change order log is a register that records every change to a construction contract from the moment it is raised: what the change is, where it came from, its cost and schedule impact, its approval status and the running contract value after each approval. It is the single document that tells you what the contract is worth today and what is still in the pipeline. This page gives you a free change order log template in Excel and CSV formats, with example rows, and no form between you and the download.
Download the change order log template
Both files carry the same columns and example rows. Use the Excel version if you want the formatting; the CSV opens anywhere, including Google Sheets.
Clear the example rows, set your original contract value, and log the first change the day it is raised. Values are shown without a currency symbol so the template works in any market.
The template structure, with example rows
The template has ten columns. The example rows below assume an original contract value of 2,450,000 and show one approved addition, one approved credit and one change still awaiting client sign-off.
| CO No. | Description | Origin (RFI/site condition/client request/design change) | Date raised | Cost impact | Schedule impact (days) | Status (proposed/priced/approved/rejected) | Approved date | Contract value after CO | Notes |
|---|---|---|---|---|---|---|---|---|---|
| CO-001 | Additional drainage to north car park | Site condition | 2026-03-04 | 18,400 | 5 | Approved | 2026-03-18 | 2,468,400 | Priced from dayworks rates |
| CO-002 | Substitute cladding panel specification | Design change | 2026-03-21 | -6,200 | 0 | Approved | 2026-04-02 | 2,462,200 | Credit agreed with client |
| CO-003 | Extra power outlets in office fit-out | Client request | 2026-04-10 | 4,750 | 2 | Priced | Awaiting client sign-off |
Every column, explained
A change order log is only trusted if every column is filled in consistently, because each one answers a question someone will ask under pressure later. Here is what each column is for.
- CO No. A sequential reference that never changes and is never reused, even for rejected changes. Correspondence, invoices and meeting minutes will all cite this number.
- Description. One or two lines of plain language stating what changes. Write it so someone reading the log a year later understands it without opening the attachments.
- Origin. Where the change came from: an RFI answer, a site condition, a client request or a design change. Patterns in this column are commercial intelligence; a run of site-condition changes tells a very different story from a run of client requests.
- Date raised. The date the change was first identified, which starts the clock on any notice periods the contract imposes.
- Cost impact. The agreed or estimated value of the change, positive for additions and negative for credits. Update it when the price is agreed; an estimate left in place after agreement misstates the contract value.
- Schedule impact (days). The time consequence of the change in working days, including zero, recorded explicitly. A blank cell reads as not assessed, which is a different and worse thing than no impact.
- Status. Proposed, priced, approved or rejected. The distinction between priced and approved is the one that matters most: priced work is not yet contract value, and building it early is at your own risk.
- Approved date. The date the client or their agent formally approved the change. This is the date the contract value legitimately moves.
- Contract value after CO. The running total, updated only when a change is approved. At any moment, the newest entry in this column is the current contract sum, which is exactly what the log exists to answer.
- Notes. Anything the other columns cannot hold: pricing basis, related references, agreement conditions.
Running the log so it stays trusted
Log every change the day it is identified, however small and however informal the conversation that raised it. The log's value comes from being complete, not tidy. Review it at the same rhythm as your cost reporting, chase every entry sitting in proposed or priced status, and reconcile the newest contract value after CO figure against what the client's own records say. A log that agrees with the client's log is a quiet log; the disputes start when the two drift apart for months unnoticed.
Common change order log mistakes
The most damaging mistake is logging changes only after they are approved, which turns the log from a management tool into an archive and hides your real exposure: the unapproved pipeline. Second is treating verbal instructions as too informal to log; the changes that end in dispute are almost always the ones that started as a conversation on site. Third is updating the contract value when a change is merely priced rather than approved, which overstates the contract sum and flatters revenue until the correction lands. Finally, rejected changes are often deleted from the log; keep them, because the record that a change was raised, priced and rejected is precisely what you need if the same issue resurfaces.
When the log needs to move out of the spreadsheet
One project, one log, one owner: a spreadsheet does the job. The failure mode is growth: several live projects, changes raised by site staff who do not own the spreadsheet, and a month-end scramble to work out which version is current. That is where change order management software earns its place: it keeps every change on one record from the moment it is raised, carries its status through pricing and approval, and updates the contract value only on approval, so the current contract sum is always one lookup away rather than one spreadsheet argument away.
Frequently asked questions
What is a change order log?
A change order log is a register of every change raised against a construction contract, recording each change's description, origin, cost and schedule impact, approval status and the running contract value after each approved change. It answers, at any moment, what the contract is worth and what is still pending.
Who should keep the change order log?
One named owner, usually the project's commercial lead or project manager, should control the log, but anyone on the team should be able to feed changes into it the day they are identified. Split ownership is the fastest way to end up with two conflicting logs.
Should rejected change orders stay in the log?
Yes. A rejected change keeps its number and its row, with the status set to rejected. The record that an issue was raised, priced and declined protects both parties if the same scope question comes back later in the project.
