A GC pay-app moves through four discrete states, and the GC portal shows them as four separate labels in the same column. "Submitted" is the file you dropped into the upload box. "Accepted" is the portal confirming the file arrived and matched the schema it expects — a dollar amount on a line, an invoice number, the GC's project code on the row. "Approved" is the next step: the PO line is funded and the change orders are sequenced against the GC's schedule of values. "Paid" is the cleared wire your bank shows on the statement. "Accepted" is none of those three things. "Accepted" is the GC's portal confirming receipt. It is the status the GC pay-app summary shows next to the dollar amount, and it is the moment trade AR teams stop pushing. The first thing to internalise: accepted does not mean approved. Accepted does not mean paid. The dollar on the accepted line is not what lands in your account. I watched a single PO on a mid-rise frame job walk this exact pattern over 43 days and it is the cleanest illustration of why "accepted" cannot be treated as "approved" or "paid" that I have seen. Day 0 the invoice was submitted through the GC portal against the schedule of values. Day 2 the portal flipped the row to Accepted — file received, schema matched, dollar amount visible — and the AR team logged the win. Day 8 the row sat on Accepted while AP at the GC "parked" the line pending a missing PO reference, the same G-02 portal-only mismatch that shows up on most portal reconciliation runs. Day 29 the GC issued a partial waiver covering roughly eighty percent of the line. Day 36 the GC issued a revised waiver. Day 43 the wire arrived — short by the change-order the GC had sequenced into a master SOV line two cycles earlier. The dollar gap had been sitting on the portal the whole 43 days, right next to the Accepted label. The receipt the GC mailed to the job trailer showed Accepted . The bank never knew the wire was partial, and the AR team never saw the change-order adjustment until they reconciled the pay-app CSV against QuickBooks after the next month-end close. The line to take from it: accepted means the GC's portal has your file. Neither approved nor paid means what most people think it means. Drumtap's planned reconciliation workflow is designed to surface that gap at the line-item level inside the pay-app window, before the next month-end close ages it out. Every QuickBooks row is paired against the corresponding portal CSV row for the same pay-app, the change-order trail and the conditional/unconditional waiver status sit between them, and the discrepancy list sums into the dollar amount of the dispute. The planned workflow starts with manual reconciliation and export review; live QuickBooks and GC-portal connectors, banking-feed verification, and portal-log ingestion are planned and not active yet. Drumtap does not connect to any bank, submit to a portal, or send dispute emails automatically. The honest framing: the reconciliation tells you the gap, while you decide what to send, when to send it, and when the bank confirms. Access and any paid terms remain disabled pending legal review. Walk the reconciliation loop end-to-end on the /how-it-works page — the three-step CSV upload, line-by-line reconcile, and owner-reviewed follow-up. The /pricing page describes planned tiers for information only; access, billing, and checkout remain disabled pending legal review. Request early access through /signup if you want timing and final terms when the private beta opens. For the structural framing of the same problem (QB invoice vs GC portal paid, the line-by-line gap that becomes the dispute packet), start with portal reconciliation: the core problem Drumtap solves . For the specific SOV mechanics — what the schedule of values sets as your draw ceiling, the three line items most commonly missed, and how retainage compounds every rejection — read how to read a GC payment application before it's too late .