Change Order Log Check: When Billed-to-Date Does Not Match the Approved Amount
An approved change order has a number that was agreed, signed, and entered on the log. Months later, the billing against it has a number of its own — the billed-to-date — and the two numbers are not the same. The difference did not arrive in one step. It accumulated one pay application at a time, each one plausible on its own, and nobody ever put the approved figure and the billed total on the same line and subtracted.
That subtraction is the whole problem. Until it happens, an under-billed change order sits as work performed and approved but never fully charged, and an over-billed one sits as a question a reviewer will eventually ask with the packet already out of your hands.
How billed drifts away from approved
Billing against a change order rarely happens in one payment. A COR is approved, added to the Schedule of Values, and billed in pieces as the work progresses — a portion on this month's pay application, a portion on the next.
Each piece is entered separately, and each entry is a chance for the running total to wander. A line gets billed on two consecutive applications because last month's entry was not carried forward visibly. The approved amount was revised by a later signature, and the billing kept pace with the earlier figure. A final piece is billed at what the preparer remembers the balance to be instead of what the log says it is. Or the work is finished and fully billed, but one application's entry was keyed a digit off, and the error is small enough to ride along unnoticed.
None of these require a dramatic mistake. They require only that nobody compares the two totals directly — approved on one side, everything billed to date on the other.
What the EX-07 check actually does
EX-07 Billed ≠ Approved is the check for this problem in the Construction Control workbook, and its mechanism is one subtraction.
For each change-order request whose status is Approved and which has at least one billing line on the pay application's Schedule of Values, the workbook uses SUMIF to add every billed-to-date amount recorded against that request. Then it subtracts: approved amount minus billed-to-date total. If the difference is not zero — in either direction — the request is flagged, and the Exception Report counts the flagged requests so they can be reviewed as a set.
Here is the shape of it, with invented COR numbers and amounts for illustration:
| COR | Approved | Billed to date | Difference | Flag |
|---|---|---|---|---|
| COR-301 | $4,200 | $1,400 + $1,400 + $1,400 across three pay apps = $4,200 | $0 | — |
| COR-302 | $2,750 | $2,200 | $550 under | Flagged |
| COR-303 | $1,600 | $1,850 | $250 over | Flagged |
COR-301 was billed in three pieces, on three separate applications, and it is not flagged — the pieces sum to the approved amount, and a sum is all the check reads. COR-302 and COR-303 are flagged in opposite directions, and the check treats them identically, because to a subtraction, under and over are the same kind of fact: the two numbers do not match.
The limits, stated plainly
A difference is a flag to review. It is not proof of an error, and this check cannot tell you why the numbers differ.
The most common reason is innocent: the change order is still being billed. A COR approved last month and billed 80% to date shows a difference because the remaining 20% has not been billed yet — and it should not have been. The flag fires anyway. Read correctly, it is a prompt to confirm that the gap is the expected unfinished balance, not an accusation that the gap is wrong. When the final piece is billed and the totals meet, the flag clears on its own.
What the check does not see matters as much. An approved COR with no billing line on the Schedule of Values at all is not this check's case — a missing line is a different failure, flagged by EX-06; EX-07 only compares requests that appear on the schedule at least once. The comparison is amounts only: beyond the Approved status that admits a request to the check, no status is read, and a billed entry is never matched against anything but the approved figure. And the check reads the numbers as entered. If the approved amount itself was keyed wrong on the log, the subtraction faithfully compares billing against the wrong number, and a match would mean both sides repeat the same error. The check compares the data against itself; it cannot compare the data against the signed change order.
How EX-07 fits the seven
EX-07 is one of seven checks in the workbook. EX-01 counts duplicate ticket IDs by exact match. EX-02 flags tickets with Date, Scope, Labor hours, or Loaded $/hr blank — exactly those four fields. EX-03 flags a ticket with no change-order reference in its link column. EX-04 flags a change-order request whose linked tickets total $0 — a test of the ticket total, not of ticket existence. EX-05 compares a pending change-order request's amount against the total of its linked tickets — an amount comparison, not a status match. EX-06 flags an approved change-order request with no billing line on the pay application's Schedule of Values — absence only; it does not compare amounts.
EX-07 is the last of the seven because it asks the last question the packet can answer: for the work that was approved and billed, do the two totals agree?
Where to go from here
If you want the record-keeping structure first, the free guide to building a change order log template is here:
https://ty-square-csv-preflt-2026-10.pages.dev/articles/change-order-log-template
The free pay-application checklist is a separate listing, here:
If you want the checks themselves, the Construction Control workbook is $39 — a macro-free Excel workbook for desktop Excel with 528 formulas, including EX-07 and the six other checks named above. Data goes in by pasting from four CSV templates; there is no importer. It is a worksheet for use alongside your AIA G702/G703 — it does not replace them.
Disclosure: this article was drafted with AI assistance. It is from Construction Control, maker of the workbook.
Top comments (0)