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

Syntra Standard Oracle Test Library

Oracle Fusion Payables Payment Accounting Test Cases

Validate creation of accounting for eligible Oracle Fusion Payables payments, including expected liability, cash/clearing and related accounting results, with General Ledger transfer covered only where included in the tested scope.

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

Test Objective

Validate creation of accounting for eligible Payables payments and confirm expected cash, liability and related accounting results.

The scenario should confirm that:

accounting is generated successfully for an eligible, completed payment
the liability account is relieved appropriately for the paid invoice(s)
the cash or cash-clearing account is represented correctly for the payment method used
total debits and credits balance across the generated accounting event
the accounting date is correct and falls within an open accounting period
the payment's accounting status updates correctly once accounting is generated
General Ledger transfer/posting is reflected correctly where included in the scenario's scope
no unexpected accounting errors occur during accounting generation

This scenario does not claim that General Ledger posting is validated for every payment — that depends on the customer's specific Oracle Fusion configuration and is confirmed only where GL transfer is included in the tested scope.

When to Use This Test

Functional testing of a new Oracle Fusion Payables payment implementation
Regression testing after an Oracle quarterly update affecting payment accounting
UAT sign-off for AP payment accounting
Final-stage scenario in the AP payment lifecycle, following payment creation, validation, processing and void handling

Where This Test Fits in the AP Payment Lifecycle

Payment Created

→

Payment Completed

→

Create Accounting

→

Liability/Cash Accounting

→

Accounting Status

→

General Ledger where included

This test covers accounting generation for a completed, eligible Payables payment — including liability and cash/clearing accounting — and represents the final stage of the AP payment lifecycle, with General Ledger transfer/posting covered only where included in the scenario's scope.

← Previous Stage

Void Payment

Preconditions

Oracle Fusion Payables is configured and available, with appropriate user access to payment accounting functions.
A payment exists that is completed and eligible for accounting generation.
The accounting period intended for the payment is open.
Valid liability and cash/clearing accounts are configured for the business unit and payment method involved.
A valid ledger is available and assigned for the payment's business unit.
The test user has permission to generate accounting for Payables payments.

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

Sample Test Data

Supplier	${SUPPLIER}
Payment Number	${PAYMENT_NUMBER}
Payment Amount	${PAYMENT_AMOUNT}
Payment Currency	${PAYMENT_CURRENCY}
Payment Method	Check / EFT / Wire, per payment configuration
Liability Account	${LIABILITY_ACCOUNT}
Cash/Clearing Account	${CASH_CLEARING_ACCOUNT}
Accounting Date	${ACCOUNTING_DATE}
Ledger	${LEDGER}

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

Test Steps

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

#	User Action	Expected Result
1	Locate Eligible Payment Search for and open the Payables payment that is completed and eligible for accounting generation. ${PAYMENT_NUMBER} This single business step replaces multiple technical actions such as opening payment search, entering the payment number, clicking Search and selecting the result.	The correct payment is located and its status confirms it is eligible for accounting generation.
2	Confirm Payment Completion Status Review the payment's status to confirm it has completed processing and is eligible for accounting.	The payment status confirms it is complete and ready for accounting generation.
3	Initiate Accounting Generation Initiate the Create Accounting process for the selected payment.	The Create Accounting request is accepted and accounting generation begins without unexpected errors.
4	Review Liability Accounting Review the liability distribution generated for the paid invoice(s), confirming the account relieved. ${LIABILITY_ACCOUNT}	The liability account is relieved appropriately and reflects the expected amount.
5	Review Cash/Clearing Accounting Review the cash or cash-clearing distribution generated for the payment method used. ${CASH_CLEARING_ACCOUNT}	The cash or cash-clearing account is represented correctly for the payment amount and method.
6	Verify Debit and Credit Entries Balance Review the total debit and credit amounts across all distributions generated for the accounting event.	Total debits equal total credits for the accounting event.
7	Verify Accounting Status Review the payment's accounting status and accounting date following accounting generation. ${ACCOUNTING_DATE}	The accounting status updates correctly to reflect that accounting has been generated, and the accounting date falls within the open period.
8	Confirm GL Transfer/Posting State If In ScopeBusiness assertion Where General Ledger transfer is included in the tested scope, review the transfer/posting status of the generated accounting; otherwise confirm the accounting is complete with no unexpected errors. ${LEDGER} This is the main business assertion for the scenario. GL transfer/posting is validated only where explicitly included in the tested scope — this step does not assert that posting occurs universally.	Where GL transfer is included in the tested scope, the transfer/posting status is reflected correctly; otherwise the accounting is confirmed complete with balanced liability and cash/clearing distributions and no unexpected accounting errors.

Expected Results

Accounting is generated successfully for the eligible, completed payment.
The liability account is relieved appropriately for the paid invoice(s).
The cash or cash-clearing account is represented correctly for the payment method used.
Total debits equal total credits across the generated accounting event.
The accounting date falls within the open accounting period.
The payment's accounting status updates correctly to reflect that accounting has been generated.
Where GL transfer is included in the tested scope, General Ledger transfer/posting reflects the expected status.
No unexpected accounting errors occur.

Key Validation Checkpoints

Accounting process completes without unexpected errors.
Payment accounting status updates correctly.
Liability account is relieved appropriately.
Cash/clearing account is represented correctly.
Debit and credit entries are balanced for the accounting event.
Accounting date is correct and within the open period.
Currency and accounting amounts are correct.
Accounting exceptions, if any, are captured with an expected reason.
GL transfer/posting state is correct only where explicitly included in the tested scope.

Core Business Scenario

Payment Accounting

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 payment accounting 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 payment accounting test dozens of times simply to cover different combinations of payment method, currency, bank account and accounting date. 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

Payment Completed

The payment finishes processing and becomes eligible for accounting generation.

Create Accounting

Accounting generation is initiated for the eligible payment.

Liability Accounting

The liability distribution is generated against the configured liability account, relieving the paid invoice(s).

Cash/Clearing Accounting

The cash or cash-clearing distribution is generated against the configured account for the payment method used.

Balancing

Debit and credit totals are confirmed to balance across the generated accounting event.

General Ledger

Where included in the scenario's scope, accounting is transferred and posted to the General Ledger.

Results + Evidence + Exceptions

Execution results, business assertions, screenshots/evidence and exceptions are captured.

Rather than maintaining dozens of near-duplicate copies of the same payment accounting 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 Payment Accounting 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

Account a standard payment
Account a full invoice payment
Account a partial payment
Account an electronic payment
Account a void payment
Different currencies, including a multi-currency example with an applicable exchange rate
Multiple payments accounted in the same run
Different bank accounts
Different accounting dates within the open period
Different ledgers, where applicable

Negative Scenarios

Incomplete payment
Invalid liability or cash account
Closed accounting period
Invalid accounting date
Missing accounting configuration
Invalid bank/cash account
Payment not eligible for accounting
Accounting-process exception

These are representative examples only. Negative scenarios and 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

Generic test data often fails to represent the configuration of a real Oracle Fusion environment. Where connected, Jarvis can use approved test data available through Syntra DataVault — including liability and cash/clearing accounts, currency, ledger and accounting date — to create variations relevant to the customer's actual implementation.

Standard Library Definition

Payment              ${PAYMENT_NUMBER}
Liability Account    ${LIABILITY_ACCOUNT}
Cash/Clearing Account ${CASH_CLEARING_ACCOUNT}
Currency             ${PAYMENT_CURRENCY}
Accounting Date      ${ACCOUNTING_DATE}
Ledger               ${LEDGER}

DataVault

Liability Accounts
  AP-LIAB-US
  AP-LIAB-UK
Cash/Clearing Accounts
  CASH-CLR-US
  CASH-CLR-UK
Currencies
  USD
  EUR
  GBP
Ledgers
  US Primary Ledger
  UK Primary Ledger
Accounting Periods
  Current open period per ledger

Jarvis AI Generates

Scenario 01 — Full Payment + USD + Current Period
Scenario 02 — Partial Payment + EUR + Exchange Rate Applied
Scenario 03 — Electronic Payment + Alternate Bank Account
Scenario 04 — Void Payment Reversal Accounting
Scenario 05 — Invalid Liability Account
Scenario 06 — Closed Accounting Period
...

Customer-specific test data and AI-generated variations are not published to the Syntra Standard Test Library. Where DataVault is connected, customer-specific data such as liability and cash accounts, currency and ledger configuration remain within the customer's controlled SyntraFlow environment and access model.

Example Test Variations

Representative examples of scenarios Jarvis can generate from this business scenario. 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	Standard Payment Accounting	Full	Full invoice payment, standard liability and cash accounts	Syntra Ready
VAR-002	Full Invoice Payment Accounting	Full	Payment fully settles a single invoice	Syntra Ready
VAR-003	Partial Payment Accounting	Partial	Payment partially settles an invoice; liability partially relieved	Syntra Ready
VAR-004	Electronic Payment Accounting	Bank	Payment processed via electronic payment method / bank file	Syntra Ready
VAR-005	Void Payment Accounting	Void	Reversal accounting generated for a voided payment	Syntra Ready
VAR-006	EUR Currency Payment	Currency	Payment currency = EUR with applicable exchange rate	Syntra Ready
VAR-007	GBP Currency Payment	Currency	Payment currency = GBP with applicable exchange rate	Syntra Ready
VAR-008	Multiple Payments in Same Run	Full	Accounting generated for multiple payments together	Syntra Ready
VAR-009	Alternate Bank Account	Bank	Payment issued from a different bank account	Syntra Ready
VAR-010	Different Accounting Date	Accounting	Accounting date differs from payment date within the open period	Syntra Ready
VAR-011	Alternate Ledger	Accounting	Payment accounted against an alternate ledger where applicable	Syntra Ready
VAR-012	Accounting Within Current Open Period	Period	Accounting date falls within the current open period	Syntra Ready
VAR-013	Incomplete Payment	Accounting	Payment has not completed processing	Syntra Ready
VAR-014	Invalid Liability Account	Accounting	Configured liability account is invalid	Syntra Ready
VAR-015	Closed Accounting Period	Period	Attempted accounting date falls within a closed period	Syntra Ready
VAR-016	Invalid Accounting Date	Period/Accounting	Accounting date is invalid or outside any open period	Syntra Ready
VAR-017	Missing Accounting Configuration	Accounting	Required accounting rule or method configuration is missing	Syntra Ready
VAR-018	Invalid Bank/Cash Account	Bank	Configured cash/clearing account is invalid	Syntra Ready
VAR-019	Payment Not Eligible for Accounting	Accounting	Payment status does not qualify for accounting generation	Syntra Ready
VAR-020	Accounting Process Exception	Accounting	Unexpected exception occurs during accounting generation	Syntra Ready

Automatically Expand Positive and Negative Test Coverage

Positive Testing

Jarvis generates scenarios using combinations expected to successfully generate accounting for eligible Payables payments.

Completed Payment + Valid Liability/Cash Accounts + Open Period → Accounting Generated

Negative Testing

Jarvis can generate scenarios designed to exercise Oracle's validations, business rules and exception handling around payment accounting.

Invalid Liability Account → Expected Account Validation
Closed Accounting Period → Expected Period Validation
Incomplete Payment → Expected Accounting Blocked
Invalid Cash/Clearing Account → Expected Account Validation
Payment Not Eligible for Accounting → Expected Eligibility Validation

A negative test should not be marked as failed simply because Oracle correctly blocks accounting generation for an ineligible payment. If the expected Oracle validation or block occurs, the negative test has passed.

Scenario	Oracle Outcome	Test Result
Eligible payment	Accounting completes with balanced entries	PASS
Invalid account	Configuration validation occurs	PASS
Closed period	Period validation occurs	PASS
Incomplete payment	Accounting prevented	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.

AP Payment Accounting Regression Pack

Standard Payment Accounting
Partial Payment Accounting
Electronic Payment Accounting
Void Payment Accounting
EUR Currency Payment
Multiple Payments in Same Run
Alternate Bank Account
Different Accounting Date
Invalid Liability Account
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 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 Payment Accounting 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 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 — Payment Accounting, 8 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 Eligible Payment

May internally include

Open Payment Search → Focus Payment Number Field → Enter Payment Number → Search → Select Payment → Confirm

Business Step

Review Liability Accounting

May internally include

Open Accounting Distributions → Filter Liability Line → Capture Account and Amount → Validate

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
Initiate Accounting Generation	Pass	—
Review Liability Accounting	Pass	—
Verify Accounting Status	Pass	Pass

Related AP Payment Tests

Payment Accounting is the final stage of the AP payment lifecycle, following payment creation, validation, processing and void handling — and connects back to Invoice Accounting upstream, which records the original supplier liability. Explore the related payment and invoice accounting scenarios below.

Void Payment Electronic Payment Invoice Accounting

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

Start with the Syntra Standard payment accounting test, use DataVault to provide environment-specific liability, cash and ledger data, let Jarvis generate additional positive and negative variations, and execute the resulting regression pack automatically with SyntraFlow.

Automate with SyntraFlow Explore Accounts Payable 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

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

Frequently Asked Questions

What does the Payment Accounting test validate in Oracle Fusion Payables?

It validates that accounting can be generated correctly for an eligible, completed Payables payment — including the liability distribution, cash/clearing distribution, balanced debit and credit entries and the payment's accounting status.

Does this test validate posting to the General Ledger?

Only where General Ledger transfer/posting is explicitly included in the specific test scenario's scope. Not every payment accounting scenario is validated through to GL posting — where that step is out of scope, it is treated as not applicable rather than assumed to have succeeded.

How are void payments accounted for?

A voided payment generates its own accounting to reverse the original payment's liability and cash/clearing entries. Void-specific accounting variations, including reversal timing, are covered as part of this scenario's variation set.

How does payment accounting connect to invoice accounting?

Payment accounting relieves the supplier liability that was originally recorded by Invoice Accounting. This scenario is the downstream, final stage of the AP payment lifecycle, following invoice accounting, payment creation, validation and processing.

How are the many payment accounting test variations generated?

Jarvis AI uses this standard accounting scenario together with available DataVault test data and configuration to generate relevant positive and negative variations — for example different payment methods, currencies, bank accounts and accounting dates — for the customer's environment.