On this page
Every contractor knows change orders are where margin is made or lost. Fewer have traced a single one end to end and counted how many times a person retypes the same facts along the way.
So let’s do that. Below is one change order, followed through six systems that a typical mid-size general contractor might run. The project and numbers are illustrative, drawn from the sample job we use across this site, but the path will look familiar to anyone who has sat in a project accountant’s chair.
Stop 1: The field app
During ceiling rough-in on level 3, the superintendent notices that ductwork passes through a rated corridor wall with no fire damper, though the life-safety plan calls for one at every rated penetration. It’s a coordination gap between the architectural and mechanical drawings.
The super logs it in the field app: location, gridlines, photos, a short note. Facts entered: once. So far so good.
Stop 2: The PM platform
The project engineer sees the daily log (or gets a text with a photo, which is more likely) and opens RFI-212 in the PM platform. They retype the description, re-attach the photos, add the drawing references and send it to the design team.
Re-key #1. The design team answers: add fire dampers at the affected penetrations. Work that wasn’t in the contract is now required. That’s a change order.
Stop 3: The estimate spreadsheet
The PM asks the mechanical sub for a price. The sub sends a PDF quote. The PM builds the change order pricing in a spreadsheet, typing the sub’s number in from the PDF and adding the GC’s own costs and markups:
| Line | Amount |
|---|---|
| Mechanical subcontractor quote | $70,000 |
| GC supervision and general conditions | $8,000 |
| Subtotal | $78,000 |
| Fee (10%) | $7,800 |
| Bond and insurance | $600 |
| Change order total | $86,400 |
Re-key #2. If the sub revises the quote after a scope clarification, the spreadsheet has to be updated by hand, and now there are two versions of the PDF in two inboxes.
Stop 4: Email and e-signature
The PM copies the numbers from the spreadsheet into a change order request document, built from a word-processor template, and emails it to the owner’s rep. A week of back-and-forth happens in an email thread. The owner approves it, and it becomes CO #14 for $86,400.
Re-key #3. The approved amount now lives in a signed PDF, the owner’s CO log and the PM’s email. The PM platform gets updated when someone remembers.
Stop 5: The accounting system
The project accountant gets the signed CO and makes three separate entries in the accounting system:
- A prime contract change: contract value goes up by $86,400.
- A budget revision: $70,000 to the HVAC cost code, $8,000 to general conditions, with the fee left as margin.
- A subcontract change order to the mechanical sub, so their commitment covers the added work.
Re-keys #4 and #5. The third entry is the one that gets missed. When it does, the sub’s next invoice exceeds their remaining commitment. AP flags it and the payment stalls, or AP doesn’t flag it and the overage gets paid without backup. It’s the same pattern as an invoice like INV-4471 landing $6,150 over what’s left on PO-118: not fraud, just a commitment that never caught up with an approved change.
Stop 6: The billing spreadsheet and the WIP
To get paid, CO #14 needs a line on the schedule of values so it can appear on the AIA G703 continuation sheet for Pay App #9. Someone adds the line in the billing spreadsheet. Re-key #6.
At month end, whoever builds the WIP schedule updates the revised contract value and the estimated cost for the job. Re-key #7.
Tallying it up
| Stop | System | What got retyped | What can go wrong |
|---|---|---|---|
| 2 | PM platform | Condition, location, photos | Detail lost between log and RFI |
| 3 | Spreadsheet | Sub quote | Stale quote version |
| 4 | Document + email | CO amount and scope | Negotiated number never makes it back |
| 5 | Accounting | Contract, budget, commitment | Subcontract CO missed, invoice over commitment |
| 6 | Billing + WIP | SOV line, revised contract | CO approved but not billed |
Seven retypes of facts that were already known. And this is the clean version: one CO, no disputes, no partial approvals, no time-and-material tickets.
The typing is the cheap part
It’s easy to price re-keying as labor. We’ll give you the formula rather than an industry average, because we haven’t seen one we trust:
annual cost = change orders per year × retypes per CO × minutes per retype × loaded hourly rate
With round, made-up inputs (200 COs a year, 7 retypes each, 15 minutes per retype, $60 an hour loaded), that’s 350 hours and $21,000 a year. Real money, but not the number that should keep a CFO up at night. The expensive failures are the ones the typing causes:
- Cash latency. If CO #14 misses the pay app cutoff because the SOV line wasn’t added in time, you finance $86,400 of work for another billing cycle. On monthly billing, that’s usually a month or more.
- Disagreement. The owner’s CO log, your PM platform and your accounting system show three different approved totals. Somebody reconciles them at closeout, when memories are short and leverage is gone.
- Margin blindness. If the budget revision isn’t posted, the HVAC cost code looks like it’s overrunning when the overrun is actually covered by an approved change. Or the opposite: costs spent against a pending CO look covered when they’re still at risk.
- Sub friction. A commitment that doesn’t match the approved scope delays a sub’s payment, and subs remember who pays slowly.
- The CO that never gets billed. Every controller has a story about one. It’s the full amount, not 15 minutes.
What one record looks like
Here’s the same story the way we’re designing it in os.construction. This is product direction, not a shipped feature: we’re pre-launch and building it with founding contractors.
The super’s log creates a field issue with location and photos. The project engineer turns it into RFI-212 in one step, with the same photos and the same location, nothing retyped. When the design team answers, a potential change order is created from the RFI. The sub’s quote attaches to that record, and the pricing uses your markup rules. The owner approves it, and that single status change updates the contract value, posts the budget revision, drafts the subcontract change order for the PM to approve, and adds the CO line to the schedule of values for the next pay app. WIP and the forecast reflect it immediately, because they read the same record.
The facts were typed once, by the person who saw the problem. Everybody after that added judgment (the answer, the price, the approval), not keystrokes.
That’s the whole argument for an operating system instead of another app. If your change orders take the scenic route, get early access and tell us which stop hurts most.
Share this article