Change-order log template: track submitted, approved, billed and paid

Use the log to show the next unfinished step

A request can be approved and still miss the billing cutoff. Another can have a signed field ticket but no recorded commercial decision. A single status column makes those differences hard to see, especially when the PM and billing coordinator use the same word complete to mean different things. The log should expose the handoff rather than compress it.

Give every request a stable ID, short scope description, project reference and current revision. Link the field record, proposal, correspondence, approval, billing line and cash application where those events exist. The log is an index and reconciliation aid around the authoritative records. It should help the next person find the missing decision or document without reconstructing an inbox.

Use the actual contract and company process to determine authority, required notices and billing treatment. This guide does not establish entitlement, a legal deadline or a universal condition for invoicing. Its fictional example uses a defined basis so the arithmetic is clear. Preserve different real-world rules instead of forcing every project into the sample's assumptions.

Keep each request and revision traceable

A request ID should survive a revised price or scope explanation. Record the revision, submitted date and source for the amount currently under review, while preserving earlier issues. If a revision supersedes an earlier proposal, do not count both as separate outstanding requests unless they genuinely represent separate work under the project's process.

Connect supporting evidence by reference. A field ticket may establish what was reported or acknowledged on site. A proposal records the requested commercial adjustment. An approval record establishes the decision it actually covers. Keep the scope and limits visible so a signed ticket is not silently promoted into approval of price, time or every later revision.

When a larger package groups several requests, retain the relationship between the child IDs and the package. Billing may occur through a combined line, but the office still needs to allocate it back to the underlying requests if it wants a meaningful reconciliation. An unallocated package total can hide which approved item remains unbilled.

Define the states your team will use

Use distinct fields for draft, submitted revision, commercial review, approval, billing and cash application according to the actual process. Add a current next-action owner instead of relying only on a colored status. A request under review may need a quantity clarification, while an approved request may need a billing reference. Those actions belong to different people.

Procore's published default-status guidance distinguishes approved, draft and several pending states and describes their effect in a particular budget view. That is a bounded example of software status carrying a defined meaning. It is not evidence that an approved budget entry has been invoiced or paid, and actual configurations and processes can differ.

Keep any project-specific billing authority separate from the approval label. Some processes may treat pending work differently. Record the actual basis and source for an amount billed. Do not create a blanket rule that all unapproved work is billable, or that no pending item can ever be billed. Route uncertain treatment to the authorized commercial and billing owners.

Sources: Procore: Default statuses for change orders

Worked example: five requests totaling $42,000

The following five requests and amounts are fictional, in US dollars. Submitted values total $42,000. Two requests have $18,000 in recorded approval; the other three, totaling $24,000, remain pending in this example. Billing of $12,000 relates only to the approved amounts, and $6,000 of cash has been applied to those billed lines.

For this simplified exercise, all columns use the same amount basis and there are no taxes, retainage, credits or deductions in the reconciliation. Approved but unbilled is $18,000 minus $12,000, or $6,000. Billed but not yet covered by applied cash is $12,000 minus $6,000, also $6,000. These are different unfinished handoffs, not two names for the same balance.

The total requested value remains $42,000. Do not add submitted, approved, billed and paid to report a larger volume of work; the later amounts overlap earlier stages. The example does not claim that the pending $24,000 will be approved, that every unpaid amount is overdue or that the cash has been received without a matching application record.

Reconcile each row before trusting the summary

In the example, COR-01 has $4,000 approved but unbilled and $3,000 billed without applied cash. COR-02 has $2,000 approved but unbilled and $3,000 billed without applied cash. The row balances reconcile to the two $6,000 summary figures. Each should lead to a defined next question rather than a generic chase for payment.

For the unbilled amount, ask the billing owner whether the item has the required backup, allocation and submission reference for the relevant cycle. For billed amounts, confirm the invoice or pay-application line, current review state and cash application through the accounting process. The PM should not infer a missing payment solely from a change-order approval record.

If the actual project includes retainage, taxes, credits, write-offs or different gross and net values, record those components and use a reviewed reconciliation. A simple subtraction can be misleading when the columns use different bases. If a billed value exceeds the recorded approved value, flag the difference and its authority for review rather than automatically setting a negative balance to zero.

Record the decision the approval actually covers

An approval field should identify the current scope or revision, amount, date, approving authority and source reference under the project's process. Keep a partial approval distinct from the full requested value. If a reviewer approves a portion and returns the balance for clarification, the log should show both the approved portion and the unresolved request.

Do not infer commercial approval from receipt, acknowledgment or silence. Preserve what the record actually states. A foreman's confirmation that a crew performed work may support the field account while the price adjustment still awaits the authorized process. The log should help the PM obtain the appropriate decision, not upgrade evidence to a status it does not support.

When a decision is changed or superseded, retain the history and notify the people using the amount. An updated approval may affect billing or a prior allocation. Identify the specific downstream records to review so the accounting team does not continue from an older amount simply because it was copied into an earlier spreadsheet.

Make the approval-to-billing checkpoint explicit

At the billing review, list approved items not yet linked to a billing submission, along with their owner and missing action. Use the actual cutoff and requirements for the project. If an item is not ready, identify whether it lacks a required record, allocation, internal review or another defined prerequisite. Approved but unbilled is a question to resolve, not automatic evidence of an error.

Link the actual submission line and date when billing occurs. A draft invoice or planned application is not the same as a submitted one. Keep returned or revised billing records connected to the original request so an item does not disappear from the review merely because it once had an invoice number.

After cash is applied, retain the accounting reference and amount allocated to the request or its billing line. A bank deposit covering several projects needs the proper application process before it can close a specific change-order balance. The log should use the reviewed accounting result rather than assign cash based on whichever item happens to match the deposit total.

Use the editable COR log CSV

The free CSV above includes project, request ID, scope, revision, source records, submitted amount and date, approval amount and reference, billing amount and line, cash applied and reference, reconciliation basis, adjustments, next owner and action. It is a blank register, not an automatic entitlement or accounting engine. Adapt its fields to your actual contract and systems.

Enter the five fictional requests and check the totals. Submitted should equal $42,000, approved $18,000, billed $12,000 and cash applied $6,000. The simplified approved-but-unbilled total should be $6,000. Keep pending requests visible separately rather than combining them with an approved balance merely to create one open number.

Then test a revised request, a partial approval and a billing return. Confirm that the current version is clear and that the next action changes appropriately. Where the basis changes, such as introducing retainage, ask the authorized owner to define the reconciliation rather than extending the sample formula without reviewing its assumptions.

Run a short cross-team exception review

Bring the PM and billing owner together around specific exceptions: submitted without a decision, approved without a billing reference, billed without a clear current outcome, and cash received without allocation. Each row needs a responsible person, next step and source. Avoid asking everyone to chase every open item when the real blocker belongs to a particular handoff.

Use separate timing fields where they serve different questions. Submission age, time since approval and time since billing can all matter, but they should use defined dates and purposes. A pending-request aging review is different from an accounts-receivable review. The log can connect them while preserving their distinct owners and decisions.

Keep the record current through reconciled events rather than optimistic summaries. A request can be progressing and still have an unresolved balance. That visibility is useful: it lets the team decide what to do next without overstating approval, billing status or collection. Record the review date so another person knows how current the summary is.

Coordinate missing records and responses with Buildalytic

Buildalytic advertises extra-work documentation that collects field records for office review, and custom workflows that request information, log replies, wait and hold steps for named approvals. Bring a redacted COR with one missing handoff to a demo. Ask to see how the record and next owner stay connected to the request ID.

Keep commercial approval, formal submission and accounting application with the authorized team and systems. Review supported connections and permissions for your environment. A follow-up workflow should not be presented as automatic change approval, a guaranteed payment result or a substitute for the project's contract process.

Use COR-01 from the example to test an approved but partly unbilled request. Then test a revised proposal whose approval is still unresolved. A useful demonstration should show the difference in next action and preserve the supporting record, including what happens when the requested response never arrives.

Sources: Buildalytic extra-work documentation; Buildalytic custom construction workflows