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

Syntra Standard Oracle Test Library

Oracle Fusion Apply Prepayment to Invoice Test Cases

Validate that an eligible, fully paid supplier prepayment is correctly applied against a standard invoice in Oracle Fusion Payables, reducing the invoice's open balance and updating the prepayment's available balance with full traceability.

Test ID	ORCL.P2P.AP.INV.PREPAYMENT.APPLY
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

Validate that an eligible, paid supplier prepayment can be correctly applied against an applicable standard invoice in Oracle Fusion Payables, and that all downstream balances and statuses update accurately.

The scenario should confirm that:

The correct prepayment is selected from the eligible list for the supplier
The correct application amount is applied against the invoice
The remaining invoice amount (amount due) is calculated correctly after application
The prepayment available balance is updated correctly after application
The prepayment application is visible on the invoice's distributions and application history
A negative prepayment application distribution line is created with the correct accounting impact
The prepayment status transitions appropriately (Available with reduced balance, or Fully Applied)
Tax proration on the applied prepayment amount, where configured, is handled correctly
The invoice validates successfully after the application is recorded

This scenario begins after the prepayment has already been created, validated, and paid; prepayment creation and payment are covered by the sibling Create Prepayment Invoice test.

When to Use This Test

Regression testing of AP prepayment offsets ahead of period close to confirm liabilities are stated correctly
Validating supplier advance recoupment for capital projects and long-lead-time purchases
Confirming partial prepayment application behavior for phased deliveries or milestone billing
Testing multi-prepayment application scenarios for suppliers with recurring advance arrangements
Verifying Oracle correctly blocks application attempts against unpaid, ineligible, or mismatched prepayments
Confirming quarter-end and year-end supplier balance reconciliation reflects applied prepayment amounts

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

Prepayment Created

→

Validated

→

Paid

→

Standard Invoice Created

→

Apply Prepayment

→

Remaining Invoice Balance

This test picks up after a prepayment has been created, validated, and paid in full; it exercises only the application step against a standard invoice and the resulting balance updates.

← Previous Stage

Create Prepayment Invoice

Next Stage →

Invoice Accounting

Preconditions

A standard invoice has already been created for the supplier and exists in Incomplete or Validated status
An eligible, fully paid prepayment already exists for the same supplier and business unit
The prepayment is of type Temporary; Permanent prepayments are excluded from application eligibility
The prepayment has been validated and its associated payment has been confirmed as paid
Where a settlement date is defined on the prepayment, that date has been reached
The prepayment has an available (unapplied) balance greater than zero
The invoice and prepayment share the same currency, or approved cross-currency application rules are configured
The user has the Accounts Payable Invoice processing role with Apply Prepayment privileges
The target invoice is not fully paid, cancelled, or on a hold that blocks prepayment application

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

Sample Test Data

Supplier	Acme Industrial Supplies
Supplier Site	ACME-US-001
Business Unit	US1 Business Unit
Prepayment Invoice Number	PREPAY-100234
Prepayment Type	Temporary
Prepayment Amount	$10,000.00
Prepayment Available Balance	$10,000.00
Standard Invoice Number	INV-100987
Standard Invoice Amount	$12,500.00
Settlement Date	01-Aug-2026
Application Amount	$10,000.00
Currency	USD

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 Eligible Standard Invoice Search for and open the standard invoice that has an eligible paid prepayment available from the same supplier. INV-100987	Invoice opens in edit mode showing the header, current amount due, and line details.
2	Initiate Prepayment Application From the invoice header, select Actions and then Apply Prepayment.	The Apply Prepayment window opens for the invoice.
3	Review Eligible Prepayments Review the list of validated, paid, unapplied prepayments displayed for the supplier and business unit. Only Temporary prepayments that are paid and past any settlement date restriction appear as eligible.	PREPAY-100234 appears in the list with its correct available balance and currency.
4	Select Prepayment Select the specific prepayment line to apply against the invoice. PREPAY-100234	The prepayment is selected and its available balance is displayed for reference.
5	Enter Application Amount Enter or confirm the amount to apply, not exceeding the lesser of the prepayment's available balance or the invoice's open amount. $10,000.00	The application amount field accepts the entered value within the eligible range.
6	System Eligibility Validation System validates prepayment status (paid), settlement date, supplier match, currency, and available balance sufficiency.	All eligibility checks pass without error.
7	Confirm Application Click Apply to commit the prepayment application to the invoice.	A confirmation message is displayed and the Apply Prepayment window closes.
8	Review Invoice Distributions Navigate to the invoice Distributions tab.	A new prepayment application distribution line appears with a negative amount equal to the applied amount.
9	Save Invoice Save the invoice record.	The invoice saves without error and the application is persisted.
10	Validate Invoice Run the Validate action on the invoice.	The invoice validates successfully and the open/due amount is recalculated.
11	Review Updated Invoice Amount Due View the invoice header amount due field.	Amount Due reflects a reduction equal to the applied prepayment amount ($2,500.00 remaining on a $12,500.00 invoice).
12	Review Prepayment Status and Balance Open the prepayment invoice record. PREPAY-100234	The prepayment's available balance is reduced by the applied amount and its status updates to Fully Applied or remains Available with a reduced balance.
13	Validate End-to-End Application OutcomeBusiness assertion Cross-check the invoice and prepayment records together to confirm the full outcome of the application.	The correct prepayment (PREPAY-100234) was selected, the correct amount ($10,000.00) was applied, the remaining invoice balance ($2,500.00) is correct, the prepayment available balance ($0.00) is updated correctly, and the application is visible in the invoice's Prepayment Applications history.

Expected Results

The Apply Prepayment window lists only eligible, paid, unapplied prepayments for the correct supplier
The selected prepayment and entered amount are accepted without validation error
A negative prepayment application distribution line is created on the invoice
The invoice's amount due is reduced by exactly the applied amount
The prepayment's available balance is reduced by exactly the applied amount
The prepayment status correctly reflects Fully Applied or partially reduced Available balance
The invoice validates successfully after the application is recorded
The application is visible and traceable from both the invoice and the prepayment records
Accounting impact of the application is reflected correctly in subsequent distribution and accounting review
No unintended change occurs to unrelated invoice lines, tax lines, or other prepayments for the supplier

Key Validation Checkpoints

Eligible prepayment list filters correctly by supplier, business unit, and currency
Prepayment type is confirmed as Temporary before appearing as eligible
Prepayment paid status is confirmed before appearing as eligible
Settlement date restriction, if configured, is enforced before allowing application
Application amount does not exceed the prepayment's available balance
Application amount does not exceed the invoice's open amount
Prepayment application distribution line amount matches the entered application amount exactly
Invoice amount due recalculates correctly post-application
Prepayment available balance recalculates correctly post-application
Prepayment status field updates correctly post-application
Application is recorded in the invoice's Prepayment Applications history for audit traceability
Invoice validation completes without new holds introduced by the application

Core Business Scenario

Apply Prepayment to 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 apply prepayment to 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

Full prepayment application
Partial prepayment application
Prepayment smaller than invoice
Prepayment equal to invoice
Multiple available prepayments
Different eligible invoices
Different application amounts

Negative Scenarios

Unpaid prepayment
Prepayment not yet available for application
Supplier mismatch
Invalid application amount
Amount exceeds available prepayment
Ineligible invoice
Settlement date condition not met

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

The standard test defines a single fixed prepayment application. DataVault replaces the hardcoded values with variables so Jarvis AI can generate a broad matrix of realistic application scenarios spanning amounts, suppliers, and prepayment counts.

Standard Library Definition

Supplier: Acme Industrial Supplies
Prepayment: PREPAY-100234 ($10,000.00, Temporary, Paid)
Invoice: INV-100987 ($12,500.00)
Application Amount: $10,000.00

DataVault

Supplier: {{supplier_name}}
Prepayment: {{prepayment_number}} ({{prepayment_amount}}, {{prepayment_type}}, {{prepayment_status}})
Invoice: {{invoice_number}} ({{invoice_amount}})
Application Amount: {{application_amount}}

Jarvis AI Generates

1) Acme Industrial Supplies | PREPAY-100234 ($10,000.00, Temporary, Paid) | INV-100987 ($12,500.00) | Apply $10,000.00 (Full)
2) Northgate Freight Services | PREPAY-100511 ($4,000.00, Temporary, Paid) | INV-101204 ($9,000.00) | Apply $4,000.00 (Partial)
3) Beacon Office Supply | PREPAY-100078 ($6,200.00, Temporary, Paid) | INV-100650 ($6,200.00) | Apply $6,200.00 (Equal)
4) Halden Manufacturing Co. | PREPAY-100333 + PREPAY-100334 ($5,000.00 each, Temporary, Paid) | INV-101500 ($9,500.00) | Apply $5,000.00 + $4,500.00 (Multiple)
5) Vertex Engineering Partners | PREPAY-100910 ($15,000.00, Temporary, Unpaid) | INV-101711 ($8,000.00) | Application blocked - prepayment not paid
6) Cardinal Logistics Group | PREPAY-100450 ($3,000.00, Temporary, Paid) | INV-101822 ($3,000.00) | Application blocked - settlement date not yet reached

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

Jarvis AI expands the base application scenario into a full matrix of positive and negative variations, covering amount splits, multi-prepayment supplier arrangements, and eligibility failure conditions.

ID	Variation	Type	Key Difference	Execution
VAR-001	Full prepayment application	Full	Entire prepayment available balance applied in one transaction against the invoice.	Syntra Ready
VAR-002	Partial prepayment application	Partial	Only a portion of the prepayment's available balance is applied, leaving a residual prepayment balance.	Syntra Ready
VAR-003	Prepayment equal to invoice amount	Full	Prepayment amount exactly matches the invoice amount, fully offsetting the invoice due.	Syntra Ready
VAR-004	Multiple available prepayments applied	Multiple Prepayments	Two separate prepayments for the same supplier are applied sequentially to one invoice.	Syntra Ready
VAR-005	Different application amount combination	Partial	Application amount varies to test rounding and tax proration behavior across amount tiers.	Syntra Ready
VAR-006	Unpaid prepayment blocked	Negative	Prepayment exists but payment has not been confirmed; excluded from eligible list.	Syntra Ready
VAR-007	Prepayment not yet available (settlement date)	Negative	Prepayment settlement date has not been reached; application attempt is rejected.	Syntra Ready
VAR-008	Supplier mismatch rejected	Negative	Attempted application using a prepayment belonging to a different supplier than the invoice.	Syntra Ready
VAR-009	Amount exceeds available prepayment balance	Negative	Entered application amount is greater than the prepayment's remaining available balance.	Syntra Ready
VAR-010	Ineligible invoice type rejected	Negative	Application attempted against an invoice type or status that does not support prepayment application.	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 → Apply Prepayment to Invoice completes successfully

Negative Testing

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

Unpaid prepayment → Expected Oracle validation
Prepayment not yet available for application → Expected Oracle validation
Supplier mismatch → 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
Full prepayment application within available balance	Prepayment applied in full; distribution created; invoice amount due reduced to zero	PASS
Partial prepayment application leaving residual balance	Partial amount applied; prepayment retains reduced available balance for future use	PASS
Application amount exceeds available prepayment balance	Oracle blocks the application with validation error: application amount exceeds available prepayment amount	PASS
Application attempted against an unpaid prepayment	Prepayment is excluded from the eligible list and application is blocked with a payment status error	PASS
Apply Prepayment window fails to load eligible prepayments	Window times out and returns an unexpected system error instead of listing eligible prepayments	FAIL

Turn AI-Generated Variations into a Regression Pack

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

AP Apply Prepayment Regression Pack

Full Prepayment Application
Partial Prepayment Application
Prepayment Equal to Invoice Amount
Multiple Prepayments Applied to One Invoice
Application Blocked for Unpaid Prepayment
Application Blocked Before Settlement Date
Application Blocked for Supplier Mismatch
Application Amount Exceeds Available Balance
Application Blocked for Ineligible Invoice
Invalid Application Amount Rejected

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 Apply Prepayment 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 — Apply Prepayment to 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

Initiate and complete prepayment application

May internally include

Open Invoice -> Click Actions menu -> Select Apply Prepayment -> Select prepayment line PREPAY-100234 -> Enter application amount -> Click Apply -> Confirm dialog

Business Step

Validate invoice and confirm updated balances

May internally include

Click Validate -> Wait for validation completion -> Open Distributions tab -> Confirm prepayment application line -> Navigate to prepayment invoice -> Confirm updated available balance and status

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
Open Apply Prepayment window from invoice Actions menu	Pass	—
Select prepayment and enter application amount	Pass	—
Confirm application and review distributions	Pass	Pass - correct prepayment and amount applied
Validate invoice after application	Pass	Pass - remaining invoice balance correct
Review prepayment invoice available balance	Pass	Pass - prepayment available balance updated correctly

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 Prepayment Invoice Create Standard 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 Apply Prepayment to 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 AP Invoice Processing Test Library

Frequently Asked Questions

What happens if the application amount exceeds the prepayment's available balance?

Oracle Fusion rejects the application with a validation error stating the amount exceeds the available prepayment balance. No distribution is created and the invoice remains unchanged until a valid amount is entered.

Can more than one prepayment be applied to a single invoice?

Yes. As long as multiple eligible, paid Temporary prepayments exist for the same supplier, they can each be applied to the same invoice in separate application actions, provided the combined applied amount does not exceed the invoice's open amount.

Why can't a Permanent prepayment be applied to a standard invoice?

Permanent prepayments represent advances that are expected to be recovered outside the standard invoice offset process, such as through direct settlement. Oracle Fusion restricts application eligibility to Temporary prepayments only.

Does applying a prepayment affect tax calculated on the invoice?

It can. Depending on tax configuration, the applied prepayment amount may be prorated across the invoice's tax and recoverable/non-recoverable tax lines, which is why tax proration is included as a validation checkpoint in this scenario.

Can a prepayment application be reversed after it is applied?

Yes, Oracle Fusion supports unapplying a prepayment application, which reverses the distribution and restores both the invoice's open amount and the prepayment's available balance. Reversal behavior is covered separately from this apply-focused scenario.

What eligibility checks does Oracle perform before allowing an application?

Oracle validates that the prepayment is Temporary, has been validated and paid, has an available balance greater than zero, matches the invoice's supplier and currency, and has passed any configured settlement date before it appears as eligible for application.

Download Test Case