Skip to main content
DoneThat

AI Adoption GuideConstructionClose

Subcontractor Final Payment Verification

LLM checks final subcontractor claims against contract scope, approved variations, and retention schedule for discrepancies.

Construction processBidAwardPlanMobilizeBuildInspectHandoverClose

By Don, DoneThat’s AI coach · updated

What to check before a final payment certificate

A final subcontractor payment is not a last progress claim with a bigger number. It is a close-out check: does this claim match the contract scope, the variations that were actually approved, and the retention that is still held? The model should return a discrepancy flag with cites to the claim, the contract, approved variations, and the retention schedule. If a source is missing, that field stays empty. The model does not invent a variation, and it does not release retention.

Commercial teams feel the pressure at this point. The subcontractor wants the account closed. The site team wants the package off the punch list. The QS still has to certify only what the documents support.

This check sits after entitlement work on extras, not instead of it. If a line is still argued as a variation, run variation claim entitlement analysis first. Treating an unapproved extra as original scope is how money leaves the project without a paper trail.

Assemble the four artefacts, then compare line by line

Keep the pack as four labelled sources. Do not merge them until each one is identified.

The final claim is the subcontractor's final account or last valuation: line items, quantities, rates, previous payments, and the amount now due. The subcontract is original scope, exclusions, measurement rules, and the payment and retention clauses. Approved variations are only the instructions, variation orders, or signed final-account agreements the contract administrator has issued. Pending notices, rejected claims, and information-only documents are not approvals. The retention schedule is the percentage held, the release events, and the current held amount.

Claims and contracts often sit in project platforms such as Autodesk or Procore, or in a mix of those systems and emailed PDFs. Treat the platform as a filing cabinet. The model still has to read the same four artefacts. A status chip in the platform is not an approval.

Compare line by line. Each claimed item must sit in the original subcontract or on an approved variation. If it is neither, flag it; do not reclassify it as a variation. Claimed rates and quantities must follow the contract or the variation that changed them. A rate that appears only on the claim is a discrepancy, not a new agreement. The claim's previously certified total must match the payment certificates you already have. The amount now claimed as a retention release must match the schedule and the event it names. If the schedule is not in the pack, do not compute a release from a contract percentage and a completion date the model inferred.

The output is not a recommended certificate. It is a list of matches and discrepancies, each tied to a cite.

Cite every discrepancy, and leave gaps empty

A usable flag names the mismatch and points at the evidence. A commercial manager or QS should open the four documents and land on the same sentences.

Each discrepancy should carry what the claim says (page, clause, or line item); what the contract says if the item is alleged to be original scope; what the approved variation set says, including "not found" when the extra is absent; and what the retention schedule says, including "not found" when the schedule is missing.

Empty stays empty. If the retention schedule was never uploaded, the retention field is blank. The model must not fill it from a familiar round percentage, from another package, or from a practical-completion letter that never mentions retention. Filling a missing retention schedule is a common failure mode: the claim looks tidy, the percentage looks familiar, and the certificate then releases money this subcontract never authorised in writing for this event.

The same rule applies to variations. If the claim includes extra containment instructed on site, and there is no approved variation for that work, the flag is that the line is on the claim and not in the approved set. Cite the claim line. Cite that the approved-variation set was searched and did not contain it. Do not draft a new variation order. Do not treat a site instruction, an RFI answer, or a meeting minute as an approval unless that document is itself the contract's variation instrument.

Paying an unapproved variation is the other classic miss. Similar wording in the original spec and in the extra produces a false match, the line is certified as original scope, and the final account is later reopened because the extra was never instructed. The check exists to stop two different things collapsing into one.

Why a green match is not a retention release

A clean comparison on scope and variations can still be the wrong moment to let retention go.

Retention is a contractual hold, not a quality score. The model may report that claimed work lines reconcile to the subcontract and to approved variations. That is a statement about the account. It is not authority to release retention. Release depends on the event the retention clause and schedule name, such as practical completion, making good of defects, or a staged formula.

Do not let a no-discrepancy result drive a retention line to zero. If the claim asks for full release and the schedule says half at practical completion and half at the end of the defect liability period, flag the over-claim and cite both. If defects remain open, use open defect aging monitor and defect liability period tracking agent before touching the second-half release. Warranties that should already be in the close-out file belong in warranty register extraction. Their absence is a close-out gap, not a reason for the payment model to invent a retention figure.

The comparison is green. Someone treats green as pay and release. Retention walks out with the final valuation even though the schedule still holds a balance, or even though the schedule was never attached. Keep the model's job narrow: flag. The certificate, including any retention movement, stays with the QS.

Worked example: mechanical package final account

A mechanical subcontractor submits a final account. The pack contains the subcontract, three signed variation orders, the last payment certificates, and a retention schedule that holds a balance until making good of defects. The claim also includes a line for additional plant-room attenuators, instructed verbally.

The model should match original measured items to the bills and to previously certified amounts, and cite those lines. It should match each signed variation to the approved set, with cites both ways. It should flag the attenuators: on the claim, not in the approved set, not in the original bills. It does not create a new variation to close the gap.

On retention, it compares the amount the claim now seeks to release with the schedule. If the claim seeks the full hold and the schedule still ties the remainder to making good, it flags that mismatch and cites the schedule clause. It does not reduce the held amount because the scope lines matched.

If the retention schedule had been missing, the retention comparison would stop. The output would show the retention field empty, with a note that the schedule was not provided. It would not apply the subcontract's percentage to the agreed value and call that the hold.

The QS then decides: park the attenuator line until an instruction exists, certify the matched scope and approved variations, and leave retention where the schedule puts it. The model does not make those decisions. It only makes them easier to see.

What the QS still certifies

The human step is the certificate. After the flags, the QS still confirms that the documents are the right revision, that approved means approved under this subcontract (not a main-contract instruction that was never flowed down), and that any retention movement matches the schedule and the site reality of completion and defects.

Use the discrepancy list as a reading order, not as a payment instruction. Open every cite. If a file is missing, leave that field empty and run the check again when the pack is complete. The useful output is a cited discrepancy list, not a release, a new variation, or a filled-in schedule.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first