How to Extract Data from an AIA Pay Application (G702 and G703)

An AIA pay application is one of the most numbers-heavy documents in construction, and one of the most tedious to retype. Every billing cycle, a general contractor receives a pay application from each subcontractor, and project accounting has to key the contract sum, the change orders, the work completed, the retainage, and the current payment due into the accounting system, line by line off the schedule of values. On a large job that is dozens of forms a month, every one with its own math. This guide walks through how to pull that data off a pay application automatically, which fields matter, how to tie waivers to the draw, and how to keep the totals right. If you just want the money page for this task, our AIA pay application OCR reads the G702 and G703 you receive and exports the schedule of values straight to Excel.

What is an AIA pay application (G702 and G703)?

An AIA pay application is the standard construction request for payment, made up of two forms submitted together. The G702 is the cover sheet: it carries the original contract sum, the net change by approved change orders, the contract sum to date, the total completed and stored to date, retainage, the total earned less retainage, previous certificates for payment, and the current payment due, along with the contractor and architect certifications. The G703 is the continuation sheet that itemizes the schedule of values behind the G702, breaking the contract into line items with scheduled value, work completed this period and from previous periods, materials stored, the percentage complete, and the balance to finish for each line.

What data do you need to extract from a pay application?

The fields that matter fall into two groups. From the G702 cover sheet you capture the project and contractor, the application number and period, the original contract sum, change orders to date, contract sum to date, total completed and stored, retainage, previous certificates, and the current payment due. From the G703 continuation sheet you capture each line of the schedule of values: the item number and description, the scheduled value, the work completed to date, the materials presently stored, the total to date, the percentage complete, and the balance to finish. The point is to get named, structured values, not a flat block of text, so the draw can be reconciled and posted without anyone rekeying the math.

How to extract data from an AIA pay application, step by step

The reliable workflow has four steps. First, classify the document so the engine knows it is a G702 and G703 pair and not a lien waiver or an invoice mixed into the same packet. Second, read every page with OCR, converting the scan, PDF, or photo into machine-readable text, including any hand-marked fields. Third, extract the values tied to their labels, so each number lands in the right field rather than as loose text. Fourth, validate the result: check that the schedule of values lines sum to the totals on the cover sheet, that retainage matches the percentage on the contract, and route anything low-confidence to a person to confirm. Construction document processing software runs this whole sequence on its own when you drop a pay package in.

How does OCR read a schedule of values?

A schedule of values is a table, and reading a table accurately is harder than reading a paragraph because the meaning of a number depends on its row and its column. Modern extraction handles this by reading structure, not position: it recognizes the columns of an AIA continuation sheet, the scheduled value, work completed, stored materials, total to date, percent, and balance, and ties each cell to its line item even when subcontractors use slightly different layouts or add their own columns. That is why a table-aware engine beats a template that breaks the moment a sub reformats the sheet. To understand the difference between simply reading text and pulling structured fields, see OCR versus data extraction.

How do you match lien waivers to a pay application?

A pay application rarely travels alone. Each payment has to be matched to a lien waiver from the sub being paid, and the waiver type has to fit the payment stage, conditional when a check is in hand but not cleared, unconditional only after funds are confirmed. When the software extracts the claimant, the amount, the through-date, and the waiver type from each waiver and the payee and amount from each pay application, it can line them up automatically and flag a mismatch, such as an unconditional waiver that shows up before payment is confirmed. That catches the lien exposure that manual matching tends to miss when fifty forms land at month end.

How accurate is OCR for pay applications?

Modern AI OCR commonly starts around 95 percent field-level accuracy on clean documents and climbs toward 99 percent with validation. Accuracy matters here because a misread retainage figure or a wrong current-payment-due flows straight into a payment. The dependable pattern is straight-through processing for high-confidence values and a short review queue for anything the engine flags, plus a totals check that confirms the schedule of values ties to the cover sheet. That way a project accountant verifies the few uncertain numbers instead of rekeying every line of every draw. This is the same human-in-the-loop approach used across intelligent document processing.

Can it export to construction accounting software?

Yes. The value of extraction is in where the data goes next. Once the pay application is read and validated, the fields export as a file or push through an API into the construction accounting and ERP systems contractors run on, such as Procore, Sage 300 CRE, Foundation, Viewpoint, and QuickBooks. The schedule of values, retainage, and payment due land where project accounting already works, so the draw posts without a manual rekey. Because pay applications are highly structured forms, form processing software handles the field-by-field reading, and document classification sorts the pay app from the waivers and invoices in the same packet.

What are common mistakes when processing pay applications?

The most common mistake is trusting templates: a per-subcontractor template breaks the first time a sub reformats their sheet, and someone falls back to retyping. The second is skipping the totals check, which lets a transposed digit on one line ride through to the payment. The third is processing the pay application without tying it to the matching lien waiver, which is how double-payment exposure slips in. The fourth is treating handwriting as unreadable, when intelligent character recognition can read field-completed forms and flag only the uncertain characters. Avoid those four and a pay package that used to take a day clears in minutes, with a cleaner audit trail than manual entry ever produced.

Pay applications are the heartbeat of construction billing, and they do not have to be a data-entry tax. With classification, table-aware extraction, validation, and a clean export, the numbers move from the sub's form into your accounting system accurately and fast. To process pay applications, lien waivers, change orders, and COIs together on every draw, start with construction document processing software.