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

Syntra Standard Oracle Test Library

Oracle Fusion Electronic Supplier Payment Test Cases

Validate the creation and processing of electronic supplier payments in Oracle Fusion Accounts Payable using a configured payment method, supplier and disbursement bank accounts, and a payment process profile.

Test ID	ORCL.P2P.AP.PAY.ELECTRONIC
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 12 business-readable test steps; SyntraFlow's automation executes approximately 33 underlying Oracle Fusion UI actions to complete it.

Test Objective

The objective of this test is to verify that Oracle Fusion Accounts Payable can create and process an electronic supplier payment using a configured payment method, bank account and payment process profile.

The scenario should confirm that:

an eligible invoice or invoices can be selected for electronic payment
the intended electronic payment method is applied to the payment
the correct supplier bank account and disbursement bank account are used
the payment amount and currency on the created payment match the source invoice(s)
the payment reaches the expected status after processing
a payment file or output is generated where the payment process profile is configured to produce one
sensitive supplier banking details are not unnecessarily exposed in test evidence or reports

This scenario validates the Oracle Fusion electronic payment creation and processing workflow, and any file or output generated within Oracle Fusion's test environment. It does not transmit funds to a bank or any external payment network — SyntraFlow executes this scenario as test automation against Oracle Fusion TEST/UAT environments only.

When to Use This Test

Functional testing of electronic supplier payment processing for a new Oracle Fusion implementation
Regression testing of payment method, bank account and payment process profile configuration after an Oracle quarterly update
UAT sign-off for electronic payment issuance before go-live
Baseline case referenced by the payment process request, void and payment accounting 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

This test covers electronic payment creation and processing once eligible invoices have been selected and validated — it does not perform the initial invoice selection, payment validation, void processing or payment accounting themselves, which are covered by separate scenarios in the same AP payment lifecycle.

← Previous Stage

Payment Process Request

Next Stage →

Payment Accounting

Preconditions

One or more eligible invoices exist and are approved for payment.
The supplier is configured for electronic payment with a valid and active supplier bank account.
A disbursement bank account is configured and active for the paying business unit.
A payment process profile supporting the intended electronic payment method is available.
The accounting period for the payment date is open.
The test user has permission to create and process electronic payments.

Exact payment methods, bank account setup and payment process profile configuration vary by Oracle Fusion implementation, banking setup and customer-specific configuration.

Sample Test Data

Supplier	${SUPPLIER}
Supplier Bank Account	${SUPPLIER_BANK_ACCOUNT}
Disbursement Bank Account	${DISBURSEMENT_BANK_ACCOUNT}
Payment Method	${PAYMENT_METHOD}
Payment Process Profile	${PAYMENT_PROCESS_PROFILE}
Payment Currency	${PAYMENT_CURRENCY}
Invoice Number	${INVOICE_NUMBER}
Payment Amount	${PAYMENT_AMOUNT}
Payment Date	${PAYMENT_DATE}

Sample values are illustrative placeholders only. Replace all values with valid data from the target Oracle Fusion TEST/UAT environment. No real bank account numbers, routing details or other sensitive banking information should ever be entered as test data.

Test Steps

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

#	User Action	Expected Result
1	Sign in to Oracle Fusion Sign in to the Oracle Fusion environment using an authorised Accounts Payable test user.	Oracle Fusion home page is displayed successfully and the user session is established.
2	Navigate to Payables Payments Navigate to the Payables work area and open the Payments task.	The Payments work area opens successfully.
3	Select the Eligible Supplier and Invoice(s) Select the eligible supplier and one or more approved invoices to be paid electronically. ${SUPPLIER} / ${INVOICE_NUMBER}	The correct supplier and invoice(s) are selected and available for payment.
4	Select the Electronic Payment Method Select the intended electronic payment method for the payment. ${PAYMENT_METHOD}	The electronic payment method is applied to the payment.
5	Select the Disbursement Bank Account Select the disbursement bank account the payment will be issued from. ${DISBURSEMENT_BANK_ACCOUNT}	The correct disbursement bank account is selected for the payment.
6	Verify the Supplier Bank Account Details Review the supplier bank account associated with the payment to confirm it is valid and active. ${SUPPLIER_BANK_ACCOUNT} This single business step replaces multiple technical actions such as opening the supplier bank account detail panel and confirming its active status and ownership.	The supplier bank account displayed is valid, active and correctly associated with the supplier.
7	Select the Payment Process Profile Select the payment process profile that supports the intended electronic payment method. ${PAYMENT_PROCESS_PROFILE}	The selected payment process profile is applied to the payment.
8	Review Payment Amount and Currency Review the payment amount and currency calculated from the selected invoice(s). ${PAYMENT_AMOUNT} / ${PAYMENT_CURRENCY}	The payment amount and currency match the source invoice(s).
9	Create and Submit the Electronic Payment Create and submit the electronic payment for processing. ${PAYMENT_DATE}	Oracle Fusion accepts the payment submission and begins processing it without unexpected errors.
10	Confirm the Resulting Payment StatusBusiness assertion Review the payment record after processing to confirm its resulting status.	The payment reaches the expected status for a successfully processed electronic payment.
11	Verify the Payment File or Output Where ApplicableBusiness assertion Where the payment process profile is configured to produce a payment file or output, confirm it has been generated within Oracle Fusion. This is a supporting business assertion for the scenario — file/output creation is verified only where the tested payment process profile is configured to produce one.	A payment file or output record is created within Oracle Fusion for the processed payment, where applicable to the configured payment process profile. This confirms the file is created in Oracle Fusion's test environment — it does not confirm or imply that funds have been transmitted to a bank.
12	Verify No Sensitive Bank Data Is Unnecessarily Exposed in EvidenceBusiness assertion Review the captured test evidence and reports to confirm sensitive supplier banking details are masked or omitted where not required. This is the main business assertion for the scenario — a correctly processed payment that also protects sensitive banking data is a passing test.	Test evidence and reports do not unnecessarily expose sensitive banking information such as full account or routing numbers.

Expected Results

An electronic payment is successfully created against the selected eligible invoice(s).
The intended electronic payment method is applied to the payment.
The correct supplier bank account and disbursement bank account are used.
The payment amount and currency match the source invoice(s).
The payment reaches the expected status after processing.
A payment file or output is generated where the payment process profile is configured to produce one, within Oracle Fusion's test environment.
Sensitive banking details are not unnecessarily exposed in test evidence or reports.

Key Validation Checkpoints

Electronic payment is created against the selected invoice(s).
Intended electronic payment method is correctly selected.
Correct supplier and disbursement bank accounts are used.
Payment amount and currency are correct.
Payment status correctly reflects successful processing.
Payment file or output is created within Oracle Fusion where applicable.
No sensitive bank information is unnecessarily exposed in reports or evidence.

Core Business Scenario

Electronic 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 electronic payment 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 electronic payment test dozens of times simply to cover different combinations of supplier, bank account, currency, payment process profile or invalid 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 electronic payment scenario and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — Suppliers, Supplier Bank Accounts, Disbursement Bank Accounts, Payment Methods, Payment Process Profiles and Currencies, where configured and connected.

Jarvis AI

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

Positive + Negative Test Variations

Bank, currency, supplier and profile-specific scenarios, plus exception conditions.

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, masked screenshots/evidence and exceptions.

Rather than maintaining dozens of near-duplicate copies of the same electronic payment 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 Electronic 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

Electronic transfer payment to a single supplier
Payment using different supplier bank accounts
Payment using different disbursement bank accounts
Payment in different currencies
Payment to a single supplier
Payment covering multiple suppliers
Payment for a single invoice
Payment for multiple invoices
Electronic payment processed through a Payment Process Request
Payment processed under different payment process profiles
Payment file generation confirmed where applicable to the configured profile

Negative Scenarios

Missing supplier bank account
Invalid supplier bank account
Inactive bank account
Invalid or unconfigured payment method
Invalid disbursement bank account
Missing routing or bank identification information
Unsupported currency for the selected bank account
Payment validation failure
Payment file formatting exception
Transmission exception within the tested Oracle Fusion processing flow

These are representative examples only. Payment methods, bank account configuration and payment process profile behavior depend entirely on the customer's Oracle Fusion configuration and banking setup — this list is not exhaustive and does not represent a claim of universal support.

Generated Using Your DataVault Test Data

Generic test data often fails to represent the supplier, banking and payment process profile configuration of a real Oracle Fusion environment. Where connected, Jarvis can use approved test data available through Syntra DataVault — Supplier Bank Account, Disbursement Bank Account, Payment Method, Payment Process Profile and Currency — to create electronic payment variations relevant to the customer's actual implementation, with sensitive banking fields masked.

Standard Library Definition

Supplier                  ${SUPPLIER}
Supplier Bank Account      ${SUPPLIER_BANK_ACCOUNT}
Disbursement Bank Account  ${DISBURSEMENT_BANK_ACCOUNT}
Payment Method             ${PAYMENT_METHOD}
Payment Process Profile    ${PAYMENT_PROCESS_PROFILE}
Payment Currency           ${PAYMENT_CURRENCY}
Invoice Number             ${INVOICE_NUMBER}
Payment Amount             ${PAYMENT_AMOUNT}

DataVault

Suppliers
  Configured suppliers per Business Unit
Supplier Bank Accounts
  Masked account references per supplier
Disbursement Bank Accounts
  Operating Account (USD)
  Regional Account (EUR/GBP)
Payment Methods
  Configured electronic payment methods
Payment Process Profiles
  Configured per payment method and bank account
Currencies
  USD, GBP, EUR + unconfigured pairs

Jarvis AI Generates

Scenario 01 — Operating Account + USD + Single Invoice
Scenario 02 — Regional Account + EUR + Multiple Invoices
Scenario 03 — Multiple Suppliers, One Payment Process Request
Scenario 04 — Payment File Generated for Configured Profile
Scenario 05 — Missing Supplier Bank Account
Scenario 06 — Inactive Bank Account
...

Customer-specific test data and AI-generated variations are not published to the Syntra Standard Test Library. Where DataVault is connected, customer-specific banking data such as supplier bank accounts and disbursement account details remain within the customer's controlled SyntraFlow environment and access model, with sensitive fields masked in captured evidence.

Example Test Variations

Representative examples of electronic payment scenarios Jarvis can generate from this business scenario, spanning bank accounts, currencies, suppliers, payment process profiles, payment files and exception 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	Valid Electronic Transfer Payment	Bank	Valid supplier bank account, valid disbursement account, payment processes successfully	Syntra Ready
VAR-002	Payment — Supplier Bank Account A	Bank/Supplier	Different configured supplier bank account	Syntra Ready
VAR-003	Payment — Supplier Bank Account B	Bank/Supplier	Second configured supplier bank account	Syntra Ready
VAR-004	Payment — Disbursement Account A	Bank	Different configured disbursement bank account	Syntra Ready
VAR-005	Payment — Disbursement Account B	Bank	Second configured disbursement bank account	Syntra Ready
VAR-006	Payment — USD	Currency	Payment currency = USD	Syntra Ready
VAR-007	Payment — EUR	Currency	Payment currency = EUR	Syntra Ready
VAR-008	Payment — GBP	Currency	Payment currency = GBP	Syntra Ready
VAR-009	Single Supplier Payment	Supplier	Payment issued to one supplier	Syntra Ready
VAR-010	Multiple Supplier Payment Run	Supplier	Payment run covers multiple suppliers	Syntra Ready
VAR-011	Single Invoice Payment	Supplier	Payment covers exactly one invoice	Syntra Ready
VAR-012	Multiple Invoice Payment	Supplier	Payment covers multiple invoices for the same supplier	Syntra Ready
VAR-013	Electronic Payment via Payment Process Request	Profile	Payment initiated through a Payment Process Request rather than directly	Syntra Ready
VAR-014	Payment Process Profile A	Profile	Different configured payment process profile	Syntra Ready
VAR-015	Payment Process Profile B	Profile	Second configured payment process profile	Syntra Ready
VAR-016	Payment File Generated	File/Profile	Payment process profile configured to produce a payment file output	Syntra Ready
VAR-017	Missing Supplier Bank Account	Exceptions/Bank	Supplier has no bank account configured for electronic payment	Syntra Ready
VAR-018	Invalid Supplier Bank Account	Exceptions/Bank	Supplier bank account reference fails validation	Syntra Ready
VAR-019	Inactive Bank Account	Exceptions/Bank	Bank account exists but is inactive	Syntra Ready
VAR-020	Invalid Payment Method	Exceptions	Selected payment method is not valid or not configured	Syntra Ready
VAR-021	Invalid Disbursement Bank Account	Exceptions/Bank	Disbursement bank account reference fails validation	Syntra Ready
VAR-022	Missing Routing/Bank Information	Exceptions/Bank	Required routing or bank identification information is missing	Syntra Ready
VAR-023	Unsupported Currency	Exceptions/Currency	Currency not configured for the selected bank account	Syntra Ready
VAR-024	Payment Validation Failure	Exceptions	Payment fails Oracle Fusion validation before processing completes	Syntra Ready
VAR-025	Payment File Formatting Exception	Exceptions/File	Generated payment file does not meet expected format rules	Syntra Ready
VAR-026	Transmission Exception in Processing Flow	Exceptions/File	Processing flow reports a transmission-stage exception within Oracle Fusion's test environment	Syntra Ready

Automatically Expand Positive and Negative Electronic Payment Coverage

Positive Testing

Jarvis generates scenarios using combinations expected to successfully create and process an electronic supplier payment.

Valid Supplier Bank Account + Valid Disbursement Account + Configured Payment Method → Electronic Payment Created

Negative Testing

Jarvis can generate scenarios designed to exercise Oracle's banking, payment method and payment process profile validations.

Missing Supplier Bank Account → Expected Banking Validation
Inactive Bank Account → Expected Account Status Validation
Invalid Payment Method → Expected Configuration Validation
Unsupported Currency → Expected Currency Validation
Missing Routing Information → Expected Banking Validation

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

Scenario	Oracle Outcome	Test Result
Valid supplier bank account	Electronic payment created	PASS
Missing supplier bank account	Banking validation occurs	PASS
Inactive bank account	Validation prevents payment	PASS
Invalid payment method	Configuration validation occurs	PASS
Unexpected system error	Unexpected failure	FAIL

Turn AI-Generated Variations into a Regression Pack

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

Electronic Payment Regression Pack

Valid Electronic Transfer Payment
Payment — Supplier Bank Account A
Payment — USD
Payment — EUR
Multiple Supplier Payment Run
Multiple Invoice Payment
Electronic Payment via Payment Process Request
Missing Supplier Bank Account
Inactive Bank Account
Payment File Formatting Exception

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

Once scheduled, SyntraFlow executes the selected electronic 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	Electronic Payment Regression Pack
Schedule	Weekly Regression
Tests	26 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 (masked)

Execution Result

Meet Jarvis — SyntraFlow's AI Testing Engine

Jarvis extends the Syntra Standard Test Library by analysing the electronic payment 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 — Electronic Payment, 12 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 (masked)

↓

PASS / FAIL

Business Step → Underlying UI Actions

Business Step

Verify the Supplier Bank Account Details

May internally include

Open Supplier Bank Account Panel → Read Account Status → Confirm Active → Confirm Ownership

Business Step

Verify No Sensitive Bank Data Is Unnecessarily Exposed in Evidence

May internally include

Capture Evidence → Apply Masking Rule to Bank Fields → Confirm Masked Output → Store Evidence

What SyntraFlow Captures Per Run

Parameterised input valuesReusable navigationAutomation action traceScreenshots / evidence capture with sensitive-field maskingExecution 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
Create and Submit the Electronic Payment	Pass	—
Confirm the Resulting Payment Status	Pass	Pass
Verify No Sensitive Bank Data Is Unnecessarily Exposed in Evidence	Pass	Pass

Related AP Payment Tests

Electronic payment processing is one stage of the same AP payment lifecycle — explore the related payment creation, payment process request and payment accounting scenarios below.

Payment Process Request Create Payment Payment Accounting

Turn This Standard Test into Your Oracle AP Electronic Payment Regression Suite

Start with the Syntra Standard electronic payment 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 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 Home Syntra DataVault

Frequently Asked Questions

What does the Electronic Payment test validate in Oracle Fusion Accounts Payable?

It validates that an electronic supplier payment can be created and processed for eligible invoices using a configured payment method, supplier bank account, disbursement bank account and payment process profile, and that the resulting payment status and any generated payment file or output are correct.

Does SyntraFlow actually send money or transmit real bank payments?

No. SyntraFlow validates the Oracle Fusion electronic payment creation and processing workflow, and any payment file or output generated within Oracle Fusion's test environment. This is test automation executed against Oracle Fusion TEST/UAT environments only — SyntraFlow does not transmit funds to a bank or any external payment network.

How is sensitive supplier banking data protected in test evidence and reports?

SyntraFlow and Syntra DataVault support masking of sensitive banking fields — such as full account or routing numbers — in captured screenshots, evidence and reports, so this information is not unnecessarily exposed.

How does this test relate to a Payment Process Request?

A Payment Process Request (PPR) is one route by which invoices are selected and submitted for electronic payment in bulk. This scenario covers the underlying electronic payment creation and processing steps, which apply whether the payment is initiated directly or through a PPR.

How are the many electronic payment test variations generated?

Jarvis AI uses this standard electronic payment scenario together with available DataVault test data — suppliers, bank accounts, currencies and payment process profiles — to generate relevant positive and negative variations for the customer's environment.