'Accepted' on a GC portal does not mean 'approved' or 'paid'

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 missing PO/reference onboarding 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 reconciliation is what surfaces 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. That packet ships pre-filled inside the pay-app window, not two months later. What Drumtap is actually qualified to do today, on the Starter plan — the one shipped plan there is today — is manual reconciliation and export review. Drumtap reads CSV uploads today; live QuickBooks and GC-portal connectors, banking-feed verification, and portal-log ingestion are planned and not active (Coming next). On refile actions, Drumtap builds upload-based refile packets on Auto (Coming next); there is no API refile today on any tier — every portal resubmission is yours. On email, Drumtap does not send dispute emails on any tier today: Starter is read-only — Drumtap builds the evidence package; you send it yourself; Pro drafts for review before they go out (Coming next); Auto sends within the rules you approve (Coming next). On cleared-funds tracking, Drumtap does not connect to any bank: the reconciliation is portal CSV against QuickBooks CSV, not against disbursement. The honest framing: Drumtap is qualified today to manual reconciliation and export review. The reconciliation tells you the gap. You decide what to send, when to send it, and when the bank confirms.

Walk the reconciliation loop end-to-end on the /how-it-works page — the three-step CSV upload, line-by-line reconcile, and the Starter dispatch where you send the package yourself. For the founder-story framing on why Drumtap ships Starter-only today (manual upload, you send) with connectors, pre-drafted email, and within-rules send sitting on the roadmap, the /why-drumtap page spells out the tier cadence and the read-only-Starter posture in one read. For the monthly subscription on Starter ($199/mo available today) plus where Pro ($349/mo) and Auto ($499/mo) sit on the Coming-next waitlist, the /pricing page lays it out: 2–8% is illustrative only and Drumtap has not published a fee schedule covering the percentage, the trigger, partial payments, retainage, or disputed deductions; Drumtap does not charge under the 2–8% band today. 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.