Construction change orders: four patterns and how to manage them without margin erosion.

Change orders are the second-most-disputed line on every commercial construction project, after retention. The dollar volume in change orders on a typical mid-sized project runs 5-15% of contract value, and the management of them — pricing, approval routing, schedule impact, aging, payment — is where margin gets made or lost on both the sub side and the GC side. This is a working guide to the four common change-order patterns, how each one should be priced and routed, the aging problem that quietly erodes margin, and how AOS handles the whole flow.

If you're a sub PM, a GC PM, or an accountant on either side of the table, change-order management is the workflow you spend the most ad-hoc time on every week. It rarely follows a clean process. The pricing argument over scope additions, the schedule-impact debate over field conditions, the design clarifications that should have been COs but were absorbed quietly, the COs that aged out into closeout disputes — these are the recurring sources of margin erosion in commercial construction.

This post breaks down the four CO patterns, what's actually being negotiated in each, and what a clean workflow looks like.

The four common change-order patterns

Almost every change order in commercial construction fits one of four patterns. Knowing which pattern a CO belongs to determines how it should be priced, what schedule impact to claim, and how the approval should be routed.

Pattern 1: Scope addition (owner-directed). The owner decides they want something added to the project — an extra storefront, a different finish, more bandwidth in the AV system, an elevator upgrade. The scope is clearly outside the original contract. Both T&M and lump-sum pricing are commonly negotiated; lump-sum is the cleaner outcome but requires the sub or GC to estimate accurately. Schedule impact is usually accepted if the change is large enough to genuinely affect critical path.

Pattern 2: Field condition (unforeseen). The work runs into something that wasn't in the plans — unmarked utilities, hazardous soil, structural issues hidden behind existing finishes, weather conditions worse than the contract anticipated. The contract usually provides for these via Owner / GC / Engineer notice-and-investigate procedures. Pricing is almost always T&M, because the scope is uncertain. Schedule impact is generally accepted, with documentation of the discovery date.

Pattern 3: Design clarification or omission. The plans were ambiguous, contradictory, or missing detail. The architect or engineer issues a clarification (often via RFI response) that the sub or GC interprets as a scope expansion. Whether this is a CO depends on contract language and on how the original RFI was framed. This is the most disputed pattern — the architect's position is usually "the intent was clear"; the sub's or GC's position is "we priced what was drawn." Pricing here is contested and often gets compromised at less than the full T&M cost.

Pattern 4: Acceleration / schedule recovery. The owner or GC directs the sub (or the GC) to accelerate to recover lost schedule. The cost is overtime, additional crews, material expediting, weekend work. Pricing is T&M but with documented premium-time rates. Acceleration COs are common late in projects when prior delays have compounded; they're often the largest single COs on a job by dollar amount.

Most COs that fall apart in negotiation fall apart because the parties haven't agreed which pattern they're in. The owner thinks it's a design clarification (the sub absorbs); the sub thinks it's a scope addition (the owner pays). Naming the pattern early in the conversation is half the work.

What "managing a change order" actually means

The lifecycle of a CO has eight distinct steps, each of which can stall or go sideways:

• Trigger event. Something happens on site or in the design that changes the scope. The sub PM or GC PM identifies it.
• Notice. The party affected (usually the sub) provides written notice to the GC (and the GC to the owner) within whatever contractual deadline applies. Missing this deadline can void the CO right entirely on some contracts.
• Quantification. The sub develops a T&M estimate or a lump-sum proposal. This includes labor (with burden), materials, equipment, subcontract markup if applicable, GC's own markup if the sub is a subcontractor under a GC, and any schedule impact.
• Submission. The proposal goes to the GC's PM for review. The GC's PM reviews against the project budget, the contract terms, and whether the work fits owner-approved scope.
• Negotiation. Almost always happens. The GC pushes back on labor rates, on burden assumptions, on schedule claims, on markup. The sub defends or compromises.
• Approval. If a deal is reached, a formal change order document gets signed. Some contracts require owner signature; others delegate authority to the GC up to certain dollar thresholds.
• Performance. The work gets done. (Often the work has already been done by this point; CO timing in commercial construction is famously after-the-fact.)
• Billing. The approved CO gets added to the sub's SOV; the next pay app reflects it; retention is applied to the CO amount per contract terms; payment flows through the standard pay-app cycle.

The single biggest pathology in this lifecycle is that steps 5 and 6 (negotiation and approval) often happen after step 7 (performance). The sub does the work because the schedule can't wait, and then negotiates the dollar amount months later from a much weaker position — the work is done, the leverage is gone, and the GC and owner have every incentive to negotiate the price down.

The CO aging problem

CO aging is the dollar volume of changes the sub has performed but not yet been paid for. It's the second-largest hidden carrying cost on most commercial projects (after retention).

Typical aging by pattern:

• Scope additions: usually approved and paid within 30-60 days of the change being identified. Lower aging.
• Field conditions: 60-120 day aging is common because the T&M cost has to be substantiated and reviewed. Higher.
• Design clarifications: can age 6+ months because the dispute over whether it's actually a CO drags out. The riskiest pattern for sub-side aging.
• Acceleration: moderate aging, usually 60-90 days, with the wrinkle that schedule-recovery COs often happen near substantial completion when the GC is also negotiating closeout terms.

For a sub doing $30 million in volume, CO aging running 90 days at 10% of project value means $750K is constantly tied up in performed-but-unpaid CO work. That's a real working-capital expense, and it usually doesn't show up as a CFO concern until the CO that's been pending for 8 months finally gets approved at 60 cents on the dollar.

For the GC, CO aging is the symmetric problem on the AP side — CO liabilities that should be tracked as an accrual but often live in the PM's email rather than the accounting system. When closeout arrives, the GC discovers $400K in CO liabilities that should have been accrued months earlier.

What goes wrong on most projects

Four recurring failure modes:

1. COs initiated in email and never logged systematically. The sub PM emails the GC PM a T&M proposal. The GC PM forwards to accounting. The accountant prepares a formal CO document. The sub signs and returns. The signed document gets filed somewhere — sometimes in the project folder, sometimes in the accounting system, sometimes in three places. A central CO log that shows everything in real time often doesn't exist on either side.

2. CO aging not tracked anywhere actionable. The sub's accounting system might track CO totals at the project level but not the aging of individual unapproved COs. The PM tracks them in a spreadsheet that's perpetually out of date. The CFO is surprised at month-end when CO aging hits a threshold.

3. Schedule impact deferred to "we'll figure it out at closeout." The CO gets approved for the dollar amount but with no schedule extension. The sub absorbs the schedule impact. At closeout, the cumulative schedule impact of all the unextended COs is the basis for a liquidated-damages claim, and the sub has no documentation to defend against it.

4. Designer-driven COs (Pattern 3) get absorbed silently. The sub or GC raises an RFI; the architect's response expands the scope; the sub or GC absorbs the cost because the CO process is too painful to invoke for a small change. Multiply by 50 RFIs per project and you've absorbed real margin without anyone tracking it.

What a clean CO workflow looks like

The principles:

One central CO log per project, visible to both sides. Every potential CO — from the moment it's identified, before pricing, before submission, before negotiation — is a record in the log with a state. The states are: identified → priced → submitted → in-negotiation → approved → performed → invoiced → paid. Anyone with project access can see what's open, what's stalled, and what's aged.

Notice deadlines tracked automatically. The platform knows the contract's notice deadline (commonly 7, 14, or 21 days from the trigger event) and alerts when a potential CO is approaching the deadline without notice having been given.

Aging visible as a dashboard, not buried in spreadsheets. The CO aging report should be a real-time view at the project, client, and firm level, with breakdowns by pattern. The sub's CFO and the GC's controller both see it; neither is surprised at month-end.

Schedule impact recorded with the dollar impact. Every CO submission should include the schedule-extension claim, documented and defended. The contract amount changes; the project end-date changes (or doesn't, with the trade-off documented).

RFI-to-CO promotion. When an RFI response expands scope, the platform should make it easy to promote it to a CO — not by manually re-typing the scope, but by linking the RFI record to the new CO record. This single feature, more than any other, prevents the silent absorption of designer-driven COs.

How AOS handles change orders cross-tenant

In AOS, the CO is a first-class object with state, audit trail, and cross-tenant visibility. Specifically:

• The CO log is one record across both sides. The sub creates a CO; the GC's PM sees it in their queue with one-click approve/reject/comment; the GC's accountant adds it to the contract sum automatically when approved; the owner (if on AOS) sees it in their dashboard.
• State transitions are enforced. identified → priced → submitted → in-negotiation → approved → performed → invoiced → paid, with each state requiring specific documentation (proposal, notice timestamp, approval signature, performance verification).
• Notice deadlines are tracked automatically from the contract's notice provision and alerted at the configured threshold.
• Aging dashboard is live — the sub's CFO sees aged unapproved COs at project, GC, and firm level. The GC's controller sees the same with their own roll-up.
• Schedule impact is captured with the dollar impact, and the project's end-date is updated automatically when the CO is approved with a schedule extension.
• RFI-to-CO promotion is a one-click action on the RFI record. The new CO inherits the RFI's scope description, the related drawings, the architect's response — eliminating retyping and capturing the audit trail of what triggered the CO.
• The approved CO updates the SOV automatically, the next pay app reflects it, retention is applied per contract terms, and the cycle proceeds without manual reconciliation.

The sub PM role page walks through the PM workflow; the GC PM role page covers the other side. For the broader strategic story on how the document handoff disappears when both sides are on the platform, see the both-sides-on-one-record post. For the related lifecycle on the pay-app side, see the AIA G702/G703 working guide.

The CO management readiness checklist

Run your current CO workflow through these questions:

• Is there a single CO log per project that shows everything in real time, or does the truth live in PMs' email plus accounting plus spreadsheets?
• Is CO aging tracked as a real-time report, broken down by project and by pattern?
• Are notice deadlines tracked automatically, with alerts before the deadline expires?
• When the work is performed before the CO is formally approved, is the work-performed timestamp captured so the negotiating position doesn't deteriorate?
• Can you promote an RFI response into a CO without re-typing the scope?
• Does CO approval automatically update the SOV, the budget, and the schedule end-date?
• At any moment, can you produce a CO statement that ties to your AR and (ideally) to the GC's payable?

If most answers are "informally, with workarounds" — that's the gap AOS closes.

If you'd like to see it

We're in private-beta design-partner mode for mid-market subs and GCs. If you'd like to walk through how AOS handles CO management on a real project — particularly one with substantial CO volume or active CO aging — apply to the beta.