A clean dispute is not a clean email. It is a per-reason evidence list. The wrong list sends a portal-rejected invoice into the next change-order amendment and out of the current pay-app window — the generic "please pay, attached is our invoice" reply AR files against the next amendment and never answers. The rebuttal that moves is the one that names the rejection code, attaches the document that code requires, and clears the dollar inside the same pay cycle. Most subs do not have that packet on file because each rejection code wants a different document: G-01 (QuickBooks-only / missing portal), G-02 (portal-only / missing QuickBooks), G-03 (short payment), G-04 (portal rejection), G-05 (aged over 60 days / no portal record), and G-06 (small reconciliation delta) each want a distinct evidence file. The generic reply is why most disputes age out rather than recover. I watched a single mid-rise frame PO walk all four codes across 43 days and it is the cleanest illustration of why one packet is a loss. Day 0 the invoice landed on the portal against the SOV. Day 3 the portal flipped the row to Accepted and AR logged the win — until the GC's AP team ran their morning reconciliation and the row failed on a missing reference; the next refresh read G-02 portal-only / missing QuickBooks and the row moved into the canonical mismatch bucket. Day 8 the same line bounced into G-01 because AP replaced the row with a fresh line on a different PO number. Day 18 the GC issued a partial waiver covering ~80% of the line; the remainder sat as G-03 short payment. Day 27 the GC posted a back-charge for a retainage cure they said had been agreed at award. Day 43 the wire arrived — short by the G-03 delta, less the back-charge, which AR had treated as one packet because both were "deductions on PO 4421." They were not the same packet. G-03 required billed-versus-paid evidence and G-04 required the portal rejection record; the back-charge wanted the scope-of-work signed at award plus daily logs. The per-code evidence list, after that run, is what Drumtap builds today. For G-01 QuickBooks-only / missing portal , the packet is the QB-invoice ledger entry showing the billed line, the original signed PO or contract reference proving the line was in scope, the portal pay-app status screenshot showing the line not on the row, and the daily logs or delivery tickets for the work in scope. The check is straightforward: a billed line with an attached PO that does not appear on the GC's pay-app status. For G-02 portal-only / missing QuickBooks , the packet is the signed PO itself, the GC-issued SOV line highlighting the missing reference, the portal pay-app summary showing the G-02 status, and the QB invoice ledger entry — together with the change-order PDF if the reference rolled into a master SOV line after award. For G-03 short payment and G-04 portal rejection , the packet is the portal CSV showing the under-payment, the QB ledger entry showing the billed amount, the conditional waiver pull-down the GC asked for but the sub could not issue because the under-pay had not cleared, and the unconditional waiver sequencing the partial pay was supposed to close — the lien waiver vs conditional vs unconditional waiver read walks whether the waiver pull or a partial-payments refile is the right close. For back-charge , the packet is the GC's back-charge line on the portal with its deduction and reason code, the original scope-of-work or bid document showing what was in scope at award, the daily logs or photos for the time period under back-charge, the change-order trail showing any scope additions, and the unconditional waiver line where a real cure should have been issued against the same draw — not against the back-charge a cycle later. Drumtap's planned reconciliation workflow assembles those four evidence files at the line-item level inside the pay-app window, before the next month-end close ages the dispute out. The workflow reads every QB invoice row against the corresponding portal CSV row for the same pay-app, identifies the per-row rejection code, and prepares a review packet with the dollar gap and line-by-line dispute list. The owner decides what to send; there is no automatic portal submission or email. Live connectors and portal-log ingestion are planned and not active. The structural problem the packet addresses — the QB-side ledger versus the GC-side portal paid — is at portal reconciliation: the core problem Drumtap solves ; the SOV mechanics that produce the canonical G-code classification in the first place are at how to read a GC payment application before it's too late ; for the lien-notice and lien-rights deadlines that become the fallback once two cycles have passed, the /faq page walks the per-state clocks. Planned tiers, billing, and checkout are informational only and remain disabled pending legal review. Request early access for timing and final terms.