ChecklistImplementation

User acceptance testing checklist for ERP, CRM and platform rollouts

User acceptance testing is where the business, not the project team, decides whether a new system is fit to run its work. This checklist covers what must be true before testing starts, building scenarios from process maps, sourcing realistic and safe test data, testing with real role profiles, handling defects, accepting AI-enabled features and what formal sign-off should contain.

Reviewed 10 October 2026 5 min read

On this page

What UAT proves compared with system and integration testing
Entry criteria before UAT starts
Scope: scenarios built from process maps, not screens
Test data that is realistic, migrated and masked
Roles, access and segregation of duties in UAT
Defect severity and triage definitions for UAT
Accepting AI-enabled features with evaluation sets
UAT exit criteria and formal business sign-off
Hypothetical example: a UAT plan for a CRM replacement
Questions and answers
Sources

What UAT proves compared with system and integration testing

Quality engineering, one of ColdAI's implementation offerings, spans test automation, performance and security testing and quality governance¹. UAT is the level the business owns, and it answers a different question from the levels before it.

Question	System testing	Integration testing	User acceptance testing
Who runs it	Project testers and developers.	Project testers with interface owners.	Business users who will do the work, supported by testers.
What it proves	Each function behaves as specified.	Data moves correctly between systems and errors are handled.	The business can run its processes end to end.
Test cases come from	Functional specifications and user stories.	Interface specifications and data contracts.	Process maps, business rules and recent real cases.
Who passes it	The test lead.	The test lead with interface owners.	The accountable business owner.

Entry criteria before UAT starts

0 of 6 checked

System and integration testing completeNo open critical defects; high-severity ones fixed or accepted with a workaround.
Stable, production-like environmentConfiguration frozen for the cycle, interfaces connected to test instances of real partner systems, no unannounced deployments in test hours.
Migrated data loaded and reconciledA recent migration rehearsal is loaded and its reconciliation results shared, so testers know which data to trust. See data migration validation.
Scenarios approved by process ownersEach owner has confirmed that the scenarios cover their process, variants included.
Testers named, trained and releasedBusiness testers have had system training and have time formally freed from their day jobs.
Defect process agreedSeverity definitions, the triage meeting slot and the single tool everyone records defects in.

Scope: scenarios built from process maps, not screens

Screen-by-screen scripts prove that fields accept input. Business scenarios prove that an order becomes cash or a claim becomes a payment.

0 of 5 checked

End-to-end flowsOrder to cash, procure to pay, lead to contract or case open to close, across every system involved.
Variants and exceptionsReturns, credit holds, partial deliveries, cancellations and amendments.
Period-end and batch processesMonth-end close, billing runs, statements and overnight jobs.
Outputs others depend onCustomer documents, reports, payment files and regulatory submissions.
Negative testsWhat should be blocked: over-limit approvals, duplicate payments, invalid codes.

Test data that is realistic, migrated and masked

0 of 5 checked

Use migrated data, not hand-built recordsReal data shapes expose mapping errors that tidy test records hide.
Mask or pseudonymize personal dataUnder the GDPR, data minimization applies in test environments too, and Article 32 names pseudonymization and encryption as security measures².
Preserve relationships when maskingA masked customer must still link to the same orders, invoices and cases.
Include awkward recordsLong names, special characters, closed accounts, very old transactions and records with missing fields.
Control any production copiesRestrict and log access if real data must be used, and delete it after the cycle.

Roles, access and segregation of duties in UAT

0 of 5 checked

Test with real role profilesNever with administrator accounts, which hide missing permissions until go-live.
Cover every role at least onceIncluding approvers, delegates and read-only users.
Prove conflicting duties are blockedFor example, one user should not create a supplier and approve its payment. Public companies assess such controls as part of internal control over financial reporting under Section 404 of the Sarbanes-Oxley Act³.
Exercise approval workflowsThresholds, escalations, absence delegation and rejections.
Request access through the real processSo the joiner process is tested along with the system.

Defect severity and triage definitions for UAT

Agree these words before testing, review new defects daily, and rerun an agreed regression set after each round of fixes so a fix does not break something that already passed.

Critical: A core business process cannot be completed and there is no workaround.
High: A process can be completed only with a workaround that is costly or risky at production volume.
Medium: A defect with a simple workaround or a contained effect on one variant.
Low: Cosmetic or minor issues that do not affect results.
Change request: Something users want that was never in scope; it goes to the backlog rather than the defect queue.

Accepting AI-enabled features with evaluation sets

Document extraction, summarization or classification features give variable outputs, so a single expected result per test case does not work.

0 of 5 checked

Build an evaluation set from real casesLabeled by business experts and covering the variants that matter.
Agree metrics and thresholds before testingThe EU AI Act requires providers of high-risk systems to test against prior defined metrics and probabilistic thresholds⁴; it is sound practice for any AI feature.
Report results by segmentA good average can hide a document type or customer group that fails.
Review failures by handClassify why each one failed, in line with the measure function of the NIST AI Risk Management Framework⁵.
Test the human override pathUsers must be able to correct or reject an output, and the correction must be recorded.

UAT exit criteria and formal business sign-off

0 of 5 checked

All in-scope scenarios executedIncluding variants, period-end and negative tests.
No open critical or high defects without an accepted workaroundEach remaining defect has an owner and a fix date.
Final regression passedAfter the last round of fixes, on the build that will go live.
AI thresholds metResults recorded against the thresholds agreed beforehand.
Signed acceptance documentScope tested, results, open defects, accepted risks and the signatures of the accountable business owners.

Hypothetical example: a UAT plan for a CRM replacement

Questions and answers

Who should write UAT scenarios?

Business process owners, helped by testers who know how to structure them. Owners know the variants, exceptions and period-end steps that matter; testers make scenarios repeatable and traceable to requirements. Scripts written only by the project team tend to test what was built rather than what the business needs.

How long should a UAT cycle run?

Long enough to run every scenario, fix the defects found and rerun regression, usually in at least two cycles. Duration depends on scenario count and tester availability more than system size. Protect testers' time: UAT squeezed into spare hours produces shallow testing and late sign-off.

Can UAT be automated?

Partly. Regression of stable scenarios can be automated, which frees business testers for judgment-heavy work such as exceptions, outputs and usability. The acceptance decision itself cannot be automated, because it is a business owner stating that the system is fit for their process.

Is UAT still needed when delivery runs in sprints with regular demos?

Yes. ColdAI's iterative delivery ends each two-week sprint with working software and a stakeholder demo¹, which surfaces problems early. Demos show features in isolation, though; UAT confirms complete processes on migrated data with real roles before go-live.

Sources

Implementation: approach and quality engineering offering — ColdAI
Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex · checked 10 October 2026
Sarbanes-Oxley Act of 2002 (Public Law 107-204) — U.S. Government Publishing Office · checked 10 October 2026
Regulation (EU) 2024/1689 (Artificial Intelligence Act) — EUR-Lex · checked 10 October 2026
AI Risk Management Framework — National Institute of Standards and Technology · checked 10 October 2026

More in Implementation

Back to Implementation

Next step

Get a second opinion on your UAT plan before testing starts

Send the scope, scenario list and planned dates. We will point out missing process variants, data or role coverage, and suggest exit criteria your business owners can sign against.

Review my UAT plan

What UAT proves compared with system and integration testing

Entry criteria before UAT starts

Scope: scenarios built from process maps, not screens

Test data that is realistic, migrated and masked

Roles, access and segregation of duties in UAT

Defect severity and triage definitions for UAT

Accepting AI-enabled features with evaluation sets

UAT exit criteria and formal business sign-off

Hypothetical example: a UAT plan for a CRM replacement

Questions and answers

Sources

Related reading

More in Implementation

Get a second opinion on your UAT plan before testing starts