Many software projects do not end; they fade. The last few changes trickle in by email, the customer uses the system without ever saying it is accepted, and the final invoice waits because nobody is sure the work is finished. Months later a small request turns into an argument about whether it belongs to the project or not.
A formal close takes about two hours of work and one meeting. It protects both sides: the customer knows what they own and who to call, and you know the project is done and can be invoiced. This article is a routine for closing a project with a customer, whether you are the supplier or the person on the customer side who manages it.
Step 1: Start from the acceptance criteria
Acceptance only works if the criteria were written before the work began, usually in the order or the project brief. If they were not, write them now as a short list of observable statements: "A user can create an order and the confirmation email arrives", "The monthly report matches the old spreadsheet for March", "Ten named users can sign in".
Keep the list to what was ordered. New wishes that appear during acceptance go to a separate list for later; they are not a reason to delay the close.
Step 2: Run a short acceptance session
Book 60 to 90 minutes with the person who uses the system and the person who signs. Go through the criteria one by one, using real data where you can. A two-hour acceptance session with real work describes how to run this well.
For each criterion, write one of three results: accepted, accepted with a small fix, or not accepted. Do not argue about the result in the room; write down what would change it.
Step 3: Make one list of open items
Everything that is not fully accepted goes on a single list with four columns: what, who fixes it, by when, and how the customer will check it. Fixes that are part of the order are done before the final sign-off, or the sign-off names them explicitly. Anything new is quoted separately.
A project can be closed with a short list of small, dated fixes. It cannot be closed with a vague sentence such as "some things still to tidy".
Step 4: Hand over more than the software
A running system is not a handover. Prepare a one-page pack and go through it with the customer:
- Access: who has administrator rights, where accounts and domains are registered, and which of them are in the customer's name. Never send passwords by email; use the customer's password manager.
- Documents: a short description of how the system works, how to run the common tasks and what to do when something stops. Keep it to a few pages.
- Data and backups: where the data lives, how often it is backed up and how to get it out.
- Source and licences: who holds the code and which third-party licences or subscriptions the customer now pays for.
- Owner: one named person on the customer side who decides about the system. If the author leaves, a one-page handover keeps this from being lost.
Do a basic security check of what you hand over: remove test accounts, change shared passwords and confirm that access is limited to the people who need it. The UK National Cyber Security Centre's small business guide lists the basics.
Step 5: Sign and invoice on the same day
Write a half-page acceptance note: the project name, the date, the result of the session, the open-items list and a line saying that the work in the order is accepted once those items are done. Both sides sign it, or confirm it by email from named addresses.
Send the final invoice the same day. It should match the order and the earlier invoices, refer to the acceptance note and use the payment terms the customer already agreed. If a short fix list is still open, you can agree to invoice the last small part after it is done, but say so in the note. For late payments, the rules on interest and recovery are set out by GOV.UK; a polite three-step reminder routine keeps the conversation friendly.
Step 6: Say what happens next
The most common source of friction after a close is the first problem. Before you part, agree what the customer should do when something breaks, how quickly you respond and what costs extra. A monthly support agreement puts this on one page. If the customer does not want an agreement, at least write down a contact, a response time and an hourly rate for changes.
Plan a short check after 30 days: has the system been used as intended, and is anything small waiting? That is also the right moment for a thirty-minute retrospective and, later, for archiving the project files.
Where AI tools fit in
An assistant can turn the order into a draft acceptance checklist, tidy your meeting notes into the open-items list or draft the handover pack from your technical notes. A person who knows the project must read and correct the result, and no customer data or credentials should be pasted into a tool that your contract does not allow.
What to do this month
- Pick one project that has no formal close and write its acceptance criteria from the original order.
- Book the acceptance session and prepare the open-items list template.
- Fill in the handover pack: access, documents, data, licences and owner.
- Send the acceptance note and the final invoice on the same day.
- Put a 30-day check in the calendar.
This is general guidance for small businesses, not legal advice. Check your contract for its own acceptance and payment terms.
Sources
- GOV.UK, Late commercial payments: interest and debt recovery: the rules on interest and recovery when a business customer pays late.
- National Cyber Security Centre, Small Business Guide: basic steps for accounts, passwords, backups and access.