Payment applications AIA-style G702/G703 SOV + retainage

Construction Payment Applications: Contractor Guide

Quick answer:

A construction payment application is a formal request for payment that shows what is complete, what is being billed this period, retainage withheld, and what is left—usually driven by a Schedule of Values (SOV). Many teams submit in an AIA-style format with a summary page and a continuation sheet.

The hard part is not just creating the form. It is making sure the numbers tie out, the backup is complete, and the package is easy for the reviewer to approve without follow-up.

PayAppPro outputs are AIA-style only and are not licensed AIA documents. AIA®, G702® and G703® are registered trademarks of the American Institute of Architects.

“Payment application” is the formal version of saying: here is what we have built so far, and here is what we should be paid this period. The challenge is keeping the details straight—SOV, stored materials, retainage, change orders, waivers, and the classic kickback: “your totals don’t tie.”

If you are working in QuickBooks Online

Start here: Does QuickBooks do AIA billing (G702/G703)? Then see: Progress billing in QBO and Retainage in QBO.

What Is a Construction Payment Application?

A construction payment application, often shortened to pay app, is a structured billing package that shows what has been earned on the job so far and what is being requested for the current billing period. It is built for review, not just for accounting.

A normal invoice might only show a charge amount and payment terms. A pay application shows a broader financial story: contract amount, changes, work completed to date, this period billing, retainage, prior payments, and amount currently due.

On many commercial projects, that story is presented using AIA-style G702 summary logic and G703 continuation logic. On other jobs, the owner, GC, lender, or project portal may use a custom format. The structure may change, but the math usually does not.

Why Payment Applications Exist Instead of Simple Invoices

Owners, GCs, architects, and lenders are usually not just asking “how much do you want paid today?” They are asking:

  • What is the contract value now? including approved change orders
  • What has been completed so far? by line item or scope
  • What is new this billing period?
  • How much retainage is being withheld?
  • What is the amount due after prior payments and current calculations?
Reality check: reviewers rarely “fix” a broken pay app for you. If the totals, supporting documents, or rollforward logic are unclear, the package usually gets kicked back and the payment clock slows down.

Normal Invoice vs. Construction Payment Application

Normal invoice Construction payment application
Primarily asks for payment Asks for payment and explains how the amount was earned
Usually centered on the current charge Centered on prior, current, and to-date totals
May not track line-item contract values Usually tied to an SOV or similar line-item structure
Less dependent on prior billing history Depends heavily on rollforward consistency across periods
Works well for standard AR Works well for review, approval, and contract-based construction billing

What to Include in a Construction Payment Application

Whether you are using AIA-style billing, a lender form, or a GC template, most pay applications include the same core components.

1) Project and contract information

  • Project name and address
  • Owner and GC names as they appear in contract documents
  • Your legal company name
  • Original contract sum
  • Net approved change orders to date
  • Current contract sum

2) Schedule of Values (SOV)

Your Schedule of Values (SOV) is the backbone of the pay app. It breaks the contract into billable line items so the reviewer can see how progress is being tracked over time.

Instead of rebuilding the billing package from scratch every month, you update the same approved structure. That is what makes the submission reviewable.

Need a starting point? Grab the free SOV template (Excel/PDF).

3) Previous, this period, and to-date billing

This is where progress billing becomes a rollforward problem. Reviewers expect last month’s approved “to date” totals to become this month’s “previous” totals. If that sequence breaks, they start questioning the package.

For the plain-English version of that workflow, see construction progress billing.

4) Stored materials, if allowed

Stored materials can support cash flow, but they also attract scrutiny. Reviewers often want supporting invoices, storage location details, photos, and a clean explanation of how stored amounts reduce as the materials are installed.

See: how to bill stored materials on AIA-style G702/G703, what stored materials are, and stored materials ledger workflow.

5) Retainage

Retainage is one of the most common reasons pay app math drifts. It is usually a percentage withheld from earned work, and sometimes stored materials are treated differently than installed work.

If retainage is applied one way on one page and another way somewhere else, the entire billing package becomes harder to trust. See also: how to calculate retainage on G702/G703.

6) Change orders

Approved change orders affect the contract sum, the SOV, and the continuation math. If your pay application reflects an updated contract value but your SOV still reflects the old one, you are creating a mismatch before the reviewer even opens the backup.

Related: how to bill change orders on AIA-style G702/G703.

7) Lien waivers and supporting documents

On many jobs, the actual “pay app package” is larger than the G702/G703-style forms. It includes support documents that make the billing approvable.

  • Lien waivers
  • Stored material backup
  • Signed change orders
  • Any owner, GC, or lender required forms
  • Possibly insurance certificates or vendor support, depending on the job

How a Typical Pay App Month Works

The cleanest billing workflows usually follow the same pattern each month:

1) Update progress

Update SOV line items for work completed this period, stored materials, and approved scope changes.

2) Reconcile totals

Make sure contract sum, SOV, continuation totals, retainage, and summary totals all tell the same story.

3) Attach backup

Add waivers, stored material backup, CO approvals, and any project-specific required forms.

4) Submit cleanly

Submit one reviewer-friendly package instead of sending math in one place and support docs in five others.

How AIA-Style G702 & G703 Fit In

In an AIA-style workflow, the job is usually split into two major billing views:

  • G703-style continuation sheet for line-item SOV math
  • G702-style summary for total earned, retainage, prior payments, and amount due

Backups like waivers, stored material support, and change order documents then travel with the package. That is why people often say they are submitting a “pay app package,” not just a form.

Want a read-only reference? View a completed AIA-style G702/G703 example for educational reference.

Common Reasons Payment Applications Get Rejected

  • G702 summary does not match the G703 or SOV totals
  • SOV total does not match the current contract sum
  • Approved change orders are missing or handled inconsistently
  • Line items exceed scheduled values without a documented contract update
  • Stored materials are billed without adequate backup
  • Retainage is applied inconsistently from one period to the next
  • Lien waiver amounts do not match the application or payment history
  • Supporting documents are incomplete or scattered

Full checklist: common G702/G703 errors and how to avoid them.

How QuickBooks Online Fits Without Pretending It Is a Pay App Tool

QuickBooks Online is strong for accounting and AR. What it does not natively do well is generate a reviewer-ready AIA-style payment application package with all the rollforward context construction reviewers expect.

The practical workflow many teams settle on is:

  1. Build the pay app package using an SOV-driven process
  2. Get the package approved
  3. Mirror the approved totals into QBO so accounting stays aligned with what was accepted

Start here: does QuickBooks do AIA billing (G702/G703)?


How PayAppPro Simplifies Payment Applications

You can build pay apps in spreadsheets, but consistency across months is where spreadsheets quietly break down. PayAppPro is built to reduce the number of ways a payment application can drift.

  • Build your SOV once and reuse it each billing period
  • Keep summary totals tied to continuation math automatically
  • Track stored materials and retainage consistently
  • Keep backup documents organized by application
  • Generate clean AIA-style PDFs quickly

The goal is not just “make a PDF.” The goal is to make the package easier to review, easier to trust, and easier to approve.

FAQ: Construction Payment Applications

A construction payment application is a formal request for payment that shows completed work to date, what is being billed this period, retainage withheld, and the remaining balance—often using an SOV and an AIA-style format.

Common attachments include lien waivers, change order approvals, stored material invoices or backup, and any project-specific forms required by the GC, owner, or lender.

Not always. Many projects accept AIA-style pay applications that follow the same structure, but you should confirm what your contract or GC, owner, or lender requires.

Most rejections happen when totals do not tie out, retainage is inconsistent, change orders are not reflected correctly, stored materials lack backup, or lien waivers do not match the application amounts.

QuickBooks Online is strong for accounting and AR, but it does not natively generate an AIA-style pay app package. Many teams use a pay app workflow for G702/G703-style presentation and mirror the approved totals into QBO.

Related Guides

Create Your Next Construction Payment Application

Build AIA-style pay apps, track stored materials and retainage, and keep totals tied out across billing periods.