Oracle ERP Testing Tool > Test Library > Financials > Cash Management > Bank Statements

Syntra Standard Oracle Test Library

Oracle Fusion Bank Statement Load & Parsing Test Cases

Validate that imported bank statement content — header fields, transaction lines, debit/credit codes, dates, currency and balances — is correctly interpreted and mapped into Oracle Cash Management before validation and processing.

Test ID	ORCL.R2R.CM.BS.PARSE
Application	Oracle Fusion Cloud
Product	Financials
Module	Cash Management
Process	Bank Statements
Business Flow	Record-to-Report / Cash Management
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 34 underlying Oracle Fusion UI actions to complete it.

Test Objective

The objective of this test is to verify that imported bank statement content is correctly interpreted and mapped into Oracle Cash Management statement headers and transaction lines.

The scenario should confirm that:

the statement header — bank account, statement date, currency, opening and closing balance — is parsed correctly
transaction lines are parsed without loss, duplication or truncation
debit and credit transactions are mapped to the correct indicator
transaction reference and bank/branch code values parse completely
value date and transaction date are parsed into distinct, correctly formatted fields
currency is parsed and matches the bank account configuration
opening balance, closing balance and parsed transaction amounts are internally consistent
no recognized field is dropped or left unmapped during parsing

This scenario does not claim that parsed statement lines are reconciled against Oracle transactions or that exceptions are resolved — those are covered by separate downstream validation, processing and exception-handling test scenarios.

When to Use This Test

Functional testing of a new Oracle Fusion Cash Management bank statement integration
Regression testing after a change to a bank's statement format or delivery method
UAT sign-off for bank statement parsing prior to go-live
Baseline case referenced by validate, process and exception-handling bank statement scenarios

Where This Test Fits in the Bank Statement Lifecycle

Import

→

Parse

→

Validate

→

Process

→

Exception Handling

→

Reprocess

→

Inquiry

This test covers parsing of an already-imported statement into Oracle Cash Management statement headers and transaction lines, and serves as a downstream scenario to import and a prerequisite for subsequent validation and processing scenarios.

← Previous Stage

Import Bank Statement

Next Stage →

Validate Bank Statement

Preconditions

Oracle Fusion Cash Management is configured and accessible to the test user.
A raw imported bank statement file or feed is present and available for parsing.
The statement format mapping/template for the source bank is configured in Oracle Fusion.
A valid bank account exists and is correctly associated with the statement format.
The test user has permission to view Cash Management bank statements.

Exact parsing behavior, supported statement formats and field availability may vary by Oracle Fusion implementation and banking configuration.

Sample Test Data

Bank Account	${BANK_ACCOUNT}
Statement Date	${STATEMENT_DATE}
Transaction Debit/Credit Code	Debit or Credit indicator per line
Transaction Amount	${AMOUNT}
Value Date	${VALUE_DATE}
Transaction Date	${TRANSACTION_DATE}
Currency	Matches bank account currency
Transaction Reference	Bank-supplied reference number
Bank/Branch Code	Bank-supplied routing/branch identifier
Opening Balance	Header-level opening balance
Closing Balance	Header-level closing balance

Sample values are illustrative. Replace them with valid data from the target Oracle Fusion environment and the source bank's actual statement format.

Test Steps

12 business-readable steps. SyntraFlow's automation executes ~34 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 Cash Management test user.	Oracle Fusion home page is displayed successfully and the user session is established.
2	Navigate to Cash Management Navigate to the Cash Management work area.	The Cash Management work area opens successfully.
3	Open Bank Statements Open the Bank Statements task within Cash Management.	The Bank Statements work area is displayed.
4	Locate the Imported Statement Search for and open the previously imported statement for the target bank account and statement date. ${BANK_ACCOUNT} / ${STATEMENT_DATE} This single business step replaces multiple technical actions such as opening search, entering the bank account, clicking Search and selecting the result.	The correct imported statement is located and its parsed status is available.
5	Review Parsed Statement Header Review the parsed statement header — bank account, statement date, currency, opening balance and closing balance.	Header fields display values consistent with the source statement file.
6	Review Parsed Transaction Lines Review the parsed transaction lines associated with the statement.	All transaction lines present in the source file appear as parsed lines, with no lines missing or duplicated.
7	Verify Debit/Credit Mapping Verify that debit and credit transaction lines are mapped to the correct debit/credit indicator. ${AMOUNT}	Debit and credit codes map correctly to the corresponding amount and indicator.
8	Verify Transaction Reference Values Verify that each transaction line's reference value matches the source statement.	Reference values parse completely, without truncation or corruption.
9	Verify Value Date and Transaction Date Mapping Verify that value date and transaction date parse into distinct, correctly formatted fields. ${VALUE_DATE} / ${TRANSACTION_DATE}	Value date and transaction date are correctly distinguished and formatted as expected.
10	Verify Currency Mapping Verify that statement and transaction currency are mapped correctly.	Currency matches the bank account currency configuration.
11	Verify Opening/Closing Balance Consistency Verify that the opening balance, closing balance and the net total of parsed transaction amounts are internally consistent.	Opening balance plus the net parsed transaction total reconciles with the closing balance.
12	Confirm No Unmapped or Dropped FieldsBusiness assertion Confirm that the parsed statement header and lines account for all recognized fields from the source file, with nothing dropped or left unmapped. This is the main business assertion for the scenario — the test does not stop merely because the statement header and lines were displayed.	The parsed statement fully represents the source data, with header and line fields mapped correctly and no unmapped or dropped fields.

Expected Results

Statement header is created with correct bank account, statement date, currency, opening and closing balance.
All transaction lines from the source statement are present as parsed lines.
Debit and credit transactions are mapped to the correct indicator.
Transaction amounts match the source statement values.
Transaction reference and bank/branch code values parse completely and accurately.
Value date and transaction date are correctly distinguished and formatted.
Currency is parsed correctly and matches bank account configuration.
Opening and closing balances are internally consistent with the parsed transaction lines.
No recognized field is dropped or left unmapped.
Parsed statement is available for subsequent validation and processing scenarios.

Key Validation Checkpoints

Statement header bank account matches the imported file.
Statement date parses correctly.
Currency matches bank account configuration.
Opening balance matches the source file.
Closing balance matches the source file.
All transaction lines from the source file are present as parsed lines.
Debit/credit indicator is correct for each line.
Transaction amount matches the source value for each line.
Value date and transaction date are correctly distinguished.
Transaction reference values parse without truncation.
Bank/branch code parses into the expected field.
Opening balance plus net transaction total reconciles with closing balance.

Core Business Scenario

Load & Parse Bank Statement

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 statement parsing 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 parsing test dozens of times simply to cover different combinations of statement format, transaction code, currency and date 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 — Bank Accounts, Statement Formats, Transaction Codes, Currencies, Date Formats 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 parsing 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 Load & Parse Bank Statement 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 Cash Management Bank Statements.

Positive Scenarios

Parse valid statement header
Parse multiple transaction lines
Parse debit transaction
Parse credit transaction
Parse transaction reference
Parse bank codes
Parse value date and transaction date
Parse currency
Parse opening and closing balances

Negative Scenarios

Missing statement header
Invalid line structure
Invalid amount
Invalid transaction code
Invalid date
Missing currency
Malformed reference
Inconsistent totals
Unexpected characters/encoding

These are representative examples only. Negative scenarios and expected behavior can depend on the customer's Oracle Fusion configuration, statement format and banking setup — 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 — statement format, transaction codes, currency and date formats — to create parsing variations relevant to the customer's actual implementation.

Standard Library Definition

Bank Account       ${BANK_ACCOUNT}
Statement Date     ${STATEMENT_DATE}
Transaction Code   ${TRANSACTION_CODE}
Amount             ${AMOUNT}
Value Date         ${VALUE_DATE}
Transaction Date   ${TRANSACTION_DATE}
Currency           ${CURRENCY}

DataVault

Bank Accounts
  Operating Account 001
  Payroll Account 002
Statement Formats
  BAI2
  MT940
  Custom CSV
Transaction Codes
  Debit codes (per bank)
  Credit codes (per bank)
Currencies
  USD
  GBP
  EUR
Date Formats
  Configured per bank/format

Jarvis AI Generates

Scenario 01 — BAI2 Format + Operating Account 001 + USD
Scenario 02 — MT940 Format + Payroll Account 002 + GBP
Scenario 03 — Custom CSV + Multiple Currencies
Scenario 04 — Invalid Transaction Code
Scenario 05 — Missing Currency
Scenario 06 — Inconsistent Totals
...

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 statement format, bank account and transaction code details 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	Valid Statement Header	Positive/Header	Header fields parse correctly with valid bank account and statement date	Syntra Ready
VAR-002	Multiple Transaction Lines	Positive/Line	Statement with multiple transaction lines parses without loss	Syntra Ready
VAR-003	Debit Transaction Line	Positive/Line/Amount	Debit code and amount parse into the debit field	Syntra Ready
VAR-004	Credit Transaction Line	Positive/Line/Amount	Credit code and amount parse into the credit field	Syntra Ready
VAR-005	Transaction Reference Parsed	Positive/Line	Reference number parses without truncation	Syntra Ready
VAR-006	Bank Code Parsed	Positive/Line	Bank/branch code parses into expected field	Syntra Ready
VAR-007	Value Date Parsed	Positive/Date	Value date parses into expected date field	Syntra Ready
VAR-008	Transaction Date Parsed	Positive/Date	Transaction date parses distinctly from value date	Syntra Ready
VAR-009	Currency Parsed	Positive/Header	Currency code parses and matches bank account currency	Syntra Ready
VAR-010	Opening Balance Parsed	Positive/Header/Amount	Opening balance parses into header field	Syntra Ready
VAR-011	Closing Balance Parsed	Positive/Header/Amount	Closing balance parses into header field	Syntra Ready
VAR-012	Multiple Accounts in Supported Structure	Positive/Header	Statement file containing multiple bank accounts parses into separate headers	Syntra Ready
VAR-013	Missing Statement Header	Negative/Header	Header record absent or unrecognized	Syntra Ready
VAR-014	Invalid Line Structure	Negative/Line	Transaction line does not match the expected format	Syntra Ready
VAR-015	Invalid Amount	Negative/Amount	Non-numeric or malformed amount value	Syntra Ready
VAR-016	Invalid Transaction Code	Negative/Line	Debit/credit code not recognized	Syntra Ready
VAR-017	Invalid Date	Negative/Date	Date value outside expected format or range	Syntra Ready
VAR-018	Missing Currency	Negative/Header	Currency code absent from header	Syntra Ready
VAR-019	Malformed Reference	Negative/Line/Encoding	Reference field contains unexpected structure	Syntra Ready
VAR-020	Inconsistent Totals	Negative/Amount/Header	Opening/closing balance does not reconcile with parsed transaction lines	Syntra Ready
VAR-021	Truncated Record	Negative/Line/Encoding	Record cut short mid-field	Syntra Ready
VAR-022	Unexpected Characters/Encoding	Negative/Encoding	Non-standard characters or encoding in the statement file	Syntra Ready

Automatically Expand Positive and Negative Parsing Coverage

Positive Testing

Jarvis generates scenarios using statement content expected to parse cleanly into Oracle Cash Management statement headers and transaction lines.

Valid Header + Valid Lines + Valid Codes + Valid Dates + Valid Currency → Statement Parses Correctly

Negative Testing

Jarvis can generate scenarios designed to exercise Oracle's parsing validations around malformed, missing or inconsistent statement content.

Inconsistent Totals → Expected Balance Inconsistency Flagged
Invalid Transaction Code → Expected Code Validation Displayed
Unexpected Characters/Encoding → Expected Parsing Error Flagged

A negative test should not be marked as failed simply because Oracle flags malformed or inconsistent parsed data. If the expected validation or inconsistency flag occurs, the negative test has passed.

Scenario	Oracle Outcome	Test Result
Valid statement structure	Statement parses correctly	PASS
Inconsistent totals	Expected inconsistency flagged	PASS
Invalid transaction code	Expected code validation appears	PASS
Unexpected parser error	Unexpected failure	FAIL

Turn AI-Generated Variations into a Regression Pack

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

Bank Statement Parsing Regression Pack

Valid Statement Header
Multiple Transaction Lines
Debit Transaction Line
Credit Transaction Line
Value Date Parsed
Currency Parsed
Opening Balance Parsed
Closing Balance Parsed
Inconsistent Totals
Invalid Transaction Code
Missing Currency
Unexpected Characters/Encoding

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 testingAfter a bank statement format change

Pack	Bank Statement Parsing Regression Pack
Schedule	Nightly Regression
Tests	22 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

Bank Statement Lifecycle

Exact processing depends on customer banking setup, formats and integrations. Manual entry can enter this flow directly at Validate. Stages link to the corresponding test scenario family.

Import→

Parse

→Validate→Process→Exception Handling→Reprocess→Inquiry

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 — Load & Parse Bank Statement, 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

↓

PASS / FAIL

Business Step → Underlying UI Actions

Business Step

Locate the Imported Statement

May internally include

Open Statement Search → Focus Bank Account → Enter Statement Date → Search → Select Statement → Confirm

Business Step

Verify Opening/Closing Balance Consistency

May internally include

Read Header Opening Balance → Sum Parsed Line Amounts → Read Header Closing Balance → Compare Computed vs Stated Closing Balance

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 Parsed Statement	Pass	—
Review Parsed Lines	Pass	—
Verify No Unmapped Fields	Pass	Pass

Related Bank Statement Tests

Parsing is one stage of the same bank statement lifecycle — explore the related import, validation, exception and inquiry scenarios below.

Import Bank Statement Validate Bank Statement Bank Statement Exceptions Bank Statement Inquiry

Turn This Standard Test into Your Oracle Cash Management Regression Suite

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

Automate with SyntraFlow Explore Bank Statements 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

Cash Management Bank Statements Cash Management Oracle Cash Management Testing Tool Syntra DataVault DataVault Data Masking

Frequently Asked Questions

What does bank statement parsing validate that import does not?

Import confirms that a statement file or feed is received and loaded into Oracle Fusion. Parsing confirms that the loaded content is correctly interpreted — header fields, transaction lines, debit/credit codes, dates, currency and balances mapped to the right Oracle Cash Management fields.

What happens when a statement contains a malformed transaction line?

A malformed line is expected to be flagged rather than silently parsed as valid. Negative variations of this test confirm that invalid line structures, invalid amounts, invalid codes and similar issues are correctly identified during parsing.

Does this test cover encoding issues in the statement file?

Yes. Variations cover unexpected characters and encoding conditions in the source file, confirming that such records are correctly flagged rather than parsed into corrupted or silently incorrect field values.

How are the many bank statement parsing test variations generated?

Jarvis AI uses this standard parsing scenario together with available DataVault test data and configuration to generate relevant positive and negative variations covering different statement formats, transaction codes, currencies and date formats.

Can this bank statement parsing test be scheduled?

Yes. Selected parsing variations can be grouped into a regression pack and scheduled for on-demand or unattended batch execution.

Does this test check whether balances reconcile with parsed transactions?

Yes. One of the core validation checkpoints confirms that the parsed opening balance, closing balance and net transaction total are internally consistent. A mismatch is a negative scenario that should be correctly flagged.