As addition to the other answers:
When your contract states your scope and which vulnerabilities to test, you could write down that you actually tested cases in scope against known vulnerabilities defined in the contract. Something like:
SQL-Injections are ...
We identified 42 Input fields in the Webpages in Scope. We identified 0
Input fields vulnerable to SQL injection (with our used method).
Drawback is: in case there actually is a SQL-Injection possible in one of the listed fields appended to the report; you didn't promise 100% security but promised that this isn't a vulnerability, but then you surely made something wrong - that's why you should somehow state which kind of tests you used, what kind of SQL-Injections are state of the art in the introduction to SQL-Injections, so you will not be blamed for not finding attacks which will be found in future.
This also works for general Website-Security stuff:
HTTPS: https is ... recommended to use TLS X.Y ...
We determined the usage of https for all websites in Scope with TLS X.Y.
Certificates expire Dates are set to Date X which is in the recommended
certificate expire time range. Certificates hold an 4096-Bit key which is
acceptable for current usage.
Also try to create templates of your reports since you don't want to rewrite everything about SQL-Injection and HTTPS/TLS etc. over and over again, so you only have to fill the results of your tests. This will also ensure you made all tests and did not miss any, when you see some paragraph not written to be done and not found anything nor have any findings.