UAT sign-off belongs to two people on the client side: the business owner who will run the application in production signs off the functions, and IT signs off the technical side. The vendor's project manager countersigns, which is how they accept the list of open defects. The time allowed to fix a blocking defect goes into the contract before development starts, in working days counted from the moment the defect is classified. Without that number, every blocker is argued case by case while the go-live date slips.
In Morocco and France the signed document is called the PV de recette, and it can go wrong in two directions. Sign too early and you have accepted the application as tested, so a defect you did not list becomes much harder to get fixed. Refuse without written rules and the project stalls, the payment tied to sign-off sits frozen, and nobody can say how far go-live will slip. The severity grid and the fill-in template below are there to prevent both.
What does your contract already say about blocking defects?
Take the plan for your next campaign and the contract behind it, and look for who classifies a blocking defect and how many working days the vendor has to fix one. A text search of both files for "blocking" and then "fix time" (or whatever your contract calls them) is enough, and fits between two meetings. If either answer is missing, send the vendor's project manager the severity grid below today, with the fix times left blank, and ask for it back before the next steering committee. While the plan is open, check that every tester is named with their days booked, since the campaign moves at the pace your key users can give it.
Who signs UAT, and what does the signature commit each side to?
Three signatures are enough, as long as each one matches a real responsibility. The business owner, usually the director whose teams will use the tool every day, signs for functional conformity, because only they can say whether the tested process matches the real one. IT signs for the technical side (security, performance, backups, monitoring). The vendor's project manager countersigns the list of open items and the fix times attached to them. Your CEO does not need to sign unless your delegation of authority requires it for the payment the sign-off releases.
For you, signing means accepting the application as tested, on the scope tested. For the vendor, the signature turns every listed defect into a dated commitment, and it often starts the warranty clock. That is why the template has a line for what was not tested.
Why write acceptance criteria before development?
Criteria written after development describe what was built. UAT then checks that the application does what it does, which tells you very little. Each criterion has to exist before the first line of code, attached to a requirement, and be precise enough that a tester who missed the workshops can answer yes or no. "An expense claim above the travel policy's hotel ceiling goes to a second approver" takes a minute to check. "The approval flow is smooth" cannot be checked at all.
The business owner writes the criteria with the vendor's analyst during specification, and both sides sign them along with the requirements document. The UAT test plan is built from them, case by case, with its entry conditions, starting with an identified build and the vendor's own test report. On a custom development project, you negotiate this when you sign the contract. After kickoff it becomes a change order.
Blocking, major, minor: who classifies a defect, and what happens when the two sides disagree?
The same grid runs the campaign and feeds the sign-off. Fix times depend on how critical the process is and on the size of the vendor's team, which is why the grid leaves them for you to set.
| Blocking | Major | Minor | |
|---|---|---|---|
| Definition | A tested process cannot complete without an acceptable workaround, or data is lost or corrupted | The process completes only with a manual workaround, or a business rule is misapplied on a secondary case | No effect on the outcome (label, layout) |
| Example | An approved expense claim never reaches reimbursement | The accounting export of claims drops the cost centre | A truncated label |
| Who classifies | Business owner, same day | Business owner, at triage | Tester |
| If the sides disagree | Both project managers decide the same day; until then it counts as blocking | Next triage, then steering committee | Vendor asks for reclassification at triage |
| Fix time | To set, in working days | To set, in working days | Often the next planned release |
| Effect on sign-off | Prevents signature | Tolerated within an agreed limit, with a date | Listed, no effect on the decision |
Triage is a short daily meeting during the campaign. It settles most disputes, since most of them come down to how a criterion reads rather than to the defect itself. One more rule heads off a lot of arguments. If the expected behaviour is not written in a signed criterion or in the approved specification, the item is a change request and stays off the certificate. The same line applies after go-live, as our piece on corrective versus evolutive maintenance explains.
Which UAT sign-off template can you copy and sign?
Copy the block below into your word processor and fill it in at the end of each campaign. Every field answers a question that will come up the day you disagree, and "none" is better than a blank.
UAT SIGN-OFF CERTIFICATE (PV DE RECETTE)
Project: ________________________________
Application and build delivered: ________
Test environment: _______________________
Contract reference: _____________________
Campaign no. ____ from __/__/____ to __/__/____
Test plan version: ____
Testers: ________________________________
RESULTS
Cases planned ____ run ____ passed ____
failed ____ not run ____ (reason: ______)
Scope tested: ___________________________
Scope not tested (reason, planned date): ________
Entry conditions checked: [ ] yes [ ] no
(identified build, test data, vendor's
internal test report)
OPEN DEFECTS
Blocking ____ (must be zero to sign)
Major ____ Minor ____
Ref. | Severity | Fix time | Re-test on | Verifier
____ | ________ | ________ | __/__/____ | ________
____ | ________ | ________ | __/__/____ | ________
Change requests set aside (refs): _______________
DECISION
[ ] Accepted
[ ] Accepted with open items, fixed by __/__/____
[ ] Refused, reasons attached, next cycle on __/__/____
EFFECTS
Go-live date: __/__/____
Payment milestone: [ ] due [ ] on hold
Warranty start (if the contract ties it to sign-off): __/__/____
SIGNATURES
Business owner
Name: ______________ Role: ______________
Date: __/__/____ Signature:
IT
Name: ______________ Role: ______________
Date: __/__/____ Signature:
Vendor project manager (open defects acknowledged)
Name: ______________ Role: ______________
Date: __/__/____ Signature:
Attachments: campaign report, extract of the defect log
Three fields need more care than the rest. Scope not tested protects both sides, since it puts in writing what the signature does not accept. Entry conditions record whether the campaign started on an identified build after the vendor's own tests, and the change requests set aside keep a trace of items moved off the certificate, so they do not come back later dressed as defects.
The three decision boxes apply thresholds you wrote down in advance.
| Decision | Condition | Next step |
|---|---|---|
| Accepted | No blocking, no major, agreed coverage reached | Go-live, minors scheduled |
| Accepted with open items | No blocking, majors within the agreed limit, each with a date | Go-live as the contract says, dated re-test |
| Refused | One blocking, or majors over the limit, or coverage too low | Written reasons, new cycle |
Specifications written in French sometimes mention VABF and VSR. Both come from French public-sector IT contracts. Their general administrative terms, the CCAG-TIC approved in 2021, name the first step the vérification d'aptitude (VA), which some French administrations call vérification d'aptitude au bon fonctionnement, hence VABF. It is close to your UAT campaign, while the VSR (vérification de service régulier) observes the system in operation for thirty days (article 32). These rules do not bind a private contract in Morocco. The CCAG-TIC only governs French public contracts that refer to it, and what follows go-live belongs in your post-go-live support contract in any case.
What happens when UAT fails?
A refusal is manageable if it triggers a written next step. The vendor ships a fix build with a list of the defects it addresses. Your testers re-run the failed cases plus a regression set picked in advance, because a fix can break a screen that used to work. The protocol states how many re-test cycles the fixed price covers and what happens after that, for example a penalty per extra cycle, the vendor paying back your testers' days and, as a last resort, the right to terminate the module. Every refusal lists its reasons defect by defect.
The protocol binds you as much as the vendor. If your testers start late or you sit on the decision, the vendor can demand an answer, and some contracts then treat silence as acceptance. Payment works both ways too. A milestone paid on sign-off ties the vendor's cash to the quality of what they ship, and in return the vendor can fairly ask for it to fall due if you have not decided within the agreed time. That is why your own decision deadline deserves a line in the contract, just like the fix times.
How many cycles does it take to get an expense management app accepted?
An engineering and consulting firm is running UAT on the expense claims and travel application its consultants use while on assignment with clients. The firm is invented, and every number that follows is an assumption. The tool applies the travel policy (hotel ceilings, class of travel), routes each claim to the engagement manager and then, above a set amount, to financial control, and sends approved claims to accounting, which reimburses the employee. The contract sets 140 test cases, two working days to fix a blocking defect and five for a major, a limit of four majors for acceptance with open items, and one re-test cycle included; beyond it, each cycle triggers the agreed penalty and the vendor reimburses your testers' days.
In cycle one, 121 cases pass and 19 fail: 2 blocking, 6 major and 11 minor. Sign-off is refused. Both blockers sit in the transfer of approved claims to accounting, which is why on a systems integration project the test cases for data flows between applications are worth writing first.
With the minors pushed to the next release by mutual agreement, the included re-test cycle re-runs the 8 cases tied to blockers and majors plus 30 regression cases. Of those 38, 35 pass. The two blockers are fixed, but two majors are still open and the regression set turns up a new one, in the conversion of expenses paid in foreign currency.
With no blockers and three majors, within the limit of four, the certificate is signed as accepted with open items. It gives the vendor five working days for the three majors and hands the re-test to the financial control key user; that re-test is part of the certificate and does not count as a cycle. If a major is still open on the date, go-live moves, and the next round, beyond the included cycle, triggers the penalty and the reimbursement of testers' days. The 11 minors are listed with their target release.
FAQ
- Can we go live with defects still open?
Yes, if the protocol allows it and every blocking defect is fixed. Majors within the agreed limit and minors then go on the certificate, each with a date and the name of the person who will verify the fix. The real risk is open items with no date and no owner, which drop off everyone's list the week the application goes live.
- Who should write the UAT test plan, us or the vendor?
Your business teams write the acceptance criteria and approve the test cases, because they know the exceptions in the real process. The vendor then details the cases and should hand you its own test report before your campaign starts. If the vendor writes everything alone, it tests its own reading of your needs, and the cases will miss situations only your assistants or accountants run into, such as a trip paid in foreign currency or a claim split between two cost centres.
- How long should a UAT campaign take?
Start from the number of test cases and divide it by what one tester can really run in a day on top of their normal job, then add at least one re-test cycle. With the 140 cases from the example and three testers who each get through, say, fifteen a day, the campaign takes a little over three days before the re-test.
Sources
- Order of 30 March 2021 approving the CCAG-TIC (Légifrance, in French)
- CCAG-TIC 2021, article 32, qualitative verification (marche-public.fr, in French)
- Public procurement acronyms, VABF (marche-public.fr, in French)
Last verified: 1 November 2026.
In the payment schedule of your next development contract, the final UAT milestone should fall due when the certificate is signed, or when your decision deadline runs out if you have not ruled by then. Send us your acceptance protocol before you sign that contract and we will compare it with this grid and template at no charge (book a slot).
