What a UAT acceptance certificate protects you from

Most disputes about software are not about quality. They are about whether the thing that was delivered is the thing that was agreed, and they surface weeks after go-live when nobody can remember what was said in a meeting in March.

An acceptance certificate is the cure for that, and it only works if it is written down item by item before anybody builds anything.

How it works on our projects

Every project gets a checklist in your portal. One row for each thing the system has to do, written in your language rather than ours: "the contact form arrives in the shared inbox", not "POST handler returns 200". You work through them yourself, on your own devices, and mark each one passed or failed.

A failure needs a sentence saying what happened. That is not bureaucracy: "it does not work" starts a week of guessing, and "I clicked Submit and the page stayed blank" is usually enough to find it the same day.

Nothing goes live until every item passes

This is enforced, not encouraged. The button that signs your acceptance certificate stays disabled until the last item is green, and the server checks the whole checklist again at the moment you sign, rather than trusting what your screen was showing. If somebody reopens an item while you are signing, the signature is refused and tells you which items are outstanding.

Once signed, the checklist is frozen. It becomes the evidence behind a document rather than a working list, so the record of what you accepted cannot drift afterwards.

What it protects

It protects you from paying for something that does not do what you asked. It protects us from an open-ended definition of done. And it gives both of us one document to point at when somebody asks, in six months, whether a particular behaviour was in scope.

Your signed certificate is filed in your portal documents, with its reference, the items that passed and the date. You can download it whenever you need it.