Construction Control — Articles

Change Order Log for T&M Subcontractors: What It Has to Capture

A change order log is the running register of every change order on a job: what was asked for, what it is worth, whether it was approved, what paperwork backs it up, and whether it has been billed. For a subcontractor doing time-and-materials (T&M) work, the log is also the bridge between the field and the pay application — every T&M ticket that turns into billable change work should be traceable from the ticket, through the log, onto a pay app line.

Most billing gaps on T&M work are not pricing problems. They are tracking problems: a ticket that was never tied to a change order, an approved change order that never made it onto a pay application, a billed amount that does not match the approved amount. A log that captures the right fields makes those gaps visible while there is still time to correct the current pay period instead of discovering them at job closeout.

This page covers the fields a change order log needs for T&M subcontractors, shows a worked example, and explains how the log is used to reconcile tickets, change orders, and the pay application.

Log, form, and register: three different documents

The terms get mixed up, so here is the distinction this page uses:

• A change order form is the document for one change: description, amount, signatures. One form per change order.
• A change order log (also called a change order register or tracking log) is the running list of all of them — one row per change order, updated as statuses change.
• A T&M ticket is the field record of work performed on a time-and-materials basis: labor, material, equipment, date, and the signature or approval captured in the field.

The form proves one change. The ticket proves the work happened. The log is where the two are tied together and checked against billing. This page is about the log.

The fields a change order log must capture

A log that is only a list of descriptions and amounts cannot be reconciled against anything. For T&M work, each row needs the following fields:

1. COR number. Your internal change order request number, one per change, never reused (for example COR-01, COR-02). Every other document — ticket, form, pay app reference — points back to this number.
2. Date issued. The date the change was identified or requested.
3. Description of the change. Short and specific: what work, where on the job.
4. Linked T&M ticket numbers. The ticket(s) that document the work (for example T-1007). A change order with no ticket behind it, and a ticket with no change order in front of it, are both exceptions to look at.
5. Change amount. The value of the change as submitted.
6. Approval status. Pending, Approved, Rejected, or Void — plus the approved amount if it differs from the submitted amount, and the approval date.
7. Backup on file. Yes or no: is the supporting paperwork actually in the job file — signed ticket, written directive, email confirmation, signed change order form? A verbal go-ahead with nothing written down gets a "no" here until the paper exists.
8. On pay application. Which pay period and which pay app line the change was billed on — or blank if it has not been billed yet.
9. Amount billed to date. What has actually been billed against this change so far.
10. Open item note. Anything unresolved: waiting on a signature, amount in dispute, backup still to collect.

Fields 4, 6, 7, 8, and 9 are the ones most often missing from homemade logs, and they are the fields reconciliation depends on. Without ticket linkage there is no way to check that field work and billed work are the same work. Without approval status and backup, there is no way to check that what was billed was approved. Without the pay app fields, there is no way to check that approved work was billed at all.

A blank change order log template (copy the structure)

You can build this in any spreadsheet. Use one log per project. Do not mix projects in one log. One row per change order; do not delete rows for rejected or void changes — mark the Status instead, so the numbering stays complete. Copy the column headings exactly. Format the date columns as dates and the money columns as currency. Insert new rows above the TOTALS row.

The COR-06 row is the example (its Project / Job cell is blank — the worked example below names no project). Start your own entries in the blank row, and keep the TOTALS row at the bottom. Delete the example row before using the log for a live project, or keep it on a separate example sheet.

Field notes:

• Project / Job: the project or job name or number exactly as on the contract and pay application, same entry on every row; a new log for a new project.
• COR #: your own sequential numbering (COR-01, COR-02, …) in entry order; never reuse a number; never renumber to match someone else's number — if the GC assigns a different number, keep yours and record theirs in Open item note.
• Date identified: the date the change was first identified; enter the row on this date even if other dates are not yet known.
• Date submitted: the date the priced request was sent to the GC; blank until sent.
• Date approved: the date approval was received; blank until received, and blank for a rejected or void change.
• Description: what changed, where the work is, and what work is included, in one line, so a person who did not do the work can match the row to the ticket.
• Linked ticket(s): ticket numbers typed, comma-separated, in ticket order; "None yet" if no ticket exists; append later tickets, never replace an earlier number.
• Amount submitted: the total price on the request as sent — the sum of the linked T&M tickets plus any markup on that request; nothing not on the request. If pricing changes before approval, update to the latest amount sent and add a dated Open item note with the earlier amount marked superseded. After approval, never change it to match Approved amount — the difference must stay visible.
• Status: four values only — Pending, Approved, Rejected, Void; free-text statuses cannot be checked against anything.
• Approved amount: only when approval comes back; never assumed equal to submitted. Blank for Pending, Rejected, Void — never $0 for rejected/void ($0 can be mistaken for an approved amount). Partial approval: enter the amount actually approved, keep Status Approved, explain the difference (and the reason, if given) in Open item note.
• Backup on file: "Yes" + a brief description, or "No". For a T&M change, backup = the signed T&M ticket(s) + the priced change order request + the approval document when received; a ticket alone is not complete backup. When backup is missing, record what is missing in Open item note + Next action / Owner.
• Billed on pay app #s: every application number on which the change has been billed, comma-separated, in order billed; append, never delete or overwrite; blank until the change actually appears on a submitted application — scheduled to bill is not billed.
• Amount billed to date: the cumulative gross amount shown for this change on the submitted application(s), before any retainage deduction; never copied from the change order, never an intended/scheduled amount. If an application is later revised, replace with the revised gross total and add a dated revision note.
• Balance remaining to bill: Approved rows only — Approved amount minus Amount billed to date (set the column to that calculation for Approved rows); blank for Pending/Rejected/Void.
• Open item note: anything still unresolved (missing backup, missing ticket, pending approval, partial-approval difference, a change missing from a pay application, a disputed billed amount). On resolution, clear it to blank — a blank note means nothing is open; do not leave "resolved/done" notes.
• Next action / Owner: the next action + the responsible person or role; blank only when no action is outstanding; clear it with the related Open item note when completed.
• TOTALS row: sums under Amount submitted, Approved amount, Amount billed to date, and Balance remaining to bill; blank cells are not counted as $0. Cross-check: total Approved − total billed = total Balance remaining; if not, find the row causing the difference before the next submission.

Worked example: one job, seven change orders

The register below is fictional. It shows the state of one small T&M job at the end of pay period 3.

Read row by row, four of the seven rows need attention before the next pay application:

• COR-04 is approved and billed, but the only approval is verbal. If the amount is questioned later, the job file holds no written backup.
• COR-05 is still Pending in the log, yet $640 for it was billed on pay application 3. Either the approval arrived and the log was not updated, or work was billed before approval. Both need an answer; the log and the pay app disagree.
• COR-06 is the expensive one. The work was ticketed (T-1007), priced at $1,700, approved, and backed up — and then never placed on a pay application. Nothing about the row looks wrong until the "Billed on pay app #" column is read against the approval: approved work, documented work, unbilled work.
• COR-07 was billed at the submitted $510 instead of the approved $450. Small amount, same failure type: billed does not equal approved.

COR-03 shows the opposite discipline: it is pending, and it is correctly not billed. Pending is a normal state; pending and billed at the same time is the exception.

How the log connects to reconciliation

Reconciliation is the comparison of three records that should agree: the T&M tickets (work performed), the change order log (work approved), and the pay application (work billed). The log is the middle record, and it is the one that lets the other two be compared line by line instead of from memory at closeout.

Working from the log, the manual comparison for each pay period is:

1. Every ticket accounted for. Walk the period's tickets and confirm each one is linked to a log row or is base-contract work. A ticket with no log row and no contract home is an unlinked ticket.
2. No ticket counted twice. The same ticket number appearing on two different log rows means the same work may be billed under two changes.
3. Every row complete. A log row missing its amount, status, or ticket link cannot be checked — the missing field is itself the finding.
4. Approved means documented. For each Approved row, confirm backup is marked Yes. Approved with no backup is an exposure, not a clerical detail.
5. Pending means consistent. Compare the log's Pending rows against what the GC or owner shows as pending. A change one side shows as approved and the other as pending is a mismatch to resolve before billing, not after.
6. Approved means billed. For each Approved row past its first available pay period, confirm a pay app number and a billed amount are recorded. An approved, backed-up row with a blank billing column — COR-06 in the example above — is approved work missing from the pay application.
7. Billed equals approved. For each billed row, compare amount billed to date against the approved amount, not the submitted amount. COR-07 is the pattern: the difference is small and easy to wave past, and it is still a difference.

Those seven comparisons are the whole method. Done on paper or in a plain spreadsheet, they take a careful pass through the register each pay period. Done consistently, they turn "we think everything got billed" into a row-by-row answer.

What a log does not do

A change order log is a tracking record, not an approval system and not a billing system. It does not:

• create approvals — a row marked Approved should reflect an approval that exists in writing somewhere in the job file;
• replace the GC's or owner's own change order forms, which may still be required for each change;
• prepare lien waivers, certified payroll, or any other compliance documents;
• set or track contractual notice deadlines — if your contract requires written notice within a set number of days, that clock lives in the contract, not in this log.

If you want the seven comparisons done by formula

The manual method above is free and complete as a method. The repetitive part is the comparing: the same seven checks, run over every row, every pay period.

Our workbook, Construction Control, runs those same seven comparisons as formula checks. You paste your tickets, change orders, and schedule-of-values records into the workbook using four supplied CSV templates (tickets, change orders, SOV main, SOV retainage) — there is no importer, and nothing about the entry is automated — and its 528 formulas run seven checks: EX-01 Duplicate Tickets, EX-02 Missing Fields, EX-03 Unlinked Tickets, EX-04 COR Without Backup, EX-05 Pending COR Mismatch, EX-06 Missing from Pay App, and EX-07 Billed ≠ Approved. Each pasted record that fails a check is flagged on its own sheet, and the flags are gathered in an Exception Report — a summary table showing the count and signed amount per check. The workbook runs the checks and produces the exception list; the human reconciles.

Facts, plainly: the workbook is $39. It requires desktop Excel and is macro-free. All sales are final; no refunds. It runs the seven checks above and no others — it does not handle lien waivers, payroll, GC-specific forms, deadlines, or tie-outs between AIA G702 and G703 forms.

Start smaller if you prefer: the same seven checks are listed in a free one-page checklist on this site — a direct download, no purchase. The checklist runs no checks itself; it is the manual pass on paper, so you can work your current register by hand first and see which exceptions turn up.

Keeping the log alive

A change order log only works if it is updated when things happen, not reconstructed at billing time. Update the row on the day the event happens, using the submitted document itself, not what was intended.

Enter the row the day the change is identified: Project / Job, COR #, Date identified, Description, Status Pending. If a ticket exists, type its number in Linked ticket(s) the same day; if none, enter "None yet" and record the missing ticket in Open item note + Next action / Owner.

Field handoff: the field lead gives the signed ticket to billing on the day the ticket is signed; billing enters or updates the row that same day. A ticket left on a desk is not an entry in the log, and a row entered without its ticket number cannot be matched to the work later.

Approval or rejection: on the day the decision comes back, update Status — and for an approval, Approved amount + Date approved the same day. For a rejection, leave Approved amount and Date approved blank and write the rejection date in Open item note. Do not renumber. If the GC's number differs, keep your COR # and add theirs to Open item note. If a COR # was typed in error, correct the cell and keep the old number + correction date in Open item note so the row can still be traced. Never delete the row; never reuse its number.

Revised pricing: update Amount submitted the day the revised request is sent, with the dated superseded-amount note; never create a second row for the same change.

Pay application: after EVERY submission, including a partially billed change, update Billed on pay app #s, Amount billed to date, and Balance remaining to bill from the submitted application itself. Append the new number; never overwrite. Amount billed to date = the new cumulative gross total, before retainage. If an application is later revised, replace with the revised gross total + a dated revision note.

Backup and open items: when backup arrives, change Backup on file from No to Yes with its description and clear the related Open item note + Next action / Owner. When an open item is resolved for any reason, clear both on the day it is resolved — a note or action left in place hides the items still genuinely open.

Billing-cycle tie-out and chase: at the end of each billing cycle, after submission, tie the log to that application — check every Approved row (pay app #s, billed to date, balance), flag any Approved row missing from the application in Open item note (as in the COR-06 example), and check the TOTALS row. At the same tie-out, follow up every change still Pending that was already Pending at the previous tie-out; update Next action / Owner; Status stays Pending until a decision actually comes back.

If an update is missed:

• Row not entered the day identified → no number, ticket can sit unfiled, work can be done and never priced or billed.
• Ticket number not typed / backup not filed → work cannot be matched to its ticket; the GC can dispute the T&M hours or materials even when the work was done.
• Status/Approved amount/Date approved not updated the decision day → approved work looks pending and is left off the pay application; rejected work looks pending and can be billed in error.
• Pay-app columns not updated after a submission → billed total and balance wrong; approved work can be billed twice or missed entirely (the COR-06 example).
• Backup not recorded when it arrives → the log shows No; the next person searches for backup that exists; a disputed change has no proof on file in the log.
• Open item note / Next action not cleared → closed items look open; real open items are harder to see; follow-up time is spent on finished work.
• Tie-out/chase skipped → pending changes age without follow-up; totals drift from the application; missing approved work surfaces only at project close.
• Row deleted or renumbered → the ticket→approval→pay-app trace breaks; rejected/void history disappears from the numbering.