The change order log a subcontractor actually needs

You are about to open a spreadsheet, type “CO Log” in A1, and start inventing columns. Everybody does. It is the right instinct and it usually produces a log that can’t answer the one question you built it for.

Here is the version worth building, the two numbers it exists to produce, and an honest account of where it breaks.

What a change order log is for

Not record-keeping. Your change orders are already the record.

A log exists to answer two questions, on demand, without anybody opening a folder:

1. How much unapproved money are we carrying right now?
2. Which items are stuck, and who is sitting on them?

Every column either serves one of those or it’s decoration. That test alone will cut your spreadsheet in half.

The eleven columns that earn their place

1. Your number

Your own sequence — CO-014, COR-07, whatever — assigned the moment the item is identified, not when it’s priced. Two rules, both learned the hard way:

Never reuse a number. If CO-009 gets voided, CO-009 stays voided forever. The next item is CO-010.

Never renumber. It feels tidy. It destroys every email, ticket and pay app that referenced the old number.

2. The GC’s number

The GC has their own log and their own reference, and it will not match yours. Capture theirs in its own column the first time you see it. This single column prevents more confused phone calls than anything else on the sheet.

3. Date identified

The date the condition was discovered — not the date you priced it, and not the date you submitted. It is usually the date a notice clause runs from — check what yours says — so it’s the cell that matters most later.

4. Date submitted

Blank until it goes out. The gap between columns 3 and 4 is your office’s own performance, and it’s worth looking at.

5. A description someone else can read

One line, specific, written for a stranger. “Added circuits” is useless. “Four added 20A circuits for owner FF&E, Level 3 east, per ASI-11” is a description that survives six months and three personnel changes.

6. Location

Grid line, room number, unit, elevation — whatever your drawings call it. A location you can point to is a location nobody argues about.

7. Type: lump sum, T&M, or unit price

How the item is being priced, agreed before the work starts where you can manage it. This column also tells you how much of your pending exposure is open-ended, which is a different kind of risk from a fixed number.

8. Amount requested

What you asked for. Keep it exactly as submitted, even after you revise — put the revision in its own row or its own column, and never quietly overwrite the original. Overwritten numbers are how a log loses the trust of the person reading it.

9. Status

Plain words, from a fixed list. Don’t improvise per row:

identified · priced · submitted · GC reviewing · owner reviewing · approved · rejected · voided

10. Date of the current status

Not a history — just when the item entered the status it’s in. One date, so you can calculate age with subtraction. This is the column most logs leave out, and without it the log cannot do half its job.

11. Who owes the next move

One cell, one name, two possibilities: us or them. If it’s us, what we owe — a revised breakdown, backup, a signature. If it’s them, who and since when.

Fill that column for every open row and the weekly meeting changes character. You stop reading a list of worries and start reading a list of actions.

The three columns to add once it’s approved

Approved amount (which is not always the amount requested), the SOV line it was added to, and billed to date. Without these three, your log tells you that you won and never tells you whether you got paid. Change orders approved in month four and first billed in month seven are depressingly common, and that gap lives in exactly this blind spot.

The columns to leave out

• A long notes field. It becomes a diary nobody reads, and the real evidence — tickets, photos, the RFI number — isn’t in it anyway.
• Percent likelihood of approval. Invented numbers, averaged into a forecast, is a worse decision input than no number.
• Anything you’d have to retype from another system. Contract value, cost codes, labor hours. If it lives somewhere else, every copy is a future discrepancy.
• Color as the only status. A row that is “yellow” doesn’t sort, doesn’t filter and doesn’t survive being printed.

The two numbers, finally

With those columns you can produce the only two outputs that matter.

Pending exposure. Sum column 8 for every row that isn’t approved, rejected or voided. That is work you have performed or committed to perform that nobody has agreed to pay for. Put it next to your contract value and you have the single most useful ratio in a sub’s month-end: if pending exposure is running at a serious fraction of the contract, the job is not what your billing says it is.

Aging by owner. Sort open rows by column 10, oldest first, and split by column 11. Two lists. The “us” list is a to-do list you can clear this week. The “them” list is your follow-up call sheet, in priority order, with the exact number of days you’ve been waiting sitting right there in the row.

That’s the whole report. Two numbers, fifteen minutes a week, and nothing sits for fifty-one days without anybody noticing.

Four ways a spreadsheet log fails anyway

Build it well and it will still do these things, because they’re properties of the format rather than the design.

It’s a second copy. Every number in it already exists in a change order, a ticket or an email. Copies drift. The day your log and your pay app disagree, you find out which one the GC believes, and it isn’t the spreadsheet.

The evidence isn’t attached. The log says CO-014, $8,420, submitted 12 Aug. The signed ticket, the three photos and the ASI are in a folder, an inbox and somebody’s phone. When the GC pushes back, you spend an afternoon reassembling a package you already assembled once.

It doesn’t tie to the schedule of values. Approved change orders have to land on the SOV to be billable. A log that lives in a separate file has no mechanism to make that happen — only a person who remembers.

One person maintains it. Usually the best person in your office. When they’re on vacation, the log stops being true, and nobody downstream can tell.

What it should become

The pattern worth aiming at: the log stops being a document and becomes a view.

If each change order already carries its own status, its own dates, the amount requested, the tickets and photos behind it and the SOV line it landed on, then “the log” is just those records sorted by age. There’s nothing to maintain, nothing to retype, and no version of the truth that can drift from the other version.

That’s how SubMark does it. A change event gets logged from the field with photos the day it happens. If the work runs on time and material, it becomes a T&M tag priced off your own rate lists and signed on the spot — and a month of signed tags converts into one change order instead of eleven. Each change order tracks its status, how long since it was submitted and what you asked for, with every line traced to the signed T&M tag it came from. When one is approved it’s added to your schedule of values automatically, so it’s a billable line before the next draw.

Pending exposure and aging are then a screen, up to date, for anyone in your office who opens it.

The change order management page sets out the stages a request moves through and how the aging report reads off them, which is the part a log is really trying to reproduce.

See the change order and billing side of the product, or look at the pricing — foremen and field crews are free and unlimited, so the people logging changes in the field never cost you a seat.

If you still want the spreadsheet

Reasonable. It’s free and it works at low volume. Build it with the eleven columns above, add the three approval columns, use a fixed status list, and put the age formula in once so nobody has to count days by hand.

Then set a recurring fifteen minutes on a Tuesday to walk the whole thing. The log isn’t the discipline. The pass over it is.

Next: the full change order process from the sub’s side, which is where the log fits in the first place.