SAP UAT Testing Checklist: What to Validate Before S/4HANA Go-Live

The most expensive SAP go-live failures don't happen because of bad configuration. They happen because nobody tested the business processes end-to-end — the procure-to-pay cycle under volume, the foreign currency revaluation at period-end, the IDoc error handling when an interface drops a message. These scenarios don't appear in SI test scripts. They appear in production on day three of go-live.

This checklist covers the SAP UAT scenarios that matter most before cutover. It's structured around business process areas rather than modules, because that's how failures actually occur: not in FI or MM in isolation, but across them, at the seams.

Why SAP UAT is different from other enterprise testing

SAP's architecture is both its strength and its testing challenge. Deep integration between modules means that a configuration decision in Materials Management propagates into Finance, Controlling, and Logistics — often in ways that aren't visible until a cross-module scenario runs in full. A purchase order that looks correct in ME23N can still trigger an incorrect accounting document in MIGO, because the valuation class for a material was set up without considering the GL account determination in OBYC.

SAP S/4HANA deployments introduce an additional complexity: the Universal Journal. Merging FI and CO into a single table sounds like a simplification. In practice, it changes how period-end close behaves, how cost element reporting works, and how intercompany eliminations are structured — and any of those changes can invalidate test assumptions carried forward from ECC.

“SAP can be configured correctly at the module level and still fail at the business process level. UAT is the only test that validates the end-to-end scenario — the workflow a real user runs, across the modules it touches, at the volume the business actually operates.”

1. Procure-to-pay — the highest-risk process chain

Procure-to-pay (P2P) is the process chain that generates the most SAP go-live failures. It spans PR creation, PO approval, goods receipt, invoice verification, and vendor payment — and every step has configuration dependencies on the previous one. UAT must test the full chain, not individual transactions.

• —Purchase requisition to purchase order conversion — approval workflows, sourcing rules, and account assignment validation across all procurement categories
• —Three-way match under realistic conditions — goods receipt with partial quantities, delivery tolerances, and invoice verification with price variances
• —Goods receipt with split storage locations — does posting correctly distribute inventory and generate the correct accounting document?
• —Invoice parking and blocking — does the exception workflow route correctly to the approving cost centre owner when a tolerance is exceeded?
• —Payment run configuration — payment terms, house bank selection, and payment method determination tested with representative vendor master data
• —Cross-company P2P — intercompany purchasing scenarios where the ordering and supplying entities are in different company codes

The failure mode to watch for in P2P UAT is silent error. A three-way match that fails due to a quantity tolerance should block the invoice — but a misconfigured tolerance key can let it pass to payment with no alert. Test the tolerance boundaries, not just the clean-path scenario.

2. Order-to-cash — revenue process integrity

Order-to-cash (O2C) covers the complete revenue cycle from sales order to cash receipt. In SAP S/4HANA, this process is where pricing condition misconfiguration, credit management settings, and revenue recognition rules combine to produce incorrect financial outcomes that are difficult to unwind after go-live.

• —Sales order creation with pricing — condition determination tested across all customer/material combinations, including special pricing agreements and volume discounts
• —Credit management integration — credit checks at order save and delivery, credit hold workflow, and credit limit update after payment receipt
• —Delivery processing — picking, packing, and goods issue for orders with mixed storage locations, partial deliveries, and backorder scenarios
• —Invoicing — billing document creation, tax determination, and output determination for all customer groups and sales organisations
• —Returns and credit memos — return delivery, goods receipt reversal, and credit memo issuance tested end-to-end
• —Revenue recognition — IFRS 15 scenarios if S/4HANA Revenue Accounting and Reporting (RAR) is in scope

Output determination — the overlooked failure point

SAP output determination — the configuration that controls whether a customer receives an email confirmation, a PDF invoice, or an EDI message — is tested last in most implementations and breaks first in production. UAT must confirm that the correct output type fires for each customer group, that the email addresses resolve correctly from the customer master, and that EDI partner profiles are live and accepting messages.

3. Finance and period-end close

Finance UAT in an S/4HANA deployment is where the Universal Journal changes matter most. The merge of FI and CO means that cost allocation cycles, profit centre derivation, and intercompany reconciliation all behave differently from ECC. If your business has carried forward test cases from a previous system, they need to be redesigned — not just re-executed.

• —GL posting and document splitting — does document splitting correctly derive profit centre and segment for all posting types, including cross-company transactions?
• —Cost centre allocations and assessment cycles — do period-end cycles run to completion without errors, and do the results match the expected distribution rules?
• —Foreign currency revaluation — test for all currency pairs in scope, and validate the accounting document generated in both the local and group currency
• —Intercompany reconciliation — are intercompany payables and receivables matched correctly at period-end, and does the elimination work at the group level?
• —Fixed asset accounting — depreciation run, asset addition, and asset transfer tested with the new asset accounting framework if migrating from classic AA
• —Period-end close sequence — the full close checklist run end-to-end in the UAT client, including all blocking activities in the correct order

Foreign currency revaluation deserves specific attention. The valuation method, exchange rate type, and account determination in OB09 combine in ways that produce incorrect postings for intercompany balances in the wrong company code — a failure that typically surfaces at period-end when it's hardest to fix.

4. SAP Fiori and role-based access

SAP Fiori is the front end most end users will actually interact with — and it's the area most commonly undertested in UAT. Fiori role configuration is distinct from backend authorisation objects, which means a user can have the correct S/4HANA role and still see a blank launchpad, missing tiles, or no search results in a Fiori app.

• —Launchpad tile visibility — test each business role persona as a named test user; tiles should appear exactly as designed, no more and no less
• —Composite role conflicts — when users are assigned through composite roles rather than single roles, test that permission inheritance works correctly and that there are no authorization object gaps
• —Fiori app functionality — don't just confirm tiles load; execute the workflow the tile supports to confirm the backend connectivity is intact
• —Mobile device testing — Fiori apps served to tablets used in warehouse, field service, or logistics roles must be tested on the actual device and network, not just desktop Chrome
• —Fiori app personalisation — if users are expected to personalise their launchpad, test that personalisations persist across sessions and don't conflict with role assignments

5. Integration landscape — IDocs, APIs, and RFC

SAP implementations are almost never standalone. The integration landscape — EDI partners, SuccessFactors, third-party logistics systems, warehouse management, or custom middleware — is where the most damaging post-go-live failures occur. These failures are damaging because they're invisible: a missing IDoc generates no user-facing error, just a backlog of unposted documents.

• —IDoc monitoring and error handling — trigger each inbound and outbound IDoc type in the UAT system and confirm correct posting; then simulate a failure and confirm the error appears in BD87 and triggers the correct alert
• —API integration testing — REST and SOAP interfaces to third-party systems tested with production-representative payloads, including error responses and retry logic
• —RFC connectivity — remote function call connections to connected systems validated, including connection timeouts and authorisation under the RFC service user
• —SuccessFactors/HCM replication — if Employee Central Payroll or SuccessFactors HCM is in scope, test the replication of org structure and employee master data under realistic volumes and timing
• —Cutover integration sequence — the order in which interfaces are switched to production endpoints during cutover rehearsed as a timed exercise

Timing failures — the integration risk automated testing misses

The integration failure that automated testing consistently misses is timing. An IDoc from an EDI partner arrives at 11:58 PM. The posting job runs at midnight. The IDoc timestamp falls in the wrong processing window, the document posts to the prior period, and Finance discovers the variance at the next period-end. No unit test or system integration test simulates this scenario. UAT — run across a realistic time window, with real job scheduling — does.

6. Migration data quality

Data migration into SAP S/4HANA is a parallel workstream to system configuration, and the two workstreams intersect dangerously in UAT. Migrated data that looks correct in an isolated data quality check can still fail when it interacts with the configured system — a vendor master loaded without the correct payment method will cause the payment run to skip that vendor silently.

• —Open item migration — open purchase orders, sales orders, and accounts payable/receivable items migrated correctly with correct document dates and amounts
• —Material master completeness — all required views populated for each material type and plant combination; missing views cause transaction errors, not loading errors
• —Customer and vendor master — payment terms, bank details, output partner functions, and credit data validated against source records
• —Asset master migration — asset values, depreciation start dates, useful life, and accumulated depreciation reconciled against the legacy fixed asset register
• —Cutover reconciliation — migrated balances reconciled to the legacy trial balance at the cutover date before go-live sign-off

How to structure an SAP UAT cycle

An SAP UAT cycle runs in three layers. The first layer is process UAT: individual business process chains tested end-to-end by domain testers (Finance, Procurement, Logistics) using scenario-based test cases, not transaction-by-transaction scripts. This layer validates that the system does what the business needs.

The second layer is integration UAT: cross-functional scenarios that span multiple process areas. A returns process that starts in SD, generates a goods receipt in MM, posts a credit memo in FI, and triggers an EDI message to the customer's system is an integration scenario. It needs to be tested as a single sequence, not as three separate functional tests.

The third layer is cutover rehearsal: the complete go-live sequence run as a timed exercise, including data migration, interface switch-over, and the first business transactions in the new system. This layer validates operational readiness — whether the team can actually execute the cutover in the available window.

“The organisations with the smoothest SAP go-lives run all three layers, with independent specialists running the first two. Implementation partners build excellent SAP systems. They're not well-positioned to test them objectively — the familiarity that makes them effective configurers is the same familiarity that causes them to avoid testing the scenarios they know are fragile.”

The case for independent SAP UAT

Your SAP implementation partner has spent 12–18 months in your system. They know which scenarios are configured conservatively and which are stretched thin. That knowledge is valuable. It's also what makes their testing blind to the failure modes that matter most.

Independent UAT specialists approach the system the way a procurement manager on day one of go-live will approach it: with a business task to complete, an end-to-end process to run, and no institutional knowledge of the implementation decisions that produced the current state. That perspective — deliberately naive, systematically thorough — finds defects that internal testing doesn't find. Consistently. Across every engagement.

For an SAP S/4HANA deployment in the $5–20M range, the UAT cycle is not the cost to minimise. It's the validation layer that protects the entire investment.