ERP user acceptance testing (UAT) is the stage where the people who will run the business on the system test it against real processes, with migrated data, before go-live. It checks end-to-end flows such as procure-to-pay, order-to-cash and record-to-report, logs and triages defects, and ends with a formal sign-off by each process owner.
UAT is different from the testing your implementer or developer does. System and integration testing ask "does the software work as built?". UAT asks "can we run the business on this?". The two overlap, but only the business can answer the second question. This plan works for a packaged ERP or a custom ERP build; in a custom project, UAT is also where you confirm that each module matches the agreed scope before the next one starts.
What should ERP UAT cover?
UAT should cover every process the business will run in the ERP on day one, tested end to end across modules, plus the reports, approvals, integrations and access rights those processes depend on. Testing screens one by one is not enough.
The layers of a UAT plan
| Layer | What it tests | Example |
|---|---|---|
| Single-module scenarios | One task in one module | Create a supplier with tax details and bank account |
| End-to-end flows | A process across modules, through to the ledger | Requisition to PO to receipt to supplier invoice to payment |
| Approvals and controls | Limits, segregation of duties, audit trail | A PO above the manager's limit routes to the next approver |
| Reports | Figures agree with transactions | Aged payables equals the payables control account |
| Integrations | Data in and out of other systems | Web orders arrive with correct prices and tax |
| Access rights | Each role sees and does only what it should | A stores user cannot approve a supplier invoice |
| Period-end | Close tasks work in sequence | Accruals, depreciation, revaluation, period lock |
Which end-to-end flows must be tested?
At minimum, test procure-to-pay, order-to-cash and record-to-report, plus any operational flow you run, such as plan-to-produce for manufacturers or inventory transfers for multi-site businesses. Each flow must be followed through to the general ledger and checked there.
Procure-to-pay
- Raise a purchase requisition for stock and for a non-stock service
- Approve it at and above the approval limit
- Convert to purchase order and send to the supplier
- Receive goods in full, then a partial receipt on a second order
- Post the supplier invoice, including a price variance outside tolerance
- Run the payment proposal, approve and post the payment
- Check stock, the payables ledger, accruals and the general ledger entries
Order-to-cash
- Create a quote for a customer with special pricing
- Convert to sales order; trigger a credit limit check
- Pick, pack and ship, including a back order
- Invoice, including tax for a domestic and a cross-border customer if relevant
- Process a credit note for a return
- Receive and allocate a customer payment, including a part payment
- Check receivables ageing, revenue accounts and stock movements
Record-to-report
- Post a manual journal that requires approval
- Run a recurring journal and an accrual with reversal
- Run depreciation for fixed assets
- Revalue foreign currency balances, if you trade in more than one currency
- Reconcile bank accounts
- Close the period and confirm users cannot post into it
- Run the trial balance, profit and loss, balance sheet and management reports, and compare them with expectations
Other flows to add when they apply
- Plan-to-produce: bill of materials, work order, material issue, labour or machine time, finished goods receipt, variance
- Inventory: transfer between locations, cycle count and adjustment, batch or serial tracking
- Inter-company: a sale from one entity to another, with both sides posted (see multi-entity ERP governance)
- Payroll or HR, if in scope: a pay run with joiners, leavers and changes, checked against the old system's results
How do you write an ERP UAT test script?
A UAT script states the scenario, the role that performs it, the starting data, each step, the expected result and the actual result, with space for evidence. It is written by the business, usually by champions with the process owner, not by the people who built the system.
Test script template
| Field | Example |
|---|---|
| Script ID | P2P-07 |
| Process and scenario | Procure-to-pay: supplier invoice with price variance outside tolerance |
| Role | Accounts payable clerk |
| Preconditions | PO 4500123 received in full; tolerance set by process owner |
| Steps | 1. Open supplier invoice entry. 2. Match to PO 4500123. 3. Enter unit price above the PO price beyond tolerance. 4. Submit. |
| Expected result | Invoice is blocked for payment and routed to the purchasing approver; no payment proposal includes it |
| Actual result | Recorded by the tester |
| Evidence | Screenshot or document number |
| Status | Pass, fail or blocked |
| Defect reference | If failed |
Write both "happy path" scripts and negative scripts that try to break a rule: an approval limit exceeded, a closed period, a duplicate supplier invoice number, a user acting outside their role. Negative tests find the gaps that matter most for control.
What data and environment does UAT need?
Run UAT in a dedicated test environment that mirrors production configuration, loaded with data from the latest trial migration. Testing with invented data misses the problems hidden in real records.
- Migrated master data: real customers, suppliers, items and chart of accounts, so testers recognise them
- Opening balances and open transactions from a trial load, so receipts, invoices and payments can be tested against real open items
- Production-like configuration: the approval limits, tax codes and user roles you intend to go live with
- Working integrations to test copies of connected systems, or agreed stubs where a live test copy does not exist
- A fixed configuration during each test cycle, with changes released between cycles, so results are comparable
UAT is also a strong test of migration quality. Our ERP data migration plan explains trial loads and reconciliation, which should run before UAT starts.
If your project is a custom build, our ERP module development service delivers modules in sequence, so each one can pass UAT before the next is released.
How should UAT defects be triaged?
Every failed step becomes a logged defect with a severity, an owner and a target fix cycle. A short daily triage meeting with the process owners and the delivery team decides what is a defect, what is a change request and what is a training issue.
| Severity | Definition | Go-live rule |
|---|---|---|
| Critical | Process cannot be completed, or financial results are wrong, with no workaround | Must be fixed and retested before go-live |
| High | Process can be completed only with a difficult or risky workaround | Fixed before go-live unless the process owner formally accepts the workaround |
| Medium | Inconvenient, with a reasonable workaround | Can go live with a plan and date for the fix |
| Low | Cosmetic or minor | Scheduled after go-live |
Three triage questions
- Is the system behaving differently from the agreed design? That is a defect.
- Is it behaving as designed, but the design is wrong for the business? That is a change request. It is reviewed for impact on scope and timeline and agreed before work starts.
- Did the tester expect something the design never promised? That is often a training or communication issue; record it for the training plan.
Keep the categories separate. Mixing change requests into the defect log is a common reason UAT never seems to end.
How long and how many cycles should UAT run?
Plan at least two cycles: a first cycle that runs every script and finds the defects, and a second that retests fixes and reruns the end-to-end flows. The duration depends on the number of processes and testers, so plan it from your script count rather than from a generic rule.
A simple way to estimate: count the scripts, estimate the time per script from a sample, divide by the hours your testers can actually give per day, then add time for retesting. Testers are usually also doing their day jobs, which is the most common reason UAT overruns.
Illustrative UAT plan for a mid-sized distributor
This is an illustrative structure, not a client case.
| Week | Activity | Who |
|---|---|---|
| Before UAT | Scripts written and reviewed; trial migration loaded; testers trained on the test environment | Champions, process owners, delivery team |
| Cycle 1 | All single-module scripts, then end-to-end flows; defects logged daily | Champions per area |
| Fix window | Critical and high defects fixed and released as one build | Delivery team |
| Cycle 2 | Retest fixed defects; rerun all end-to-end flows and period-end; access rights tests | Champions, finance |
| Sign-off | Open defect review; workarounds accepted or rejected; sign-off by each process owner | Process owners, sponsor |
What are the UAT sign-off criteria?
Sign-off is a written decision by each process owner that their processes can run in the system from go-live. It should rest on agreed criteria, set before UAT starts.
UAT sign-off checklist
- All scripts executed, with evidence
- No open critical defects; open high defects each have a workaround accepted in writing by the process owner
- End-to-end flows passed and checked through to the general ledger
- Period-end close completed in the test environment
- Key reports reconciled to underlying transactions
- Access rights tested for every role, including negative tests
- Integrations tested with realistic volumes
- Open medium and low defects listed with planned fix dates
- Each process owner and the sponsor have signed
UAT sign-off feeds directly into the go-live decision. Our ERP go-live checklist covers what happens next: cut-over, hypercare and the first month-end.
When is a large UAT programme not the right approach?
For a small, single-entity system with a few users and standard processes, dozens of formal scripts may cost more than the risk they reduce. A shorter list of end-to-end scenarios run by the people who will use the system, plus a period-end test, may be enough.
The trade-off runs the other way when money, stock or regulated data move through the system. Skipping negative tests and period-end testing is where serious problems are usually missed. If UAT keeps surfacing basic gaps in design, the issue is earlier in the project; see why ERP implementations fail and the ERP implementation steps guide.
How to start
List the processes you will run in the ERP on day one, name a process owner for each, and choose the champions who will write and run scripts. If you are still defining scope, our software requirements brief template helps you describe processes in a form that later becomes your test scenarios.
Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, which gives your team a first, small round of acceptance testing on real screens. Discuss your project with us, or see how we deliver on our custom ERP software page.