Browser version scriptSkip Headers

Oracle® Fusion Applications Procurement, Payables, Payments, and Cash Guide
11g Release 6 (11.1.6)
Part Number E22897-06
Go to Documentation Home
Home
Go to contents  page
Contents
Book<br />List
Book
List
Go to Feedback page
Contact
Us

Go to previous page
Previous
Go to previous page
Next
PDF

5 Manage Banking

This chapter contains the following:

Manage Bank Statements

Manage Bank Statements

Processing Electronic Bank Statements: Explained

The electronic bank statement process transfers bank statements and imports them into Oracle Fusion Cash Management.

The following four statement file formats are supported:

For customers who access Oracle Fusion Applications through Oracle Public Cloud, an SFTP server is set up for users to transfer the statement files. For other implementations, if an SFTP server is available, bank statement files can be transferred to the SFTP server.

To utilize the SFTP server to transfer and import bank statements, first, compress the statement file into a zip file, and transfer the zip file to a directory on the SFTP server. Next, run the Load Interface File for Import process.

The process consists of the following three phases:

  1. Fetch phase: the program fetches the bank statement zip file from the SFTP server, unzips it, and stores the statement file in the database.

  2. Load phase: the program processes the fetched electronic bank statement and populates the bank statement interface tables, also known as the staging area.

  3. Import phase: the loaded bank statement data from the staging area is processed against functional validations before the data is populated into the bank statements tables. During this phase the parsing rules are executed.

If the process fails with import errors, after fixing the reported errors, rerun just the import phase from the Processing Warnings and Errors table of the Bank Statements and Reconciliation Overview page. However, if there are any errors during the load phase, purge the error data and resubmit the program.

The following prerequisites for Oracle Fusion Cash Management and Oracle Fusion Payments are required prior to processing electronic bank statements.

Cash Management

Set up the following entities in Cash Management:

Payments

The Bank Statements Processing program integrates with Payments.

Set up the following entity in Payments before using the program:

Example

The following example describes how to load an electronic bank statement.

  1. Obtain a bank statement file, bai2.txt, from the bank.

  2. Compress the file into a zip file called bai2.zip.

  3. Transfer the zip file to the SFTP server and place it in a directory, for example, /CE/statements/.

  4. Run the process, Load Interface File for Import. This program has 3 parameters: Import Process, Data File, and Retain File.

  5. Check for any processing errors from the Bank Statements and Reconciliation Overview page. If the file is successfully imported, it can now be reviewed from the Manage Bank Statements page.

For other implementations, if the SFTP server is not set up, the statement files can be stored on the local machine or a remote machine. Run the Process Electronic Bank Statements to transfer and import the statement files. When using this process, the statement file should not be compressed.

The Process Electronic Bank Statements process consists of the following three phases:

  1. Fetch phase: the program fetches the electronic bank statement file or stream from external sources and stores it in the database. The external sources can be a file stored on a remote machine or a file stored on the local machine.

  2. Load phase: the program processes the fetched electronic bank statement and populates the bank statement interface tables, also known as the staging area.

  3. Import phase: the loaded bank statement data from the staging area is processed against functional validations before the data is populated into the bank statements tables. During this phase the parsing rules are executed.

In addition to the prerequisites listed above, the following entities in Oracle Fusion Payments must be set up before running this program:

Automatic Reconciliation: Explained

Automatic Reconciliation or autoreconciliation, is the most common process used for reconciling system transactions with bank statement lines. Use autoreconciliation when processing a large volume of bank statements or wanting to automate the reconciliation process. The Automatic Reconciliation program uses the reconciliation rule set assigned to the bank account to reconcile bank statement lines and system transactions.

Reconciliation Exceptions: Overview

An exception occurs when the reconciliation program cannot find a system transaction to match with a particular bank statement line. These exceptions are classified as ambiguous, date or amount.

Automatic Reconciliation Exceptions

For each one to one automatic reconciliation rule, exceptions are looked for in the following order: ambiguous, date, and amount. If an exception type is found for a given bank statement line the program stops looking for other types of exceptions using the same rule. The exceptions are presented to you in the context of the bank statement line so the appropriate matching system transaction can be selected and reconciled. If a system transaction is an exception to more than one bank statement line it can only be selected to reconcile with one of the statement lines

Bank Statement Processing and Troubleshooting: Overview

The results of the of the bank statement processing program are displayed in the Bank Statements and Reconciliation work area if a problem is encountered. The Processing Errors and Warnings region displays the following statuses:


Status

Explanation

Load Error

This status is assigned at the file level. A file fails with load errors for the following two reasons: There was an error in fetching the data. There was an error parsing the data and populating the interface tables. Such errors typically arise when the data is not compliant with its standard.

Import Error

This status is assigned at both statement level and file level. An import error at statement level indicates that the data got populated in the interface (loaded) successfully but some functional validations have failed. Example: duplicate bank statement or a transaction code not setup. An import error at file level implies that there exists at least one statement in that file that failed with an import error.

Import Warning

This status is assigned at the statement level. Statements with Import Warning imply that this statement has been imported without any errors, but the program encountered some functional validation failures which are harmless enough not to stop the import.

Depending on the status of the file or the statement and the associated issue you can use the Retry icon to restart the program from where it failed in its last run. The following table explains the different retry options available:


Status

Fields on the Retry Dialog

Action on Program Resubmission

Load Error

If the file failed during the fetch phase (no hyperlink on File ID), all the parameters that were specified during program submission will be available in the dialog. The parameters can then be updated and program resubmitted again.

The program starts all over again from the fetch phase.

Load Error

If the file failed during the load phase (there is hyperlink on the File ID). Since the file is already fetched, the parameters associated with fetching the file are not shown; rather only the Format parameter is shown. In case a wrong value for Format is specified in the earlier run, it can be corrected here and the program resubmitted again.

The program starts from the load phase. The program attempts to load the already fetched data file using the Format specified.

Import Error

Import error at file level; no fields are available on retry dialog.

The program starts the import phase for all the statements that filed with import errors under that file.

Import Error

Import error at statement level. If a statement fails with Duplicate Bank Account error then the dialog will show the bank account field. The correct bank account can be selected and program resubmitted again.

The program starts the import phase for that particular statement, using the updated bank account. The program will start the import phase for that particular statement.

Import Error

Import error at statement level, for all other import errors, no fields are available on retry dialog.

The program starts the import phase for that particular statement, using the updated bank account. The program starts the import phase for that particular statement.

The following list of common issues and solutions can be used to troubleshoot the Bank Statement Processing program:


Issue

Solution

The program has been run and successfully completes but does not appear on the Manage Bank Statements page.

Check the Bank Statements and Reconciliation work area to verify if any processing errors have been reported for your bank statement.

The program has reported a load error for your file and you realize that the wrong file was processed and want to correct the error.

If the file was fetched (a hyperlink appears on the File ID field), you must purge the file in order to load the correct one. If the file was not fetched (no hyperlink on the File ID field), you can restart the program using the Retry option.

The program has reported a load error for your file and the file was fetched. You have figured out the problem in the data file and want to retry the program. Can you process the edited file?

No. If you want to reprocess a data file that has been fetched in the system, then you have to submit the program afresh. Once a file is fetched, subsequent retry on that file does not re-fetch the data file from its original source.

You have processed a data file where some statements imported successfully, but some failed. The failures were because of an error from the bank. They have sent the corrected file, but the file contains the other statements data that was successfully imported. What is the impact if the file is processed again?

You can process the same file without any problem. The program has the capability to detect duplicate bank statements and it flags such statements as Import Error.

A transaction or balance code A in the data file appears as B after the import. Why?

Verify if there is a code mapping defined for A that maps it to B.

A new code map group has been defined but it does not seem to be working.

Make sure the new code map group is assigned to the Format in Oracle Fusion Payments.

The program reports an import error if a transaction code is not defined, but does not report or give a warning if a balance code is missing for balances. What happens to the balance codes?

Such balances are imported by the program and they appear in the bank statements user interface. However, the balance description is empty because they are not defined in the system.

After import, some balance records have an empty balance description.

Verify if the balance codes for the balance records are defined in the balance code lookup.

The program indicates that a transaction code is not defined. Should a code map or a transaction code be defined?

If an existing internal code serves the same purpose as the new code, you can create a code map associating the new code with the existing code. If you want to use the transaction code as it is, then define the transaction code.

Manually Reconciling a Bank Statement: Explained

Manual bank statement reconciliation involves selecting bank statement lines and system transactions to be reconciled together. During reconciliation if a system transaction has not been cleared the reconciliation process clears the transaction first, and then reconciles it. Oracle Fusion Cash Management supports manual reconciliation for all matching scenarios (one to one, one to many, many to one, and many to many) and allows you to reconcile across bank statements from the same bank account.

Banks sometimes make mistakes by depositing or withdrawing incorrect amounts to bank accounts. These bank errors show up on bank statements, along with the corrections and adjustments to those errors. Banks resolve errors using two methods: reversal and adjustment.

Reconciling Corrections and Adjustments to Bank Errors

Correcting bank errors using the reversal and adjustment method are described in the following example:

A check was generated for $100.00, but the bank recorded this payment as $10.00 by mistake. On your bank statement, you will see an entry of $10.00 (payment).

Using the reversal method, the bank reverses the whole error transaction amount so that the error entry and the reversal entry net out to zero. Then, the bank makes another transaction entry for the correct transaction amount. In this example, a reversal entry of $10.00 (receipt) is created to offset the original error entry, and a new correction entry is created of $100.00 (payment). With the reversal method, the error and reversal statement lines as well as the new correction entry line should all be reconciled to the check transaction.

Using the adjustment method, the bank simply creates a new transaction entry to make up for the difference between the original transaction amount and the error entry. In this example, the bank generates a new adjustment entry of $90.00 (payment), which is the difference between the original error amount of $10.00 (payment) and the correct amount of $100.00 (payment). With the adjustment method, the error line and adjustment line should be reconciled to the check transaction.

External Cash Transactions: Overview

External cash transactions are transactions related to cash activity that has not been recorded within the system. There are four sources of external transactions: