Change Order Request (COR)

Definition — what it is

A change order request is the contractor's formal submission asking the owner to execute a modification to the contract price, time, or scope. It packages the priced proposal, the cause and entitlement basis, the cost breakdown, the schedule impact, and the supporting backup into a single document that the owner is contractually obligated to review and respond to within a defined window. A COR is not a change order and does not amend the contract by itself; it is the demand that precedes the bilateral agreement. In practice the terms PCO and COR are often used interchangeably, but the distinction that matters is functional: the PCO is the internal pricing exercise, while the COR is the formal, transmitted request that starts the owner's contractual review clock and preserves the contractor's position on the record.

Also known as: Change Order Proposal Request, Request for Change Order, Proposal Request Response, COR

Why it matters — what it protects

The COR is the document that converts internal pricing into a contractual demand. Until a change is formally requested in writing through the channel the contract specifies, the owner has no obligation to respond and no clock is running. The act of formally submitting a COR is what transforms a conversation about extra work into an enforceable request the owner must address, which is why sloppy or informal change requests routinely go unanswered for months with no recourse.

It is the packaging that determines whether entitlement survives review. A COR that arrives with a clear scope statement, the causing document, a defensible cost breakdown, and a schedule analysis gets reviewed on its merits; one that arrives as a bare number with no backup gets set aside or negotiated to nothing. The completeness of the package is often more decisive than the merits of the underlying change.

It protects the schedule clock. Most contracts require the owner to accept, reject, or direct within a set number of days of receiving a COR, and the failure to respond can itself become a source of delay and a basis for a claim. Tracking COR submission dates and response deadlines is how contractors hold owners to the contractual timeline instead of absorbing indefinite silence.

The COR log is the audit trail of the entire change relationship on a project. In any dispute, it shows what was requested, when, in what amount, and how the owner responded — and a pattern of unanswered or arbitrarily rejected CORs is powerful evidence in a claim. The log is not just administrative hygiene; it is the contemporaneous record that decides who prevails when the project ends in disagreement.

Lifecycle — how it moves

1. Assembly from PCO

   The priced PCO, its basis of estimate, the causing document, and the schedule analysis are packaged into a single COR. Missing backup is the most common reason a COR stalls, so assembly is a completeness exercise, not a formality.

2. Entitlement statement

   The COR states why the owner owes the change — the directive, RFI answer, differing condition, or design error that caused it — and references the notice already given. This is the argument the owner's reviewer will test first.

3. Formal submission

   The COR is transmitted through the contractually specified channel, numbered, logged, and dated. The submission date starts the owner's review clock, so it must be recorded precisely.

4. Owner acknowledgment

   The owner or their representative logs receipt. On well-run projects this triggers a review assignment; on poorly run ones the COR disappears into an inbox and aging begins immediately.

5. Review and negotiation

   The owner scrutinizes scope, pricing, markup, and time. Rounds of clarification and repricing are normal, and the contractor's backup is what holds value through this stage.

6. Owner disposition

   The owner accepts (leading to an executed owner change order), rejects with stated reasons, or directs the work to proceed under a construction change directive when price cannot be agreed but the work is needed.

7. Execution or escalation

   Accepted CORs become executed change orders and flow into the schedule of values and billing. Rejected CORs the contractor still believes in escalate toward a formal claim, carrying the COR record as evidence.

8. Reconciliation and closeout

   At closeout, the COR log is reconciled against executed change orders and the contract sum, so that no requested change is left unresolved and the final contract value is defensible.

Anatomy — the data it carries

COR number

Unique identifier linked to the source PCO and change event, and forward to the resulting change order, keeping the whole chain traceable.

Title and scope statement

A precise description of the requested change. The clarity of this statement determines what the owner is actually agreeing to when they execute.

Entitlement basis

The document or condition that justifies the change — directive, RFI, ASI, differing condition — plus reference to the notice given. The owner's first line of challenge.

Cost summary and breakdown

The requested amount with the direct-cost detail and markup behind it. A summary with no breakdown invites rejection or open-ended negotiation.

Basis of estimate

Assumptions, quantities, productivity, and quotes supporting the price. The attachment that defends the value when the owner pushes back.

Schedule impact and time requested

Days of extension sought and the supporting analysis. Omitting it is treated as a waiver of the time extension.

Pricing method

Lump sum, unit price, or time-and-material with a cap. Sets how the change will be measured and paid and how risk is shared.

Backup attachments

Quotes, marked drawings, photos, the causing document, and any prior notice — the evidence package the owner reviews.

Submission and required-response dates

When it was submitted and by when the contract requires a response. The pair of dates that lets you enforce the owner's contractual clock.

Owner reviewer and status

Who on the owner side holds it and its state — submitted, in review, in negotiation, executed, rejected, or directed under a CCD.

Response and reason

The owner's disposition and, if rejected, the stated reasons — critical evidence if the change later becomes a claim.

Linked change order

The executed owner change order the COR became, closing the loop between request and contract amendment.

Failure modes — how it breaks

Informal request, no contractual clock

The change is raised in an email or a meeting rather than submitted as a formal COR through the contractual channel. The owner has no obligation to respond, no review clock runs, and months later the contractor discovers it never actually made a request the contract recognizes.

Incomplete package

The COR arrives with a number but no basis of estimate, no causing document, and no schedule analysis. The owner sets it aside pending backup, and the aging clock the contractor thought it started never really began because the submission was never complete.

Weak entitlement statement

The COR asks for money without clearly stating why the owner owes it. The reviewer cannot connect the change to a directive or a document, defaults to rejecting or deferring, and the contractor is left arguing entitlement it should have established up front.

Response deadline never enforced

The contract gives the owner 21 days to respond and the owner takes 120, but nobody tracks the deadline or asserts the contractor's rights. The silence becomes normalized, and the delay that silence caused is never claimed.

Rejection accepted without documentation

The owner rejects a COR verbally or with a vague reason, and the contractor drops it. Without a documented rejection and a preserved position, a legitimate change with real entitlement quietly dies with no path to a claim.

Log drifts out of sync with the contract sum

Executed CORs are not reconciled against the schedule of values and the contract sum, so the billing, the change log, and the contract value diverge. At closeout, nobody can prove what the contract is actually worth.

Metrics — how it is measured

Submission-to-response cycle time

Days from formal submission to owner disposition, measured against the contractual response window. The core accountability metric on the owner side.

Overdue COR count and value

CORs past their contractual response deadline, counted and totaled. Quantifies owner non-responsiveness and supports a delay argument.

Approval rate

Share of submitted CORs the owner executes. Low rates indicate weak entitlement, weak packaging, or an owner disputing valid changes.

Value realization

Executed value as a share of requested value. Reveals how much survives negotiation and thus the strength of the backup.

Package completeness rate

Share of CORs submitted with full backup on first submission. Measures the contractor's own discipline and predicts cycle time.

Rejection-to-claim conversion

Share of rejected CORs that escalate to formal claims. High conversion signals a contentious owner or an entitlement problem in the contractor's approach.

Log-to-contract reconciliation variance

Difference between executed CORs and the adjusted contract sum. Should be zero; any variance is a billing or record-keeping error.

The AI shift — what actually changes

Conversational

The COR log becomes something you question. You ask which CORs are past the owner's contractual response deadline, which were rejected without a documented reason, and where the executed CORs no longer reconcile to the contract sum — with each answer tied to the transmittal and response records, so owner non-responsiveness and record drift both stop hiding.

Generative

From a priced PCO and its source records, a model assembles the full COR: a precise scope statement, an entitlement narrative that connects the change to its causing document and prior notice, the cost summary with breakdown, the schedule analysis, and the transmittal — a submission-ready package rather than a raw number the contractor still has to justify later.

Orchestrated

The COR stops being a loose transmittal. On submission the response deadline is calculated from the contract and tracked, backup completeness is checked before it goes out, executed CORs flow into the schedule of values and reconcile against the contract sum, and rejections are captured with their reasons so the path to a claim stays intact.

Autonomous

The routine motion runs inside guardrails: CORs are assembled from priced PCOs, completeness is verified before submission, response deadlines are monitored with escalations, and log-to-contract reconciliation runs continuously. Humans always approve the entitlement argument, the price, and the decision to escalate a rejection into a claim.

Prompts — put it to work

Tool-agnostic and copy-ready. Adapt the specifics — thresholds, contract windows, cost codes — to your own project before you run them.

Conversational — The owner has gone quiet on your changes and you need to quantify it before a project meeting.

Review our COR log against the contract's 21-day response requirement. List every COR past its response deadline with the number, scope, requested value, submission date, days overdue, and owner reviewer. Total the overdue value. Then flag any COR that was rejected without a documented reason, and any executed COR that does not reconcile to our current schedule of values. Rank the overdue items by dollars at risk and tell me the aggregate delay the owner's non-response has caused if these are on the critical path.

What good output looks like: An aged overdue summary tied to the contractual response clause, with rejected-without-reason items and reconciliation gaps flagged — evidence of owner non-responsiveness, not just a status list.

Follow-ups:

• Draft a formal notice to the owner citing the overdue CORs and the contractual response clause.
• Which overdue CORs are blocking work in the field right now?
• Which rejected CORs have strong enough entitlement to escalate to a claim?

Generative — A PCO is priced and approved internally and you need the COR packaged for formal submission.

Assemble a formal change order request from this approved PCO. Scope: added heavier-gauge framing at level 4 per RFI 88, priced at the attached amount with the basis of estimate. Write a precise scope statement, an entitlement narrative that connects the change to RFI 88 and to the notice we issued on the change event, a cost summary that references the attached breakdown, the requested time extension with reference to the schedule analysis, and a professional transmittal that cites the contract's 21-day response requirement and lists every attachment in the backup package. Keep the tone factual and firm, not adversarial.

What good output looks like: A submission-ready COR with a clear scope statement, a documented entitlement narrative, a complete backup index, and the contractual response clause cited — not a bare number with a subject line.

Follow-ups:

• Rewrite the entitlement narrative to preempt an owner claim that this was always our scope.
• Produce the backup-package index the owner's reviewer will expect.
• Draft the cover note to our own project executive summarizing the ask and the risk.

Orchestrated — You just executed a batch of change orders and need billing and the contract sum to stay true.

Reconcile our executed CORs against the schedule of values and the contract sum. For each executed COR, confirm the value posted to the SOV matches the executed amount, the correct cost codes were used, and the adjusted contract sum reflects it. Identify any executed COR not yet reflected in the SOV, any SOV line that does not trace to an executed COR, and any variance between the sum of executed changes and the adjusted contract value. Return a reconciliation report with each discrepancy tied to the specific records, and flag anything you cannot resolve rather than forcing a match.

What good output looks like: A clean reconciliation between executed CORs, the SOV, and the contract sum, with every discrepancy identified and traced — so billing and contract value never diverge.

Follow-ups:

• Draft the SOV revision to post the missing executed CORs.
• Which discrepancies affect our next pay application?
• Confirm nothing we billed is unsupported by an executed change.

Autonomous — Standing policy for running the COR pipeline and holding the owner to the contract clock.

Manage our COR pipeline continuously under these rules. Assemble CORs from internally approved PCOs, verify each package is complete — scope statement, entitlement basis, cost breakdown, schedule analysis, and backup index — before it is cleared for submission, and never let an incomplete COR go out. On submission, calculate and track the owner's contractual response deadline; escalate overdue CORs to the project manager at the deadline and to the project executive 14 days past it, and maintain a running total of overdue value. Reconcile executed CORs against the SOV and contract sum continuously and surface any variance. Never finalize an entitlement argument, never set price, never submit without my clearance, and never escalate a rejection into a claim without my decision. Give me an exception queue, not the full log.

What good output looks like: A managed pipeline where completeness checks, deadline tracking, and reconciliation run automatically, while entitlement arguments, pricing, submission clearance, and claim escalation stay with a human.

Follow-ups:

• Show what you assembled, what you flagged as incomplete, and what you escalated this week.
• What is our total overdue value and the oldest unanswered COR?
• Which reconciliation variances remain unresolved?

Get the full Construction AI Prompt Catalog — every prompt in the library in one document.

Maturity — locate yourself honestly

0. Level 0 — Informal

   Changes are requested by email or verbally with no formal COR, no contractual clock, and no reliable record of what was asked or answered.

1. Level 1 — Logged

   A COR register tracks numbers, values, submission dates, and statuses. Packaging quality and deadline enforcement are inconsistent.

2. Level 2 — Linked

   CORs trace back to PCOs and change events and forward to executed change orders, response deadlines are calculated from the contract, and executed CORs reconcile to the SOV.

3. Level 3 — Assisted

   COR packages are assembled from PCOs with completeness checks, entitlement narratives are drafted for review, overdue items are surfaced, and reconciliation is generated automatically.

4. Level 4 — Operated

   Assembly, completeness verification, deadline monitoring, and reconciliation run unattended inside guardrails, while humans own entitlement arguments, pricing, submission clearance, and claim escalation.

Common questions

Are a COR and a PCO the same thing?

They overlap and the terms are often used interchangeably, but the useful distinction is functional. The PCO is the internal pricing exercise that quantifies a change; the COR is the formal, transmitted request that packages that pricing with its entitlement basis and backup and starts the owner's contractual review clock. On many projects one document serves both roles, but treating the formal submission as a deliberate act is what preserves your contractual position.

What happens if the owner never responds to a COR?

If the contract sets a response window, the owner's silence past that window is itself a breach that can support a delay claim and, on some contracts, a right to proceed. The key is to track the deadline, formally notice the owner when it passes, and document the non-response — because silence that is never challenged tends to be read later as if the contractor did not really consider the change important.

Should we start work before a COR is executed?

Not on the strength of an unexecuted COR alone. If the schedule forces the work forward, obtain a written directive to proceed, typically a construction change directive, which authorizes the work while price and time are still being resolved. Performing changed work with only an open COR means the owner can later dispute both scope and price after the money is already spent.