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 of the existing material online on the AIA G702/G703 pay application walks the form column by column and assumes the data is already there. The work of actually building the data — extracting the dollars from supplier invoices, getting them on the right cost codes, and rolling them up to the right SOV lines — sits upstream of the form and gets very little written treatment. This article is about that upstream. If your monthly job is to build AIA G703 continuation sheet from supplier invoices and a job-cost ledger rather than to fill in numbers someone else has already produced, this is the layer of the workflow you actually live in.

The article is written for a controller, project accountant, or office manager at a US specialty trade subcontractor — electrical, HVAC, mechanical, plumbing, fire protection — and walks the workflow in the order it is actually met: the SOV-to-cost-code mapping built at project setup, the column-by-column derivation of G703, the documentation discipline behind Column F, retainage variants in Column J, change orders and cross-project allocation, the audit trail the GC reviewer reads against, and the three routes shops take to produce G703 each month. The rollup discipline applies regardless of tooling; the route question comes at the end.

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

The single setup decision that determines whether every subsequent pay app is mechanical or manual 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 every subsequent monthly rollup is mechanical addition. Skip it and rebuild the logic at every billing cycle, and every pay app is manual reconciliation. The cost of skipping is paid in compounding hours across the project's life — and worse, in inconsistent SOV-line-to-cost-code logic that the GC's project accountant catches as month-over-month percent-complete jumps that don't match work in place.

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.

The setup workflow itself is straightforward. At bid handoff, you have two source documents. The estimator's cost-code structure exists as a list of cost codes — often AGC bid-day codes or CSI MasterFormat divisions — that the bid was built against. The GC-approved SOV exists as a separate document, usually negotiated with the GC and the architect during the schedule-of-values approval process. The project accountant builds a mapping table that 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. The discipline is that this mapping is maintained, not rebuilt — when approved change orders later add new cost codes and new 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

Per AIA Contract Documents' guidance on G702 and G703, AIA Document G703-1992 is the Continuation Sheet a contractor uses with the G702 Application and Certificate for Payment to list portions of the work and their scheduled values, suitable for any size project. That is the form's role; what follows is how each column actually derives from the cost-coded job-cost data sitting 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 documentation arrives in pieces. The vendor invoice lands first, often days before the material ships. The delivery ticket arrives with the shipment. The insurance certificate has to be requested from the vendor's broker and can take a week to issue. The bill of sale needs the vendor's authorised representative to sign. By the pay-app submittal date, the controller has either assembled the full stack and submitted Column F dollars with the supporting documents, or the project accountant strikes Column F for that line and the cash slides to next month. The controller who tracks documentation status against vendor invoices through the period — rather than scrambling on submittal day — is the controller who consistently bills stored materials in the period the materials arrive.

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 what most controllers default to: 5% or 10% of each pay app's earned-and-stored value, withheld until substantial completion, computed line by line in Column J of G703 and totalled into G702. That is the right baseline assumption absent contract language saying otherwise. The trouble is that contract language often says otherwise, and Column J ends up being the place those variations have to land mechanically.

Four variants account for most of what a controller actually meets in practice.

Labour-only retainage. The contract retains on labour but not on materials. Column J is calculated against the labour portion of Column E (work performed) and excludes the materials portion of Column E and all of Column F (stored materials). This pattern is common where the owner wants the sub paid for materials at supplier-invoice cost without holdback — usually because the materials are long-lead, cash-flow-sensitive, or both, and the owner has already committed to the procurement cost. The implementation discipline: your job-cost ledger has to separate labour cost from material cost within each cost code, so when you roll up by SOV line you can produce the labour-only figure for retainage calculation.

Variable rates by SOV line. Some contracts retain at one percentage on most lines and a higher percentage on specific scopes — commissioning lines are a common case, where the GC wants to hold more retainage to ensure the sub completes commissioning closeout work. Column J then carries different percentages by line, and the SOV line schedule has to record the rate per line at project setup so the calculation is mechanical at every pay app rather than re-derived from the contract each month.

Milestone-released retainage. The contract releases a portion of withheld retainage at defined milestones — top-out, dry-in, substantial completion of a phase — rather than holding all retainage until project substantial completion. The mechanics on the next pay app: the released portion appears as a negative entry on that period's Column J for the lines covered by the milestone, with the released dollars flowing into the period's payable amount on G702. The cumulative retainage held to date is recomputed line by line as if that retainage had never been withheld; the negative line entry is what reconciles the prior period's cumulative to the new lower cumulative.

Reduced retainage past 50% completion. Some AIA-based contracts step retainage down — from 10% to 5%, or from 5% to 0% — once the project crosses 50% completion. This is a single trigger event, but it has cascading effects: from the trigger forward, all new earned-and-stored value is retained at the new rate, and depending on contract language, prior retainage withheld at the higher rate may also be released down to the new cumulative figure. The controller has to track which pay app crosses the trigger and reset the rate going forward, with the catch-up release on the trigger pay app handled the same way as a milestone release (negative Column J line entries reconciling cumulative).

The calculations under each pattern are mechanical once the rule is named. 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; the materials portion is excluded. Under variable rates, each line's specific rate is applied to its own Column G. Under milestone release or 50%-completion step-down, the cumulative retainage is recomputed at the new effective rate and the difference appears as a negative Column J line entry that period.

What ties all four together is that the rule originates in the contract, not in Column J. Every retainage rule in Column J is sitting in the prime contract or the subcontract's payment provisions, often referencing AIA A201 General Conditions language as the framework. Pull the retainage terms from the executed subcontract at project setup, record them in your project-level retainage rules document, and apply them mechanically each month. Interpreting retainage at pay-app time — reading the contract afresh under deadline pressure each period — is how line-by-line errors creep in and how the GC's project accountant ends up sending pay apps back for revision.

The GC tracks the inverse — subcontractor retainage release schedule tracking on the GC side is its own workflow, more relevant to the GC's AP team than to the sub's controller building Column J. Worth knowing exists; not part of what you produce on G703.

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.

The practical allocation patterns vary by what the supporting data supports. Allocate by quantity drawn when material is issued from a central stockroom to specific jobs and the issue tickets are tracked: each job's quantity drawn times the unit cost on the supplier invoice gives that job's share. Allocate by takeoff proportion when the purchase was made against the combined material requisitions of several jobs and the proportion is known at PO time: each job's requisitioned quantity as a share of the PO total. Allocate by another defensible basis when neither is available — for instance, a pro-rata split based on labour hours on each job during the delivery period for genuinely consumable material. Whatever method is used, the allocation logic has to be documented so the auditor can trace each project's share back to the source invoice; an allocation that exists only in the controller's spreadsheet without a written rationale is the audit finding waiting to happen.

The practical handling of cross-project allocation is where line-item-level extraction pays for itself. When supplier invoices are extracted with each line item — material description, quantity, unit price, line total — the per-line dollars are what enable a clean split. A copper-wire invoice with five line items at known quantities per item can be split by issue ticket against each job's quantity drawn from each line item; the result is per-job, per-cost-code dollars that route through the SOV mapping like any single-project invoice. An invoice extracted only at header level — vendor, date, total, with the line detail living only in the PDF — cannot be split mechanically; the controller has to open the PDF and apportion by hand, which is exactly the per-period reconciliation pain the SOV mapping discipline was designed to remove.

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 certifies the pay app for payment by the owner. To do that, they read every G703 against three things: internal consistency (do the columns add up, do the percentages match the dollars, does Column G equal D plus E plus F line by line), period-to-period continuity (does this period's Column D properly equal prior D plus prior E for each line, accounting for the stored-materials transition described earlier), and supporting documentation (is each line backed by something a reviewer can actually look at). The first two are arithmetic. The third is where the pay-app package lives or dies, and where most of a controller's preparation time goes.

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 in the pay-app package, both reconciling back to the column dollars.

The first is lien waivers. The sub submits a conditional waiver with the current pay app — waiving lien rights conditional on receiving the current period's payment — and an unconditional waiver for the prior period's payment, since the prior payment has now been received. The waiver dollar amounts must reconcile: the current conditional waiver to the current G702 application total, and the prior unconditional waiver to the prior G702 paid-to-date. A controller who submits a conditional waiver at a different dollar value than the G702 application total invites the project accountant to ask which document is wrong.

The second is the sworn statement, sometimes called a contractor's affidavit depending on the contract. This is a notarised statement listing vendors and amounts paid for the prior period, often required at every pay app or at defined milestones. The vendor list on the sworn statement reconciles back to the supplier invoices that fed the prior period's Column E and Column F dollars. The statement is the bridge between what the sub paid its vendors and what the sub billed the GC, and the architect's certification on the G702 itself is the third tier of attestation that the period's earned-and-stored value matches work in place.

Two-tier validation runs through the whole package. The internal tier is the PM's sign-off on percent complete by SOV line before the controller pulls cost data — this is what makes Column E defensible at the field level. The external tier is the GC project accountant's review of the package and the architect's certification on G702 itself. The audit trail exists to satisfy the external tier; the internal sign-off is what makes the audit trail defensible when the external review pushes back.

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. The audit trail is either built each period, in step with the work — vendor invoices captured and cost-coded as they arrive, delivery tickets filed against the invoice, on-site photographs uploaded with the receiving record, lien waivers issued and tracked as payments come in — or it is reconstructed under deadline pressure when the GC asks for the package. Shops in the first mode assemble pay-app packages in hours. Shops in the second spend days each period and still submit incomplete packages that come back for revision.

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.

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 against the project's cost-code structure before the data lands in the GL or the 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, cost code — everything needed to roll into G703 by the SOV-to-cost-code mapping. This route fits the multi-project, multi-vendor, multi-pay-app shop where Excel reconciliation has broken down but a full construction ERP is overkill, has not been deployed, or has been deployed and is fed by manual data entry — which produces the same reconciliation pain in a different tool. AI invoice data extraction sized for multi-project specialty subs is what this route looks like in practice: a tool that converts batches of supplier invoices into a structured Excel, CSV, or JSON file using a natural-language prompt the controller writes once and reuses each pay app. The controller writes a prompt that names the fields needed for the rollup — invoice number, date, vendor, line description, quantity, unit price, line total, job, cost code — saves it to the prompt library, and applies it to each period's batch of supplier invoices. Output is per-line-item with native Excel typing on numerical and date fields, so totals roll up cleanly through pivot tables or formula-driven SOV-line groupings. Batch sizes scale with the shop: a mid-market specialty sub running four to ten projects can submit a full month's vendor invoice intake — typically a few hundred to a few thousand pages — in a single batch, and the same prompt produces consistent structured output across every document.

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.

The route to choose follows the shop. Single-project subs with short SOVs run Route 1 indefinitely without pain. Shops with the volume and IT capacity to deploy and maintain a full construction ERP run Route 2 and get the integrated benefit across job costing, AP, and pay-app generation as a single system. The middle band — the multi-project mid-market specialty sub where the per-pay-app reconciliation pain is real every month but a full ERP is the wrong answer for cost or for organisational fit — is where Route 3 fits. The honest framing is that each route serves a different shop shape, and the wrong route at the wrong shop has its own characteristic failure: Route 1 too small for the work produces reconciliation pain; Route 2 too big for the shop produces implementation overhead with no return; Route 3 in a one-project shop is solving a problem the shop does not have. Pick by shape, not by category.