Change Order vs Work Order

A work order is the original contract between client and contractor. It defines the scope, schedule, payment structure, warranty, and dispute process. The work order is the document the whole project is measured against.

On ContractShield, the work order starts as a client-posted request and becomes a signed contract after a contractor's bid is accepted. Every subsequent phase ties back to that signed work order.

A change order is a formal amendment to the work order that adds, removes, or modifies scope. It includes the scope delta, the cost delta (plus or minus), and the timeline impact. Every change order needs client approval before the contractor authorizes new work.

Change orders exist because construction projects discover surprises. Rot behind a tub, wiring that does not meet code, a client who changes their mind on tile. All of those fit inside the change order framework without the original work order becoming a mess.

Blurring the line between work orders and change orders is where construction projects run over budget. If the contractor treats a scope change as a verbal agreement, the client argues later about what was agreed. If the client requests scope changes without approving a change order, the contractor is in an impossible position at invoice time.

Structural fix: treat both as versioned records, not email threads. The original work order is v1. Each change order is v2, v3, and so on. Payments tie to the current version.

On ContractShield, work orders and change orders share the same template. The client sees the scope delta, the cost delta, and the timeline impact in the same format they saw the original bid. Approval is digital, and the contract auto-updates with the change.

No email archaeology, no paper amendments, no arguments about what was said on a phone call. Everything is in one place with timestamps and digital signatures.

Three scenarios cover 80% of 2026 US residential change orders. Site surprise (rot, old wiring, foundation issues) is the biggest. Client-requested upgrade (nicer tile, better vanity, bigger window) is second. Code-driven requirement found during inspection is third.

All three deserve a change order. Site surprises should draw from the contingency line before they become a change. Client upgrades are pure additions. Code-driven requirements are usually split between client and contractor depending on who assumed code compliance.

• Site surprise: rot, legacy wiring, soil or foundation issues.
• Client upgrade: finish tier change mid-project.
• Code requirement: inspection punchlist demands scope add.

A good change order has six fields: work order reference, scope delta, cost delta, timeline impact, rationale, and client approval. It ties back to the original work order version and records the new version after approval.

ContractShield change orders include all six by default. The rationale field is the most important. If the change is a site surprise, the rationale field documents photos and the sub's findings.