Esc

↑↓ move↵ openIndex · Pagefind
Concepts / Change events and potential change orders

Change events and potential change orders

How a possible change is captured as a change event, priced as a potential change order, submitted and approved, and how exposure is tracked before anything is signed.

On this page

A signed change order is the end of a story. The change event is the beginning. This page explains how the app tracks a change from the moment it is found, so exposure is visible on the job long before a signature. For the signed side, see Commitments and change orders.

The lifecycle

Different contracts and tools use different names. The app keeps each stage as its own linked record (change event, potential change order, change order request, change order package), so the history of each stage is kept and nothing is retyped. How many of those stages you use is a project setting: one, two or three tiers. See Change events and change orders for the screens.

EventPricedSubmittedApprovedBilledrough estimatePCOCOR to ownerCO signedon pay app
One change, five stages. Each stage links to the one before.
Stage Common names What’s known
Event Change event, issue, potential change Something happened. Rough estimate at best
Priced Potential change order (PCO) Cost and revenue estimated, sub quotes attached
Submitted Change order request (COR), proposal Sent to the owner, waiting
Approved Change order (CO), or construction change directive (CCD) Contract changed. Billable
Billed SOV line on a pay app On the G703

A change can also be rejected or voided at any stage. Rejected changes stay on record, which matters if the cost was already incurred.

Where change events come from

A change event can come from any of these. In the app, an RFI can be set as the event’s Origin RFI; for the others, describe the source in the event’s reason and attach the record:

  • A daily log or photo showing a hidden condition.
  • An RFI answer that adds or changes scope.
  • A submittal returned with changes.
  • An owner direction, verbal or written.
  • A drawing revision or bulletin.
  • A sub’s notice of a change on their scope.

The person who finds it does not need to price it. A super can flag a condition; a PM decides whether it’s a change.

Following RFI-212

  1. Event opened from the daily log

    The super logs missing fire dampers in the L3 corridor with photos. The PM opens a change event with a rough order of magnitude (ROM) by cost code.

  2. Linked to RFI-212

    The question goes to the design team as RFI-212, set as the change event’s origin. The answer confirms added scope.

  3. Priced

    The mechanical sub prices it through an RFQ sent from the change event. A PCO on the prime contract is created from the change event, and its grand total includes your markup: $86,400 on the revenue side. A second PCO from the same event, on the mechanical subcontract, carries the cost side by cost code.

  4. Submitted

    The PCO is submitted for review, on its own or grouped into a change order package (through a change order request if the project uses three tiers), with the photos, RFI and quote attached.

  5. Approved as CO #14

    The owner signs and the package is executed as CO #14. The approved owner change order updates the prime contract, the change on the subcontract updates the sub’s contract, and the change event posts its budget change when it is closed.

Cost side and revenue side

Every change record has two sides:

  • Revenue: what you expect the owner to pay, through a prime contract change.
  • Cost: what you expect to spend, by cost code, including the commitment changes to subs and suppliers. See Subcontracts and commitment changes.

The difference is the margin on the change. Keeping both sides on one change event means a change where cost is known but revenue is disputed shows up as what it is: exposure.

Exposure views (Planned)

Planned: every job shows its change exposure at a glance. Today, the Change Events and Change Orders lists filter by status, and the budget keeps pending and approved changes in separate columns.

View Shows
Open events Unpriced changes, with rough estimates and age
Pending Priced and submitted, waiting on the owner
Cost ahead of approval Costs already posted against changes that aren’t approved
Approved, not billed Signed changes not yet on a pay app

Pending and potential changes can feed the forecast according to your company’s policy: signed only, or including expected changes. How unapproved changes are treated for revenue recognition is an accounting policy decision your team and CPA set. Applying your policy to the forecast automatically is Planned; the app won’t choose the policy for you.

Agents and change events

RFI and Risk agents that suggest change events and flag aging pending changes are Planned. When they ship, a person will approve every action. See How agents work.

Keep exploring

Related across os.construction

Run it on your own project.

Start a 14-day free trial. Want a say in what ships next? Join the founding program.

Your role (optional)

14-day free trial. Pricing for paid plans isn't set yet. Talk to us. Already have an account? Sign in →

Ask the OS

Reading this page

Ask anything about this page. Answers use what you're reading as context.

Suggested

    AI · may be imperfect · sample data where shown

    Open file