Website acceptance checklist before you invoice
The final acceptance pass on a client website: what you verify, what the client decides, and the exact point at which sending the invoice is safe.
Acceptance is not QA
QA is your own work: bugs, layouts, accessibility, performance. Acceptance is the client's decision that the delivered pages match the agreed scope — and it is only provable if it is attached to evidence of what was actually delivered. Keep the two separate in your process and in your email.
Before sending for acceptance (your part)
- Confirm every page is deployed at its final public URL — no staging links, no preview params.
- Resolve all redirects: the URL the client approves should be the URL that will keep working.
- Capture desktop and mobile screenshots of each page in the acceptance scope.
- Record the capture timestamp and content hash per page, so the decision binds to a version.
- Sanity-check the boring technical facts: page titles, canonicals, no stray noindex, no 404 assets.
What the client decides (their part)
- Each page gets its own decision: approved, or a specific change request.
- Change requests name the page and the element — not "make it pop".
- One review link covers the whole scope, so nobody is digging through email attachments.
The invoice trigger
Safe to invoice when all three hold:
- Every page in scope is approved, or its requested changes were made and re-approved.
- The approval is recorded against the captured version — link, timestamp, per-page status.
- The invoice itself references that approved version, so finance and client memories agree.
If pages change after acceptance
Re-run the capture. Pages whose content hash is unchanged keep their acceptance automatically; only genuinely changed pages go back to the client. This turns "small edit in three weeks" from a trust negotiation into a two-minute decision. See the changed-page approval guide for that flow.