Change-order approval authority: verify who could sign

Create an authority matrix from actual documents

Start with the executed contract and the owner's current delegation policy. Record the role authorized to direct work, approve a change amount, commit funding, certify a payment and release cash. These may be different people. Identify any limits, required countersignatures and emergency procedures.

Store the delegation's effective dates and source reference. A current job title cannot prove that a person held the same authority six months earlier. Where a policy is ambiguous, route the interpretation to the responsible owner or counsel. The matrix records their decision; it should not invent a permission because an approval would otherwise be inconvenient.

Test the decision that each approval actually made

Read the approval wording and its attached version. A field signature may acknowledge hours or receipt without agreeing the final price. A technical response may accept a design but leave funding unresolved. Record the type of decision instead of treating all signatures as interchangeable.

Check whether the approved amount was later revised and whether that revision required another approval. Compare the audit trail with the executed change document, including delegated substitutions. A system can record a valid login while the user acts outside their delegated limit. Conversely, a missing software click may coexist with a valid approval executed through another authorized channel.

Worked example: a revision crosses an approval limit

Assume a fictional owner's policy lets a project manager approve related changes up to $25,000 and requires an executive above that amount. Revision one of a change is $22,000 and has the project manager's approval. Revision two adds $8,000, bringing the request to $30,000.

The old signature does not establish approval for the $30,000 revision under the example's policy. Ask for the required executive decision or another valid basis. Do not automatically reject the underlying work or call the $8,000 fraudulent. If the policy applies a cumulative limit to related commitments, confirm whether other related changes must also be considered. The threshold here is invented, not a suggested market standard.

Use the Amtrak finding as a control-design example

Amtrak OIG reported that procurement controls were bypassed and an $18,902 invoice was charged to an unrelated project and grant. The supplier later credited it, and the OIG found no evidence of fraud. This illustrates why an apparently completed payment workflow still needs review of authority and coding.

For your project, test whether an authorized role can override routing and what independent review follows. Inspect the evidence for any exception path, not just the intended process diagram. Keep a coding correction separate from a supplier overcharge or confirmed loss.

Sources: Amtrak OIG: payment controls in electronic procurement (September 30, 2026)

Make missing approval an actionable question

An exception should identify the decision needed, current version, amount, governing source and named owner. Preserve the original instruction and any later ratification. A retrospective approval should retain its real date rather than rewriting history to make the sequence look complete.

Buildalytic's published workflows include named approval steps and logged follow-up. Ask to see one actual approval handoff using your roles and redacted documents. An authority audit, historical role mapping or new connector needs explicit scoping. Keep approval rights in the authoritative contract and system configuration; a reminder service should not silently acquire power to approve money.

Sources: Buildalytic: current custom-workflow scope