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 QuickBooks-only row has no portal match, when a G-02 portal-only row has no QuickBooks match, when a G-03 short payment under-pays your draw, or when a G-04 portal rejection stops the submission, 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 and message, the conditional/unconditional waiver status, and 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 becomes a Drumtap G-01 through G-06 reconciliation label after the comparison — it is not a status code emitted by the portal. 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-03 short payment or G-04 portal rejection the owner must review. 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. The /pricing page describes planned tiers for information only; billing and checkout are disabled pending legal review. Request early access through /signup for timing and final terms. 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.