Oracle ERP Testing Tool > Test Library > Financials > Accounts Payable > Invoice Processing

Syntra Standard Oracle Test Library

Oracle Fusion Create Prepayment Invoice Test Cases

Validate that Oracle Fusion Payables correctly creates, distributes, approves, and pays a supplier prepayment invoice — the advance-payment record that becomes available for application against a future standard invoice.

Test ID	ORCL.P2P.AP.INV.CREATE.PREPAYMENT
Application	Oracle Fusion Cloud
Product	Financials
Module	Accounts Payable
Process	Invoice Processing
Business Flow	Procure-to-Pay
Scenario Type	Positive / Functional
Test Usage	Functional Testing / Regression Testing / UAT
Priority	High
Automation	SyntraFlow Ready
Library	Syntra Standard

Note on test design: SyntraFlow executes the detailed Oracle Fusion UI interactions automatically while presenting the scenario as business-readable test steps for documentation, review and reporting. This scenario is presented as 13 business-readable test steps; SyntraFlow's automation executes approximately 36 underlying Oracle Fusion UI actions to complete it.

Test Objective

This test validates the end-to-end creation of a supplier prepayment invoice in Oracle Fusion Payables, confirming the advance payment is correctly typed, distributed, approved, and paid so it is available for future application.

The scenario should confirm that:

Invoice Type can be set to Prepayment and the header correctly reflects a prepayment record rather than a standard invoice
Prepayment Type (Temporary or Permanent) is captured and drives downstream application eligibility
Supplier, supplier site, and business unit combination is valid, active, and not on payment hold
The prepayment distribution line posts to the designated prepayment/advances clearing account rather than an expense account
Settlement date is captured for prepayment aging and monitoring purposes
Invoice currency, conversion rate, and payment terms are captured correctly, including for foreign-currency prepayments
The Validate action confirms distribution completeness, tax determination, and funds availability before approval
Approval workflow routes the prepayment based on configured amount and hierarchy rules
The prepayment reaches Paid status with an Unapplied balance, ready for future application

Creating and paying the prepayment is a distinct test family from applying it to a standard invoice, which is covered separately by the Apply Prepayment to Invoice test.

When to Use This Test

Advance payment issued to a supplier before goods or services are delivered (Temporary prepayment)
Non-recoverable advance to a contractor or service provider recorded as a Permanent prepayment
Milestone-based advance tied to a purchase order for a capital or construction project
Multi-currency prepayment issued to an overseas supplier requiring conversion rate capture
High-value advance payment that must route through multi-level executive approval
Advance payment against a long-lead-time procurement where settlement is expected months out

Where This Test Fits in the Procure-to-Pay Process

Create Prepayment

→

Validate

→

Approve where required

→

Pay Prepayment

→

Available for Application

This test covers the first stage of the prepayment lifecycle — creation through payment. Once paid and Unapplied, the prepayment becomes eligible for offset against a standard invoice, which is validated by the Apply Prepayment to Invoice test.

Next Stage →

Apply Prepayment to Invoice

Preconditions

Supplier and supplier site are active, approved, and not on payment or purchasing hold
Business unit AP options are configured to permit prepayments, with a designated prepayment (advances) GL account available
If a foreign-currency prepayment, a conversion rate type and current rate exist for the invoice date
Payment terms are defined and assigned to the supplier site
Approval rules for the Prepayment invoice type and amount thresholds are configured in BPM
The Accounts Payable period covering the invoice date is open
The test user has the Accounts Payable Invoice Entry or equivalent privilege
Tax rules and tax determinants are configured if tax applies to prepayment transactions
If PO-backed, a purchase order with a prepayment-enabled milestone or line exists

Exact setup and field availability may vary by Oracle Fusion implementation and security configuration.

Sample Test Data

Supplier	Global Freight Solutions Ltd.
Supplier Site	GFS-USD-SITE1
Business Unit	US1 Business Unit
Invoice Type	Prepayment
Prepayment Type	Temporary
Invoice Number	PREPAY-2026-0142
Invoice Date	12-Aug-2026
Invoice Amount	25,000.00
Currency	USD
Payment Terms	Immediate
Settlement Date	10-Nov-2026
Distribution Combination	01-000-1410-0000-000 (Advances to Suppliers)

Sample values are illustrative. Replace them with valid data from the target Oracle Fusion environment.

Test Steps

13 business-readable steps. SyntraFlow's automation executes ~36 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.

#	User Action	Expected Result
1	Open Create Invoice and select Prepayment type Navigate to the Create Invoice work area and select Prepayment as the invoice type Invoice Type = Prepayment	A new prepayment invoice header opens with Invoice Type defaulted to Prepayment
2	Enter business unit, supplier, and site Enter the business unit, then search for and select the supplier and supplier site US1 Business Unit / Global Freight Solutions Ltd. / GFS-USD-SITE1	Header populates with supplier remit-to and liability account defaults from the site
3	Select prepayment type Choose whether the prepayment is Temporary (applicable to future invoices) or Permanent (non-applicable advance) Prepayment Type = Temporary	Prepayment Type field is saved on the header and controls later application eligibility
4	Enter invoice number, date, amount, and currency Enter the invoice number, invoice date, amount, and currency for the advance payment PREPAY-2026-0142 / 12-Aug-2026 / 25,000.00 / USD	Header fields save without validation errors; conversion rate is captured automatically for foreign currency
5	Enter payment terms Select the payment terms governing when the prepayment is due Immediate	Payment terms are applied to the invoice header
6	Enter settlement date Enter the expected settlement date by which the prepayment should be applied or cleared 10-Nov-2026	Settlement date is stored on the invoice for prepayment aging and monitoring reports
7	Enter prepayment distribution Add or confirm the distribution line pointing to the prepayment (advances) GL account for the full invoice amount 01-000-1410-0000-000 (Advances to Suppliers)	Distribution line is created against the designated prepayment asset account, not an expense account
8	Apply tax classification if applicable Enter or confirm the tax classification code where prepayments are subject to tax or withholding As configured for supplier/site Skipped where the business unit exempts prepayments from tax.	Tax lines calculate correctly and post to the appropriate tax account
9	Save and validate the invoice Save the invoice and run Validate to check distribution completeness, tax determination, and funds availability	Invoice validates successfully with no holds; status moves to Validated
10	Submit for approval Submit the validated prepayment invoice into the approval workflow where routing rules apply	Invoice routes to the correct approver based on configured amount and hierarchy rules
11	Approve prepayment invoice Approver reviews and approves the prepayment invoice	Invoice status updates to Approved and becomes eligible for payment selection
12	Select and pay prepayment Include the prepayment invoice in a Payment Process Request and confirm payment	Payment is issued and the invoice payment status updates to Paid
13	Confirm prepayment is available for future applicationBusiness assertion Review the paid prepayment invoice and confirm its application balance	Prepayment shows Paid with an Unapplied balance equal to the invoice amount, ready for future application to a standard invoice

Expected Results

Prepayment invoice is created with Invoice Type = Prepayment and the correct Prepayment Type (Temporary or Permanent)
Supplier, site, and business unit combination is accepted only when active and valid
Distribution posts to the prepayment (advances) GL account rather than an expense account
Settlement date is stored and visible on prepayment aging reports
Foreign-currency prepayments capture the correct conversion rate and functional-currency equivalent
Validate action clears the invoice with no unexpected holds when data is complete and accurate
Approval workflow routes the invoice correctly based on configured thresholds
Payment Process Request successfully selects and pays the approved prepayment
Final prepayment status is Paid with an Unapplied balance available for future application
Permanent prepayments are correctly excluded from future application eligibility

Key Validation Checkpoints

Invoice Type field equals Prepayment on the saved header
Prepayment Type field equals the value entered (Temporary or Permanent)
Supplier site status is Active and not on hold at time of entry
Distribution combination resolves to the configured prepayment/advances natural account
Settlement date field is populated and passed through to the Prepayment Status report
Currency and conversion rate fields match test data for foreign-currency scenarios
Validation status transitions from Incomplete to Validated with zero unresolved holds
Approval history log reflects the correct approver and approval timestamp
Payment record links the prepayment invoice to the Payment Process Request
Prepayment application amount available equals the full paid invoice amount
Accounting entries debit the prepayment asset account and credit cash/liability as expected
No expense distribution lines exist on a prepayment invoice

Core Business Scenario

Create Prepayment Invoice

Business Steps

Test Variations

AI-Generated

Test Data

DataVault-Driven

Execution

On-Demand / Scheduled / Batch

Automation

SyntraFlow Ready

Jarvis AI

Go Beyond the Standard Test with Jarvis AI

The Syntra Standard Test Library defines the core business scenario. Jarvis AI can extend this scenario by generating additional positive and negative test variations using customer-specific test data and configuration available through Syntra DataVault.

Teams do not need to manually duplicate the same create prepayment invoice test case dozens of times simply to cover different combinations of data and configuration. Jarvis uses the standard business scenario as the foundation and generates relevant variations for the customer's environment.

From Standard Test to Executed Regression Pack

Syntra Standard Test

Reusable business process and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — Business Units, Suppliers, Supplier Sites, Currencies, Payment Terms, Accounting combinations, Tax configurations, Dates, Amounts and other relevant test attributes.

Jarvis AI

Analyses the standard scenario together with available test data and generates relevant scenario variations.

Positive + Negative Test Variations

Positive, negative, boundary and configuration-specific scenarios.

Regression Pack

Selected variations can be grouped into an executable suite.

On-Demand / Scheduled / Batch Execution

Execute immediately or schedule the regression pack for unattended batch execution.

Results + Evidence + Exceptions

Capture execution results, business assertions, screenshots/evidence and exceptions.

Rather than maintaining dozens of near-duplicate copies of the same test, SyntraFlow maintains the core business scenario and allows Jarvis AI to generate relevant variations using the customer's available test data.

AI-Generated Test Variations

The same Create Standard Supplier Invoice business scenario can produce many test variations without creating separate public library pages. Below is a real slice of SyntraFlow's Build Scripts library, filtered to Accounts Payable Invoice Processing.

Positive Scenarios

Basic prepayment
Different suppliers
Different amounts
Different currencies
Different accounting distributions
Different settlement dates
Different payment terms
Temporary vs. permanent treatment

Negative Scenarios

Invalid supplier
Missing amount
Invalid accounting distribution
Closed period
Invalid date
Invalid settlement configuration
Other configured validation failures

These are representative examples only. Expected behavior can depend on the customer's Oracle Fusion configuration, controls and security — not every Oracle configuration behaves identically.

Generated Using Your DataVault Test Data

Instead of hardcoding a single prepayment scenario, DataVault parameterizes the supplier, amount, currency, prepayment type, and settlement date so Jarvis AI can generate a realistic spread of prepayment invoices from one definition.

Standard Library Definition

Supplier: Global Freight Solutions Ltd. | Site: GFS-USD-SITE1 | Amount: 25,000.00 USD | Prepayment Type: Temporary | Settlement Date: 10-Nov-2026

DataVault

Supplier: {{supplier_active}} | Site: {{supplier_site_active}} | Amount: {{amount_numeric: 1000-500000}} | Currency: {{currency_iso}} | Prepayment Type: {{enum: Temporary|Permanent}} | Settlement Date: {{date_offset: +30 to +180 days}} | Distribution: {{gl_prepayment_account}}

Jarvis AI Generates

1) Global Freight Solutions Ltd. / GFS-USD-SITE1 / 25,000.00 USD / Temporary / 10-Nov-2026
2) Meridian Components Inc. / MCI-EUR-SITE1 / 18,500.00 EUR / Temporary / 05-Dec-2026
3) Anchor Logistics Pty / ALP-AUD-SITE2 / 42,000.00 AUD / Permanent / 20-Jan-2027
4) Northwind Engineering / NWE-GBP-SITE1 / 75,000.00 GBP / Temporary / 15-Oct-2026
5) Delta Industrial Supply / DIS-USD-SITE3 / 5,250.00 USD / Temporary / 01-Sep-2026
6) Crestline Capital Projects / CCP-USD-SITE1 / 310,000.00 USD / Permanent / 30-Jun-2027

Customer-specific test data and AI-generated variations are not published to the Syntra Standard Test Library. They remain within the customer's controlled SyntraFlow environment and access model.

Example Test Variations

Each row below is a distinct prepayment scenario generated from the same DataVault definition, spanning amount, currency, settlement timing, and negative validation conditions.

ID	Variation	Type	Key Difference	Execution
VAR-001	Basic Temporary Prepayment	Amount	Standard $25,000 temporary prepayment with default payment terms	Syntra Ready
VAR-002	Permanent Prepayment Treatment	Amount	Prepayment Type set to Permanent; excluded from future application eligibility	Syntra Ready
VAR-003	High-Value Prepayment	Amount	$310,000 amount triggers multi-level approval routing	Syntra Ready
VAR-004	EUR Prepayment	Currency	Foreign-currency EUR prepayment with conversion rate captured at invoice date	Syntra Ready
VAR-005	GBP Prepayment to Overseas Supplier	Currency	GBP currency with alternate supplier site and bank account	Syntra Ready
VAR-006	Extended Settlement Date	Settlement	Settlement date 180 days out for a long-cycle capital project	Syntra Ready
VAR-007	Near-Term Settlement Date	Settlement	Settlement date 15 days out flags an aging risk on the Prepayment Status report	Syntra Ready
VAR-008	Invalid Supplier Rejection	Negative	Inactive or invalid supplier ID entered; expects a blocking validation error	Syntra Ready
VAR-009	Missing Amount Rejection	Negative	Invoice amount left blank; expects a required-field validation error	Syntra Ready
VAR-010	Closed Period Rejection	Negative	Invoice date falls in a closed AP period; expects a period-closed validation error	Syntra Ready

Automatically Expand Positive and Negative Test Coverage

Positive Testing

Jarvis generates scenarios using combinations expected to successfully complete the business process.

Valid data → Create Prepayment Invoice completes successfully

Negative Testing

Jarvis can generate scenarios designed to exercise validations, business rules and exception handling.

Invalid supplier → Expected Oracle validation
Missing amount → Expected Oracle validation
Invalid accounting distribution → Expected Oracle validation

A negative test should not be marked as failed simply because Oracle rejects the transaction. If the expected Oracle validation occurs, the negative test has passed.

Scenario	Oracle Outcome	Test Result
Basic temporary prepayment created and paid	Invoice validates, approves, and pays; final status Unapplied	PASS
Prepayment created against inactive supplier	System blocks entry with validation error 'Supplier is invalid or inactive'	PASS
Prepayment submitted with missing invoice amount	Validation error 'Amount is required' correctly raised	PASS
Prepayment dated within a closed AP period	System throws an unhandled internal error instead of the expected period-closed validation message	FAIL
Foreign-currency prepayment with valid conversion rate	Invoice validates and converts correctly to functional currency equivalent	PASS

Turn AI-Generated Variations into a Regression Pack

Users can select generated scenarios and group them into reusable execution packs.

AP Prepayment Invoice Regression Pack

Basic temporary prepayment
Permanent prepayment (non-applicable type)
Multi-currency prepayment
PO-backed milestone prepayment
High-value prepayment with multi-level approval
Prepayment with tax withholding
Invalid supplier rejection
Missing amount rejection
Closed period rejection
Invalid settlement configuration rejection

Add Selected to Regression Pack(coming soon)Run Now(coming soon)Schedule(coming soon)

Run On-Demand or Schedule Automated Batch Execution

SyntraFlow can execute selected scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.

Once scheduled, SyntraFlow executes the selected scenarios unattended and records the outcome of each test and business assertion.

Run immediatelyNightly regressionWeekly regressionBefore releaseAfter configuration changesAfter environment refreshQuarterly Oracle update testingPre-UAT validation

Pack	AP Prepayment Invoice Regression Pack
Schedule	Weekly Regression
Tests	20 scenarios
Execution	Batch Mode
Start	10:00 PM
Environment	Oracle Fusion TEST
Status	Scheduled

Illustrative example — not a live schedule.

Review Results Across the Entire Test Pack

Users can drill from the regression pack into a scenario, its business steps, the underlying automation actions, and the evidence captured for each.

Illustrative example data — not actual production metrics.

Total Scenarios

Passed

Failed

Exceptions

Positive Tests

Negative Tests

Business Assertions

Regression Pack → Scenario → Business Step → Automation Action → Evidence

From Business Scenario to Execution Evidence

Business teams get readable test documentation; automation teams retain detailed execution traceability.

Standard Business Scenario

AI-Generated Variation

Regression Pack

Business Test Step

Automation Actions

Business Assertion

Screenshot / Evidence

Execution Result

Meet Jarvis — SyntraFlow's AI Testing Engine

Jarvis extends the Syntra Standard Test Library by analysing the business scenario, available DataVault test data and expected business outcomes to generate additional test coverage for the customer's environment.

Generate

Positive and negative variations.

Parameterize

Use relevant test data from DataVault.

Assemble

Build reusable regression packs.

Execute

Run scenarios autonomously.

Schedule

Execute unattended test batches.

Validate

Evaluate expected business outcomes.

How SyntraFlow Automates This Test

The Standard Test defines the scenario; DataVault, Jarvis AI and SyntraFlow's execution engine take it from a single reusable business definition to executed, evidenced regression coverage.

Standard Library — Create Prepayment Invoice, 13 Business Steps

↓

DataVault — Customer-Specific Test Data

↓

Jarvis AI — Generate Positive + Negative Variations

↓

Regression Pack — Select Relevant Coverage

↓

SyntraFlow Execution — Each Variation

↓

Detailed UI Actions

↓

Business Assertions

↓

Evidence

↓

PASS / FAIL

Business Step → Underlying UI Actions

Business Step

Enter business unit, supplier, and supplier site

May internally include

Open Create Invoice -> Click Business Unit LOV -> Select business unit -> Click Supplier field -> Search and select supplier -> Click Supplier Site LOV -> Select active site -> Confirm header populated

Business Step

Enter prepayment distribution

May internally include

Open Distributions tab -> Click Add Row -> Enter/lookup prepayment natural account combination -> Enter distribution amount -> Click Calculate Tax if applicable -> Save distribution line

What SyntraFlow Captures Per Run

Parameterised input valuesReusable navigationAutomation action traceScreenshots / evidence captureExecution timingPass / fail statusBusiness assertionsEnvironment-independent test data

Action Status vs. Business Validation

A successful UI interaction does not automatically prove the business outcome — this is illustrative of how SyntraFlow separates action success from business validation; it does not reflect a specific live execution.

Step	Action Status	Business Validation
Enter supplier and supplier site	Pass	—
Enter prepayment distribution	Pass	Pass
Validate invoice	Pass	Pass
Submit for approval	Pass	—
Confirm prepayment paid and available for application	Pass	Pass

Related Oracle Fusion AP Invoice Test Cases

Part of the same Procure-to-Pay invoice lifecycle. Linked cards are live; the rest are on the Syntra Standard Test Library roadmap.

Create Standard Invoice Create PO-Matched Invoice Apply Prepayment to Invoice Invoice Validation Invoice Holds Invoice Approval Invoice Accounting Invoice Distributions

Turn This Standard Test into Your Oracle Regression Suite

Start with the Syntra Standard Create Prepayment Invoice test, use DataVault to provide environment-specific test data, let Jarvis generate additional positive and negative variations, and execute the resulting regression pack automatically with SyntraFlow.

Automate with SyntraFlow Explore Oracle ERP Testing Tool

Use This Oracle Fusion Test Case

Download Test Case

Full objective, preconditions, test data and steps.

Excel (.xlsx) CSV JSON

Add to Test Library

Save to your SyntraFlow regression suite.

Coming soon

Automate with SyntraFlow

Run this script against your own tenant today.

Related Oracle Testing Resources

Oracle ERP Testing Tool Test Library Financials Accounts Payable Invoice Processing Oracle Prepayment Testing Oracle Payables Testing Tool Oracle ERP Testing Tool

Frequently Asked Questions

What is a prepayment invoice in Oracle Fusion Payables?

A prepayment invoice records an advance payment made to a supplier before goods or services are received. It uses Invoice Type = Prepayment and posts to a prepayment (advances) GL account rather than an expense account, distinguishing it from a standard invoice.

What is the difference between Temporary and Permanent prepayment types?

A Temporary prepayment can later be applied against a standard invoice from the same supplier to offset the amount owed. A Permanent prepayment is treated as a non-recoverable advance and is not available for future application.

Does this test cover applying the prepayment to an invoice?

No. This test ends once the prepayment is validated, approved, and paid, leaving it in an Unapplied status. Application against a standard invoice is validated separately in the Apply Prepayment to Invoice test.

Why does the distribution line matter for a prepayment invoice?

The distribution must post to the designated prepayment or advances asset account. If it posts to an expense account instead, the invoice is accounted incorrectly and the balance will not be trackable as an outstanding advance.

How does SyntraFlow generate multiple prepayment scenarios from one test?

DataVault parameterizes supplier, amount, currency, prepayment type, and settlement date on a single test definition, and Jarvis AI expands it into a realistic spread of positive and negative scenarios without hand-authoring each one.

Are negative scenarios like invalid supplier or closed period treated as failures?

No. When Oracle Fusion correctly raises the expected validation error, that is a PASS. A negative scenario only fails when Oracle produces an unexpected error or silently allows invalid data through.

Download Test Case