Most findings are never fixed, and the usual reason is that the report described a vulnerability rather than a decision somebody has to make.
The parts that matter
A title that states the problem, not the tool's name. "Any authenticated user can read other customers' invoices" beats "IDOR in /api/invoices".
Evidence. The request, the response, the screenshot, the account used. Enough for an engineer to reproduce it without guessing and without asking you.
Impact in their terms. Not "could lead to unauthorised access" but "a free-tier user can read every invoice in the system, including names and amounts". Say what an attacker gains, and what it would cost.
Likelihood, honestly. A weakness requiring a chain of unlikely conditions is worth reporting and worth marking as such. Inflating severity trains teams to ignore you.
A fix the team can make. Point at the mechanism, not the principle: which parameter needs an ownership check, which header, which configuration. "Implement defence in depth" is not a fix.
Severity
Use a scale consistently and show your reasoning. CVSS is useful shorthand and a poor standalone answer, because it does not know which host matters to you. Score the technical severity, then adjust for context — exposure, data, compensating controls — and record the adjustment.
What to leave out
Boilerplate, filler, and findings with no path to impact. A report with eight real issues gets acted on; the same report padded to forty does not.