Portal reconciliation: the core problem Drumtap solves

Most trade subcontractors do not lose money because their numbers are wrong. They lose money because the GC portal accepts, modifies, or rejects the invoice in ways their QuickBooks never sees back as ledger entries. When a G-01 invoice missing from the portal leaves the pay-app sitting unlogged, when a G-02 missing PO/reference holds the line in the AP parking lot, or when a G-04 partial or short payment under-pays your draw, you wait through another cycle. Your QB invoice says one thing. The portal paid you a different thing. The difference is the dollar amount of the dispute — and that gap is the structural problem Drumtap is built around.

Portal reconciliation is the work of lining up what you billed (the QB invoice, after change orders and schedule-of-values updates) against what the GC actually accepted, modified, or paid out of the portal (the portal CSV, the pay-app status codes, the conditional/unconditional waiver status, the change-order sequencing on the GC's side of the schedule). Drumtap does it line item by line item: one QB row against one portal row, with the change-order trail and the waiver status as the connective tissue between them. A single line that does not match flags the whole pay app — the same way a G-01, G-02, or G-04 status code would have flagged it on the portal, except now you see it from your side of the ledger, in time to act on it before the next billing cycle rather than after.

The reconciliation produces three outputs that, together, are a dispute packet. First, the dollar amount: the sum of every line that the portal paid less than the invoice, plus every line that the portal rejected outright, plus every change order the GC marked down or excluded. Second, the evidence list: per discrepancy, the specific documents the case requires — a signed PO for the line that does not appear on the GC schedule of values, the change-order PDF for the line the GC sequenced wrong, daily logs for the line-item the GC counted under units shipped rather than units installed, and the conditional waiver pull-down for any G-04 partial or short payment the waiver status will close out. Third, the email draft: pre-filled with the discrepancy, the dollar amount, and the evidence attachments, ready for your AR person to send the GC without a back-and-forth on what the case actually requires.

This is the work that has always been in the codebase somewhere but has never had a name. AR teams reconcile by hand when they have time — usually after the month-end close, usually by exporting the portal CSV and the QB invoice report into the same spreadsheet and eyeballing the differences. Owners reconcile by feel: they know the GC pays slow, they know the portal "modified" a pay-app last month, they know there is money on the table they cannot put a number on. Drumtap makes the gap visible at the line-item level the moment a pay cycle closes, so the dispute packet exists before the next pay-app is due — not two months later, after the GC has already moved the dispute into the next change-order amendment.

For pricing on what Drumtap charges once the reconciliation surfaces a real gap and the dispute packet actually clears your bank, the /pricing page spells out the $199 / $349 / $499 monthly tiers (with Pro and Auto on the Coming-next waitlist) and an illustrative-only recovery-fee figure (no fee schedule has been published; Drumtap does not charge under the 2–8% band today). For the specific rejection codes that drive most of those gaps, start with the GC-portal-rejections read; for the lien-rights and waiver-timing side of the same reconciliation, the lien-rights, lien-waiver-timing, and partial-payments read covers how a partial payment becomes a clean dispute packet without sacrificing the leverage your lien rights give you.