A subcontractor's pay application is rarely stuck because someone decided not to pay it. It is stuck because nobody can prove, quickly, that it should be paid.
The concrete sub calls asking where their money is. To answer, the project manager has to confirm the work billed for is actually in place, the project accountant has to check it against the subcontract and the budget, someone has to find the lien waiver for the current period, the retention has to be figured correctly, and the insurance certificate has to still be current. Each of those lives in a different system or a different inbox. So the pay app waits, the sub chases, the project team chases the field, and the relationship pays for what is really a paperwork problem.
If you run finance or commercial on construction projects, this is the workflow where slow proof quietly costs you goodwill and, on a bad month, a good subcontractor who decides your jobs are more trouble than they are worth.
What "clear to pay" actually means on a construction job
Approving a pay application looks like an accounting task and is really a cross-team one. Before a sub's billing is genuinely clear to pay, several things have to line up at once: the work it bills for is in place, it sits inside a signed subcontract or purchase order with budget left against the right cost codes, the lien waiver for the period is in hand, retention is calculated correctly, the sub's insurance and any compliance documents are current, and someone with authority still owes the approval.
When those answers are spread across the field, the project management office, and accounting, the pay app moves only as fast as the slowest person you can reach. The job is to put the proof in one place, so a clean pay application moves and a questionable one is visibly held with a reason and an owner attached, instead of sitting silently while everyone assumes someone else is handling it.
A pay application is not a normal invoice
Part of why this workflow breaks is that people treat a pay app like any other vendor bill, and it is not. A subcontractor bills against a schedule of values, usually on an AIA G702 and G703 or a similar continuation sheet, showing the percentage complete on each line, work stored but not yet installed, the total earned to date, retention held, and the net due this period. It is a cumulative claim, not a fresh invoice, so it only makes sense when you can see it against the last one and against the subcontract total.
That structure is where the checking work comes from. Someone has to agree the percentages reflect real progress, confirm stored-material claims are backed by delivery and protected on site, and make sure the retention and prior-payment math ties out. A number that looks reasonable in isolation can still be wrong because the sub billed the same line twice across two periods, or because a change order moved the contract value and the continuation sheet was never updated. None of that is caught by looking at the bottom-line figure.
Walking the approval chain, and where it stalls
On most jobs the path a pay app travels is roughly the same, and so are the places it gets stuck.
The subcontractor submits the pay application, often near a monthly cutoff, sometimes with the lien waiver attached and sometimes not. The project manager or superintendent is supposed to verify that the billed work is actually in place, using their own walk of the site, the daily reports, and progress photos. The project accountant then checks the billing against the subcontract, confirms budget remains on the right cost codes, recalculates retention, and looks for the current insurance certificate and any required compliance paperwork. A project executive or owner approves at a threshold. Then the whole thing rolls up into the general contractor's own requisition to the owner or lender, and cash comes back down the chain to the sub.
Every handoff in that chain is a place the pay app can stop. The field is busy and the percentage-complete confirmation slides. The lien waiver never arrived, or arrived for the wrong period. The insurance certificate lapsed last week and nobody flagged it. The change order that raised the contract value is approved in email but not in the accounting system, so the billing looks like an overbilling. The owner's draw is on a fixed monthly cycle, so even a clean pay app waits for the requisition window. Nobody in the chain is refusing to help. They just cannot see the same picture at the same time, so every payment becomes a small investigation that starts over with the next one.
Lien waivers: the paperwork that quietly holds the money
The single most common reason an otherwise-clean pay app sits is the lien waiver, because it is both a legal document and a timing puzzle. A sub exchanges a waiver for payment, but the type and the period have to match, and the lower-tier waivers from that sub's own suppliers and second-tier subs often have to come with it before the general contractor is comfortable releasing funds.
This is worth getting right in your workflow because a mismatched or missing waiver is easy to catch mechanically and expensive to miss. The four common forms line up like this.
| Waiver type | When it is used | What it releases | Common mistake |
|---|---|---|---|
| Conditional progress | Exchanged for the current period's payment | Rights for that period, effective only once the payment clears | Treated as final proof before the check has actually cleared |
| Unconditional progress | After the sub has received the current period's payment | Rights for that period, unconditionally | Signed before funds arrive, giving up rights with nothing received |
| Conditional final | With the final payment and retention release | All remaining rights, effective once final payment clears | Collected before retention and open change orders are actually settled |
| Unconditional final | After final payment has been received | All remaining rights, unconditionally | Missing lower-tier waivers behind it, so exposure remains |
The point of putting this in the queue is not to give legal advice, and your counsel and your state's rules govern the actual forms and deadlines. It is to make the waiver a checkable field on every pay app: which type is required this period, is it present, does it match the amount and the dates, and are the lower-tier waivers behind it accounted for. A waiver problem that used to surface during the payment run should surface the moment the pay app lands.
Retention is easy to carry wrong
Retention, or retainage, is the slice held back on each payment until the work is complete, often five or ten percent, and it drifts more than people expect. The held amount has to be tracked per subcontract and per period, the release has to trigger at the right milestone or at completion, and reduced-retention arrangements partway through a job have to be applied consistently. When retention lives only inside the accounting system's running total and never on the pay app itself, disputes about how much is being held, and when it comes back, become their own round of chasing.
A workflow that carries retention as a visible line on each request, held to date and released to date against the subcontract, turns those disputes into a number both sides can see. It also makes the final-payment moment cleaner, because retention release is one of the points where lien waivers, open change orders, and punch-list completion all have to close at once.
The subcontractor paperwork that stalls otherwise-good pay apps
Beyond the billing itself, a pay app can be entirely correct and still not be payable because a compliance document is stale. The most common are the certificate of insurance that has lapsed or does not name the right additional insured, and, on public or prevailing-wage work, certified payroll that has not been filed for the period being billed. Some jobs also require conditional waivers from lower tiers, updated safety documentation, or W-9 and tax details before a first payment.
These are exactly the items that are invisible until the payment run, when someone notices the insurance expired and the whole release stops. Treating them as standing fields on each subcontractor, checked automatically against the billing period, means a lapse shows up as a flag with a name next to it days earlier, while there is still time to get the updated document without holding the money.
Where the hours go today
Pay applications land through email, the accounting or ERP system, a project management platform, or a subcontractor portal. The proof that would clear them lives somewhere else: field reports and progress photos in the project tool, the subcontract and change register in document control, the lien waivers in an inbox or a shared drive, the insurance certificates with whoever tracks compliance. Accounting chases the project team, the project team chases the field, and the sub chases everyone.
No one in that chain is careless. They simply cannot hold the same picture at once, so the work of assembling each payment packet gets done from scratch every month, and the person who feels it most is the one who has to answer the sub's phone call.
The fix: one queue where each pay app carries its own proof
The first useful version is a single queue where each pay application carries its own proof and its own owner, so the answer to "why is this not paid yet" is on the screen instead of in three inboxes. That queue holds each request in one line with the subcontractor, the project, and the cost codes it bills against; the proof it needs, each marked present or missing, from work-in-place confirmation to lien waiver, retention, insurance, and any change order; and a clear status with the name of whoever holds it now.
That is the difference between a folder of pay apps and a workflow. The folder tells you what arrived. The queue tells you what is clear to pay, what is held, why, and whose move it is next. The status is where it earns its keep, because a pay app is never just "in progress." It is waiting on a specific thing from a specific person, and when the queue says which thing and which person, the daily chasing turns into a short list of nudges instead of a round of discovery emails.
Example: what an approval queue looks like
| Payment request | Status | Blocker | Owner |
|---|---|---|---|
| Concrete subcontractor, Building B | Held | Change order in email, not yet in the subcontract value, so the billing reads as overbilled | Project accountant |
| Electrical, tenant improvement | Held | Conditional lien waiver missing for this period | Project manager |
| Steel supplier, stored materials | Under review | Delivery confirmed, on-site protection not yet verified | Superintendent |
| Mechanical, retention release | Ready to pay | None | Project executive |
Pick one pay app that sat too long last month and ask whether anyone can now see, in five minutes, why it was held, what was missing, and who was supposed to clear it. If the honest answer is another round of emails, that is the workflow to fix first.
Say a GC running 14 projects pays 90 subs a month
To make this concrete, and this is an illustrative example rather than a real company, say a general contractor runs 14 active projects and pays roughly 90 subcontractors and suppliers each month, with most billings clustered around a monthly cutoff. In a good month, perhaps sixty of those pay apps are clean and move without much thought. The trouble sits in the other thirty.
Ten are missing the current lien waiver, or have the wrong type. Eight are billing against a scope that a pending change order was supposed to move, so the percentages look off until the change is booked. Six have an insurance certificate that lapsed sometime in the last few weeks. Four have a stored-materials claim with no proof the material is on site and protected. Two have a retention figure that does not tie to the running subcontract total. None of these are refusals. Every one of them is a document or a confirmation that exists somewhere and has not been matched to the billing yet.
Under the old habit, the project accountant finds these one at a time during the payment run, near the cutoff, under pressure, and each one triggers an email and a wait. With a queue, all thirty surface the day the pay apps arrive, each tagged with the missing item and the person who can supply it. The volume of exceptions is the same. What changes is that they are visible early, named, and owned, so the sub gets an answer instead of silence, and the clean sixty are never held up behind the messy thirty.
The checks every pay application has to pass
Underneath the queue is a short, honest definition of what a payable pay app looks like on your jobs. Writing it down is more than half the work, because most of the delay comes from the checks living in people's heads. The set below is a starting point; the exact list depends on your contracts and your jurisdiction.
| Check | What proves it | Where it comes from | Who owns the call |
|---|---|---|---|
| Work is actually in place | Percentage complete agrees with the site | Site walk, daily reports, progress photos | Project manager or superintendent |
| Billing sits inside the commitment | Amount fits the subcontract or PO, with budget left on the cost codes | Subcontract, commitment ledger, budget | Project accountant |
| Change orders are reflected | Contract value on the continuation sheet includes approved changes | Change order register, accounting system | Project manager and accountant |
| Lien waiver is in hand | Correct type and period, matching the amount, with lower-tier waivers | Subcontractor submission, document control | Project accountant |
| Retention is correct | Held and released to date tie to the subcontract | Accounting system, prior pay apps | Project accountant |
| Compliance is current | Insurance and, where required, certified payroll cover the period | Compliance tracking, subcontractor records | Compliance or accounting owner |
| Someone still owes the approval | The right person has signed at the required threshold | Approval chain | Project executive or owner |
Once that definition exists, everything downstream has something to attach to. Before it exists, any tool you add is just moving undefined work around faster.
Where AI helps, and where it must not
AI is genuinely useful here, and it is useful in a narrow way. It can read the pay application and the continuation sheet and pull the fields, match the billing against the subcontract and the schedule of values and flag where they disagree, check whether the lien waiver present is the right type for the period and whether its amounts tie, recompute retention and prior payments, notice that an insurance certificate expires before the billed period ends, summarize why a given exception is stuck, and draft the follow-up to the subcontractor. That work is reading, extracting, checking, and drafting, and it is where the hours are lost today.
What it must never do is release a payment or wave through a hold. Every commercial approval and every release decision stays with the accountable person on the project or finance team. The value is not that judgment gets automated. It is that the accountable people spend their time on the judgment, on whether that percentage is really complete and whether that change is really approved, instead of on assembling the packet the judgment depends on.
The data and systems underneath
The pieces sit in the usual places: the construction accounting or ERP system, whether that is Sage 300 Construction and Real Estate, Viewpoint Vista, CMiC, Foundation, or another; a project management platform such as Procore or Autodesk; document control for subcontracts, waivers, and change orders; the compliance tracker for insurance and certified payroll; the bank or ACH payment file; the subcontract and commitment ledger; and, on almost every job, some spreadsheets holding the parts the systems do not.
Start from the question, not the systems: what makes one pay app clear to pay on your projects, and which source proves each part. For some teams the first build is a structured approval queue sitting over exports from those systems, refreshed on a schedule. For others it becomes a live connection between the accounting, project, and document systems. Either way the definition of clear to pay comes first, and the connections are chosen to serve it rather than the other way around.
What tends to go wrong
The same traps repeat across teams that try this. The first is treating it as a finance-only workflow, when the field and the project managers hold half the proof; a queue that only accounting can see never gets the percentage-complete confirmation it needs. The second is automating the extraction of pay-app fields before anyone has agreed what a complete, payable request looks like, so the queue fills with tidy-looking numbers that still need a human to judge them. The third is letting a hold sit without a reason and an owner, which just moves the chasing from the inbox into a nicer-looking list.
A fourth is specific to construction and worth naming: letting the lien waiver and insurance checks stay manual because "we usually catch them." Usually is the problem. These are the items most easily checked by a machine and most expensive to miss, and they are the ones that stop a payment run cold when they slip. Each of these traps has the same tell. The subcontractor still has to call to find out what is happening.
A sensible order to build it in
You do not need a platform decision to start. You need one payment type or one subcontractor group and an honest walk back through recent late payments to see why each one stalled. The sequence below is what usually works.
| Stage | Focus | What should exist by the end |
|---|---|---|
| Week 1 | Define clear to pay for one payment type | The written checklist of what a payable pay app requires, and a queue showing each request, its status, its proof, the reason it is held, and the owner |
| Weeks 2 to 3 | Connect only the sources that keep the queue honest | Enough of the accounting, project, document, and compliance data to populate the checks, with AI pulling fields, matching to the subcontract, and flagging waiver, retention, and insurance issues |
| Week 4 | Run a real payment cycle through it | One screen before the payment run showing which pay apps are ready, which are held, why, and who owns the next step |
| Beyond | Widen or deepen, deliberately | A second payment type or a tighter live connection, added only once the first is trusted before the payment run rather than after it |
The test for whether to keep going is simple. Before the payment run, can the team look at one screen and see which pay apps are clear, which are stuck, why, and whose move is next? If yes, widen it. If the proof sources or the approval authority are still too fuzzy to trust, narrow it until they are not.
How Ubisar would build this with you
In week one, we would pick one subcontractor group or one payment type with you and walk back through recent late payments to see exactly why each stalled. The first output is an approval queue that shows each request, its status, the subcontract and continuation-sheet links, the proof it still needs, the reason it is blocked, the owner, and a note on where it sits against the owner draw.
In weeks two and three, we would connect only the accounting, project, document-control, and compliance data needed to keep that queue honest, and let AI pull the pay-app fields, match them to the subcontract and schedule of values, check the lien waiver and retention math, flag lapsing insurance, and draft the subcontractor follow-ups, while your project and finance people keep every approval and release. By week four, the team should be able to look at one screen before the payment run and see which pay apps are ready, which are held, why, and who owns the next step. We keep going if that picture is clear before the run instead of after it, and we narrow it if the proof or the approval authority is still too loose to trust.
This fits with the neighboring work on a job. An upstream bid comparison workflow makes payment checks easier, because the scope and terms you are checking against were leveled and written down before award. A change order approval workflow keeps the contract values current, so pay apps stop reading as overbillings. And the field proof that clears a pay app comes straight out of a working site report and field issue workflow and the RFI and submittal routing around it. It is all part of the same real estate and construction picture.
If late subcontractor payments are costing you goodwill and, on a bad month, a good sub, bring us one payment type and we will build the queue around it. That is how AI, Data & Tech Implementation works: one workflow a month, starting from $4,000/month, cancel anytime. If you want to talk it through first, get in touch and we will reply within one business day.