A UAT plan that produces a decision

# UAT plan: [release or feature]

## 1. Purpose
The business outcome this release is meant to deliver.

## 2. Scope
In scope (business processes, not screens):
Out of scope:

## 3. Participants and sign-off
Business users testing, by role:
Who accepts on behalf of the business:
Who supports them technically:

## 4. Acceptance criteria
The conditions agreed before the work started.
Restated here so the verdict is checkable, not an opinion.

## 5. Environment and data
Environment:
Data set, and who prepares it:
Accounts and permissions each participant needs:

## 6. Scenarios
| # | Business scenario | Who runs it | Pass / Fail | Notes |
|---|-------------------|-------------|-------------|-------|
| 1 |                   |             |             |       |
| 2 |                   |             |             |       |

## 7. Entry criteria
What must be true before UAT starts.

## 8. Exit criteria
What must be true before UAT is called complete.
Which severities block sign-off.

## 9. Defect handling
How a participant reports a failure, and who triages it.

## 10. Schedule
Start, end, and the checkpoint where progress is reviewed.

# UAT plan: pay by invoice

## 1. Purpose
Customers can pay by invoice, and finance can reconcile those payments without a manual export.

## 2. Scope
In scope (business processes, not screens): raising an invoice, chasing an unpaid one, reconciling a payment against a bank statement line.
Out of scope: refunds and credit limit changes, neither of which was touched.

## 3. Participants and sign-off
Business users testing, by role: two credit controllers and one finance manager.
Who accepts on behalf of the business: the finance manager.
Who supports them technically: the product owner, in the room on both afternoons.

## 4. Acceptance criteria
An invoice raised on Monday appears in the finance export the same day, with the purchase order attached.
An overdue invoice can be chased without leaving the invoice.
A payment matched to an invoice clears it with no manual export.

## 5. Environment and data
Environment: staging
Data set, and who prepares it: anonymised August invoices, seeded by the product owner the day before.
Accounts and permissions each participant needs: one credit controller account each and one finance manager account, signed into once the afternoon before.

## 6. Scenarios
| # | Business scenario | Who runs it | Pass / Fail | Notes |
|---|-------------------|-------------|-------------|-------|
| 1 | Raise an invoice against an existing purchase order | credit controller | Pass | |
| 2 | Chase an invoice overdue and partly paid | credit controller | Fail | UAT-07 |
| 3 | Reconcile a payment short by the bank charge | finance manager | Not run | Bank sandbox unavailable both days |

## 7. Entry criteria
All functional testing complete on this build, and every participant signed in once, the day before.

## 8. Exit criteria
Every scenario carries a result, including Not run with its reason. No blocker open and no major on invoice creation.
Which severities block sign-off: blocker and major block. Minor is listed and accepted.

## 9. Defect handling
Reported from inside the app, so the environment and the failed request travel with the report. Triaged the same afternoon by the product owner and the engineering lead.

## 10. Schedule
Two afternoons, 14 and 15 September, with a review at the end of the first. Anything unrun by the second is recorded Not run and named in the decision.