Why pay applications get rejected: the 7 causes and how to fix each
Seven causes cover nearly every rejection: the G703 does not tie to the G702, a line’s own math is broken, the carry-forward from last month fails, a line is billed over 100%, retainage is at the wrong rate or base, Line 2 holds unapproved change orders, or paperwork is missing. The first six are arithmetic, so you can catch and fix them before you send.
Build your pay app free
Type your G703 lines, check the math, download the PDF. Next month carries over. No account.
1. The G702 and G703 don’t agree
The continuation sheet’s column totals must equal the certificate’s Lines 3 and 4 exactly (here’s how the two forms tie). A single mistyped digit anywhere in the schedule breaks the tie. This is the classic bounce: the reviewer adds up Column G, gets a different number than Line 4, and sends the whole packet back. When the totals break and the bad digit is not obvious, work through the seven specific causes of a G702/G703 mismatch, and the check that isolates each before anything goes back to the sub.
2. A line item’s own math is wrong
G ≠ D + E + F, or the balance to finish isn’t C − G. It comes from a copy-paste or formula slip in the sub’s spreadsheet. Easy to make, tedious to find by hand, trivial for software to localize. In a formula-linked G702/G703 Excel template both columns are formulas, so it only happens when someone types over one.
3. It doesn’t carry forward from last month
This month’s “previous applications” column must equal last month’s work completed, line by line, and Line 7 must equal last month’s Line 6. Drift here reads as double-billing even when it’s an innocent error, and it is a hard rejection.
4. Overbilling or front-loading
A line over 100% complete, or early-schedule lines billing far ahead of plausible progress. Reviewers, owners, and lenders all watch for this; a percent-complete column that doesn’t square with the site tells them to distrust the whole application.
5. Retainage computed at the wrong rate or base
The contract says 10% until 50% completion; the application holds 5%. Or retainage on stored material was skipped. Either way Line 6 is wrong, and so is every number after it. Before rejecting over Line 5, confirm the contract’s rate and any step-down against how retainage is calculated and where it goes wrong, then recompute 5a and 5b in the free retainage calculator.
6. Change orders that aren’t approved
Line 2 including pending or disputed change orders inflates the contract sum to date and everything downstream. Receivers check Line 2 against their own change-order log.
7. Missing signatures, notarization, or lien waivers
The application is arithmetically perfect and still unpayable: no notarized certification, missing conditional waiver, or a waiver amount that doesn’t match the payment. Requirements vary by state and by contract. Keep a checklist per project.
Catching all of this before it costs a cycle
Causes 1 through 6 are deterministic: they violate arithmetic the document itself defines. If you send pay apps, type your figures into the free builder before they go out: it runs the same identities, shows each failure with the expected figure and the dollar gap, and downloads the G702/G703 as a PDF. If you receive them, PayAppCheck runs every identity on upload, including the month-over-month carry-forward, so the sub gets one correction request instead of a payment cycle of back-and-forth. Start with the full review checklist.
Questions people ask
What is the most common reason a pay application gets rejected?
Arithmetic that does not tie between the two forms: the G703 continuation sheet’s column totals must equal the G702 certificate, with the sum of Column C equal to Line 3 and the sum of Column G equal to Line 4. A single mistyped digit anywhere in the schedule breaks that tie, and the reviewer sends the packet back. Paperwork gaps such as missing notarization or lien waivers come second.
Can a rejected pay application be resubmitted?
Yes. A rejection is a request for correction, not a forfeiture: the subcontractor fixes the numbers or the paperwork and resubmits, and the receiver reviews the corrected packet against the same checks. The real cost is time, because most contracts run monthly billing cycles, so a rejection pushes payment back at least one cycle. Sending one complete correction request, with every error listed, prevents a second round.
Who has the authority to reject a pay application?
Whoever the contract names as the reviewer. On AIA-style contracts the architect certifies payment and can certify a lower amount than applied for or return the application, the general contractor rejects subcontractor pay applications before they roll up, and owners and lenders can refuse funding on top of that. Check the contract’s payment article for the named certifier and the deadline to respond.
How do I stop pay applications being rejected for math errors?
Check the identities the forms define before the application enters your approval flow: per line G = D + E + F and H = C - G, column sums tying to G702 Lines 3 and 4, retainage Line 5 = 5a + 5b, payment due Line 8 = Line 6 - Line 7, and this month’s Column D equal to last month’s D + E. Every one of these is deterministic, so software can verify them on upload and return one list of exact errors. PayAppCheck runs all of them the moment a pay application is uploaded and flags each failure with the expected figure, the stated figure, and the dollar delta.
What do I do when my pay application is rejected?
Find the exact line, the figure it states and the figure the reviewer expected, then correct that figure and everything computed from it. A wrong Column E figure moves Column G on its row, then Line 4, Lines 5a and 5, Line 6, Line 8 and Line 9, so fix the whole chain rather than the one box named. Recheck every identity before you resubmit: G = D + E + F on each row, the Column G total equal to Line 4, Line 5 = 5a + 5b and Line 8 = Line 6 - Line 7. Then send the corrected G702 and G703 back together.
Check yours before you send it.
Make a pay app