UAT Testing for SAP: How to Run Effective User Acceptance Testing on SAP Implementations

SAP

the world's most deployed enterprise ERP platform

70%

of SAP go-live issues linked to insufficient user testing

4-8

weeks minimum for proper SAP user acceptance testing

SAP implementations are amongst the most complex technology programmes an organisation will ever undertake. Thousands of configuration decisions, hundreds of custom objects, and deeply integrated modules that span finance, logistics, manufacturing, and human resources. Yet when it comes to UAT, the approach is often alarmingly superficial: a spreadsheet of test cases, a handful of key users pulled off their day jobs, and a sign-off process driven by project timeline pressure rather than genuine readiness.

This guide is for SAP implementation teams — whether you're a systems integrator delivering an S/4HANA programme, a client-side programme manager, or a module lead trying to get your area ready for go-live. It covers what to test across SAP's core modules, how to structure your test plan around real business processes, the mistakes that derail nearly every SAP go-live, and how to get meaningful sign-off from your steering committee. For broader ERP testing principles, see our comprehensive ERP UAT guide.

1. Why SAP UAT Is Uniquely Challenging

SAP is not a simple application with a straightforward interface. It is an enterprise platform where finance, materials management, sales, production planning, warehouse management, and human capital management all operate against shared master data, shared configuration, and a deeply interconnected posting logic. This creates a testing challenge that is qualitatively different from testing standalone software — or even other ERP platforms. The key ERP risks in 2026 hit SAP programmes harder than most, precisely because of this complexity.

Here's what makes SAP testing fundamentally different:

Massive configuration scope — a typical SAP implementation involves thousands of configuration items across IMG (Implementation Guide) activities. Each configuration decision — from account determination to pricing procedures to output types — affects how transactions behave. A single misconfigured condition table in SD pricing can silently produce incorrect invoice values across the entire sales organisation
Deep cross-module integration — posting a goods receipt in MM automatically triggers FI postings, updates CO cost objects, adjusts inventory valuation, and may trigger quality management inspection lots. Testing the goods receipt in isolation tells you nothing about whether the financial postings are correct
Complex authorisation model — SAP's authorisation concept operates at the level of individual authorisation objects with specific field values. A user might be able to execute transaction ME21N (create purchase order) but be blocked from certain document types, purchasing organisations, or value thresholds. Testing with SAP_ALL or overly broad profiles is meaningless
SAP-specific data structures — company codes, plant hierarchies, sales organisations, distribution channels, purchasing organisations, storage locations — these organisational structures drive everything in SAP. Your testers need to understand which combinations are valid and test across the relevant organisational units
Multiple user interfaces — modern SAP landscapes involve SAP GUI transactions, Fiori apps, and potentially SAP Business Technology Platform extensions. The same business process may behave differently across these interfaces, and your users will interact with whichever one is deployed for their role
Transport-driven change management — configuration and custom development move through the SAP landscape via transport requests. A transport imported into the UAT system can change behaviour that was previously tested and passed. This makes regression testing after transport imports essential, not optional

The SAP-Specific Risk:

SAP's deep integration means a configuration error in one module can silently corrupt financial postings, inventory valuations, or cost allocations across the entire enterprise. Generic test scripts that treat each module independently will miss these cross-cutting issues entirely. The history of ERP implementation failures is disproportionately populated by SAP programmes where integration testing was inadequate.

2. What to Test in a SAP Implementation: Module by Module

The biggest mistake in SAP UAT is testing transactions rather than business processes. Your users do not care whether transaction FB01 works — they care whether they can complete a month-end close, process a payment run, or fulfil a customer order from sales order to goods issue to billing. Here is what you actually need to cover, organised by module. For guidance on writing the actual test cases, see our guide on how to write effective test cases.

FI/CO — Financial Accounting and Controlling

Finance is the backbone of every SAP implementation. If the general ledger is wrong, everything is wrong.

General ledger posting — post journal entries via FB50 or the Fiori equivalent, validate account determination, and confirm postings land in the correct GL accounts with the right cost centre, profit centre, and segment assignments. Test document splitting rules if configured
Accounts payable — full cycle from invoice entry (FB60/MIRO for logistics invoices) through payment proposal (F110), payment execution, and bank clearing. Test partial payments, credit memos, down payments, and withholding tax if applicable
Accounts receivable — customer invoice posting, incoming payment processing (F-28), automatic clearing, dunning runs (F150), and aged debt reporting. Test direct debit processing and payment advice notes if used
Cost centre accounting — validate that costs post to the correct cost centres, run allocation cycles (assessment and distribution), and confirm that plan vs actual reporting produces accurate results
Asset management — asset acquisition (both direct and via integration with MM), depreciation runs (AFAB), asset transfers, retirements, and year-end close. Validate that depreciation posts to the correct expense and accumulated depreciation accounts
Bank reconciliation — electronic bank statement upload, automatic matching rules, manual clearing of open items, and cash position reporting
Period-end and year-end close — foreign currency revaluation (FAGL_FCV), GR/IR clearing (F.13), accruals, financial statement generation, and fiscal year rollover. This is non-negotiable for go-live readiness

MM — Materials Management

Materials Management testing needs to follow the physical and financial flow of procurement, not just validate that screens open.

Procurement cycle — purchase requisition (ME51N), purchase order creation (ME21N) with approval workflow, goods receipt (MIGO), and invoice verification (MIRO). Test the three-way match logic and tolerances. Test blanket purchase orders and scheduling agreements if used
Inventory management — goods movements (MIGO) for receipts, issues, transfers, and scrapping. Validate that each movement type triggers the correct FI postings via automatic account determination. Test stock transfer orders between plants and storage locations
Invoice verification — test MIRO for PO-based and non-PO-based invoices. Validate price variance postings, quantity variance handling, and the GR/IR clearing process. Test evaluated receipt settlement (ERS) if configured
Material master data — validate that material master records are correctly maintained across all relevant views (basic data, purchasing, MRP, accounting, costing). Test that valuation class and price control settings produce the correct financial results
Inventory valuation — for materials using standard price, validate price differences. For moving average price, validate that receipts and issues update the price correctly. Run the material ledger actual costing cockpit (CKMLCP) if applicable

SD — Sales and Distribution

Sales and Distribution testing must cover the full order-to-cash cycle, including pricing, availability, delivery, and billing.

Order-to-cash — sales order entry (VA01), availability check (ATP), delivery creation (VL01N), goods issue (VL02N), billing document (VF01), and accounting document release to FI. Test the entire chain as a single end-to-end flow
Pricing — validate that pricing procedures, condition records, surcharges, discounts, and tax determination produce the correct values. Test pricing at header and item level, including manual price overrides if permitted
Delivery and shipping — picking, packing, goods issue posting, and proof of delivery. Validate that goods issue triggers the correct inventory movements and COGS postings. Test partial deliveries and backorder processing
Billing — invoice creation, credit memos, debit memos, and intercompany billing if applicable. Validate that revenue recognition postings are correct and that output determination generates the correct invoice formats
Returns and complaints — return order processing, return delivery, credit memo creation, and inventory re-entry. Test that returned goods are correctly valued and that the financial reversals are accurate
Output management — order confirmations, delivery notes, invoices, and any custom output types. Validate that output determination triggers correctly and that print forms or email outputs are formatted correctly

PP — Production Planning (if applicable)

Production orders — create from planned orders or manually, release, confirm operations (CO11N/CO15), and complete technically. Validate that goods movements for component consumption and finished goods receipt are correct
BOMs and routings — validate that production BOMs explode correctly and that routing operations produce accurate capacity requirements and planned costs
MRP runs — execute MRP (MD01/MD02) and validate that planned orders, purchase requisitions, and scheduling agreement schedule lines are generated correctly against demand
Production order settlement — settle production orders to validate that variances (price, quantity, lot size) are calculated and posted correctly to CO

WM/EWM — Warehouse Management

Inbound processing — goods receipt against purchase orders, transfer order creation for put-away, and bin confirmation. Validate that warehouse stock and inventory management stock reconcile
Outbound processing — delivery-triggered transfer order creation for picking, pick confirmation, and goods issue. Test wave management and pick strategies if configured
Stock transfers and physical inventory — storage bin-to-bin transfers, warehouse-level physical inventory counts, and cycle counting. Validate that adjustments post correctly through to FI

HCM — Human Capital Management (if in scope)

Personnel administration — hiring actions, organisational assignment changes, and terminations. Validate that infotype records are created correctly
Payroll integration — if payroll posts to FI, validate that payroll results generate the correct wage type postings to GL accounts, cost centres, and profit centres

Integrations, Custom ABAP, and Fiori

Custom ABAP development — any Z-programmes, user exits, BADIs, or enhancement implementations must be tested within the business process they support. Pay particular attention to custom validation logic, substitution rules, and custom reports
Fiori apps — every Fiori app that will be used in production must be tested by the users who will use it. Validate that OData services return correct data, that Fiori launchpad tiles display accurate counts, and that approvals and workflows function correctly through the Fiori interface
Third-party integrations — test data flow in both directions via IDocs, RFCs, APIs, or middleware. Validate error handling for failed messages, duplicate detection, and retry logic. Test with realistic message volumes
Authorisation testing — test with production-equivalent roles, not SAP_ALL. Validate that users can execute the transactions they need and are blocked from those they should not access. Test authorisation objects for posting limits, document types, and organisational unit restrictions

Practical Tip:

Build your test scenarios around your organisation's actual company codes, plant structures, sales organisations, and real master data. Testing with generic "test data" or SAP's standard IDES data will miss configuration issues that only surface with your real organisational structures and master data records.

Stop Managing SAP UAT in Spreadsheets

Centralise Your SAP Testing with LogicHive

Real-time readiness dashboards, structured sign-off by module owner, and full audit trails — built for SAP implementation teams who need to prove go-live readiness to the steering committee.

Start Free Trial

3. Structuring Your SAP Test Plan

A well-structured test plan is the difference between a controlled UAT process and a chaotic free-for-all. SAP programmes demand more rigour here than most, because the sheer volume of configuration and the number of stakeholders involved can quickly overwhelm an unstructured approach. If you are managing UAT across multiple SAP projects, this structure becomes even more critical.

Conference Room Pilots vs UAT

SAP programmes typically include Conference Room Pilots (CRPs) earlier in the project lifecycle — usually during the Realise or Build phase. It is essential to understand the distinction between CRPs and UAT, because conflating them is a common source of false confidence.

CRP 1 (early Build) — a walkthrough of configured processes with key users and consultants. The purpose is to validate that the design works in principle. Data is usually generic, and consultants typically drive the session. This is design validation, not testing
CRP 2 (late Build) — a more detailed walkthrough using closer-to-real data. Key users may execute some steps themselves. This identifies gaps in configuration but is still not UAT — the system is not yet complete, and integrations may not be in place
SIT (System Integration Testing) — validates that modules and integrations work together technically. Typically led by the SI partner with client observation. A purchase order should flow from MM through to FI posting; an IDOc from a third-party system should create the correct master data record
UAT — business users independently execute structured test cases against a production-like environment with migrated data. This is the formal validation that the system is ready for go-live. If your consultants are executing the tests, it is not UAT — it is extended SIT

Critical Rule:

UAT should not begin until SIT is substantially complete and the transport landscape is stabilised. Starting UAT whilst the SI partner is still importing transports with configuration changes wastes your business users' time and erodes their confidence in the system.

Organise by Business Process, Not Module

This is where most SAP test plans go wrong. They are structured around SAP modules: "FI tests", "MM tests", "SD tests". But that is not how your business works. Your users do not think in modules — they think in processes. Structure your test plan around end-to-end business processes:

Procure-to-pay — from purchase requisition through purchase order, goods receipt, invoice verification, payment proposal, payment execution, and bank clearing. This crosses MM, FI, and potentially WM
Order-to-cash — from sales order entry through availability check, delivery, picking, goods issue, billing, and incoming payment. This crosses SD, WM/EWM, FI, and CO
Plan-to-produce — from demand planning through MRP, production order creation, component consumption, finished goods receipt, and order settlement. This crosses PP, MM, CO, and FI
Record-to-report — from journal entry through period-end close activities, cost allocations, intercompany eliminations, and financial statement generation. This is primarily FI/CO but touches every module that creates financial postings
Hire-to-retire (if HCM is in scope) — from employee hiring through payroll processing, cost posting, and termination

Regression Testing After Transports

SAP's transport-based change management means that every transport imported into the UAT system can potentially change behaviour that was previously tested. You need a clear process for this:

Transport impact analysis — before importing a transport, document what it changes and which test scenarios are affected
Targeted regression testing — re-execute the specific test cases affected by the transport, not the entire test suite
Transport freeze before sign-off — establish a transport freeze window before final UAT sign-off. No configuration or development transports should be imported during this window without explicit steering committee approval

Write Test Cases SAP Users Can Follow

Your AP clerk does not need to know that they are testing "MIRO three-way match with tolerance handling". They need clear, step-by-step instructions written in plain English with SAP-specific references:

Example: Test Case for Supplier Invoice Verification

Open transaction MIRO (or the "Post Invoice" Fiori app)
Enter invoice date 12/02/2026 and select "Invoice" as transaction type
Enter purchase order number 4500001234
Verify that the PO line items populate automatically with the correct quantities and prices
Enter the vendor's invoice reference number INV-2026-0450
Enter the invoice amount as £12,500.00 (matching the PO value)
Simulate the document (Ctrl+F5) and check the FI posting preview — confirm the debit is to the GR/IR clearing account and the credit is to the vendor payables account
Post the invoice
Navigate to the vendor line items (FBL1N) and confirm the invoice appears as an open item against vendor 100234

Expected result: Invoice posts successfully with no tolerance errors. Vendor balance increases by £12,500.00. GR/IR clearing account shows the matched amount. Document number is generated in the correct number range.

Notice the specificity: real transaction codes, real PO numbers, real vendor numbers, and precise expected results. This is what separates a useful test case from a vague instruction. For a broader framework, see our complete guide to user acceptance testing.

4. Common SAP UAT Mistakes

Having observed SAP programmes across industries and geographies, certain mistakes appear with depressing regularity. Here are the ones that cause the most damage — and they are all avoidable.

Testing with Perfect Data

UAT environments loaded with clean, idealised master data and no transaction history behave very differently from a production system three months after go-live. Test with migrated data, including records with incomplete fields, legacy data quirks, and the inevitable imperfections that exist in any real dataset. If your vendor master records have inconsistent payment terms or your material masters have missing MRP views, you need to discover that during UAT — not during the first production payment run.

Ignoring Authorisation Testing

Testing with SAP_ALL or broad composite roles is one of the most common and most dangerous mistakes. Your users will not have SAP_ALL in production. They will have carefully scoped roles with specific authorisation objects and field values. If you do not test with production-equivalent roles, you will discover authorisation gaps on go-live day — and your users will be unable to execute their core transactions. Test both positive access (can they do what they need?) and negative access (are they blocked from what they should not do?).

Not Testing Fiori Apps Alongside SAP GUI

If your deployment includes both SAP GUI transactions and Fiori apps, you must test both. Fiori apps use OData services that may not expose every field or validation rule available in the underlying SAP GUI transaction. Workflows triggered from Fiori may behave differently. Tile counts on the Fiori launchpad may not update correctly. Assuming that "if it works in GUI, it works in Fiori" is a recipe for go-live problems.

Skipping Integration Testing

SAP rarely operates in isolation. IDocs to and from third-party systems, RFC connections to legacy applications, API integrations with e-commerce platforms, and middleware orchestrations all need testing under realistic conditions. Test with production-like message volumes, validate error handling for malformed messages, and confirm that retry and reprocessing logic works. A single failed IDoc processing in production can halt an entire business process.

Relying on the SI Partner to "Handle Testing"

Your systems integrator is responsible for unit testing, configuration testing, and leading SIT. They are not responsible for UAT. If your SI partner is writing your UAT test cases, executing them, and signing them off, you do not have UAT — you have a very expensive quality assurance exercise that tells you nothing about whether your business users can actually operate the system. UAT must be owned and executed by the business. The right UAT tooling can help consultants support this process without taking ownership of it.

No Regression Testing After Transport Imports

Importing a transport that fixes a defect in SD pricing can inadvertently break FI account determination or CO cost object assignment. Every transport imported into the UAT environment during the testing phase must trigger targeted regression testing of the affected processes. Without this discipline, you are continuously introducing untested changes into an environment that is supposed to be proving production readiness.

SAP UAT Readiness Checklist

Use this checklist before starting UAT on your SAP implementation. If you cannot tick every item, your UAT is at risk.

Pre-UAT Prerequisites

☐SIT is complete with all critical defects resolved
☐UAT client is refreshed with latest transports and migrated data
☐Transport freeze plan is agreed for the UAT window
☐User accounts created with production-equivalent roles (not SAP_ALL)
☐Fiscal year and posting periods are open in all relevant company codes
☐All custom ABAP developments are transported and unit tested
☐Integrations (IDocs, RFCs, APIs) are connected and message flow is confirmed
☐Fiori launchpad is configured with correct catalogues and groups

UAT Execution

☐Test cases reference specific T-codes or Fiori app names
☐Business users are assigned as testers (not SI consultants)
☐End-to-end process flows span multiple modules (not module-silo tests)
☐Data migration validation is included in test scope
☐Authorisation testing uses production-equivalent roles
☐Defect logging and triage process is agreed with severity definitions
☐Sign-off criteria are defined per module owner and communicated
☐Minimum four weeks of elapsed time is allocated for UAT

5. Getting Sign-Off on a SAP Programme

UAT sign-off on a SAP programme is not a simple act of ticking a box. It is a structured governance process that must satisfy the steering committee, the business process owners, and — in many organisations — internal audit. Getting this right requires planning that begins before UAT starts, not in the final week when everyone is scrambling for go-live approval.

Steering Committee Expectations

SAP programme steering committees expect evidence-based go-live recommendations, not optimistic project updates. Before UAT begins, align with the steering committee on what they need to see to make a go/no-go decision:

Test execution metrics — percentage of test cases executed, passed, failed, and blocked, broken down by business process area
Defect position — total defects by severity (critical, high, medium, low), with resolution status and ageing. The steering committee needs to see the trajectory, not just a snapshot
Business process readiness — a clear statement from each process owner on whether their area is ready for go-live, with evidence to support their position
Outstanding risks and conditions — any conditions attached to the sign-off, with documented workarounds, owners, and deadlines

Structured Sign-Off by Module Owner

Break sign-off into layers rather than treating it as one monolithic decision:

Process-Level Sign-Off

Each business process owner signs off their area: the finance director signs off record-to-report, the head of procurement signs off procure-to-pay, the commercial director signs off order-to-cash. This happens first and provides the evidence base for the overall decision.

Integration Sign-Off

Confirm that all integrations between SAP and external systems — IDocs, RFCs, APIs, middleware — are functioning correctly, with error handling validated and monitoring in place for production.

Data Migration Sign-Off

Finance and operations confirm that migrated master data and opening balances are accurate, complete, and work within real transactions. Opening balances reconcile to the legacy system's closing figures.

Go-Live Readiness Assessment

The programme manager presents the consolidated readiness position to the steering committee: process sign-offs, integration status, data migration validation, outstanding defects, and residual risks. The steering committee makes the go/no-go decision. This is a business decision, not a technical one.

Audit Trail Requirements

SAP programmes — particularly in regulated industries or publicly listed companies — often face internal audit scrutiny of the go-live decision. Your UAT process needs to produce an audit trail that demonstrates:

Who tested what, and when — every test case execution must be attributed to a named tester with a timestamp
Evidence of testing — screenshots, document numbers, or system outputs that prove the test was actually executed, not just marked as passed
Defect resolution trail — every defect from identification through triage, resolution, retest, and closure
Formal sign-off records — documented sign-off from each process owner with date and any conditions attached
Conditional go-live items — if the go-live is approved with outstanding items, these must be documented with owners, deadlines, and severity assessments

A centralised UAT platform makes this audit trail automatic rather than relying on manual collation of spreadsheets and email approvals.

Practical Tip:

Create a single go-live readiness dashboard that shows test execution progress, defect status by severity, sign-off status by business process area, and outstanding conditions — all in real time. Present this to the steering committee weekly during UAT. This eliminates the last-minute scramble to compile status reports and gives everyone the same view of reality.

Final Thought

SAP implementations fail at go-live not because the software is inadequate, but because the testing was. UAT is your last line of defence before the business starts running on a new system — and on a SAP programme, the stakes are as high as they get.

The organisations that get SAP go-lives right are the ones that treat UAT as genuine business assurance: structured test plans organised by business process, real end users executing tests with production-equivalent authorisations, evidence-based sign-off presented to the steering committee, and the discipline to delay when readiness signals are negative. It is not glamorous. But it is the difference between a successful go-live and a very expensive lesson. For more on how LogicHive supports SAP testing specifically, see our dedicated platform page.

Frequently Asked Questions

How long should UAT take on a SAP implementation?

For a typical SAP implementation covering core modules (FI/CO, MM, SD), plan for a minimum of four to six weeks of dedicated UAT. Large-scale S/4HANA programmes with multiple modules, complex integrations, and global rollouts may need eight to twelve weeks. This is elapsed time with business users actively testing — not consultant effort. UAT must follow completed SIT and should not begin until transport requests for core configuration are frozen.

Should we test in SAP GUI, Fiori, or both during UAT?

If your users will interact with both SAP GUI and Fiori apps in production, you must test both during UAT. Fiori apps and SAP GUI transactions can behave differently — field validations, authorisation checks, and workflow triggers may not fire identically across both interfaces. Test each business process through the interface the end user will actually use day-to-day, and include at least one cross-interface scenario to validate data consistency.

What is the difference between a conference room pilot and UAT in SAP?

A conference room pilot (CRP) is an early validation exercise, typically run during the Realise or Build phase, where key users walk through configured processes in a workshop setting with consultants present. Its purpose is to validate that the design works in principle. UAT is a formal testing phase where business users independently execute structured test cases against a production-like environment to confirm the system is ready for go-live. CRPs inform the design; UAT validates the finished build.

How do we handle authorisation testing during SAP UAT?

Authorisation testing in SAP must be performed with production-equivalent roles, not SAP_ALL or overly broad profiles. Each tester should log in with the role assignments their real user will have in production. Test both positive scenarios (can the user execute the transactions they need?) and negative scenarios (are they blocked from transactions they should not access?). Pay particular attention to authorisation objects for posting, approval limits, and sensitive transactions like vendor master maintenance.

Who should sign off on SAP UAT?

SAP UAT sign-off should be structured in layers. Each module or process area should be signed off by the designated business process owner — not the SAP consultant or project manager. These individual sign-offs feed into an overall go-live readiness assessment presented to the steering committee. The steering committee makes the final go/no-go decision based on evidence from the process owners, the integration test results, data migration validation, and the outstanding defect position.

Free Forever Plan Available

Run Your SAP UAT with Confidence

LogicHive gives SAP implementation teams real-time visibility into UAT progress, centralised evidence, and structured sign-off — so your go-live decision is based on facts, not hope.

Start Free Trial See Features

No credit card required