Change-order audit procedure: test scope, price and authority

Establish what was included before the change

Collect the executed scope, relevant drawing revision, specification, exclusions and applicable clarifications. Identify the document hierarchy and the person responsible for interpreting a conflict. The audit packet should describe the original obligation and the alleged change in enough detail that another reviewer can follow the comparison.

Link the field event to a location, date and specific instruction. Avoid treating the existence of an RFI as proof of extra scope. Some RFIs clarify an existing requirement; others lead to a priced revision. Record the responsible team's interpretation and the evidence behind it before moving to the cost test.

Rebuild the price in auditable components

Separate labor, materials, equipment, subcontract costs, credits and markups. For each component, show the source quantity, unit, eligible rate and contractual treatment. Preserve the vendor invoice and the worksheet that transformed it into the requested amount. A subtotal copied from a proposal does not reveal which items were included twice.

Test the sequence of financial markups as well as their percentages. Procore documents distinct horizontal and vertical configurations; the software setting must be compared with the actual agreement. A mathematically correct configuration can still apply the wrong contractual basis. Use the existing markup guide for detailed arithmetic and reserve this audit procedure for the complete control path.

Sources: Procore: horizontal and vertical financial markup

Worked example: a deletion changes the result

In a fictional package, additional installation costs $18,000, materials cost $7,000 and deleted work generates a $4,000 credit. Assume the agreement applies a single 10% markup to the net $21,000 base. The example's reviewed total is $23,100. A worksheet applying markup to the $25,000 addition and omitting the deletion would request $27,500.

The $4,400 difference has two components: the omitted $4,000 credit and $400 of associated markup. Do not assume these rules apply to every additive and deductive change. If the actual contract treats credits differently, recalculate under that clause. Record both the numerical difference and the reviewer-approved interpretation so the next auditor does not mistake an assumption for a settled rule.

Review the approval trail at the approved version

Identify who could approve the scope, price and funding at the time the decision was made. Compare the approved file with the file used for billing. A signature attached to revision two should not silently authorize revision four. If an emergency direction preceded formal pricing, preserve the instruction and route the remaining commercial decision through the actual project process.

Check for split requests that relate to the same event, since the approval level may depend on related commitments under the owner's policy. A screening rule can identify a cluster; the reviewer must establish whether aggregation is required. Do not label an exception fraud merely because the approval sequence is incomplete.

Issue a finding the project team can resolve

Write each finding as a short question with the source clause, record reference, amount, proposed correction and decision owner. Give the contractor an opportunity to provide omitted evidence or explain the pricing basis. Preserve disagreement and any subsequent amendment.

Then trace the agreed result into the system of record and the affected payment period. Keep a proposed price reduction separate from an executed change and a posted credit. Buildalytic's current workflow offering can support requests, reminders and approval handoffs; any independent pricing audit or connector should be scoped explicitly. A successful trial ends with an inspectable decision, including justified clean items, rather than a longer list of unresolved flags.

Sources: Buildalytic: current custom-workflow scope