FlowParse
Tool August 2026 16 min read

Subcontractor invoice reconciliation

A subcontractor's pay application and the scope the general contractor actually billed the owner for should describe the same work — but they're prepared by different people, on different schedules, and rarely checked against each other line by line. FlowParse reads both and matches them.

FlowParse
flowparse.io

Two documents describing the same work, prepared separately

A subcontractor submits their own pay application for a period's work — a percentage complete, a retainage figure, an amount due, all against their own subcontract sum. Meanwhile, the general contractor's pay application to the owner includes that same trade's scope as a line or group of lines on a much larger schedule of values. Both describe the same underlying work. Neither is automatically checked against the other.

Answering the question every project accountant eventually needs to answer — does what this sub billed actually match what we billed the owner for their scope, at the retainage rate their subcontract specifies — means holding both documents side by side and tracing the connection line by line. Neither document alone can answer it.

FlowParse
flowparse.io

Why sub-to-GC reconciliation is harder than it sounds

The two documents rarely use the same line numbering

A sub's own invoice format has no obligation to mirror the GC's schedule-of-values structure, so matching one trade's scope across both documents means mapping between two entirely different numbering systems.

Retainage rates can differ between the two contracts

A GC can withhold more retainage from a sub than the owner withholds from the GC, holding the difference under their own subcontract terms — a legitimate gap that looks like an error if the two aren't tracked separately.

Billing periods don't always align

A sub may invoice on their own schedule, slightly offset from the GC's owner-facing pay application cycle, so a given period's sub invoice can cover work that spans two of the GC's own billing periods.

One trade can appear as several lines, or several trades as one

A large trade's scope might be split across multiple schedule-of-values lines for tracking granularity, while a small trade's scope might be bundled into a single line alongside related work — neither maps cleanly to a single invoice by default.

None of these four are anyone doing anything wrong — they're the normal shape a multi-tier contract structure actually takes. But they're exactly why comparing a sub's invoice to the GC's owner-facing pay application, by eye, rarely produces a confident answer.

What this doesn't do

Doesn't decide subcontract terms

Retainage rate, payment terms and scope are set by the subcontract itself. This reads and applies those terms — it doesn't negotiate or interpret an ambiguous contract clause.

Doesn't process payment

This checks that a sub's invoice matches what was billed for their scope. Approving and issuing payment stays with your accounts payable process.

Doesn't generate lien waivers

A lien waiver is read alongside the invoice it corresponds to, for a consistency check. It doesn't produce the waiver document itself.

Doesn't resolve a scope dispute

A sub who believes they completed more than the GC billed for their scope, or a GC who disputes a sub's percent complete, is a conversation this surfaces clearly enough to have — not one it settles.

What's left is narrow, and it's exactly the part that turns into a scramble every payment cycle: turning a sub's invoice and the GC's owner-facing pay application into a clear, checked answer about whether the two actually agree.

What gets read from each side

FieldSource
Subcontract sum and percent completeSubcontractor's pay application
Retainage withheld under the subcontractSubcontractor's pay application
Schedule-of-values lines for the sub's scopeGC's owner-facing pay application
Lien waiver amount and periodLien waiver, when submitted
Prior period figures for continuityPrior pay applications from both sides

Five sources of truth, read as they actually exist across two contract tiers — not summarized from memory, and not assumed to agree with each other until the matching step actually checks.

FlowParse
flowparse.io

How it works

1

Upload the sub's invoice and the relevant pay application lines

The subcontractor's pay application, plus the schedule-of-values lines covering their scope from the GC's owner-facing pay application.

2

Both sides are read

Percent complete, retainage and amount due on the sub side; scheduled value and billed amount on the GC side.

3

Matched by scope, amount and period

Checked together, with a confidence level per matched line and any discrepancy flagged clearly.

4

Export

Excel, CSV or JSON, with matched, flagged and unmatched lines kept as separate, labeled groups.

FlowParse
flowparse.io

One trade, one month

An electrical subcontractor with a $340,000 subcontract sum, billing period six, matched against the two schedule-of-values lines their scope occupies on the GC's $2.4M owner-facing pay application.

ComponentAmount
Sub's invoice, this period$61,200
GC's billed amount for electrical scope, same period$58,900
Difference$2,300
Sub retainage rate10%
GC retainage rate (owner contract)5%

The $2,300 gap, taken alone, looks like the sub overbilled. Checked against the schedule-of-values lines directly, the sub had correctly included a small change order for additional panel work that hadn't yet been added to the GC's schedule of values — a timing gap, not a billing error, resolved by updating the schedule of values rather than disputing the sub's invoice.

FlowParse
flowparse.io

Reconciling invoices isn't a unified project management system

Worth being precise about the boundary. This doesn't replace Procore, Sage 300 CRE or whatever system manages your subcontractor relationships and change order approvals — there's no integration, no ongoing sync. You upload the documents you already have, the same way you already download a bank statement.

For the project-wide retainage picture this feeds into, see retainage tracking— this page is specifically about the sub-to-GC layer, one trade's scope checked at a time.

FlowParse
flowparse.io

Lien waivers and conditional releases

A conditional lien waiver, submitted alongside a subcontractor's invoice, states an amount the sub is waiving lien rights against, contingent on payment actually being made. That waiver amount should match the invoice it corresponds to — a waiver for a different amount than what's being paid is either a clerical error or a real discrepancy worth catching before the payment goes out.

Where a lien waiver is submitted, it's read alongside the invoice and checked for consistency — not to determine whether a conditional or unconditional waiver is legally required for a given payment, which stays a matter for whoever manages lien compliance, but to confirm the two documents agree on the number that matters.

When a sub's retainage rate doesn't match the GC's

It's common, not exceptional, for a GC to withhold a higher retainage rate from a subcontractor than the owner withholds from the GC — the difference is a cushion the GC's own contract with the subcontractor entitles it to hold, independent of what the prime contract specifies.

Each rate is read from its own governing contract and tracked separately, so a sub whose retainage is withheld at 10% while the GC's own retainage runs at 5% isn't flagged as an inconsistency — the two figures are correct precisely because they belong to different agreements.

Reconciling on a schedule that fits the billing cycle

Matching your reconciliation cadence to the project's monthly billing cycle is the simplest rule that works — checking each sub's invoice against the relevant schedule-of-values lines the same period both are prepared, rather than letting several periods of sub invoices pile up unreconciled.

For a project with a dozen or more active subcontractors, it's often more sustainable to batch the reconciliation for all subs at once, right after the GC's owner-facing pay application is finalized for the period, rather than reconciling each sub's invoice the moment it individually arrives.

Adding a new subcontractor to the picture

A new subcontractor mobilizing partway through a project adds a new invoice stream to reconcile, with its own subcontract sum, retainage rate and billing pattern — none of which need to match any existing sub's terms.

Adding a subcontractor to the reconciliation is a matter of identifying the schedule-of-values lines their scope corresponds to and uploading their first invoice — the same process as any established sub, just starting from their mobilization date rather than the project's.

Who this is for

GC project accountants

A clear, checked view of whether every subcontractor's billing actually matches what's been billed to the owner for their scope.

Subcontractors billing a general contractor

Confirmation that what you've invoiced ties out to what the GC actually billed for your work, before a payment dispute happens.

Bookkeepers serving construction clients on either side

The same reconciliation method applied whether the client is the GC or a subcontractor.

Controllers managing multiple active subcontracts at once

One consistent check applied across every sub on a job, not a separate manual process per trade.

Feeding the project accountant's close, not replacing it

The output here — a checked, matched view of what every subcontractor billed against what was actually billed for their scope — is an input to the project accountant's monthly close, not a replacement for it. Job costing, WIP schedules and the full financial picture of a project still live in whatever accounting or ERP system the firm already runs.

What changes is how much of that close is spent tracing sub invoices by hand versus reviewing a set of already-checked figures and a short list of genuine flags — the reconciliation work happens once, well before the close deadline, instead of during it.

Starting with one trade, not the whole job

A project with fifteen or twenty active subcontractors can make the idea of reconciling every one of them simultaneously feel too large to start. A more realistic path is beginning with the trade whose invoicing has caused the most confusion historically — often the one with the most change order activity — and using that as a proof of concept.

That first trade answers the practical questions before scaling up: how cleanly does the sub's invoice format actually map to the schedule of values, how much manual mapping do the flagged lines need, and how does the result compare to whatever partial check existed before. Answers from one trade transfer reasonably well to the rest of the job.

What happens with a genuine billing dispute

A flagged discrepancy that turns out to be a real disagreement — the sub believes more work is complete than the GC has billed for, or the GC disputes the sub's stated percent complete — isn't resolved by the reconciliation itself. What it provides is a precise, documented statement of exactly where the two figures diverge, which is usually most of what a dispute conversation needs to actually start productively.

Most disputes surfaced this way resolve faster than ones discovered later, because the gap is caught the period it happens rather than accumulating across several billing cycles before anyone notices the two sides have drifted apart.

Mobilization and demobilization periods

A subcontractor's first invoice on a project often includes mobilization costs — equipment delivery, site setup — that don't map cleanly to a percent-complete figure on any schedule-of-values line the way ongoing installation work does. Treated as a normal progress line, a mobilization charge can look like an inflated percent complete for very little visible work done.

Where the subcontract identifies mobilization as its own line item or an allowed early billing amount, it's read and matched as that specific category rather than folded into general progress — so a legitimate upfront cost doesn't get flagged as an overbilling simply because it doesn't follow the same percent-complete pattern as the work that follows it.

The same applies in reverse at the end of a sub's scope — a final demobilization or cleanup charge billed after the main work is otherwise complete is matched against its own line rather than checked against a percent-complete figure that's already at, or near, 100%.

Privacy

Uploads go over TLS, encrypted end to end.

Processing runs on EU-hosted infrastructure.

Original documents are deleted immediately after extraction.

Contract and subcontractor data are never used to train AI models.

Full details are on the security page.

A smaller worked example, in detail

Take three subcontractors on a mid-sized commercial build: a drywall sub with a straightforward, single-line scope; a mechanical sub whose scope splits across four schedule-of-values lines by floor; and a fire protection sub who mobilized four months into the project.

The drywall sub reconciles cleanly every period — one invoice, one line, consistent retainage. The mechanical sub's four lines require mapping their single monthly invoice against four separate schedule-of-values entries, a genuine complexity but a consistent one period to period once the mapping is established. The fire protection sub's late mobilization means their first invoice needs a one-time check that their subcontract sum and retainage terms were correctly reflected from their actual start date, not the project's.

None of the three required a different reconciliation method — the same matching logic handled a simple sub, a multi-line sub and a late-mobilizing sub without any of them needing special-case treatment.

Frequently asked questions

Reconcile a real subcontractor invoice

Upload a sub's invoice and the matching schedule-of-values lines — no signup — and see how they check against each other.

Keep reading