🧪 What is SAP UAT and Why Does Test Tracking Matter?
Today we explain what UAT really is. UAT - or User Acceptance Testing - is the last must check before your SAP system goes live. This is where the actual business users (not the consultants, not the developers) sit down and test whether the system works the way their business actually runs. If test cases are tracked poorly during UAT, defects get missed, sign-off happens too early, and the go-live becomes a tragedy. we have seen this happen many times. This guide will show you how to do it properly - with real examples from pharma, manufacturing, and finance projects.
Test Case Structure
Every test case needs a clear ID, step-by-step actions, and a specific expected result - not just “system should work.” We will cover exactly how to write them.
Defect Tracking
When something fails, you need to log it properly with a defect ID, severity, and a link back to the test case. We will go through the full defect lifecycle.
Sign-Off Process
Not everything needs to be perfect before go-live - but the critical things do. Here is who signs off, what they check, and how the final decision is made.
UAT Phases in a SAP Project
Where UAT fits in the SAP implementation lifecycle
In most SAP projects - whether you are using SAP Activate or the older ASAP method - testing happens in stages. UAT comes after the consultants have already finished their unit testing and integration testing, and just before the business decides to go live. Knows exactly where UAT sits in this timeline helps you plan your tracker and your team correctly.
| Phase | Who Executes | What Is Tested | UAT? |
|---|---|---|---|
| Unit Testing (SIT) | SAP Consultants | Individual config objects, single transactions | No |
| Integration Testing | SAP Consultants + Key Users | End-to-end process flows across modules | No |
| User Acceptance Testing | Business Users (Key Users) | Real business scenarios in near-production system | ✅ YES |
| Regression Testing | Key Users + Consultants | Retesting after defect fixes | Part of UAT |
| Performance/Load Testing | Basis Team | System under load, response times | No |
| Go-Live Cutover | Full Project Team | Data migration, cutover steps, final checks | After UAT |
Important: Please do not run UAT on your development or sandbox system. Use your QAS client (Quality Assurance) or a dedicated pre-production environment. The data should be as close to real as possible - fake data gives you fake results, and then the real problems only show up after go-live.
📋 How to Structure a SAP UAT Test Case Correctly
the number one reason UAT fails is not a system problem - it is poorly written test cases. Either they are too misty to follow, or nobody wrote down what the expected result should be. Here are the fields every single test case must have
| Field | Description | Example |
|---|---|---|
| Test Case ID | Unique identifier -never reuse IDs | MM-UAT-001 |
| Module | SAP module being tested | MM (Materials Management) |
| Test Scenario | Business process being verified | Create Standard Purchase Order |
| Prerequisites | What must exist before executing | Vendor 100045 created, Material 400110 exists, Plant 1000 active |
| Test Steps | Numbered step-by-step actions | 1. Go to ME21N 2. Enter vendor... 3. Save... |
| Expected Result | Exactly what SHOULD happen | System creates PO with number 4500001234, status Open |
| Actual Result | What actually happened during test | PO created successfully with number 4500001235 |
| Status | Pass / Fail / Blocked / In Progress | PASS |
| Tested By | Name of business user who executed | Riya Sharma (Procurement Lead) |
| Test Date | Date of execution | 04-Apr-2026 |
| Defect Ref | Linked defect ID if failed | DEF-047 (blank if passed) |
| Remarks | Any additional observations | Minor UI alignment issue noted -not blocking |
Most Common Mistake: Writing “System works correctly” as the Expected Result. Please do not do this. It tells us nothing. Instead, write the exact thing that should happen - for example, “PO number starting with 45 is created, total value is INR 2,26,000, and the system shows the message: Standard PO created.” If the expected result is vague, testers cannot tell whether it passed or failed.
Real Test Case Example -MM Module
Create Standard Purchase Order via ME21N
Prerequisites: Make sure vendor 100045 (Union Chemicals Ltd) is active. Material 400110 (Lactic Acid IP) should already be created with the purchasing view. Plant 1000 and purchasing org 1000 must be set up before you start.
1. Log into SAP QAS as user SHARMA (Procurement Role).
2. Execute transaction ME21N.
3. Enter Vendor: 100045, Purchasing Org: 1000, Purchasing Group: 001, Company Code: 1000.
4. In item line: Material 400110, Qty: 500 KG, Price: INR 450/KG, Delivery Date: 30-Apr-2026, Plant: 1000.
5. Click Save (Ctrl+S).
The system should create a PO with a 10-digit number starting with 45. The status should say Open. You should be able to see it in ME23N. The total should come to INR 2,26,000 and you should get the message: “Standard PO [number] created.” No errors.
What actually happened (04-Apr-2026): PO 4500001234 was created without any issues. The value was INR 2,26,000, visible in ME23N, and all fields were correct. TEST PASSED.
Post Vendor Invoice Against PO via MIRO
Prerequisites: PO 4500001234 should already have a goods receipt posted against it. The vendor invoice should be ready. Tax code V1 (18% GST Input) should be set up in the system.
1. Execute MIRO.
2. Select Transaction: Invoice. Reference document: PO 4500001234.
3. Enter Invoice Date: 01-Apr-2026, Amount: INR 2,26,000, Tax Code: V1.
4. Verify line items auto-populate from PO/GR.
5. Check tax amount: should be INR 40,500 (18% of 2,26,000).
6. Post the invoice.
The invoice should post and give you an FI document number. The tax line should show INR 40,500 under GL 144510. The vendor line should show a credit of INR 2,65,500. The GR/IR account should clear automatically. System message: “Document [number] was posted in company code 1000.”
What actually happened (04-Apr-2026): The invoice did not post. The system gave this error: “Tax code V1 is not permitted for this transaction.” After checking, we found the tax configuration was missing for company code 1000. Defect DEF-012 was raised. TEST FAILED - this is a blocker. Go-live cannot happen until this is fixed.
📊 How to Track UAT Progress Correctly
Tracking UAT is not just about ticking Pass or Fail. It is about giving the project manager and the business a clear, up-to-date view of where things stand - so they can make smart decisions about whether the system is really ready to go live.
The UAT Test Status Matrix
| Status | Meaning | Action Required |
|---|---|---|
| PASS | Actual result matches expected result exactly | Great - note the date and tester name, then move on to the next one |
| FAIL | Actual result does not match expected result | Stop immediately, take a screenshot, log a defect, and link it to this test case |
| IN PROGRESS | Test case is currently being executed | Must be updated before end of day - WIP overnight is not acceptable |
| BLOCKED | Cannot execute -prerequisite not met or environment down | Tell the project manager straight away and write down why it is blocked |
| NOT STARTED | Test case not yet executed | Plan when it will be tested and track it against your UAT deadline |
| PASS W/ REMARKS | Passes but with minor observations | Write down the observation - it may need fixing after go-live |
Step-by-Step: How to Run Daily UAT Tracking
Morning -Assign test cases for the day
First thing in the morning, the Test Lead opens the tracker and gives each business user their test cases for the day. Keep it manageable - 5 to 8 test cases per person per day is usually enough. Update the “Assigned To” and “Planned Date” columns, then send the assignments by email or Teams.
During Execution -Update status in real time
As testers run their cases, they should update the tracker straight away - not at the end of the day. If something fails, stop right there. Take a screenshot, write down what happened, raise a defect ticket in JIRA or your defect log, and paste the defect ID into the tracker. Do not move on without doing this.
Afternoon -Defect triage meeting (daily)
Every afternoon - around 3.30 PM works well - hold a quick 30-minute meeting with the consultants, key users, and project manager. Go through any new failures from the day. Agree on how serious each one is (Critical, Major, or Minor), who is fixing it, and by when. Update the defect log before you close the meeting.
End of Day -Update completion dashboard
At the end of each day, the Test Lead should update the dashboard - total cases, how many passed, failed, blocked, and not started yet. Work out your pass rate: divide passed cases by total executed and multiply by 100. You need at least 95% to recommend go-live. Send this summary to the project sponsors so there are no surprises.
After Fix -Retest and close
Once a consultant says a defect is fixed and the fix is in QAS, the same business user who originally failed the test must retest it. If it passes now, mark it PASS, close the defect as Resolved, and note the date. Never close a defect based on the consultant's word alone - the business user has to confirm it.
UAT Closure -Sign-off and go-live decision
Once all Critical and Major defects are closed and you have hit the agreed pass rate (usually 95% or above), it is time to call the sign-off meeting. Each module owner signs the form for their area. Then the steering committee reviews everything and makes the final call on whether to go live.
Defect Management in SAP UAT
How to log, prioritize, track, and close defects correctly
A defect is simply when what the system does does not match what you expected it to do. Every defect must be written down properly - please do not just tell the consultant verbally. Here is how we classify defects by how serious they are:
| Severity | Definition | Fix Before Go-Live? | Example |
|---|---|---|---|
| Critical | System crashes, data loss, or core business process completely broken | Mandatory -no exceptions | GR posting fails with system dump |
| Major | Incorrect results that would cause wrong business decisions or compliance issues | Mandatory | Tax calculation showing wrong amount |
| Minor | Cosmetic issues, UI alignment, non-blocking inconveniences | Can defer to post go-live patch | Column header typo in a report |
| Enhancement | New requirement not in original scope, not a defect | Log separately -out of UAT scope | Request to add new report field |
Real Defect Examples Across Modules
Tax Code V1 Not Permitted in MIRO -Company Code 1000
We tried to post a vendor invoice in MIRO using Tax Code V1 (18% GST) for Company Code 1000. The system threw this error: “Tax code V1 is not permitted for this transaction.” The tax code exists - the problem is it was never linked to Company Code 1000 in the FTXP configuration. The root cause is that the TAXINN tax procedure was not assigned to company code 1000.
Go to MIRO. Enter PO 4500001234. Select Tax Code V1 and try to post. The error shows up immediately every single time - I tested it multiple times on QAS client 200.
Business Impact: This is a critical blocker. Every vendor invoice that uses GST will fail to post. The entire accounts payable team for company code 1000 will be stuck. We cannot go live like this. The fix is to assign the TAXINN procedure to company code 1000 using OBYZ and then maintain the tax codes properly in FTXP.
Batch Number Not Auto-Generated During GR -MSC1N
When the warehouse team tried to do a goods receipt in MIGO for material 400110 (Lactic Acid IP), the batch number field was empty and nothing was being generated automatically. The system should have created a batch number on its own based on the number range set up in OMCT. It turns out the batch number range was not activated for plant 1000.
Fixed (07-Apr-2026): The batch number range object Z_BATCH was activated for plant 1000 using OMCT. The number range 0000001 to 9999999 was assigned. I retested it in QAS and the batch number now generates automatically on goods receipt. Ready for the business user to retest and confirm.
🛠️ UAT Tracking Tools -Which to Use When
| Tool | Best For | Key Feature | Cost |
|---|---|---|---|
| SAP Solution Manager (SolMan) | Large SAP enterprise projects | Native SAP integration, test workbench, business process structure | Included with SAP |
| SAP Cloud ALM | SAP S/4HANA Cloud projects | Cloud-native, real-time dashboard, transport tracking | Subscription |
| HP ALM / Quality Center | Large regulated industries (pharma, banking) | Full audit trail, 21 CFR Part 11 compliant, detailed reporting | Licensed |
| JIRA + Zephyr | Agile SAP projects, mid-size teams | Defect + test case in one tool, sprint integration, dashboards | Subscription |
| Microsoft Excel Tracker | Small projects, tight budgets | Flexible, no learning curve, easy sharing via SharePoint | Free |
| Azure DevOps | Microsoft-stack SAP projects | Test plans, boards, pipeline integration | Subscription |
Pharma teams, please read this: If you are implementing SAP in a pharmaceutical company that falls under FDA or 21 CFR Part 11 rules, a simple Excel sheet is not good enough for UAT sign-off. You need a validated tool like HP ALM with proper electronic signatures on every test record. Auditors will ask for the full trail, so make sure every single test execution is properly documented...
SAP Tables Used in UAT Tracking (Backend Reference)
| Table | Description | UAT Relevance |
|---|---|---|
| PRPS | WBS Element data (Project System) | Track UAT as a project activity in PS module |
| JEST | Individual status of objects | Track status of test objects / test orders |
| QMEL | Quality Notifications header | Log defects as quality notifications in QM module |
| QMFE | Quality Notification items (defects) | Individual defect items within a notification |
| EKKO / EKPO | Purchasing document header/item | Verify PO creation test cases passed correctly |
| BKPF / BSEG | Accounting document header/item | Verify FI posting test cases -check document numbers |
| MKPF / MSEG | Material document header/item | Verify GR/GI test cases -goods movement documents |
| AUFK | Production order header | Verify PP production order test cases |
✅ UAT Sign-Off Process -The Correct Way
UAT sign-off is the moment when the business officially says “yes, this system is ready for go-live.” This is not just a formality - it is a serious commitment. By signing, the business is confirming they have tested the system and it meets their requirements. Here is how to do it properly:
Calculate final UAT metrics
Put together the final UAT numbers: how many test cases in total, how many passed, how many failed (broken down by severity), and how many are still blocked. Work out your pass rate. For sign-off, you need zero open Critical defects and zero open Major defects. Minor ones can be left for after go-live, but they should be documented.
Prepare UAT Summary Report
Write a proper UAT Completion Report. Keep it clear and factual. It should include: a summary of what was tested in each module, the defect status (open vs closed), any known issues that are being carried forward with their risk level, your honest Go or No-Go recommendation, and a signature page for each module owner.
UAT Sign-Off Meeting
Bring everyone together for a formal sign-off meeting - the business process owners from each module, the project manager, the IT or SAP project lead, and the key users who actually did the testing. Walk them through the UAT report. Each module owner signs for their area. If anyone has a concern or objection, write it down - do not just move on.
Steering Committee Go/No-Go Decision
Take the signed UAT report to the Steering Committee. They look at the overall pass rate, any remaining risks, whether the cutover plan is ready, whether users have been trained, and whether the support team is in place. They make the final go or no-go call - and this decision gets written down formally.
Archive all UAT documentation
Once go-live is decided, save everything: the signed test cases, the defect log, the sign-off form, and screenshots of test evidence. If you are in pharma or finance, you may need to keep this for 6 to 16 years. Auditors can ask for it at any point, so make sure it is stored safely and easy to find.
The UAT Golden Standard
A good UAT has at least a 90% pass rate, no open Critical defects, no open Major defects, proper test evidence for every case, and signatures from the actual business users - not just the consultants. Remember: UAT belongs to the business, not the IT team. If the business has not signed off, UAT is simply not done yet.
Interview Q&A -SAP UAT Testing
Top questions asked in SAP Functional, PM, and Testing interviews
"What is the difference between SIT and UAT in SAP?"
SIT (System Integration Testing) is done by the SAP consultants and key users to check that processes work across modules - for example, does a Purchase Order in MM flow correctly through to an FI accounting document? SIT is a technical check. UAT is different - it is done by the actual business users, using real-life scenarios and realistic data, to check whether the system actually works the way their business works. SIT catches technical mistakes. UAT answers the question: “Can we actually use this system to run our business?” UAT is the last checkpoint before go-live and needs a formal sign-off from the business.
"What do you do if a critical defect is found one day before go-live?"
Also First - do not panic and do not hide it. Tell the Project Manager and Steering Committee straight away, and bring the full defect documentation with you. Then you need to honestly answer three questions: (1) Can the fix be done and retested safely before go-live? (2) Is there a workaround that lets the business manage manually for a short while? (3) Does the go-live date need to move? Going live with a known vital defect and no workaround is not acceptable - ever. That decision about what to do must come from the business and project manager, not from the IT team alone. Write everything down.
"How many test cases should a SAP UAT have?"
Honestly, there is no magic number. It depends on the size and complexity of your project. A good rule: every important business process should have at least one positive test (the normal happy path) and one negative test (what happens when something goes wrong or data is missing). For a typical SAP MM, FI, and SD implementation, somewhere between 140 and 300 test cases is normal. also The real principle is risk-based testing - put more effort on the processes your business uses every day and the ones where a mistake would hurt the most. A process that 60 people use daily deserves far more testing than one that one person runs once a month.
Please remember this: In SAP UAT, the business user is the one doing the testing - not the consultant. The consultant’s job is to prepare the test data, fix any defects, and support the tester when they have questions. If you find that only consultants are running the tests, that is not UAT - that is just more SIT with a different name. For the sign-off to mean anything, the business must own and run UAT themselves.