A contract review checklist before you hit send

Why a checklist catches more than just reading it over

A careful read-through feels thorough but misses exactly the errors that matter most, because your eyes skip over things you expect to be correct. A checklist works differently: it forces you to check specific, narrow things in a fixed order, which is precisely what catches a wrong date or a leftover name from the last client, the kind of error a general read-through slides right past because the sentence still reads smoothly. This matters more than it sounds like it should, because most contract-sending mistakes aren't caused by carelessness, they're caused by familiarity: the tenth time you've sent this exact template, your brain has started skimming the parts it already "knows" are fine, which is exactly where an old detail hides.

The twelve checks

1. Both parties' legal names are correct and match their actual registered business names, not a shortened or informal version that could cause confusion about who's actually bound.
2. Every date is correct and internally consistent, the effective date, the term length, and any deadline dates actually line up with each other rather than contradicting.
3. The price, rate, or payment amount matches what was actually agreed, not a figure copied from a previous version of the template that was never updated.
4. Payment terms are specific: when payment is due, by what method, and what happens if it's late, rather than left vague.
5. The scope of work or goods matches the current deal exactly, with no leftover language describing a previous client's different scope.
6. The termination clause is present and states real notice periods, how either party can end the agreement and how much notice is required.
7. Auto-renewal terms, if any, are clearly stated, including the notice period required to prevent renewal, not just that the contract "may renew."
8. Liability and indemnification language matches your actual risk tolerance for this specific deal, rather than defaulting to boilerplate that may be too broad or too narrow.
9. Confidentiality and intellectual property clauses say what you think they say, particularly who owns work product created during the engagement.
10. Signature blocks have the correct names and titles for whoever is actually signing, matching your own signing authority policy if you have one.
11. Every reference to an exhibit, appendix, or attachment is actually included in the final document, not referenced and then forgotten.
12. The document has been read once by someone other than whoever drafted it, even a quick pass, since the person who wrote it is the least likely to spot their own error.

The errors this actually catches, in practice

In practice, four of the twelve checks catch the overwhelming majority of real mistakes: the price or rate copied from an old version (check 3), a scope description that still mentions the previous client's project (check 5), inconsistent dates where the effective date and the signature date don't match the term described elsewhere in the document (check 2), and a termination or auto-renewal clause nobody actually re-read before sending (checks 6 and 7). These are specifically the errors a template-based workflow creates, since templates make drafting faster by reusing old language, and that same reuse is exactly what lets an outdated detail survive unnoticed into a brand new deal.

Who should run the review on a small team

Whoever drafted the contract should run the checklist themselves first, as a baseline. But check 12, a second set of eyes, matters more than it sounds like it should, because the person who wrote a sentence reads it the way they meant it, not necessarily the way it's actually written. On a small team, this doesn't need to be a formal approval step for every contract, pairing it with your approval workflow's existing review tiers is usually enough: anything that already requires an approver gets their second read as part of that process anyway, and anything that doesn't still benefits from asking a colleague for a two-minute glance before it goes out.

What this looks like filled in on a real contract

Picture a standard client services agreement built from last month's template. Running the twelve checks: the client's legal name is correct (check 1 passes). The effective date matches the signature date, but the term length still says "12 months" from the previous client's annual contract when this one is meant to be month-to-month (check 2 fails, caught before sending). The rate field correctly shows the new client's agreed price (check 3 passes). The scope section still includes a line about "quarterly reporting" that was specific to the last client and was never part of this deal (check 5 fails, caught before sending). Everything else passes on review. Two real errors caught, both exactly the kind that slip through a general read-through because the sentences themselves read perfectly smoothly, they're just describing the wrong deal. Putting the checklist inside a short contract SOP means the review step never gets skipped.

Making the checklist an actual habit, not a one-time printout

A checklist only works if running it takes less effort than skipping it. Keep it to the twelve items above, printed or pinned somewhere visible, rather than letting it grow every time someone remembers a new edge case, since a thirty-item checklist gets skipped entirely under deadline pressure while a twelve-item one survives it. If your team sends contracts often enough that this starts to feel repetitive, build the checks directly into your contract template instead: lock the fields that change (party names, dates, rate, scope) into clearly marked blanks, which does a good part of checks 1 through 5 automatically simply by making it obvious at a glance which fields still need filling in for this specific deal. A guide to merge fields shows how to fill those blanks automatically.

How I'd approach this

I run some version of this checklist on every contract I send, not because I don't trust my own drafting, but because the specific failure mode, a leftover detail from the last version surviving into a new document, happens to everyone who reuses templates, and it happens precisely because the rest of the document reads correctly. The businesses that catch these errors reliably aren't the ones being more careful in general, they're the ones running the same fixed list of checks every time rather than relying on a careful feeling. If you're drafting the same type of contract often enough that this checklist becomes repetitive, that's usually also the point where a proper template with locked fields for the parts that change, name, date, rate, scope, saves more time than the checklist itself, since it prevents several of these errors from being possible in the first place rather than catching them after the fact. The checklist and the better template aren't competing solutions, the checklist catches what slips through even a well-built template, since nothing prevents someone from typing the wrong number into a correctly labeled blank.