Build AIA G703 Continuation Sheet From Supplier Invoices

A G703 row's dollars come from the cost-coded supplier invoices and tracked labour already sitting in your project ledger, grouped by the Schedule of Values line that each cost code rolls up to. Once that SOV-to-cost-code mapping is set at project setup, columns C through J populate mechanically from the job-cost ledger. Work completed this period (Column E), materials presently stored (Column F), and retainage (Column J) each have their own derivation rules — and getting those rules right line by line is what separates a pay app you finish in an afternoon from one that consumes the better part of a week.

Most material online on the AIA G702/G703 pay application walks the form column by column and assumes the data is already there. The harder work is upstream: extracting dollars from supplier invoices, coding them to the right job and cost code, and rolling them up to the right SOV lines. If your monthly job is to build a G703 continuation sheet from supplier invoices and a job-cost ledger, rather than fill in numbers someone else already produced, this is the workflow layer you actually live in.

The SOV-to-cost-code mapping that makes every pay app mechanical

The setup decision that determines whether each pay app is a rollup or a reconciliation is the mapping between the project's Schedule of Values lines and the project's cost codes. Build that mapping once at project setup and each monthly rollup is addition. Skip it and the controller rebuilds the logic every billing cycle, with inconsistent SOV-line-to-cost-code decisions that the GC's project accountant sees as unexplained percent-complete jumps.

The shape of the mapping is one-to-many. Each SOV line gathers one or more cost codes. The common pattern is that an SOV line is broader than any individual cost code, and several cost codes roll up into it. Take a concrete electrical example. The GC-approved SOV carries a single line called "Lighting Fixtures." Your internal cost-code structure breaks lighting into three CSI MasterFormat divisions: 26 51 00 (Interior Lighting), 26 56 00 (Exterior Lighting), and 26 55 00 (Special Purpose Lighting). At project setup, all three cost codes are mapped to the same SOV line. From then on, any cost-coded supplier invoice that lands on 26 51 00, 26 55 00, or 26 56 00 routes automatically to the "Lighting Fixtures" line of G703 when you build the rollup. That one decision, made once, removes the question every month of which cost codes belong to which SOV line for the lighting scope.

At bid handoff, the project accountant has two source documents: the estimator's cost-code structure and the GC-approved SOV. The mapping table ties each cost code to exactly one SOV line. Each cost code has one SOV destination; each SOV line gathers one or more cost codes. When approved change orders later add new cost codes and SOV lines, the new entries are added to the table; the rest stays put.

The disagreement case is worth naming honestly. Most of the time the SOV granularity is broader than the cost-code granularity, and the rollup is many-to-one — that is the default for specialty subs whose internal cost codes track scope at a finer level than the contract SOV bothers to. The harder case is the reverse: the SOV granularity is finer than what your cost codes capture. This happens when the GC mandates SOV detail you did not estimate to — for instance, the SOV breaks "Branch Conduit" out into "Floors 1-3", "Floors 4-7", and "Floors 8-10" but your cost code is one undifferentiated branch-conduit code across the building. You then have two options: split the cost-code totals proportionally each pay app (defensible if takeoff data backs the proportions) or push back during SOV review and ask the GC to consolidate the lines. Both happen in practice; pick the one that produces less recurring reconciliation pain.

The mapping is also what makes upstream cost coding pay off at pay-app time. Each supplier invoice, when extracted and cost-coded, lands on a job and a cost code; the mapping then routes those dollars to the correct SOV line for the rollup. The discipline of coding construction supplier invoices by job, phase, and cost code at the AP stage is what makes the SOV rollup mechanical. If the supplier invoice never gets a clean cost code, no mapping in the world saves the controller from manually figuring out where it belongs at month end.

G703 columns A through J, derived from the job-cost ledger

AIA Contract Documents' guidance on G702 and G703 frames G703-1992 as the Continuation Sheet used with G702 to list portions of the work and their scheduled values. That is the form's role; the workflow question is how each column derives from the cost-coded job-cost data underneath it.

Column A — Item No. Sequential numbering of SOV lines, in the order the GC-approved SOV established. New SOV lines added by approved change orders get appended numbering — typically CO-1, CO-2, or a 100-series scheme — rather than being inserted into the original sequence.

Column B — Description of Work. The SOV line description, taken verbatim from the GC-approved SOV document. Do not paraphrase. The wording the GC certified at SOV approval is the wording every G703 carries; rewording invites the project accountant to ask whether the scope has changed.

Column C — Scheduled Value. The contract value for this SOV line, including any approved change orders that modified that specific line. The sum of Column C across all rows must equal the contract sum reported on G702 Line 1 plus net approved change orders. If your Column C totals don't tie to G702, the pay app fails the project accountant's first arithmetic check.

Column D — Work Completed From Previous Application. Cumulative work-completed value for this line through the prior period. The reliable derivation is prior Column D plus prior Column E — not prior Column G — because prior Column G includes prior Column F (materials presently stored), and any of that prior stored-materials value that has now been installed has moved into the current period's Column E. Computing Column D off prior G double-counts the moved-in materials. Walk this carefully at every period close; it is the most common reason a pay app fails reconciliation against prior periods.

Column E — Work Completed This Period. Job-cost dollars for work physically performed and installed this period, summed by SOV line via the cost-code mapping. The dollar amount is gated by the PM-signed percent-complete schedule: the PM signs off on percent complete by SOV line before the controller pulls the cost data, and Column E reflects that signed-off completion, not raw job-cost spend. A line can be 30% complete by labour-hour spend but only 20% complete by installed work in place; Column E follows the PM's percent on installed work, not the raw spend.

Column F — Materials Presently Stored. Vendor-invoiced materials that have been delivered to the project site, or to bonded off-site storage, but have not yet been installed. The dollars come from the supplier invoice; the right to put them in Column F comes from the documentation stack, walked in the next section. State the dollars here, prepare the documentation separately.

Column G — Total Completed and Stored to Date. D plus E plus F. Pure arithmetic, no judgment.

Column H — Percent (G divided by C). Column G divided by Column C, expressed as a percentage. Customarily shown to one decimal place. A line that shows over 100% in Column H is an immediate flag to the project accountant — usually it means someone billed against pending change-order scope before the CO was approved.

Column I — Balance to Finish. C minus G. The dollars of the SOV line not yet earned or stored.

Column J — Retainage. The withheld portion of the line's earned and stored value, calculated per the contract's retainage rules. Retainage is contract-driven and may vary by line, by labour versus materials, or by milestone — the calculation patterns get their own walk further on.

For each column the question to answer is which job-cost figure or prior-period figure feeds the dollar amount, not where on the form the number is typed. Once those derivations are settled and the SOV-to-cost-code mapping is in place, the columns produce themselves each period from the project ledger. The G703 stops being a document you assemble manually and becomes a report off the underlying data.

Column F materials presently stored: the documentation the GC's project accountant actually requires

Column F captures vendor-invoiced materials that have been delivered but not yet installed, so the sub gets cash for materials it has paid for or owes payment on without misrepresenting work physically completed. The column exists deliberately separate from Column E for that reason: Column E is installed work in place; Column F is value of materials in your custody waiting to be installed. The dollar amount comes from the vendor invoice. The right to put that dollar amount in Column F comes from the documentation, and the derivation rule is documentation-driven, not just dollars-driven.

The on-site stored materials documentation stack is three things. The vendor invoice is the dollar source. The delivery ticket or bill of lading is proof of receipt. The on-site photograph or storage location reference is proof the material is on the project site. Some GCs accept the AP-side audit trail (invoice plus delivery ticket) as sufficient; many require the on-site photo as well. Treat the photo as the default and skip it only when you know the specific GC's project accountant has accepted invoice-plus-ticket on prior pay apps.

When the material is not on the project site, the documentation escalates. Off-site stored materials live in a vendor's warehouse, a bonded storage facility, or any location that is not the project itself. The GC almost always requires more before certifying the column: a bill of sale transferring title to the contractor (or directly to the owner, depending on contract), an insurance certificate covering the stored materials at the off-site location for the full stored value with the owner named as additional insured, and a contractor's affidavit certifying the off-site stored materials. The affidavit is often modelled on AIA G706 (Contractor's Affidavit of Payment of Debts and Claims) — G706 itself is the affidavit a contractor issues at substantial completion to certify that vendors and subcontractors have been paid, but the form has been borrowed in practice as the template GCs accept for stored-materials certification on interim pay apps. Whether the contract names G706 specifically or just calls for "a notarised affidavit" determines whether you use the G706 form or your own.

The timing reality on Column F is what catches controllers out. The vendor invoice may arrive before the material ships; the delivery ticket arrives with the shipment; the insurance certificate and bill of sale often require separate follow-up. By the pay-app submittal date, the controller has either assembled the stack or the project accountant strikes Column F for that line and the cash slides to next month. Track documentation status against vendor invoices through the period, not on submittal day.

The upstream extraction is what makes the assembly tractable. The vendor invoice line items — material descriptions, quantities, dollar amounts — are the spine of the Column F stored-materials inventory the GC will review. When supplier invoices are extracted with line-item granularity and cost-coded to the right SOV line, building the Column F backup schedule is assembly: pull the line items, attach the delivery ticket and photograph, group by SOV line, total. When supplier invoices are only captured at header level and the line-item detail lives only in the PDF, building the Column F backup is reconstruction: open every PDF, read every line item, type the relevant ones into a schedule by SOV line. The hours scale poorly with vendor count.

The reverse flow next month closes the loop. When stored materials are installed in the following pay app, the dollar value moves from prior Column F into current Column E (work completed this period). The line's prior Column F is replaced or reduced; the line's current Column E reflects the now-installed work. This carryover is exactly why Column D is computed as prior D plus prior E rather than prior G — the stored-materials transition between Column F and Column E happens inside the period roll-forward, and reading Column D off prior G would double-count the moved-in materials.

Retainage by line: how Column J actually calculates in practice

The standard pattern is 5% or 10% of each pay app's earned-and-stored value, withheld until substantial completion, computed line by line in Column J and totalled into G702. Treat that as the baseline only when the contract does not say otherwise.

Most variants fit four rules. Under flat retainage, Column J for a line is the contract retainage rate multiplied by Column G to date. Under labour-only retainage, the labour portion of Column G is multiplied by the rate and materials are excluded. Under line-specific rates, each SOV line carries its own percentage. Under milestone release or 50%-completion step-down, cumulative retainage is recomputed at the new effective rate and the release appears as a negative Column J line entry for that period.

The rule originates in the contract, not in Column J. Pull the retainage terms from the executed subcontract at project setup, record them in the project-level retainage rules, and apply them each month. For the broader retainage workflow, see construction retainage invoice tracking; this G703 section only needs the line-level Column J calculation.

Change orders and supplier invoices that span jobs

Two recurring complications disrupt a clean SOV rollup. The first is an approved change order that adds or modifies SOV lines. The second is a supplier invoice that covers material drawn down across multiple projects. Both are handled mechanically once the patterns are clear.

When a change order is approved — meaning the GC and the owner have signed off, not just that it is in the directive or pending stage — it modifies the SOV in one of two ways. Either it adds a new SOV line for new scope, or it augments the scheduled value of an existing SOV line for additional quantity within the existing scope. New SOV lines appear as new G703 rows, conventionally numbered after the original SOV lines: CO-1, CO-2, or a 100-series scheme that keeps the original sequence intact. Augmented existing lines update Column C to the new contract value for that line; the prior Column D, E, and F values for that line are not retroactively restated, but the new Column C becomes the basis for Column H going forward. Once the new Column C is in place, the percent-complete reading shifts immediately — a line that was at 80% of the original scheduled value drops to a lower percentage of the augmented value the moment the CO posts.

Pending change orders do not modify the SOV. The controller does not bill against pending CO scope on G703, even if the work has started in the field on a verbal go-ahead from the PM. Doing so produces a Column H over 100% on the original SOV line — earned and stored value exceeding the not-yet-augmented scheduled value — which the GC's project accountant catches on the first reconciliation pass. Pending CO work waits for approval and back-bills cleanly the period the CO is approved and the SOV is updated.

The cost-code consequence is straightforward. Approved change orders typically introduce new cost codes for the new scope, or extend existing ones with new sub-codes. The SOV-to-cost-code mapping is updated to route the new cost codes to the new SOV line — a maintenance update on the table built at project setup, not a rebuild. The mapping discipline pays off here too: when the CO scope is small and the new cost code is added cleanly, the next month's rollup absorbs the new line mechanically.

Cross-project supplier-invoice allocation is the other recurring case. A copper-wire purchase covers material drawn down across two concurrent jobs. A bulk fitting order from a supplier covers requisitions from three projects. A single tools-and-consumables invoice from the supply house covers material that crews from multiple jobs picked up over the period. The dollars have to be split across each project's job-cost ledger so each project's G703 reflects its share of the cost — and only its share.

When one supplier invoice spans jobs, split it before the G703 rollup using the most defensible source data available: issued quantities, PO or takeoff proportions, or another documented allocation basis. The control is that each project's share must trace back to the source invoice and written allocation logic. The fuller allocation method belongs in splitting one supplier invoice across multiple construction projects; here the G703 consequence is simple: only the current project's share can flow into that project's SOV lines.

Line-item extraction is what makes those splits workable. If the supplier invoice is captured by material description, quantity, unit price, and line total, each job's share can be assigned before the SOV rollup. If only the header total is captured, the controller has to open the PDF and apportion by hand.

A note on materiality. Small-dollar consumables — tools, fasteners, miscellaneous shop supplies — are often not split across jobs even when the underlying material was used across several. Most controllers route them to a single "indirect" or "general" cost code on one project and let the wash come out across the year. Whether that policy is acceptable depends on the contracts in question and the size of the recurring spend; it is a judgment call about materiality, not a rule.

The audit trail behind every G703 line

The GC's project accountant reads every G703 against three things: internal consistency, period-to-period continuity, and supporting documentation. The first two are arithmetic. The third is where the pay-app package lives or dies.

The per-line backup the GC typically asks for follows the columns:

• Column E (work completed this period): the PM-signed percent-complete schedule by SOV line — the same document the controller used to gate Column E dollars in the first place — optionally backed by the underlying job-cost report sliced by SOV line and any applicable T&M tickets that fed material or labour into the period.
• Column F (materials presently stored): the documentation stack from the prior section — vendor invoice, delivery ticket, on-site photograph for on-site stored, and bill of sale, insurance certificate, and contractor's affidavit for off-site stored.
• Column J (retainage): an aging schedule of retainage held to date by line, plus any milestone-release or 50%-step-down calculations applicable this period if the contract carries those provisions.

Two coordinating documents travel with the G703 and reconcile back to the column dollars: lien waivers and the sworn statement or contractor's affidavit. The current conditional waiver should tie to the current G702 application total; the prior unconditional waiver should tie to the prior paid amount. The sworn statement lists vendors and amounts paid for the prior period, tying back to the supplier invoices behind Column E and Column F.

Two-tier validation runs through the package. Internally, the PM signs off on percent complete by SOV line before the controller pulls cost data. Externally, the GC project accountant reviews the package and the architect certifies G702. The audit trail exists to satisfy the external review; the PM sign-off is what makes it defensible.

The same documents the sub assembles and submits become the inputs the GC's AP team reviews and processes — what reads as building the package from the sub's seat reads as verifying the package from the GC's seat. The other half of this workflow is documented in how the GC's AP team verifies received G702/G703 pay applications; reading it occasionally is the simplest way for a sub controller to anticipate the questions before they arrive.

The practical consequence is binary. Build the audit trail as the work happens — invoices cost-coded, delivery tickets filed, photos uploaded, waivers tracked — or reconstruct it under deadline pressure when the GC asks for the package.

Three routes to a finished G703 each month

Any specialty trade sub building a G703 each month is using one of three patterns, or some combination of them: a manual Excel rollup of the job-cost report into a G703 template, a construction ERP that generates G703 directly from the project ledger, or a pre-accounting AI extraction layer that produces cost-coded supplier-invoice data ready to roll into a G703 workbook before the data ever lands in the accounting system. Each route earns its keep at a different shop size and a different operational shape; none is universally right.

The same extraction pattern shows up in non-AIA progress billing too: Quebec GCs consolidating subcontractor draws need Quebec subcontractor progress draw extraction that keeps retainage, stored materials, and project-level totals separate before the monthly workbook is reviewed.

Route 1 — manual Excel rollup. The controller exports the period's job-cost report from QuickBooks Contractor (or whichever GL the sub uses), sums by cost code, applies the SOV-to-cost-code mapping to roll into SOV lines, and types the totals into a G703 Excel template. This route is genuinely sustainable on small projects with a short SOV — say, under 20 lines — and a small vendor list. The controller can do the period roll in an afternoon and the audit trail fits in a folder. Where it breaks down is at multi-project shops where the per-pay-app hours scale with project count and SOV depth: 50-line SOVs across four concurrent projects with 30-plus vendors per period each month is the point at which the Excel rollup consumes the better part of a billing week and the controller starts losing accuracy on Column D continuity, Column F documentation, and Column J retainage variants.

Route 2 — construction-software-built G703. Construction ERPs generate G703 from the project ledger when the upstream coding has been disciplined. Knowify, Procore Pay, Sage 100 Contractor, Foundation, Vista (Trimble Viewpoint), and eCMS each handle pay-app generation differently — there is no single workflow across them — but the precondition is the same in each case: the G703 is only as good as the upstream coding that fed the project ledger. If the supplier invoices were not coded against the SOV-mapped cost-code structure when they entered AP, the construction-software-built G703 just produces incorrect dollars faster, and the controller still ends up reconciling at month end. The deployment cost — implementation, training, monthly licence, and ongoing IT support to keep the integration working with the GL and the field-data sources — is justified at shops with consistent multi-project volume and the IT capacity to maintain the deployment. For a single-project shop or a shop that runs lean on IT, the cost-benefit often does not work.

Route 3 — pre-accounting AI extraction feeding a G703-ready spreadsheet. Vendor invoices are extracted with line-item granularity and cost-coded before the data lands in the GL or construction ERP. The output is a structured spreadsheet with one row per invoice line item, carrying invoice number, date, vendor, line description, quantity, unit price, line total, job, and cost code. For electrical shops, the same pattern becomes an electrical supplier-invoice job-cost spreadsheet workflow; HVAC and mechanical contractors can use an HVAC supplier-invoice job-costing spreadsheet. This route fits the multi-project, multi-vendor shop where Excel reconciliation has broken down but a full construction ERP is overkill, unavailable, or still fed by manual data entry. AI invoice data extraction sized for multi-project specialty subs converts supplier invoices into Excel, CSV, or JSON using a reusable prompt for the fields needed in the G703 rollup.

For shops evaluating the wider tooling space rather than a specific extraction layer, the AP automation software comparison for construction companies covers the broader landscape — invoice approval routing, GL integration patterns, and the AP-side workflow tools that often sit alongside or upstream of pay-app generation.

Pick the route by shop shape: short-SOV single-project subs can stay in Excel, ERP-ready teams can use the construction system, and multi-project shops with invoice-line reconciliation pain may need a pre-accounting extraction layer.