Common G702 Extraction Errors
That Trigger Pay App Disputes

Most guides about G702/G703 forms focus on the obvious: check your math, don't miss the deadline, include your lien waivers. Those matter. But when you move from filling out forms by hand to extracting data from PDFs and spreadsheets into a single pay application — or when you are the GC consolidating twenty subcontractor submissions into one draw schedule — a different class of errors takes over. These are errors that survive a clean calculator tape because they are not about getting the sum wrong. They are about getting the wrong number into the sum in the first place.

When the Numbers Add Up But Your Pay App Still Gets Kicked Back

There is a particular frustration familiar to anyone who has managed construction billing for more than a few cycles: you verify every total, the retainage arithmetic checks out, the G703 grand total matches Line 4 on the G702 — and the architect or owner's rep still sends it back with a question mark next to a figure. The problem is not that the math is wrong. The problem is that somewhere between the source documents and the final form, a number changed its meaning without changing its value.

This is the core distinction that separates surface-level form errors from extraction errors. A surface error — a transposed digit, a missed subtraction — announces itself. An extraction error looks correct in isolation. It only becomes visible when someone traces it back to where it came from and finds that the source does not match what ended up on the form. Understanding the six most common ways this happens is the difference between a pay application that survives first review and one that triggers a dispute that costs you a full billing cycle.

1. The Cumulative vs. Current-Period Extraction Trap

On the G703 Continuation Sheet, columns D and E serve fundamentally different purposes. Column D carries forward the cumulative totals approved from all previous applications. Column E captures only the work completed in this billing period. Column G — Total Completed and Stored to Date — is the sum of D, E, and the materials stored this period in F. The number that matters for the G702 summary is Column G.

Yet when extracting data from a stack of documents — whether you are transcribing from a marked-up G703, pulling from a subcontractor's spreadsheet, or using an AI extraction tool to read scanned pay applications — the most common single error pattern is confusing Column E (this period only) with Column G (total to date). The subcontractor reports that they completed $45,000 of electrical work this month. That $45,000 goes into Column E. But Column G for that line item should read the cumulative total — all work completed since the project started, which might be $180,000. If you extract that $45,000 as if it were the cumulative figure, Line 4 on the G702 understates the actual completed work by $135,000. The owner sees a number that does not match their field observation of progress and flags the entire application.

The reverse error — extracting the cumulative figure into the current-period column — inflates the billing for this month and triggers an overbilling review. Neither error shows up in a simple cross-foot check because the internal arithmetic of the G702 remains internally consistent. The error only surfaces when someone compares the submitted numbers to the project's physical progress, as required under AIA A201-2017 Section 9.4, which gives the architect the authority to certify only a portion of the application if the amounts do not reflect actual completed work.

The fix begins with understanding which column in your extraction target corresponds to which concept in your source. If you are using an extraction tool that processes documents into a structured table — a process sometimes called column-name extraction, where you specify the fields you want and the AI locates the matching values on each page — make sure your column definitions distinguish between "Work Completed This Period" and "Total Completed to Date" explicitly. If the source document only reports period figures, you need a separate mechanism to accumulate them across billing cycles before they go anywhere near the G703.

2. Retainage Applied to the Wrong Base

Retainage on a G702/G703 pair is calculated against the cumulative total of completed work and stored materials, not against the amount billed this period. A subcontractor completes $50,000 of work this month, bringing their cumulative completed to $200,000. At a 10% contractual retainage rate, the retainage for this line item is $20,000 — ten percent of $200,000 — not $5,000. Applying 10% to the period-only $50,000 under-withholds retainage by $15,000.

This error is deceptively easy to make when extracting data because retainage rates often reside in a single contract field — "Retainage: 10%" — while the figure that rate gets applied to changes with every billing period. If your extraction workflow reads "10%" from the contract and multiplies it by whatever dollar figure is closest on the page, you cannot guarantee which figure it picked up. On G703 forms — a detailed schedule of values that breaks the contract sum into portions of the work — retainage may even vary by line item. Some contracts reduce retainage from 10% to 5% after substantial completion, creating a situation where different rows on the same G703 carry different retainage rates.

State law adds another layer. New York now caps retainage at 5% on private construction contracts exceeding $150,000, and contractual provisions exceeding that cap are void and unenforceable. Illinois allows 10% through the first half of the contract, then mandates reduction to 5%. North Carolina prohibits retainage entirely on projects under $100,000. If your extraction workflow applies a blanket 10% to a project governed by one of these statutes, the mismatch between what you withhold and what the contract legally permits creates an immediate dispute — and in some jurisdictions, a statutory violation.

The Construction Financial Management Association (CFMA) has documented that errors and reconciliation problems can increase project costs by 2–5% through misreporting and delayed decisions alone. On a $5 million project, that is $100,000–$250,000 in entirely avoidable cost — most of it attributable to money sitting in dispute rather than flowing through the payment chain.

3. Change Order Data That Drifts Between the G702 and G703

The G702 contains a Change Order Summary table that feeds into Line 2 (Net Change by Change Orders) and ultimately Line 3 (Contract Sum to Date). Meanwhile, approved change orders appear on the G703 as additional line items, each with their own scheduled value and progress tracking. These two representations must reconcile: the sum of all change order line items on the G703 must match the figure that flows through the G702 Change Order Summary into Line 2.

When extracting change order data from multiple sources, two things go wrong with predictable regularity. The first is including unapproved change orders in the totals. A subcontractor has five pending change orders totaling $35,000 and includes them as line items in their G703 — a practice that AIA's own G703 instructions warns against, specifying that change orders are "listed separately, either on their own G703 form or at the end of the basic schedule." When the GC or architect reviews the sub's G703 and finds dollar amounts for work they never approved, the entire application is suspect.

The second pattern is subtler: the change order dollar amount appears correctly on the G703 line item, but the roll-up into the G702 Change Order Summary is missing or zero. The G703 shows $35,000 in approved change order work. The G702 Line 2 reads $0. The discrepancy between the detailed backup and the summary is a direct rejection under AIA A201-2017 Section 9.3, which requires that applications for payment show "the status of the contract sum to date, including the total dollar amount of the work completed and stored to date, the amount of retainage (if any), the total of previous payments, a summary of change orders, and the amount of current payment requested." If the change order summary is incomplete, the application is incomplete.

Extraction workflows make this worse when change orders are recorded in separate systems — Procore for commitment management, a spreadsheet for subcontractor change logs, a PDF of the signed change order form — and somebody needs to reconcile all three into a single G702 entry. One source gets missed, and the cascade begins. For a deeper look at how manual data handoffs between these systems delay the entire payment cycle, see our analysis of why AIA G702 manual data entry delays construction payment cycles.

4. Stored Materials Valuations That Exceed the Line Item Cap

Column F on the G703 — Materials Presently Stored — tracks the value of materials purchased and on site (or, under specific contract provisions, stored off-site in a bonded warehouse). There is a structural constraint that manual review catches but automated extraction often misses: stored materials for any single line item must not exceed that line item's scheduled value. If a line item is worth $50,000 total, you cannot claim $55,000 in stored materials against it — that would mean you are billing for more material value than the entire scope of work.

This error emerges from extraction workflows through two paths. Path one: the subcontractor's materials invoice shows a delivered quantity whose value exceeds the SOV allocation, and the extraction tool faithfully transcribes the invoice figure without checking the SOV ceiling. Path two: materials were stored under one line item in a previous period, but continuing materials deliveries are being allocated to that same line item instead of a separate materials-only line. The cumulative figure blows past the cap, and the G703 shows a negative balance-to-finish — an immediate red flag that will halt certification.

The G703 is not just a list of numbers. It is a system of constraints: each line item has a maximum value, cumulative totals cannot decrease, retainage cannot exceed the contractual rate, stored materials cannot outstrip the scheduled value, and the balance to finish cannot go negative. When extraction treats each column as an independent field — rather than a linked variable in a constrained system — it reliably produces data that passes a column-by-column scan but fails the cross-constraint validation that an experienced project accountant performs in seconds.

5. The Previous Payment Carry-Forward Problem

Line 7 on the G702 — Less Previous Certificates for Payment — is the single most potent source of compounded error in the entire payment application system. It represents the sum of all previously approved payments on the project. For the first pay application, it is zero. For every application after that, it must exactly match Line 6 (Current Payment Due) from the last approved G702 — not the last submitted, not the last drafted, but the last certified.

Here is how this breaks in practice. Application #3 is submitted with a $94,000 payment request. The architect certifies only $87,000, withholding $7,000 for incomplete documentation. The subcontractor's system shows the submitted $94,000 as the carry-forward figure. Application #4 arrives with Line 7 at $94,000. But the owner's records — and the contract — say the correct carry-forward is $87,000. Every number downstream of Line 7 — the current payment due, the balance to finish — is now inflated by $7,000. The application gets rejected.

This error propagates because the certified figure exists in one place (the architect's signed G702) while the extraction source — typically the subcontractor's or GC's internal billing spreadsheet — often tracks the submitted figure. When you are consolidating multiple subcontractor pay applications into a single draw schedule, as covered in our guide on merging payment applications from an entire project into one consolidated draw schedule, each sub's Line 7 must be individually verified against the certified version from the prior cycle. One sub's carry-forward error cascades into the GC's summary G702 and becomes exponentially harder to trace.

6. The G702-to-G703 Reconciliation That Nobody Checks Until Review

Every figure on the G702 summary has a single point of origin on the G703 — with one exception: Line 2, which derives from the Change Order Summary table that exists only on the G702 itself. This creates a reconciliation blind spot. The G703 totals can be perfect, the Change Order Summary can be correct, and the two can still diverge because the Change Order Summary was populated independently of the G703 change order line items.

In a manual workflow, this reconciliation is tedious but at least centralized — one person fills out both forms and checks them against each other. In an extraction workflow, the G703 totals might come from an AI tool reading subcontractor continuation sheets, while the Change Order Summary comes from a separate log maintained by the project manager in a different format. The two data streams flow into the same G702 but were never cross-validated against each other. The result is a form that each individual section validates correctly but that, taken as a whole, contains an irreconcilable gap.

This is not a failure of extraction accuracy. It is a failure of what could be called extraction architecture — the design of which source feeds which output field and where in the workflow cross-validation happens. The most valuable thing an extraction tool can do for G702/G703 processing is not achieving 99% field-level accuracy (though that matters). It is preserving the relationship between fields across forms, so that a number extracted from page 3 of a subcontractor's G703 retains its lineage all the way to Line 4 of the GC's G702 and can be traced backward when discrepancies arise.

The practical upshot: when an architect or owner questions a figure, you should be able to say exactly which source document, which line item, and which column that number came from — not "let me check my spreadsheet and get back to you." Extraction without traceability is not much better than manual entry; it's just faster at producing the same dispute.

Building a Verification Layer Into Your Extraction Workflow

None of the six errors above are prevented by a tool that extracts data with high character-level accuracy. They are structural errors — mismatches between what the data means in its source context and what it means on the target form. Preventing them requires a verification layer: a set of cross-checks that run after extraction but before submission.

At minimum, this layer should verify that the G703 Column G total equals the G702 Line 4 value, that the retainage on each G703 line equals the contractual rate multiplied by that line's Column G (not Column E), that the Change Order Summary total on the G702 matches the sum of change order line items on the G703, that no line item's stored materials exceed its scheduled value, and that Line 7 matches the certified Line 6 from the prior approved application. These are not complex calculations. They are comparisons that take seconds to perform — but they have to be built into the workflow, not left to the person hitting "submit" at 11 PM on the last day of the billing cycle.

For teams processing a high volume of applications — general contractors receiving 15 or 20 subcontractor pay apps each month — automated extraction of AIA G702/G703 data into spreadsheets eliminates the manual entry step but the verification layer remains essential. The extraction gets the data into structured form. The verification layer confirms that the structure is self-consistent before the application goes anywhere near an architect's desk.

Some extraction tools allow you to define computed columns — fields whose values are derived from other extracted data rather than read directly from the document. This capability can serve as a built-in verification mechanism. You can define a column that computes "IF G703_ColumnG_Total ≠ G702_Line4 THEN 'MISMATCH' ELSE 'OK'" and flag every application with a reconciliation error before it ever reaches human review. The tool does not need to understand construction billing to run this comparison — it just needs to understand that two extracted values are supposed to be equal and alert you when they are not.

Frequently Asked Questions

Why does my pay application get rejected even when the math checks out?

Because correct arithmetic is not the same as correct data. The most common cause is a mismatch between what the document says and what the architect or owner's representative expects based on their independent knowledge of project progress. Common culprits: cumulative totals that don't match field observations, change orders included without approval, retainage calculated against the wrong base, or Line 7 (previous payments) not matching the last certified application. The math can be perfect while the data lineage is wrong.

What is the difference between a G702 and a G703, and why does it matter for extraction?

The G702 is the summary cover sheet: it shows the total contract sum, retainage, previous payments, and current amount due in a single-page format. The G703 is the continuation sheet that breaks the contract into individual line items from the schedule of values — a detailed, itemized breakdown of costs. Every number on the G702 (except the Change Order Summary) must trace back to the G703. When extracting data, the G703 is the source of truth for line-item-level figures; the G702 is where those figures get summarized. If the two forms are extracted independently rather than linked, reconciliation errors become inevitable.

Can an AI extraction tool handle variable retainage rates across different line items?

It depends on the tool. Some tools extract only what is visibly printed on the page and will faithfully capture whatever retainage figures appear in Column I of the G703, but they cannot verify whether those figures were calculated correctly against the contract. Others allow you to define computed columns — for example, a column named "Retainage Check (Column G × 0.10)" that calculates the expected retainage from the cumulative total and flags discrepancies. This verification approach catches errors that pure extraction cannot because it introduces the contractual rate, which exists outside the document being read.

What supporting documentation should always accompany a G702/G703 submission?

The AIA A201-2017 Section 9.3.1 requires that applications for payment be accompanied by releases and waivers of liens. Beyond the legal minimum, most projects also require certified payroll reports (for government-funded work), progress photos, evidence of stored materials (delivery receipts, warehouse documentation), and signed change orders for any work beyond the original scope. Missing documentation is the most common procedural reason for rejection — separate from data errors but equally damaging to the payment timeline.

Is it safe to include pending change orders in a pay application?

No. Including unapproved change orders in the G703 line items or in the G702 Change Order Summary is one of the fastest ways to get an application rejected. Under AIA A201-2017 Section 7.3.9, applications may include requests for payment on account of changes properly authorized by Construction Change Directives but not yet included in Change Orders — but this is a narrow exception, not a blanket permission. The safest approach is to track pending change orders in a separate log and only move them into the G703 after formal approval. Billing for work without a signed authorization creates both a contractual dispute and, in many states, a lien rights problem.