Skip to content
← Back to blog

The Construction AP Controls Framework

August 15, 20265 min read977 words

Written by Ademola Afolabi, Founder, Nexus AP. Reviewed and updated August 15, 2026.

A working controls framework for construction payables: segregation of duties, vendor bank-change verification, commitment tolerances, approval authority, waiver and retention gates, and what should never post automatically.

AP controls exist to make three bad outcomes hard: paying for work that did not happen, paying the wrong party, and paying without the documentation that protects the project. Construction raises the stakes on all three — payments are large, vendors change by project, and every payment carries lien exposure. This framework describes the control set a growing contractor actually needs, layer by layer.

It pairs with the complete construction AP guide (the lifecycle these controls attach to) and the general AP internal controls checklist.

Layer 1: Segregation of duties

No single person should be able to create a vendor, enter an invoice, approve it, and release payment. In small back offices perfect separation is impossible — the framework is to separate the most dangerous pairs first:

FunctionMust be separated fromWhy
Vendor master changesPayment releaseThe classic fraud pair: create/modify a vendor, then pay it
Invoice entryInvoice approvalEntry errors need an independent check
Work verification (PM)Payment releaseField confirms the work; finance controls the money
Payment preparationPayment releaseDual control on the money leaving
Retention release approvalRetention register maintenanceReleases checked against an independently maintained balance

Where headcount forces overlap, compensate explicitly: system-logged approvals, monthly review of vendor-master changes by someone outside AP, and dual authorization on every payment run. See segregation of duties for the general model.

Layer 2: Vendor onboarding and bank-change control

Most construction payment fraud does not involve fake invoices — it involves a real vendor's payment redirected. Two controls close the gap:

  • Verified onboarding. New vendors enter through a documented process: W-9, insurance certificate where relevant, banking details confirmed at setup, and a named internal owner. No payments to vendors that skipped the process.
  • Out-of-band bank-change verification. Any change to payment details is confirmed by calling the vendor at a number already on file — never a number supplied in the change request — with the confirmation recorded (who called, who answered, when). Email requesting an urgent banking update is the single most common attack on contractor AP, because subcontractor payments are large enough to be worth impersonation.

Duplicate vendors belong in this layer too: merge them on a schedule. Duplicate records are how duplicate payments evade detection — cross-industry data puts duplicate rates at 1–2% of invoices without automated checks (APQC).

Layer 3: Commitment matching and tolerances

Every dollar of PO-required spend should clear against its commitment — three-way where receiving exists, two-way against the PO or subcontract otherwise. The control content is in the tolerances:

  • Documented, per category. Tight on unit-priced materials; wider where small variances are routine. A tolerance nobody wrote down is not a control.
  • Variance approval is segregated. Whoever approves an over-tolerance variance is not the person who created the PO or the person who entered the invoice.
  • Change-order work is the known leak. Billings for changed scope arrive before the change order is approved. The rule that keeps job costs honest: the variance waits on the change order — the commitment updates first, then the invoice matches.

Layer 4: Approval authority and the audit trail

Approval routing belongs in a written authority matrix — by role, dollar threshold, and invoice type (PO-matched, unmatched, subcontractor billing, change-order work). Two properties make it a control rather than a diagram:

  • The system enforces it. Routing happens by rule, not by whoever forwards the email. Delegations during vacations are explicit and logged.
  • Every action is reconstructible. Who saw the invoice, what they approved, what changed, and when — with timestamps, surviving personnel changes. "Show me everyone who touched this invoice" should be a report, not an archaeology project. See audit trail.

Email approval chains fail both properties, which is why they fail audits.

Layer 5: Documentation gates at payment

The construction-specific layer. Before a payment releases:

  • The correct waiver is signed — conditional before funds clear, unconditional only after; tracked per payment, not per project. The lien-waiver risk assessment scores this control set in five questions.
  • Retention matches contract terms — withheld at the right rate, posted to a retention balance, released only against completion evidence and final waivers. Mechanics in retainage management for AP teams, arithmetic in the retainage calculator.
  • Compliance documents are current where the contract requires them (insurance certificates, licensing).

Gates mean the payment cannot proceed — a policy that can be skipped under deadline pressure is a suggestion, not a control.

The month-end AP control checklist

Ten minutes of structure that catches most drift:

  1. Unposted-invoice queue reviewed; genuine period costs accrued.
  2. Vendor-master changes for the month reviewed by someone outside AP.
  3. Payments released vs waiver log reconciled — exceptions investigated, not archived.
  4. Retention register tied to the retention payable balance in the ledger.
  5. Exception log reviewed by root cause; upstream fixes assigned.
  6. Approval-matrix overrides and delegation events reviewed.
  7. First-pass coding accuracy sampled (lines recoded at close ÷ lines entered).

What should and should not post automatically

Automation strengthens every layer above when it is scoped honestly:

Runs automatically: capture, coding suggestions from vendor and PO history, matching within documented tolerance, approval routing and reminders, waiver chasing, retention arithmetic, duplicate screening, and posting invoices that passed every rule.

Stays human: approving work that lacks field verification, overriding any failed gate, bank-detail changes, retention release, and payment release above threshold.

The test for any auto-posted invoice is auditability: which documented rule allowed this? If the answer exists, automation made the control stronger — the rule fired every time, and the log proves it. If the answer is "the model was confident", it was not a control. This is the design stance behind Nexus Build: deterministic rules decide what posts; AI assists the humans on everything else.

For the metrics that tell you these controls are working — missing-waiver rate, coding accuracy, exception rates by root cause — see the Construction AP Benchmark Centre.

Built for construction AP teams

Nexus Build handles job costing, lien waivers, retention tracking, and subcontractor payments on QuickBooks.