Pay Apps Construction Teams Can Reconcile: 8 Checks Before Submission

Pay apps construction teams submit are requests for payment against work under a contract. They commonly bring together a schedule of values, progress to date, stored materials where allowed, retainage, and supporting records. The task is to show how the requested amount follows from the contract and prior billing history.

This article explains the core records, eight review checks, a worked example, and what to test in AIA billing software. It also covers revisions, approval status, and a practical month-end workflow. Actual payment terms and required forms depend on the contract.

What is a construction pay application?

A payment application asks the relevant reviewer to approve an amount under the agreed contract process. It differs from a simple invoice because it may require detailed progress, cumulative values, certification, and attachments. A submitted amount and an approved amount can differ.

The AIA’s official G702 summary explains its application and certificate for payment and the related G703 continuation sheet. It describes contract value, completed and stored work, retainage, prior payments, and the current request. Use the correct licensed documents and instructions where the contract requires them.

However, not every project uses AIA forms. Owners and contractors may specify other formats and portals. Confirm the actual process before configuring software or building a spreadsheet.

Our article on CRM invoicing covers simpler customer billing. Payment applications need their own review of cumulative contract values and supporting evidence.

The records behind the application

Start with the contract, agreed schedule of values, approved changes, prior applications, and the current cut-off date. Next, collect progress evidence and any documents the contract requires. Keep those inputs separate from the final summary so a reviewer can trace each number.

A schedule of values breaks the work into billing lines. Give each line a stable identifier and clear description. Avoid changing line names casually, because the team needs to compare progress across periods.

Also distinguish work completed from stored materials and from cash received. These records answer different questions. A payment receipt does not by itself show how much work the reviewer approved.

8 checks before submitting pay apps

1. Confirm the reporting period and cut-off

State which period the application covers and when the team measured progress. Use the same cut-off for supporting records unless the contract allows another approach. Otherwise, the application can mix incompatible dates.

For example, a late site update may describe work after the agreed cut-off. Keep it for the next period or handle it through the agreed review route. Do not quietly include it because someone wants a larger current claim.

2. Reconcile the schedule of values

Check that the billing lines agree with the current authorized contract value. Confirm how approved changes enter the schedule. Also preserve a history when an authorized revision changes the structure.

A spreadsheet total can match while individual lines contain errors. Review the line-level movement as well as the overall amount. In addition, use clear units and descriptions where they help explain progress.

3. Check previous and current work separately

Carry forward the correct prior values, then enter the current period’s work. The cumulative total should follow from those records. Do not overwrite last month’s figure to make this month’s total look right.

For instance, a correction to an earlier line needs an explanation and review. The system should distinguish that correction from new work. This makes a later reconciliation much easier.

4. Validate stored materials under the contract

Where the contract permits billing for stored materials, confirm the required evidence and approval. That may include records of ownership, location, insurance, or other project-specific conditions. Do not assume that a supplier invoice alone meets every requirement.

Also track movement from stored materials into installed work. The cumulative claim should avoid counting the same value twice. A clear material ledger can support that transition.

5. Apply retainage according to the agreement

Retainage affects the amount currently due, but the basis and release rules depend on the contract and applicable requirements. Configure those rules with the responsible contract and finance reviewers. Avoid assuming one percentage applies to every line for the whole project.

Meanwhile, show retainage separately from disputed or excluded work. A reviewer needs to see why the request differs from gross progress value. Mixing those items into one unexplained deduction weakens the record.

6. Separate approved changes from pending proposals

A proposed change and an authorized contract adjustment are different records. Show their statuses clearly. Follow the contract process for anything that remains under review.

Procore’s contract management overview connects contracts, change orders, and payment applications. When you test a product, ask it to demonstrate how an unapproved change affects the application, rather than assuming every change belongs in the current value.

7. Reconcile prior certificates, requests, and receipts

Use the terminology and calculation required by the form and contract. Keep prior requested, certified, invoiced, and received amounts distinct. They may not all match at a given point in time.

For example, a reviewer may approve less than the amount requested, while a payment arrives later. A system that keeps only one “paid to date” field may not explain that history. Preserve each decision and transaction.

8. Check the supporting package and authority

Confirm the required attachments, signatures, review route, and submission method. Also check the version and application number. The reviewer should receive one controlled package rather than several conflicting email attachments.

Our article on project document management explains the wider record structure. For billing, link each attachment to the application it supports and retain the submitted version.

A worked example of the calculation logic

Consider a simplified fictional contract with a value of $100,000 and an approved change of $10,000. The revised value is $110,000. Assume the agreement permits the following treatment and a uniform 10% retainage for this example.

At the current cut-off, completed work totals $44,000 and eligible stored materials total $6,000. The gross cumulative value is therefore $50,000. Retainage of $5,000 leaves a net cumulative value of $45,000.

If the applicable prior amount under the agreed form is $27,000, the simplified current request is $18,000. The calculation is $50,000 minus $5,000 minus $27,000. The remaining uncompleted contract value is a different measure from the current payment request.

This example explains arithmetic only. Real forms may distinguish prior certificates and payments, use different retainage treatment, or require other adjustments. Follow the actual contract and form instructions rather than copying the example into a live application.

What to test in AIA billing software

Start with your required forms and licensing needs. Ask whether the product creates the exact required output or a similar report. A familiar layout does not prove the output meets the project’s requirements.

Next, test cumulative calculations, changes, stored materials, retainage, and corrections. Also check whether the software preserves a submitted application as a fixed version. A reviewer should be able to reproduce what they received.

Also test permissions. Site staff may supply progress, while finance reviews calculations and an authorized person signs. The product should support those roles without giving everyone authority to change the contract value.

A practical month-end workflow

First, set the cut-off and request progress evidence from named owners. Next, reconcile the schedule and approved changes. Then prepare the application and check line movements against prior periods.

Have a reviewer who did not prepare the package check the calculation and attachments. Meanwhile, resolve missing evidence before submission where possible. Record any remaining exception through the agreed process.

After submission, log the date, version, recipient, and status. Track review comments and revised amounts separately. Finally, carry the agreed prior figures into the next cycle and reconcile cash receipts through accounting.

Our article on document revision control supports the versioning side of this workflow. The principle is to keep each submitted package understandable after later changes.

Common errors that delay review

One error is using a new schedule structure without explaining the carry-forward. Another is including pending changes in the authorized value. Both can force the reviewer to reconstruct the history before checking current work.

Also avoid sending photographs without a location or line reference. Evidence needs context. A smaller package with clear references can be easier to review than a large folder of unrelated images.

Finally, do not treat “submitted” as “approved” or “approved” as “received in cash.” Give each stage its own status. That separation supports accurate follow-up and cash planning.

When spreadsheets work and when to move

A controlled spreadsheet can work for a small number of straightforward applications. It needs protected formulas, clear versions, and a disciplined review process. However, repeated manual carry-forward and multiple reviewers can increase the risk of confusion.

Consider software when the team spends substantial time reconciling periods, changes, and evidence. Measure that work before buying. A new tool should reduce a defined handoff problem rather than simply reproduce the spreadsheet on screen.

If existing project and accounting systems hold the needed data, a custom connection may help. Specify which system owns each value and how exceptions appear. Avoid a silent transfer that nobody reconciles.

Build a review pack that saves the next person’s time

Give each billing line a short note that explains the current movement. For example, name the area completed or the stage reached. Then link the evidence that supports it. The reviewer should not need to infer progress from a folder of unlabeled photos.

Next, flag lines with a large change from the prior period. Ask the site team to explain the movement before submission. The point is to catch missing context, not to assume that a large change is wrong.

Also keep a list of items that the team chose not to include. A pending approval or missing receipt may explain why a line stayed unchanged. That note helps the next cycle start from a clear position rather than another search through old messages.

Finally, check the recipient’s submission rules. File names, portal fields, dates, and package limits can affect whether the application reaches review. Test access before the cut-off day. Assign one person to confirm receipt and log any rejection or request for more detail.

Keep this list separate from the signed application. It supports the team’s preparation and follow-up without changing the required form. A clear internal review pack can make both a spreadsheet process and a software workflow easier to run.

Make the application easy to reconcile

Pay apps construction teams can defend start with a clear contract value, traceable progress, and consistent prior records. Test the calculations and the review history together. Then submit one controlled package with evidence the reviewer can follow.