Oracle ERP Testing Tool > Test Library > Financials > Accounts Payable > Payments

Syntra Standard Oracle Test Library

Oracle Fusion Partial Supplier Payment Test Cases

Validate partial settlement of a supplier invoice in Oracle Fusion Payables and verify that the remaining invoice balance is calculated and recorded correctly after the payment is processed.

Test ID	ORCL.P2P.AP.PAY.PARTIAL
Application	Oracle Fusion Cloud
Product	Financials
Module	Accounts Payable
Process	Payments
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 11 business-readable test steps; SyntraFlow's automation executes approximately 26 underlying Oracle Fusion UI actions to complete it.

Test Objective

The objective of this test is to verify that a supplier invoice can be partially settled through Oracle Fusion Payables, and that the resulting remaining invoice balance is calculated as Original Invoice Amount minus Partial Payment Amount and recorded accurately once the payment is processed.

The scenario should confirm that:

the invoice selected for partial payment has an outstanding balance greater than the intended payment amount
the entered partial payment amount is accepted and processed against the invoice
the resulting Remaining Invoice Balance equals Original Invoice Amount minus Partial Payment Amount
the invoice status correctly reflects a partially paid condition rather than fully paid or unpaid
the resulting payment is correctly linked to the source invoice
the invoice remains eligible for a subsequent payment against the remaining balance, where applicable

This scenario covers partial settlement of a single supplier invoice within Oracle Fusion Payables TEST/UAT environments. It does not cover settling an invoice in full, which is covered by the separate Pay Invoice in Full scenario. Specific payment amounts such as 25%, 50% or other customer-defined percentages are represented as data-driven variations of this same test rather than as separate published test pages.

When to Use This Test

Functional testing of partial invoice settlement for a new Oracle Fusion Payables implementation
Regression testing of remaining-balance calculation after an Oracle quarterly update
UAT sign-off for suppliers or business units that routinely settle invoices in multiple partial payments
Baseline case referenced by the create-payment, full-payment and void-payment scenarios within the same AP Payment lifecycle

Where This Test Fits in the AP Payment Lifecycle

Create / Select

→

Validate

→

Process / Electronic Payment

→

Void where required

→

Account

Partial Payment is one way of creating a payment against an eligible invoice, alongside Create Payment and Pay Invoice in Full. It does not cover payment validation, electronic payment processing, voiding or accounting, which are covered by the later stages of the same AP Payment lifecycle. Exact behavior depends on payment method, bank-account configuration and customer-specific Oracle Fusion setup.

Preconditions

A supplier invoice exists, is validated, and has an outstanding balance greater than the intended partial payment amount.
The invoice is not on payment hold.
The supplier, disbursement bank account and payment method are configured for the test tenant.
The accounting period intended for the payment is open.
The test user has permission to create and process supplier payments in Oracle Fusion Payables.

Exact setup, field availability and validation messages may vary by Oracle Fusion implementation, payment method and security configuration.

Sample Test Data

Business Unit	${BUSINESS_UNIT}
Supplier	${SUPPLIER}
Invoice Number	${INVOICE_NUMBER}
Invoice Amount	${INVOICE_AMOUNT}
Partial Payment Amount	${PARTIAL_PAYMENT_AMOUNT}
Remaining Balance (Expected)	${REMAINING_BALANCE}
Payment Method	${PAYMENT_METHOD}
Disbursement Bank Account	${DISBURSEMENT_BANK_ACCOUNT}
Payment Date	${PAYMENT_DATE}

Sample values are illustrative placeholder tokens. Replace with valid data from the target Oracle Fusion TEST/UAT environment. ${REMAINING_BALANCE} is expected to equal ${INVOICE_AMOUNT} minus ${PARTIAL_PAYMENT_AMOUNT}.

Test Steps

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

#	User Action	Expected Result
1	Sign In and Navigate to Payables Sign in to Oracle Fusion using an authorised Accounts Payable test user and navigate to the Payables work area.	The Payables work area opens successfully.
2	Locate the Invoice with Outstanding Balance Search for and open the supplier invoice that has an outstanding balance available for partial payment. ${SUPPLIER} / ${INVOICE_NUMBER} This single business step replaces multiple technical actions such as opening invoice search, entering the supplier and invoice number, and selecting the result.	The correct invoice is located and its current outstanding balance is displayed.
3	Initiate Payment for the Invoice Select the option to create a payment against the located invoice.	The payment entry screen opens for the selected invoice.
4	Enter Partial Payment Amount Enter a payment amount that is less than the invoice's full outstanding balance. ${PARTIAL_PAYMENT_AMOUNT}	The partial amount is accepted without unexpected validation errors.
5	Select Payment Method Select the payment method to be used for the partial payment. ${PAYMENT_METHOD}	The selected payment method is applied to the payment.
6	Select Disbursement Bank Account Select the bank account from which the payment will be disbursed. ${DISBURSEMENT_BANK_ACCOUNT}	The selected bank account is applied to the payment.
7	Review Remaining Balance Before Submitting Review the remaining invoice balance calculated by Oracle Fusion before submitting the payment. Reviewing the calculated balance before submission lets the tester catch an incorrect amount entry before the payment is created.	The previewed remaining balance equals Invoice Amount minus Partial Payment Amount.
8	Create / Confirm the Payment Submit and confirm the partial payment for creation in the test environment. ${PAYMENT_DATE}	Oracle Fusion successfully processes the payment creation without unexpected errors.
9	Verify Remaining Balance Matches Expected CalculationBusiness assertion Reopen or refresh the invoice and confirm the resulting remaining balance. This is the primary business assertion for the scenario — a correctly calculated remaining balance is the expected pass condition, not merely a successful save.	Remaining Invoice Balance equals Original Invoice Amount minus Partial Payment Amount.
10	Verify Invoice Status Reflects Partial PaymentBusiness assertion Review the invoice status after the payment is recorded.	The invoice status correctly reflects a partially paid condition rather than fully paid or unpaid.
11	Capture Payment IdentifierBusiness assertion Capture the payment reference/identifier generated for the partial payment.	A payment identifier is generated and linked to the source invoice for traceability.

Expected Results

The partial payment amount is accepted and processed against the invoice.
Remaining Invoice Balance equals Original Invoice Amount minus Partial Payment Amount.
Invoice status correctly reflects a partially paid condition.
The resulting payment is correctly linked to the source invoice.
Payment status reflects successful processing.
The invoice remains eligible for a subsequent payment against the remaining balance, where applicable.
A payment identifier is captured for traceability.

Key Validation Checkpoints

Original Invoice Amount − Partial Payment Amount = Remaining Invoice Balance.
Payment is linked to the correct invoice.
Remaining balance is calculated correctly after the partial payment.
Invoice status reflects a partially paid condition.
Payment status is correct after processing.
A subsequent payment against the remaining balance remains possible where applicable.

Core Business Scenario

Partial Payment

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 partial-payment business scenario. Jarvis AI can extend this scenario by generating additional amount, sequencing, supplier and currency variations using customer-specific test data and configuration available through Syntra DataVault.

Teams do not need to manually build a separate test for every possible partial-payment percentage or amount. Jarvis uses the standard scenario as the foundation and generates relevant amount-driven and sequential variations for the customer's environment.

From Standard Test to Executed Regression Pack

Syntra Standard Test

Reusable partial-payment business process and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — Suppliers, Invoices, Amounts, Payment Methods, Bank Accounts and Currencies.

Jarvis AI

Analyses the standard scenario together with available test data and generates relevant amount, sequencing and supplier variations.

Positive + Negative Test Variations

Valid partial-amount scenarios and edge cases such as overpayment, zero amount or invalid state.

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 a separate test page for every possible partial-payment percentage or amount, SyntraFlow maintains one core partial-payment scenario and allows Jarvis AI to generate amount-driven, sequential and supplier-specific variations using the customer's available test data.

AI-Generated Test Variations

The same Partial Payment 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 Payments.

Positive Scenarios

Basic partial payment for an amount less than the invoice balance
Partial payment equal to 25% of the invoice amount
Partial payment equal to 50% of the invoice amount
Partial payment for another customer-defined amount
Multiple sequential partial payments against the same invoice
Partial payment followed by a final payment that settles the balance
Partial payment across different suppliers
Partial payment in different currencies
Partial payment using different payment methods
Partial payment after invoice approval

Negative Scenarios

Payment amount greater than the eligible outstanding balance
Zero payment amount
Invalid negative payment amount
Invoice on hold
Invoice already fully paid
Invalid payment method
Invalid bank account
Closed accounting period
Invalid payment date

These are representative examples only. Negative-scenario behavior and available payment amounts can depend on the customer's Oracle Fusion configuration, controls and security — not every Oracle configuration behaves identically.

Generated Using Your DataVault Test Data

Generic test data rarely represents every supplier, invoice amount, payment method and bank account combination in a real Oracle Fusion environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct partial-payment scenarios relevant to the customer's actual implementation.

Standard Library Definition

Business Unit        ${BUSINESS_UNIT}
Supplier              ${SUPPLIER}
Invoice Number        ${INVOICE_NUMBER}
Invoice Amount        ${INVOICE_AMOUNT}
Partial Payment       ${PARTIAL_PAYMENT_AMOUNT}
Remaining Balance     ${REMAINING_BALANCE}
Payment Method        ${PAYMENT_METHOD}
Bank Account          ${DISBURSEMENT_BANK_ACCOUNT}
Payment Date          ${PAYMENT_DATE}

DataVault

Suppliers
  Active suppliers eligible for payment
Invoices
  Validated invoices with an outstanding balance
Invoice Amount
  Full outstanding balance per invoice
Partial Payment Amount
  Amount below the outstanding balance
Payment Method
  Check, EFT, wire per Business Unit configuration
Bank Account
  Configured disbursement accounts
Currency
  USD, GBP, EUR + supplier-specific currencies

Jarvis AI Generates

Scenario 01 — Supplier A + Invoice INV-1001 + 25% Payment
Scenario 02 — Supplier A + Invoice INV-1001 + 50% Payment
Scenario 03 — Supplier B + Invoice INV-2004 + Other Amount
Scenario 04 — Sequential Partial Payments + Final Payment
Scenario 05 — Payment Amount Exceeds Balance
Scenario 06 — Invoice on Hold
...

Customer-specific test data and AI-generated variations are not published to the Syntra Standard Test Library. Where DataVault is connected, customer-specific dimensions such as supplier, invoice, amount and bank account remain within the customer's controlled SyntraFlow environment and access model.

Example Test Variations

Representative examples of partial-payment scenarios Jarvis can generate from this business scenario, spanning payment amount, sequencing, supplier and currency conditions. These are illustrative, not separate indexable pages — the canonical page for all of them remains this one.

ID	Variation	Type	Key Difference	Execution
VAR-001	Basic Partial Payment	Positive/Amount	Payment amount set below the invoice's outstanding balance	Syntra Ready
VAR-002	Partial Payment — 25% of Invoice	Positive/Amount	Partial payment amount set to 25% of the invoice amount	Syntra Ready
VAR-003	Partial Payment — 50% of Invoice	Positive/Amount	Partial payment amount set to 50% of the invoice amount	Syntra Ready
VAR-004	Partial Payment — Other Amount	Positive/Amount	Customer-defined partial amount entered	Syntra Ready
VAR-005	Multiple Sequential Partial Payments	Positive/Sequential	Two or more partial payments applied to the same invoice over time	Syntra Ready
VAR-006	Partial Payment Followed by Final Payment	Positive/Sequential	Remaining balance settled by a subsequent payment	Syntra Ready
VAR-007	Partial Payment — Supplier A	Positive/Supplier	Scenario executed against Supplier A's invoice	Syntra Ready
VAR-008	Partial Payment — Supplier B	Positive/Supplier	Scenario executed against Supplier B's invoice	Syntra Ready
VAR-009	Partial Payment — Alternate Currency	Positive/Currency	Payment processed in a non-default supplier currency	Syntra Ready
VAR-010	Partial Payment — Alternate Payment Method	Positive	Payment processed using a different configured payment method	Syntra Ready
VAR-011	Partial Payment After Invoice Approval	Positive	Partial payment initiated only after invoice approval workflow completes	Syntra Ready
VAR-012	Payment Amount Exceeds Eligible Balance	Negative/Amount	Entered amount is greater than the invoice's outstanding balance	Syntra Ready
VAR-013	Zero Payment Amount	Negative/Amount	Payment amount entered as zero	Syntra Ready
VAR-014	Invalid Negative Payment Amount	Negative/Amount	Payment amount entered as a negative value	Syntra Ready
VAR-015	Invoice on Hold	Negative	Invoice carries an active payment hold	Syntra Ready
VAR-016	Invoice Already Fully Paid	Negative	Invoice has no remaining outstanding balance available for payment	Syntra Ready
VAR-017	Invalid Payment Method	Negative	Payment method not configured for the supplier or Business Unit	Syntra Ready
VAR-018	Invalid Bank Account	Negative	Disbursement bank account not valid or not configured	Syntra Ready
VAR-019	Closed Accounting Period	Negative	Payment date falls within a closed accounting period	Syntra Ready
VAR-020	Invalid Payment Date	Negative	Payment date is outside a valid or open range	Syntra Ready

Automatically Expand Positive and Negative Partial Payment Coverage

Positive Testing

Jarvis generates scenarios using payment amounts and sequencing expected to successfully settle part of an invoice's outstanding balance while leaving Oracle Fusion's remaining-balance calculation accurate.

Valid Invoice + 50% Payment Amount + Open Period → Payment Processed and Remaining Balance Correctly Calculated

Negative Testing

Jarvis can also generate scenarios designed to exercise Oracle's validations around payment amount, invoice state, payment method and period.

Amount Exceeds Balance → Expected Overpayment Validation
Zero Amount → Expected Amount Validation
Invoice on Hold → Expected Hold Validation
Invoice Already Fully Paid → Expected Balance Validation
Closed Period → Expected Period Validation

A negative test should not be marked as failed simply because Oracle rejects the payment. If the expected Oracle validation occurs — correctly preventing an invalid or unsupported partial payment — the negative test has passed.

Scenario	Oracle Outcome	Test Result
Valid partial amount	Balance reduced correctly	PASS
Amount exceeds balance	Validation prevents overpayment	PASS
Zero amount	Validation occurs	PASS
Invoice on hold	Payment prevented	PASS
Unexpected system error	Unexpected failure	FAIL

Turn AI-Generated Variations into a Regression Pack

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

AP Partial Payment Regression Pack

Basic Partial Payment
Partial Payment — 25% of Invoice
Partial Payment — 50% of Invoice
Partial Payment — Other Amount
Multiple Sequential Partial Payments
Partial Payment Followed by Final Payment
Payment Amount Exceeds Eligible Balance
Zero Payment Amount
Invoice on Hold
Closed Accounting Period

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 partial-payment scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.

Once scheduled, SyntraFlow executes the selected partial-payment 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 Partial Payment Regression Pack
Schedule	Quarterly Update 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

AP Payment Lifecycle

Several scenario families share the same lifecycle position — for example, Create Payment, Pay Invoice in Full and Partial Payment are all ways of creating a payment. Exact processing depends on payment method, bank-account configuration and customer-specific Oracle Fusion setup. Stages link to a representative test scenario family.

Create / Select

→Validate→Process / Electronic Payment→Void where required→Account

Understand Why a Test Failed

SyntraFlow execution evidence can help distinguish business-data failures, configuration issues, automation problems and potential application defects.

DataConfigurationSecurityAutomationApplicationEnvironmentExpected Validation

Jarvis Failure Intelligence — Coming Soon

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 partial-payment scenario, available DataVault test data and expected business outcomes to generate additional amount, sequencing and supplier 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 — Partial Payment, 11 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

Locate the Invoice with Outstanding Balance

May internally include

Open Invoice Search → Enter Supplier → Enter Invoice Number → Search → Select Invoice → Confirm

Business Step

Review Remaining Balance Before Submitting

May internally include

Open Payment Preview → Read Calculated Remaining Balance → Compare Against Invoice Amount Minus Partial Payment

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 remaining balance was calculated correctly — 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 Partial Payment Amount	Pass	—
Create / Confirm the Payment	Pass	—
Verify Remaining Balance Matches Expected Calculation	Pass	Pass

Related AP Payment Tests

Partial payment is one way of creating a payment within the same AP Payment lifecycle — explore the related create, full-payment and void scenarios below.

Create Payment Pay Invoice in Full Void Payment

Turn This Standard Test into Your Oracle AP Payment Regression Suite

Start with the Syntra Standard partial-payment test, use DataVault to provide environment-specific test data, let Jarvis generate additional amount, sequencing and supplier variations, and execute the resulting regression pack automatically with SyntraFlow.

Automate with SyntraFlow Explore AP Payments Test Library

Use This Oracle Fusion Test Case

Download Test Case

Excel, CSV or JSON export.

Coming soon

Automate with SyntraFlow

Run this script against your own tenant today.

Related Oracle Testing Resources

Accounts Payable Payments Test Library Accounts Payable Test Library Financials Test Library Oracle ERP Testing Tool Test Library Syntra DataVault

Frequently Asked Questions

What does this Oracle Fusion Partial Payment test validate?

It validates that a supplier invoice can be partially settled in Oracle Fusion Payables, and that the resulting remaining invoice balance — Original Invoice Amount minus Partial Payment Amount — is calculated and recorded correctly after the payment is processed.

How are 25%, 50% and other partial payment amounts handled?

They are represented as data-driven rows in the Example Test Variations table on this same page rather than as separate published test pages. This keeps a single canonical URL for all partial-payment amount variations while still exercising each distinct amount.

Are multiple partial payments against the same invoice supported?

Yes. Jarvis AI can generate variations covering multiple sequential partial payments, including a scenario where a partial payment is followed by a final payment that settles the remaining balance.

How is the remaining invoice balance calculated?

Remaining Invoice Balance equals Original Invoice Amount minus Partial Payment Amount. The test verifies this value as recorded by Oracle Fusion Payables after the payment is processed, not merely as an entered input.

Does this test use real customer data?

The public Syntra Standard Test Library uses illustrative test data. Where DataVault is connected, customer-specific dimensions such as supplier, invoice, amount and bank account can be used, protected according to DataVault's data policies.