SAP UAT Before Go-Live: What Finance and Logistics Teams Need to Test

Every SAP go-live has two teams that bear the real cost of a failed UAT cycle: Finance, who will discover configuration errors at the worst possible moment — period-end, audit, or board reporting — and Logistics, who will find out their delivery split logic is wrong when customer orders are stuck in backorder on day one. Both groups are underserved by standard SI test scripts, which tend to validate configuration rather than the end-to-end business processes those teams actually run.

This guide covers the SAP UAT scenarios that matter most for Finance and Logistics before go-live — the ones that automated testing misses and that surface in production at the moment least convenient to fix them.

Why Finance and Logistics carry the highest UAT risk

Finance and Logistics are where SAP's cross-module dependencies are most consequential. A misconfigured valuation class in Materials Management propagates into the wrong GL account in Finance. A delivery split rule that works correctly for single-storage-location orders silently fails for orders spanning two warehouses. Neither failure is visible in module-level testing — it only appears when a user runs the complete business process end-to-end.

In manufacturing businesses, the Finance and Logistics dependency is tightest. Goods movements in the warehouse drive accounting documents in FI. Cost centre allocations in CO depend on production order confirmations in PP. Intercompany sales between plants depend on purchasing and sales configuration in both entities being consistent. UAT for these organisations cannot be siloed by module — it must cross process boundaries.

“The SAP go-live failures that matter to the business — the ones that appear on executive dashboards and trigger weekend incident calls — almost always originate in Finance or Logistics. Not because those teams made mistakes, but because their processes were never properly tested as an end-to-end chain.”

Finance UAT: the critical scenarios before go-live

Period-end close — run it before you go live

The single highest-value test a Finance team can run during UAT is a complete period-end close simulation. It exercises every process that will matter under time pressure in production: GL postings, allocations, asset depreciation, foreign currency revaluation, intercompany reconciliation, and the close sequence itself. If you only have time for one Finance UAT test, it's this one.

A simulated close in the UAT client should include all of the following, in sequence:

1. 1.Post all open journals and accruals for the period, using the real Finance team members who will own each step in production
2. 2.Run the automatic payment proposal for all open vendor invoices and validate the payment run output before generating the file
3. 3.Run asset depreciation for all asset classes and confirm the posting document matches the depreciation schedule
4. 4.Run the foreign currency revaluation for all open items and bank balances in non-functional currencies — validate accounting documents for each currency pair
5. 5.Post intercompany invoices and management charge journals; confirm the counterpart entry posts correctly in the receiving entity
6. 6.Run cost centre allocation and assessment cycles; validate that receiver objects pick up the correct allocation amounts
7. 7.Generate the trial balance and reconcile each line to subsidiary ledgers — AP subledger, AR subledger, asset register, and inventory

In S/4HANA, the Universal Journal changes how some of these steps behave compared with ECC. Cost element reporting is replaced by G/L account reporting. Profit centre derivation rules apply at posting time, not at period-end. If your Finance team is carrying test assumptions from a prior ECC implementation, those assumptions need to be validated from scratch.

Foreign currency revaluation — a frequent go-live casualty

Foreign currency revaluation is one of the most commonly misconfigured Finance processes in SAP UAT, because it only breaks under specific conditions: an open item in a non-functional currency, with a valuation method that doesn't match the accounting standard, or an account determination in OB09 that posts to the wrong gain/loss account for intercompany balances. None of these failures appear in unit testing. They appear at the first month-end close in production.

• —Test revaluation for every foreign currency pair in scope — not just the most common ones
• —Validate the accounting document for both the unrealised gain/loss posting and the reversal in the following period
• —Confirm intercompany open items revalue into the correct company code — the receivable and the payable should both revalue, and the net translation difference should be consistent
• —Test the valuation method configuration for compliance with the relevant accounting standard (IAS 21, ASC 830, or equivalent)

Intercompany reconciliation — the invisible period-end failure

Intercompany reconciliation fails in SAP when the intercompany GL account pairs don't match, when document splitting derives different profit centres on each side of an intercompany transaction, or when the clearing process runs in a different sequence to how the postings were made. These failures create period-end variances that Finance cannot explain — and cannot reverse cleanly — without understanding the root configuration cause.

• —Post an intercompany journal from each entity in scope and confirm the clearing entry in the counterpart entity is generated correctly
• —Validate that document splitting assigns profit centre and segment consistently on both sides of each intercompany transaction
• —Run the intercompany reconciliation report and confirm the outstanding items match the transactions posted — no phantom balances
• —Simulate the elimination process if group consolidation is in scope and confirm intercompany balances eliminate to zero in the consolidated view

Logistics UAT: the critical scenarios before go-live

Delivery split logic — the highest-risk logistics scenario

Delivery split logic in SAP determines how a sales order with multiple line items is split into delivery documents — based on shipping point, storage location, route, and delivery group. When this configuration is incorrect, orders split in ways that don't match operational reality: some lines ship while others are stuck in backorder with no alert, warehouse teams receive split delivery documents they can't reconcile with the original order, and customers receive partial shipments without explanation.

UAT must test delivery split scenarios that reflect the actual complexity of your order book — not just clean single-line orders:

• —Multi-line orders spanning two or more storage locations — confirm the delivery split is correct and both deliveries post goods issue without error
• —Orders with mixed delivery groups — confirm that lines assigned to different delivery groups split correctly and don't block each other
• —Partial delivery scenarios — confirm that a partial goods issue for one line doesn't leave the remaining lines in an incorrect backorder status
• —Returns — confirm that a delivery reversal against a split order correctly reopens the right line items and doesn't create phantom stock movements
• —Route determination — for businesses with multiple routes or shipping conditions, validate that the correct route is determined for each ship-to address and that the schedule falls within the expected delivery window

Three-way match under realistic conditions

Three-way match — the reconciliation of purchase order, goods receipt, and vendor invoice — is the most consequential procurement control in SAP. When it works correctly, it blocks invoice payment until quantity and price tolerances are satisfied. When it's misconfigured, invoices pass to payment silently, quantities are matched against the wrong PO line, or tolerance exceptions route to the wrong approver.

• —Goods receipt with partial quantities — post a goods receipt for 80% of the PO quantity and attempt to invoice for the full amount; the tolerance configuration should block the invoice for the unmatched quantity
• —Price variance — invoice at a price above the PO price and confirm the tolerance key behaviour: does it block, create a warning, or pass silently to payment?
• —Multiple goods receipts against a single PO — if deliveries are split across multiple receipts, confirm the invoice matching correctly aggregates across all receipts
• —Service procurement — for service orders where there is no physical goods receipt, confirm the service entry sheet process and the confirmation step that releases the invoice
• —Invoice parking and workflow — when an invoice is blocked for tolerance, confirm the workflow routes to the correct approver and that the approval releases the invoice for payment

Goods movements and inventory accounting

Every goods movement in SAP generates an accounting document — a feature that is SAP's strength in inventory valuation and a source of configuration errors in UAT. The valuation class assigned to a material determines which GL account a goods movement posts to. If the valuation class is wrong, or if the account determination in OBYC doesn't match the GL account structure, goods movements post to incorrect accounts silently.

• —Goods receipt against a purchase order — validate the accounting document posts to the correct stock account and GR/IR clearing account for each material type
• —Goods issue for a production order — validate the consumption posting debits the correct cost element and cost centre for each component category
• —Transfer posting between storage locations or plants — validate the accounting treatment, particularly for inter-plant transfers that cross company codes
• —Physical inventory adjustment — post a cycle count result and validate the inventory difference posts to the correct variance account
• —Return to vendor — post a return delivery against a goods receipt and validate the reversal accounting document matches the original, not a new assessment

Warehouse management and Fiori in logistics roles

For businesses using SAP Extended Warehouse Management (EWM) or the legacy Warehouse Management (WM) module, the Fiori launchpad is what warehouse team members actually use to do their jobs. Picking tasks, transfer orders, goods receipt confirmations, and cycle count sheets all route through Fiori apps that must be tested on the actual device used in the warehouse — typically a tablet or RF scanner, not a desktop browser.

• —Test picking task assignment and confirmation on the production device — not desktop Chrome
• —Validate transfer order creation and confirmation for both inbound and outbound movements
• —Test the goods receipt Fiori app with a realistic barcode or QR scan workflow if scanners are in scope
• —Confirm that warehouse users cannot access finance transactions through their Fiori launchpad — role boundary testing is as important as functional testing
• —Test offline or low-connectivity scenarios if warehouse RF coverage is inconsistent

IDoc and integration testing for Finance and Logistics

Finance and Logistics are the primary consumers and producers of IDocs in most SAP landscapes. EDI invoices from suppliers post through inbound IDocs into Accounts Payable. Despatch advice messages to customers are generated as outbound IDocs from Logistics. Payroll results replicate from SuccessFactors via IDocs into HR. When IDoc error handling is not tested during UAT, these failures appear in production as a silent backlog — no user error, just unposted documents accumulating in BD87.

• —Trigger each inbound IDoc type used by Finance (INVOIC, REMADV) and Logistics (DESADV, ORDERS) and confirm correct posting in the UAT system
• —Simulate an IDoc failure — a missing vendor master, a closed posting period, a rejected pricing condition — and confirm the error is visible in BD87 and triggers the alert configured for the process owner
• —Test the reprocessing workflow — an IDoc that fails on first delivery should be resolvable without creating a duplicate posting
• —For SuccessFactors integration: trigger a replication run and validate that org structure and employee master data arrive correctly in SAP HCM or Employee Central Payroll
• —Validate cutover interface sequencing: which interfaces should be switched to production endpoints first, and does the order matter for dependent document flows?

What independent UAT finds that internal teams miss

Finance and Logistics teams are the right people to run UAT — they know the business process and they'll be the ones living with the consequences of a failed go-live. But they're also the teams under the most time pressure in the weeks before cutover. The scenarios they skip under time pressure are consistently the ones that surface as production incidents.

Independent UAT specialists don't skip the edge cases. They run the partial delivery against the multi-storage-location order because that's what the test script says, not because they know from experience that the clean path usually works. They test the intercompany revaluation because it's in scope, not because it happened to be the scenario that failed last time. That systematic coverage — without the familiarity bias that internal teams bring — is what independent UAT delivers.

For SAP go-lives where Finance will be reporting to the board in week two, and Logistics will be fulfilling customer orders from day one, independent UAT isn't overhead. It's the only structured test of the scenarios that matter most — before they matter in production.