Oracle AP Test Cases for Fusion Payables

How to Use This AP Test-Case Catalogue

Accounts Payable in Oracle Fusion is a chain of dependent processes: a supplier and site feed an invoice, the invoice is validated and matched, holds are raised and released, the invoice is approved, tax and payment terms are applied, distributions are accounted, and payment is processed. A test library that mirrors that chain is far easier to maintain than a flat list of scripts, because each test maps to a process the business actually runs.

Every category on this page uses a consistent test-ID prefix (for example AP-INV for invoice entry or AP-PAY for payment processing) so you can trace a defect back to a process. The representative cases shown are a subset; the linked child pages carry the full scenario sets, boundary cases, and step detail. Treat this page as the index to your Payables test suite.

Scope note. This catalogue summarises each area and points to its detailed page. For the full validation walk-through see Invoice Validation Testing; for the broad invoice lifecycle see AP Invoice Testing Scenarios; and for the end-to-end flow into payment and GL see Oracle P2P End-to-End Testing.

How to Structure an AP Test Library

A durable AP test library is organised by process area, not by tester or by release. Group cases under the same categories Oracle uses — supplier, invoice, validation, holds, approval, tax, payment — and give each a stable ID prefix. This keeps coverage visible (you can see which processes are thinly tested), makes regression selection precise, and lets new cases slot in without renumbering the whole suite.

Organise by process area

One category per Oracle AP process, each with its own ID prefix. Coverage gaps become obvious at a glance.

Stable, traceable IDs

Prefix + sequence (AP-INV-001). IDs never change, so defect and evidence links stay valid across releases.

Layer positive and negative

Every process gets both a clean pass case and the failure cases that must raise the right hold or error.

Tag priority and automation

Mark each case with a priority and whether it is an automation candidate, so cycles can be scoped by risk.

Parameterise test data

Keep amounts, suppliers, tolerances and dates as data, not hard-coded, so cases reuse across environments.

Map cases to configuration

Link each case to the setup that drives it, so a config change re-points exactly the right tests.

Positive vs Negative, Functional vs Integration

An AP test library needs a deliberate mix of test types. Positive cases prove the process works on clean data; negative cases prove the controls fire on bad data. Functional cases exercise one process in isolation; integration cases prove the hand-offs between processes hold. A suite that is all positive-functional will pass happily while real risks — a hold that never fires, an API that validates differently from the UI — go untested.

Test type	What it proves	AP example	Why it matters
Positive (pass)	Clean data completes the process	Matched invoice validates with no hold	Confirms the happy path still works
Negative (fail)	Bad data raises the correct control	Unbalanced distribution raises a hold	Controls are only real if they fire
Boundary	Behaviour at exact thresholds	Variance at tolerance vs one cent beyond	Defects hide at the edges
Functional	A single process in isolation	Payment terms derive the due date	Pinpoints where a defect lives
Integration	Hand-off between processes / systems	FBDI import then validate and account	Most defects appear at the seams
Regression	Prior behaviour survives a change	Re-run pack after a quarterly update	Catches silent Oracle drift
Role-based	Access and privilege enforced	Only a supervisor releases a price hold	Protects segregation of duties

Priority Classification & Regression Selection

Not every case runs every cycle. Classify each by priority so you can run a smoke pack daily, a core pack per sprint, and the full library at release. Regression selection then becomes a question of which processes a given change actually touches — a tolerance change re-runs matching and validation boundary cases, a security change re-runs role-based cases, a quarterly update re-runs the release-scoped subset.

Priority	Meaning	Typical AP cases	Run cadence
High (H)	Financial control or payment-blocking	Validation holds, matching, payment run	Every cycle + smoke
Medium (M)	Important but not payment-blocking	Prepayment apply, discount terms, tax recovery	Per sprint / per release
Low (L)	Edge cases and cosmetic behaviour	Terms override, rare currency formats	Full-library / release

Release Intelligence can narrow the regression scope to what a specific Oracle update changed in your tenant, and Configuration Intelligence maps cases to the setup that drives them so a config change re-points the right subset.

The AP Test-Case Catalogue by Category

The sections below walk the AP process chain. Each category gives a short summary, a table of representative test cases with their preconditions and expected results, and a link to the page where that area is tested in full. Test IDs are category-prefixed and priority (H/M/L) and automation candidacy (Y suitable, P partly, N manual) are shown per case.

Together these tables list more than sixty representative Oracle Fusion Payables test cases — a starting index, not the complete suite. The full step detail ships in the downloadable test library described further down.

Suppliers, Sites & Invoice Entry

Supplier & Supplier-Site AP-SUP

Suppliers and their sites are the master data every invoice depends on — an inactive site or an unvalidated bank account stops payment before an invoice is ever entered. These cases cover creation, duplicate prevention, site assignment, inactivation, and bank-account validation. Full detail lives on the Supplier Testing and Supplier Site Testing pages.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-SUP-001	Supplier create	Create supplier with mandatory attributes	Create privilege, unique name/TRN	Supplier saved, active	H	Y
AP-SUP-002	Duplicate supplier	Create supplier matching an existing one	Matching name or tax registration exists	Duplicate warned / blocked	H	Y
AP-SUP-003	Site assignment	Add pay/purchasing site for a BU	Supplier active	Site active, assignable to BU	H	Y
AP-SUP-004	Site inactivation	Inactivate a site referenced by invoices	Open transactions on the site	Existing txns retained; new entry blocked	M	Y
AP-SUP-005	Bank account	Assign and validate supplier bank account	Country bank-format rules configured	IBAN/routing validated per format	M	P

Invoice Entry AP-INV

Invoice entry is where PO-matched, non-PO, foreign-currency and duplicate-prone invoices enter the ledger. These cases confirm invoices save balanced and that duplicate and mismatch controls fire at entry. The full scenario catalogue lives on the AP Invoice Testing Scenarios page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-INV-001	Standard PO invoice	Enter PO-matched standard invoice	Approved PO, receipt where required	Saved, ready to validate	H	Y
AP-INV-002	Non-PO invoice	Enter unmatched invoice with distributions	Distribution set or manual accounts	Saved, header balances to lines	H	Y
AP-INV-003	Duplicate number	Enter duplicate invoice number for supplier	Same supplier + number already exists	Duplicate prevented / flagged	H	Y
AP-INV-004	Foreign currency	Enter FX invoice with conversion rate	Daily rate loaded for the date	Ledger amount derived correctly	M	Y
AP-INV-005	Header/line mismatch	Header amount ≠ sum of lines	Deliberately mismatched entry	Save blocked or hold on validate	M	Y

Validation, Matching & Holds

Invoice Validation AP-VAL

Validation is the control gate that decides whether an invoice can be accounted and paid, passing it or raising holds. These cases cover a clean pass, distribution and period holds, and batch validation at volume. Full coverage is on the Invoice Validation Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-VAL-001	Validate clean	Validate matched invoice within tolerance	PO-matched, balanced distributions	Validated, no holds	H	Y
AP-VAL-002	Distribution variance	Distributions do not sum to line total	Unbalanced distribution	Distribution variance hold	H	Y
AP-VAL-003	Closed period	Accounting date in a closed AP period	Period closed for the date	Period/date hold raised	H	Y
AP-VAL-004	Batch validate	Run ESS Validate program at volume	Large invoice set queued	All processed; holds per rules	M	Y

Invoice Matching AP-MAT

Matching compares the invoice to the purchase order and receipt, raising price and quantity holds when variances exceed tolerance. These cases cover 2-way and 3-way matches and the two variance holds. Full detail is on the Invoice Matching Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-MAT-001	2-way match	Match invoice to PO within tolerance	PO, no receipt required	Matched, no hold	H	Y
AP-MAT-002	3-way match	Match to PO and receipt	Receipt recorded, within tolerance	Matched, no hold	H	Y
AP-MAT-003	Price variance	Invoice price above PO price + tolerance	Tolerance configured	Price hold raised	H	Y
AP-MAT-004	Quantity over-billing	Billed qty above received + tolerance	Receipt quantity recorded	Quantity hold raised	H	Y

Invoice Holds AP-HLD

Holds are how Oracle stops an invoice until an issue is resolved — system-applied on failed checks or manually applied by a user. These cases cover raising, releasing, and the privilege that gates release. Full coverage is on the Invoice Holds Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-HLD-001	System hold raised	Validation raises hold on failing data	A failing condition present	Correct hold code and count	H	Y
AP-HLD-002	Manual hold	Apply a manual hold to an invoice	Hold-apply privilege	Hold applied; payment blocked	M	Y
AP-HLD-003	Hold release	Release hold after fix and re-validate	Underlying condition resolved	Hold cleared; invoice validated	H	Y
AP-HLD-004	Unauthorised release	Role without privilege attempts release	Processor role, no release privilege	Release denied	H	P

Approval, Tax & Payment Terms

Approval Workflow AP-APR

Approval routing sends invoices to the right approvers based on amount, account, and hierarchy rules before payment. These cases cover auto-approval, single and multi-level routing, and rejection. Full detail is on the Approval Workflow Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-APR-001	Auto-approve	Invoice below the approval threshold	Auto-approve rule configured	Approved without routing	M	Y
AP-APR-002	Single approver	Route invoice to one approver	Approver assigned in rule	Approved; status updated	H	Y
AP-APR-003	Multi-level route	Amount crosses two approval tiers	Hierarchy with two levels	Sequential approvals required	H	Y
AP-APR-004	Reject & resubmit	Approver rejects an in-flight invoice	Approval in progress	Returned to submitter; audit logged	M	Y

Tax AP-TAX

Tax determination calculates tax lines, applies recovery and self-assessment, and raises a variance hold when entered tax disagrees with calculated tax. These cases cover auto-calculation, variance, recovery and withholding. Full detail is on the Oracle Tax Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-TAX-001	Auto tax calc	Tax determined on a taxable line	Tax rules and rates active	Correct tax lines created	H	Y
AP-TAX-002	Tax variance	Entered tax differs from calculated	Tax tolerance configured	Tax variance hold raised	H	Y
AP-TAX-003	Recovery / self-assess	Recoverable or self-assessed tax line	Regime and recovery rules set	Correct recovery and accounting	M	Y
AP-TAX-004	Withholding	Supplier subject to withholding tax	Withholding setup on supplier	Withholding calculated correctly	M	Y

Payment Terms AP-PT

Payment terms derive the due date, discount, and installment schedule that drive when and how much is paid. These cases cover due-date derivation, discounts, split installments and overrides. Full detail is on the Payment Terms Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-PT-001	Due-date derivation	Terms drive the invoice due date	Payment terms on the site	Due date = terms + terms date	H	Y
AP-PT-002	Discount terms	Early-payment discount available	Discount terms configured	Discount amount/date computed	M	Y
AP-PT-003	Multi-installment	Split terms across installments	Installment terms defined	Scheduled payments split correctly	M	Y
AP-PT-004	Terms override	Override default terms on an invoice	Override permitted	Schedule recalculated correctly	L	Y

Prepayments, Credit Memos, Distributions & Accounting

Prepayments AP-PP

Prepayments create an advance that is later applied against standard invoices, reducing the net amount due. These cases cover creation, application, reversal and tax handling. Full detail is on the Prepayment Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-PP-001	Create prepayment	Enter and validate a prepayment invoice	Prepayment invoice type	Prepayment available to apply	H	Y
AP-PP-002	Apply prepayment	Apply prepayment to a standard invoice	Available prepayment exists	Net amount due reduced	H	Y
AP-PP-003	Unapply prepayment	Reverse a prepayment application	Applied prepayment present	Application reversed; balances restored	M	Y
AP-PP-004	Tax on prepayment	Prepayment carrying tax then applied	Tax rules on prepayment	Tax handled per config on apply	M	Y

Credit Memos AP-CM

Credit memos reduce a payable through negative-amount documents, standalone or matched to a base invoice or PO. These cases cover standalone and matched credits, over-credit handling and accounting. Full detail is on the Credit Memo Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-CM-001	Standalone credit memo	Enter and validate a negative credit memo	Supplier active	Validated; correct sign	H	Y
AP-CM-002	Matched credit memo	Match credit memo to invoice/PO	Base invoice or PO exists	Applied; balance reduced	H	Y
AP-CM-003	Over-credit	Credit exceeds the invoice balance	Balance lower than credit	Handled per config; no pay error	M	Y
AP-CM-004	Credit memo accounting	Validate credit-memo accounting entries	SLA rules configured	Reversal entries balanced	M	Y

Invoice Distributions AP-ID

Distributions carry the account coding that validation balances and accounting posts, generated by distribution sets or entered manually. These cases cover distribution sets, invalid combinations, proration and required flexfields. Full detail is on the Invoice Distribution Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-ID-001	Distribution set	Apply a distribution set to a line	Distribution set defined	Distributions generated and balanced	H	Y
AP-ID-002	Invalid CCID	Distribution has a disabled segment	Invalid account combination	Account/GL hold on validate	H	Y
AP-ID-003	Prorate charges	Prorate freight/tax across item lines	Charge lines present	Proration allocated correctly	M	Y
AP-ID-004	Required flexfield	Mandatory DFF/project coding on distribution	Flexfield marked required	Missing value blocks or holds	M	Y

Accounting AP-ACC

Accounting creates the subledger journal entries from validated invoices and transfers them to General Ledger. These cases cover draft and final accounting, account derivation and AP-to-GL reconciliation. Full detail is on the Invoice Accounting Testing page.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-ACC-001	Draft accounting	Run Create Accounting in draft	Validated invoice	Draft entries balanced	H	Y
AP-ACC-002	Final & transfer	Create Accounting final and post to GL	Period open	Entries posted to General Ledger	H	Y
AP-ACC-003	Account derivation	SLA derives liability/expense accounts	SLA rules configured	Accounts match expected mapping	H	Y
AP-ACC-004	Reconciliation	AP-to-GL trial-balance tie-out	Period accounted	AP balance equals GL liability	M	Y

Payment Processing, Integrations & Security

Payment Processing AP-PAY

Payment processing selects validated, approved invoices into a Payment Process Request, builds payments and files, and handles voids and discounts. These cases cover PPR build, single payment, file generation, void/reissue and discount capture. Full detail is on the Payment Processing Testing and Payments Testing pages.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-PAY-001	Payment Process Request	Build a PPR selecting due invoices	Validated, approved, unpaid invoices	Selected set matches criteria	H	Y
AP-PAY-002	Single payment	Pay one invoice via a payment document	Payment method and account set	Payment created; invoice paid	H	Y
AP-PAY-003	Payment file	Generate the payment format file	Payment format configured	File produced per format spec	M	P
AP-PAY-004	Void & reissue	Void a payment and reissue	Issued payment exists	Void reverses; invoice re-opens	M	Y
AP-PAY-005	Discount capture	Pay within the discount window	Discount terms and date valid	Discount taken on payment	M	Y

Integrations AP-INT

Integrations bring invoices in and push payments out through FBDI, REST, OIC and bank files — the paths that bypass the UI and therefore its controls. These cases confirm imported and API-created invoices validate the same as UI entry. There is no separate child page; this area is covered within the invoice and payment pages above.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-INT-001	FBDI import	Bulk invoice load via FBDI	Template populated and loaded	Invoices imported and validated	H	Y
AP-INT-002	REST invoice create	Create an invoice via REST API	API credentials and payload	Invoice created; matches UI validation	M	Y
AP-INT-003	OIC inbound	Inbound invoice through OIC integration	Integration flow active	Data mapped and loaded correctly	M	P
AP-INT-004	Bank feedback	Process a bank confirmation file	Payment file already sent	Payment status updated	M	P

Security & Roles AP-SEC

Security and role testing proves data access is scoped, privileges gate sensitive actions, and segregation of duties holds across enter, approve and pay. These cases cover BU data access, SOD conflict, privilege gating and audit trail. There is no separate child page; role-based cases run alongside the process pages above.

Test ID	Process	Scenario	Preconditions	Expected Result	Pri	Auto
AP-SEC-001	BU data access	AP role restricted to one BU	Role provisioned with data scope	Only permitted BU is visible	H	Y
AP-SEC-002	SOD conflict	Same user enters and pays an invoice	SOD policy defined	Conflict prevented or flagged	H	P
AP-SEC-003	Privilege gating	Non-privileged user attempts hold release	Processor role without privilege	Action denied	H	P
AP-SEC-004	Audit trail	Changes captured for audit	Auditing enabled	Who / what / when recorded	M	Y

Pri = priority (H/M/L). Auto = automation candidate (Y suitable · P partly, needs role/data setup · N manual). These sixty-plus rows are representative; the downloadable library carries the full step detail per case.

Test Data, Evidence, Automation & Role Coverage

Beyond the scenarios themselves, four dimensions determine whether an AP test library is trustworthy and maintainable: the data each case needs, the evidence each run produces, which cases are worth automating, and whether every role that touches AP is covered.

Test-data requirements

Each case needs data engineered to produce a specific outcome — a valid supplier and site, a PO and receipt at set amounts, a tolerance-breaking variance, a closed-period date, a duplicate number. Parameterise this data so the same case runs across environments without rework.

Evidence requirements

Every run should retain timestamped screenshots, the hold or status reason, and an execution trace, tied to the test ID. Audit-grade evidence turns a green result into proof a control fired — essential for SOX and internal audit sign-off.

Automation suitability

Deterministic, data-driven cases (validation, matching, accounting) automate well and are marked Y. Cases needing specific roles or manual review (SOD, some file and bank-feedback checks) are partial (P). Flag each case so cycles run the right mix.

Role-based coverage

Run the same scenario under each role that touches it — processor, supervisor, manager — and assert who can enter, approve, release holds, and pay. Role coverage protects segregation of duties and becomes critical after any security-role change.

SyntraFlow's Oracle Data Vault provisions the suppliers, POs, receipts and tax codes each case needs, so tests produce the intended outcome reliably rather than depending on hand-built fixtures.

Release-Based Maintenance of the Library

An AP test library is a living asset: Oracle's quarterly updates, Redwood redesigns, and your own configuration changes all age it. Rather than re-running everything or, worse, letting the library drift out of date, maintain it against the events that actually change AP behaviour.

Change event	Risk to AP	Recommended regression scope
Oracle quarterly update	Validation, tax or payment logic changes	Release-scoped full library
Redwood UI rollout	Invoice, hold and payment pages redesigned	UI-facing cases; see Redwood UI Testing
Tolerance change	Pass/hold thresholds shift	Matching + validation boundary cases
Tax setup change	Tax calculation and variance holds shift	AP-TAX cases
Security-role change	Who can release, approve, or pay changes	AP-SEC + role-based release cases
New BU / ledger / legal entity	Setup gaps create new holds	Cross-BU + configuration cases
Integration / API change	Imported data diverges from UI controls	AP-INT + parity cases
Production defect fix	Fix may regress adjacent processes	Targeted + smoke pack

Release Intelligence maps each Oracle update to the cases it affects, and Configuration Intelligence flags setup drift between environments before it corrupts a result.

How SyntraFlow Operationalises the AP Test Library

SyntraFlow turns this catalogue into a running, reusable, evidence-producing suite — categorised, parameterised, and mapped to your releases and configuration.

Pre-built reusable cases

A starter library across every AP category — supplier to payment — that you extend to your tolerances, tax and roles rather than scripting from zero.

Test-case categorisation

Cases organised by process area with stable ID prefixes, so coverage gaps and regression scope are visible at a glance.

Test-data parameterisation

Amounts, suppliers, tolerances and dates held as data so one case runs across environments; the Oracle Data Vault provisions what each needs.

Reusable components

Shared building blocks — login, invoice entry, validate, pay — composed into many cases, so a change is made once.

Automated execution

Playwright-based runs that self-heal when Oracle changes the invoice or Redwood pages, keeping assertions working across updates.

Evidence capture

Timestamped screenshots, hold and status logs and execution traces retained as audit-grade evidence for every run.

Defect traceability

Failures link case, evidence and the process area, so a defect traces straight back to the test and the step that found it.

Release & config mapping

Each case maps to the release and configuration that drive it, so a change re-points exactly the right subset.

Dashboard reporting

Coverage, pass rate and evidence roll up by category and priority for a clear view of AP test health.

A note on capability. Pre-built categorised cases, parameterised data, automated self-healing execution, evidence capture and dashboard reporting are current platform capabilities. Coverage scoped to your specific tolerances, tax setup, roles and integrations is configurable during onboarding. Deeper release and configuration mapping to a specific tenant is confirmed at assessment rather than assumed here — roadmap items are not presented as live.

The Oracle Fusion AP Test Case Library

Everything summarised on this page is available as a structured Excel workbook — the Oracle Fusion AP Test Case Library. It expands the representative cases here into a full, maintainable suite with a tab per process area: supplier, invoice, validation, matching, holds, approval, tax, payment terms, prepayments, credit memos, distributions, accounting, payments, integrations and security.

Each tab carries, per test case: priority, preconditions, the specific test data required, step-by-step actions, expected results, automation status, evidence to capture, the owning role, the execution cycle it belongs to, and a defect reference field. It is designed to be adopted directly as your Payables test library and then automated with SyntraFlow.

Request the AP Test Case Library and a short walkthrough of how it maps to your Oracle configuration and release cadence.

Request the AP Test Case Library

Related Oracle Payables Pages

Every category on this page has a detailed home. Explore the full Payables suite:

Oracle Payables Testing Tool ★

The AP testing hub.

Oracle ERP Testing Tool →

The platform overview.

Supplier Testing →

Supplier master data.

Supplier Site Testing →

Sites, banks and assignments.

AP Invoice Testing Scenarios →

Broad invoice scenario catalogue.

Invoice Validation Testing →

The Validate process and holds.

Invoice Matching Testing →

2/3/4-way match mechanics.

Invoice Holds Testing →

Raising and releasing holds.

Approval Workflow Testing →

Routing and approval rules.

Oracle Tax Testing →

Tax calculation and variance.

Payment Terms Testing →

Due dates, discounts, installments.

Prepayment Testing →

Create, apply and unapply.

Credit Memo Testing →

Standalone and matched credits.

Invoice Distribution Testing →

Account coding and proration.

Invoice Accounting Testing →

SLA entries and GL transfer.

Payment Processing Testing →

PPR build and payment runs.

Payments Testing →

Payment documents and files.

Redwood UI Testing →

Testing through UI redesigns.

P2P End-to-End Testing →

Procure-to-pay across modules.

Release Intelligence →

Quarterly-release impact mapping.

Configuration Intelligence →

Config drift across environments.

Oracle Data Vault →

Provisioning test data per case.

Frequently Asked Questions

What is an Oracle AP test case?

▼

An Oracle AP test case is a defined check on one Payables behaviour — for example that an unbalanced invoice raises a distribution hold, or that payment terms derive the right due date. Each case has an ID, preconditions, steps, an expected result, a priority, and an automation flag, so it can be run repeatably and traced to a defect.

How should I structure an AP test library?

▼

Organise it by Oracle process area — supplier, invoice, validation, matching, holds, approval, tax, payment terms, prepayments, credit memos, distributions, accounting, payments — and give each a stable ID prefix. Layer positive and negative cases into every area and tag each with a priority and automation flag. This keeps coverage visible and regression selection precise.

How many AP test cases do I actually need?

▼

There is no fixed number — coverage should follow risk. Every high-priority control (validation holds, matching, payment run) needs positive, negative and boundary cases; lower-risk areas need fewer. The sixty-plus cases catalogued here are a representative starting index across all categories, which most organisations then extend to their own configuration.

What is the difference between positive and negative AP cases?

▼

A positive case proves a process completes on clean data — a matched invoice validates with no hold. A negative case proves the control fires on bad data — an unbalanced distribution raises a hold. A library heavy on positive cases will pass while real control gaps go untested, so both types belong in every process area.

How do I prioritise AP test cases?

▼

Rate each case High, Medium or Low by financial and payment-blocking risk. High cases — validation holds, matching, the payment run — run every cycle and in the smoke pack. Medium cases run per sprint or release; low cases run in the full library. Priority drives which subset executes when, so you are not forced to run everything every time.

Which AP test cases are worth automating?

▼

Deterministic, data-driven, frequently-run cases automate best — validation, matching, accounting and payment cases marked Y in the catalogue. Cases needing specific role provisioning or human review, such as some segregation-of-duties and bank-file checks, are partial (P) and may keep a manual step. Flag suitability per case so cycles run the right blend.

What test data do AP test cases need?

▼

Each case needs data engineered to produce a specific outcome — a valid supplier and site, a PO and receipt at set amounts, a variance beyond tolerance, a closed-period date, a duplicate number. Parameterising this data lets one case run across environments. SyntraFlow's Oracle Data Vault provisions the underlying suppliers, POs, receipts and tax codes on demand.

What evidence should each AP test capture?

▼

Each run should retain timestamped screenshots, the hold or status reason, and an execution trace, all tied to the test ID. That turns a green result into proof the control actually fired — which is what SOX and internal audit require for sign-off. Evidence should be produced automatically so it is complete and consistent across every run.

How do I cover roles and segregation of duties?

▼

Run the same scenario under each role that touches it — processor, supervisor, manager — and assert who can enter, approve, release holds and pay. Include explicit SOD cases, such as the same user both entering and paying an invoice, to confirm the conflict is prevented or flagged. Role coverage becomes critical after any security-role change.

When should I re-run AP regression tests?

▼

On every Oracle quarterly update and Redwood rollout, and after any change to tolerances, tax setup, security roles, the chart of accounts, or a new business unit or ledger — plus after production defect fixes. Scope the re-run to the processes each change affects rather than running the whole library, so regression stays targeted and fast.

How does the library stay current with Oracle updates?

▼

Maintain it against change events, not on a fixed calendar. SyntraFlow Release Intelligence maps each Oracle quarterly update to the cases it affects, and Configuration Intelligence flags setup drift between environments. Together they tell you which subset of the library to re-run after a given change, so the library ages gracefully instead of drifting out of date.

What is functional versus integration testing in AP?

▼

Functional testing exercises one AP process in isolation — payment terms deriving a due date, for example — and pinpoints where a defect lives. Integration testing exercises the hand-offs, such as an FBDI import that then validates and accounts, or a payment file that returns a bank confirmation. Most real defects appear at these seams, so both are needed.

Do the test IDs on this page stay stable?

▼

Yes — that is the point of the prefix-plus-sequence convention. Once assigned, an ID such as AP-VAL-002 never changes, so defect links, evidence and traceability stay valid across releases even as new cases are added. New cases take the next sequence number in their category rather than forcing a renumber of the suite.

How do I get the full AP Test Case Library?

▼

The full Oracle Fusion AP Test Case Library is an Excel workbook with a tab per process area, each carrying priority, preconditions, test data, steps, expected results, automation status, evidence, owner, execution cycle and a defect reference. Request it through a short demo, where the team also shows how it maps to your configuration and release cadence.