PCO vs CO — what's the difference

The cost-recovery side of change management has two distinct documents. Confusing them leads to billing rejections, audit findings, and AR that ages out of acceptable ranges.

PCO — Proposed (or Pending) Change Order

Your priced proposal to the GC for the cost and time impact of a change. PCO contents:

• Reference back to the Change Event(s) it bundles
• Itemized labor (hours × rate, by classification)
• Material (qty × unit cost, by SKU/line)
• Equipment (owned + rented)
• Subcontractor / second-tier sub costs
• Markup per contract terms (typically 10% OH + 5% profit or per CSI Section 01)
• Schedule impact (working days, with notice/justification)
• Backup documentation: T&M tags, RFI references, photos, quotes

A PCO can be accepted, rejected, negotiated, or held. Until one of those happens, the work performed under the underlying Change Event is at-risk — you can perform it (often you must, to keep the job moving), but you cannot bill for it.

In STrOp: /projects/[id]/changes → PCO tab. Status: draft → submitted → under-review → accepted / rejected / negotiating.

CO — Change Order

The executed contract amendment between you and the GC that incorporates one or more accepted PCOs (or a unilateral directive from the owner). A CO:

• Has a unique number issued by the GC's contract
• Is signed by both parties (or unilaterally per contract terms)
• Adjusts the contract value and/or time
• Adjusts the SOV — new line items or revisions to existing ones

Only work covered by an executed CO is billable on a pay app. Work performed under an open PCO is "in process" and lives in your Change Event backlog, not on the pay app.

In STrOp: /projects/[id]/changes → CO tab. Status: pending-execution → executed → voided.

The flow

Change Event  →  PCO (priced ask)  →  CO (executed)  →  SOV line  →  pay app

Each arrow has a typical lag:

• Change Event → PCO: hours to days (quantification time)
• PCO → CO: days to months (GC review, owner approval, often the slowest)
• CO → SOV line: same day (STrOp does this automatically when a CO is executed)
• SOV line → pay app: next billing cycle

What STrOp does automatically

• When a PCO is marked executed as CO, the system:
  1. Creates a new SOV line item with the CO value and number
  2. Updates the project contract value
  3. Flags the underlying Change Events as "closed — included in CO #X"
• The pay app billing screen filters available SOV lines to executed COs only — you can't accidentally bill against a pending PCO.

Common failure modes

• Billing a PCO. Pay app rejected by the GC; aging starts over once you resubmit. Often discovered weeks later.
• CO executed but never reflected in the SOV. Pre-STrOp manual error — caught now by the auto-create flow.
• Lump-sum CO covering multiple PCOs. The GC executes one CO that bundles 4 PCOs. STrOp lets you link multiple PCOs to a single CO so the trail stays intact.
• Unilateral change directives treated as accepted PCOs. A directive is not an acceptance. The PCO stays "submitted" until the CO is signed; bill at risk.

See also

• RFI vs Change Event
• T&M tag — owner signature
• Pay app submission checklist