Oracle AP UAT Checklist

UAT is the controlled cycle in which business users execute end-to-end payables processes against agreed requirements and formally accept the result. Its purpose is a defensible sign-off — a decision, backed by evidence, that Oracle Payables is fit to go live or to absorb a change — rather than simply confirming that the software runs.

This page governs how UAT is planned, executed, and signed off — readiness, ownership, entry and exit criteria, and evidence. The detailed scenarios, with test IDs and expected results, live on the AP Test Cases page. Use this checklist to run the cycle; use the test-case library to populate what you execute inside it.

The AP business lead owns business acceptance and the finance controller owns sign-off on accounting and payment accuracy. The test lead is responsible for running the cycle and assembling evidence, but acceptance is a business decision — it should never sit with the system integrator or the test team alone.

Scope approved, configuration frozen, critical integrations available, test users created, test data loaded, open defects reviewed, UAT cases approved, expected accounting documented, and the reconciliation approach agreed. Each is a gate the test lead confirms and evidences before opening the cycle, because starting early is the most common cause of rework.

Critical scenarios passed, no open severity-1 defects, severity-2 defects accepted or resolved, accounting reconciled, payment files validated, interfaces reconciled, business users signed off, evidence stored, and production-readiness risks documented. Any criterion not met must be explicitly waived with documented risk acceptance before sign-off.

It depends on scope, the number of business units and integrations, and defect volume, so a fixed duration would be misleading. What matters is that the cycle only begins once entry criteria are met and only ends once exit criteria are satisfied. A quarterly-update UAT is far shorter than an implementation UAT because its scope is narrowed to what changed.

If the UAT tenant differs from production in patch level or configuration, results will not reproduce at go-live and the acceptance is worthless. Matching the environment and then freezing configuration for the cycle keeps results reproducible and makes the sign-off meaningful. Environment readiness is therefore a formal entry gate.

Each result should carry the case reference, the tester, the outcome against the expected result, and supporting artefacts — screenshots, hold lists, accounting entries, or reconciled report extracts. Consistent evidence lets an auditor or controller see that a control actually fired, and it is what turns a claimed pass into a defensible one.

Log each defect with a severity and an accountable owner, then triage by severity: severity-1 blocks exit and must be fixed, severity-2 must be fixed or formally accepted with documented risk. Every fix is retested and, where relevant, a regression is run. A defect with no owner is the classic reason a cycle drifts past its date.

Yes. Payables-to-GL reconciliation, payment file tie-out, and interface reconciliation are exit conditions, not optional extras. Without them, financial errors can be accepted unknowingly. The reconciliation approach should be agreed as an entry criterion so results can be tied out against a settled method rather than an improvised one.

Every quarterly update is a change that warrants a scoped acceptance cycle, but re-running a full payables UAT four times a year is impractical. The same governance model scales down when scope is narrowed to the processes the update actually affects — which is where release-impact analysis earns its place in the cycle.

System integration testing confirms that Payables works correctly with its integrations and configuration, and is typically run by the delivery team. UAT is business-owned acceptance against requirements, using production-like data and roles. UAT should begin only after SIT is stable, which is why reviewing open defects is an entry criterion.

Clear ownership is the strongest predictor of a cycle finishing on time. The RACI names, for each activity, who is responsible, accountable, consulted, and informed across the AP business lead, functional lead, test lead, integration lead, finance controller, and IT support — so no activity, defect, or decision is left without an owner.

Post-UAT readiness hands the accepted result into cutover and hypercare: the go-live decision is documented, residual risks and any accepted defects are handed to support, and the evidence pack is retained for audit. Building a reusable regression set from the UAT cases also shortens acceptance for the next quarterly update.