UAT (User Acceptance Test)
A UAT (User Acceptance Test), in German Abnahmetest, is the final testing phase of an ERP rollout, in which the future users themselves check whether the configured system maps their real business processes without errors. Only a successful UAT provides the basis for formal acceptance and go-live.
The UAT (User Acceptance Test) is the concluding test phase of an IT or ERP project, in which the future users – not the developers or consultants – check the fully configured system against their real business processes and formally sign it off. In German it is called Abnahmetest or Akzeptanztest. The goal is to answer a single question: does the system meet the business requirements well enough for the company to work productively with it? Only once the departments confirm this is the basis for contractual acceptance and go-live in place.
The UAT therefore differs fundamentally from technical tests: it is not about programming errors or system stability, but about business fitness. Testing is done against the requirements defined in advance in the requirements specification and functional specification – ideally with realistic data and typical everyday scenarios. The UAT is the last checkpoint before productive operation and, at the same time, the moment when the users take responsibility for the new system.
At a glance
- UAT = User Acceptance Test, in German Abnahme- or Akzeptanztest
- The future users test it themselves – not developers or consultants
- It checks business fitness against the requirements and functional specification, not the code
- The basis for formal acceptance, the go/no-go decision and go-live
- Based on real processes and genuine test data, not on lab examples
What a UAT (User Acceptance Test) delivers
The UAT is the bridge between the project and productive operation. During the implementation of an ERP project, consultants and internal project teams configure the system according to the agreed requirements. Whether this configuration actually holds up in daily business, however, can only be judged by those who know that daily business – the sales clerk, the purchasing planner, the accountant. It is precisely these people who carry out the UAT.
The benefit lies on two levels. On the business side, the UAT uncovers gaps between what was specified and what operations really need – such as special cases, exception processes or operating steps that were overlooked in the concept. On the organizational side, it creates acceptance: anyone who has checked and signed off a system themselves before go-live enters live operation with considerably more confidence and less resistance. The UAT is thus both quality assurance and part of change management.
How a UAT is run
A UAT is not spontaneous trial and error, but a structured process with clear preparation, execution and evaluation. It is planned, backed by test cases and documented, so that the results are fit to serve as the basis for acceptance.
Test cases and test scenarios
The foundation is test cases derived directly from the requirements. Each test case describes a concrete workflow – for example "create a customer order, pick it, generate a delivery note and invoice" – with defined inputs and the expected result. A mix of standard processes and deliberately chosen special and error cases makes sense, because it is exactly the exceptions that expose configuration gaps. Testing is done, wherever possible, with genuine or realistically migrated data in a dedicated test or acceptance environment that matches the production system.
Defect classification and acceptance criteria
Deviations found are recorded, documented in a traceable way and classified by severity – from critical defects that block a process down to cosmetic flaws. Acceptance criteria agreed in advance determine which defect classes prevent go-live and which may be carried forward as open items with a deadline. At the end there is a formal acceptance protocol that the departments sign. This protocol is often also contractually relevant, because payments and warranty periods are tied to acceptance.
Why the UAT (User Acceptance Test) matters
The UAT is the last opportunity to find errors before go-live, while fixing them is still cheap. A configuration error discovered in testing can be corrected at leisure; the same error after going live leads to wrong invoices, delayed deliveries or incorrect stock levels – with direct effects on customers and accounting. The UAT therefore directly reduces the risk of a failed or bumpy go-live.
Equally important is safeguarding the go/no-go decision. Without a solid UAT, the release of an ERP system rests on assumptions; with documented test results it becomes a traceable decision based on fixed criteria. For the client, the UAT is also the lever to demand rework before finally accepting and paying for the system.
UAT in the ERP system
In ERP projects the UAT carries particular weight, because an ERP connects almost all of a company's core processes – from purchasing and warehousing through sales to financial accounting. An error in one place propagates through the integrated data foundation. That is why the UAT here is usually set up end-to-end: not individual functions are tested, but continuous process chains such as order-to-cash or procure-to-pay across several modules.
The UAT is typically carried out by the key users of the departments, who represent their unit in the project and later act as multipliers. In a separate acceptance environment with migrated test data, they check whether master data, permissions, document flows, interfaces to the shop or shipping provider and reports work as expected. The UAT interlocks closely with data migration here – acceptance is only solid once migrated data is plausible in the test – and with user training, because testing at the same time strengthens familiarity with the system.
Distinction: UAT vs. system and integration test
The UAT stands at the end of a chain of test types and pursues a different goal than the technical tests that precede it. The system test checks whether the software works technically correctly and stably; the integration test checks the error-free interplay of modules and interfaces. Both are carried out by developers or the project team and answer the question "does the system work technically correctly?".
The UAT, by contrast, is carried out by the business users and answers the question "is this the right solution, suited to our operations?". It presupposes technically error-free software and focuses on business fitness. It differs from the test migration run in that there the completeness and correctness of the data transfer is in the foreground, whereas the UAT accepts the processes running on that data. Only once all preceding tests have been passed does the UAT, as the final, business-level acceptance, make sense.
Example
Example: an e-commerce retailer accepts its new ERP before go-live
A mid-sized online retailer is replacing its isolated point solutions with an integrated ERP. Four weeks before the planned go-live, the UAT starts in a dedicated acceptance environment into which the migrated item, customer and stock data have been loaded. One key user each from sales, warehouse, purchasing and accounting works through a list of test cases – from order intake via the shop through to the invoice and the handover to financial accounting.
During testing it becomes apparent that returns from the marketplace are not booked correctly to the right warehouse and that a tiered discount in the B2B customer segment is applied incorrectly. Both points are documented as critical defects and must be fixed before go-live; a cosmetic flaw in a report is accepted as an open item with a deadline. After the correction and a repeat test run, the departments sign the acceptance protocol – the go/no-go decision is positive and the go-live can be scheduled.
Frequently asked questions
Matching ERP systems
Related services
Questions about UAT (User Acceptance Test) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.