8Manage Cash Management and Banking

This chapter contains the following:

Manage Banks, Bank Branches, and Bank Accounts

Banks, branches, and accounts fit together on the premise of the Bank Account model.

The model enables you to define and keep track of all bank accounts in one place and explicitly grant account access to:

  • multiple business units

  • functions

  • users

This eliminates the redundant duplicate bank account setup in different business units when these business units share the same bank account.

Banks

Creating a bank is the first step in the bank account creation. You can:

  • Search for existing banks to view and update

  • Create a new bank from an existing party

Consider the following:

  • The option to create from an existing party is implicitly implemented by the matching option.

  • The option is available only after the existing party has been found with the same bank.

  • If you select the matching option, the page repopulates the information from the matched party.

Branches

Once you have created your bank, the next step is creating a branch or branches associated to the bank. The matching option is also available when creating branches. To create a new branch without using the matching option, manually enter the required information. You can also define other branch- related attributes in the same page.

If you don't use the matching option when an existing party is found, a branch with the same party name is created.

Accounts

The four areas associated with defining an account are:

  • General information

  • Control of the account

  • Security and access to the account

  • Business unit assignment

Once the bank and branch are created, proceed to the bank account setup by doing the following:

  • Select the bank branch you want to associate to your bank account.

  • Assign the owner of the bank account.

    Note: To create a bank account for Payables or Receivables, add the Business Unit Access first for the business units to use the bank account.

Consider the following:

  • The Oracle Fusion Account Payables or Receivables accounts are identified by the business unit.

  • The Oracle Fusion Payroll accounts are identified by the legal entity.

  • The program, Inactivates Banks and Bank Branches allows you to inactivate all banks and bank branches that have no active internal and external bank accounts.

This example shows how to upload new addresses for existing banks or bank branches by using the Manage File Import Activities page from Trading Community Model.

The following table summarizes key decisions for this scenario:

Decisions to Consider In This Example

What setup data are you uploading?

Addresses for existing bank and branches

Is the data an update or new setup data?

Update to existing bank or branch data

Uploading an Address

  1. On the Setup and Maintenance work area, navigate to the Manage Banks or the Manage Bank Branches page.

  2. Select Query By Example from the View menu to sort and select the banks or bank branches to which you want to upload the addresses.

  3. From the View menu, hover over Columns and select BankPartyNumber for Manage Banks or BranchPartyNumber for Manage Bank Branches. If the BankPartyNumber or the BranchPartyNumber column isn't visible, select Manage Columns from the menu and move the BankPartyNumber or the BankPartyNumber to the Visible Columns list on the Manage Columns dialog box.

  4. Click the Export to Excel button to export the selected bank party number or branch party number to a CSV or Excel file.

  5. Add the bank party number or branch party number to your CSV or Excel file containing all the address information to be uploaded, such as Address 1, city, state, and country.

  6. Save the spreadsheet as a CSV file.

    The following table represents a sample spreadsheet:

    A B C D E

    BankPartyNumber or BranchPartyNumber

    Address 1

    City

    State

    Country

    50170

    1 Main St.

    San Francisco

    CA

    US

    50172

    2 Main St.

    San Francisco

    CA

    US

  7. On the Setup and Maintenance work area, navigate to the Manage File Import Activities page, and click Create.

  8. On the Create Import Activity: Enter Import Options page, complete the following fields, and click Next.

    Field Value

    Name

    Enter a unique name

    Object

    Account

    File Type

    Text File

    Upload From

    Select the appropriate option

    Data Type

    Accept the default value or leave the data type as Comma Separated if that's the separator used in the CSV file

    Header row included

    Checked

  9. On the Create Import Activity: Map Fields page, complete the following fields, and click Next.

    • For the BankPartyNumber or the BranchPartyNumber attribute, select OrganizationProfile as the target object, and select PartyNumber as the target attribute.

    • For every Address attribute, select Address as the target object, and select the corresponding values (Address1, City, State, Country) as the target attribute.

    The following table depicts a sample attribute mapping to upload new addresses:

    Column Header Example Value Object Attribute

    BankPartyNumber or BranchPartyNumber

    50170

    OrganizationProfile

    PartyNumber

    Address1

    1 Main St.

    Address

    Address1

    City

    San Francisco

    Address

    City

    State

    CA

    Address

    State

    Country

    US

    Address

    Country

  10. On the Create Schedule page, click Next to execute the address upload immediately. You can also define a specific schedule.

  11. On the Create Import Activity: Review and Activate page, verify the import activities options. Click Activate to upload.

  12. Verify that the Scheduled Process status is Completed in the Manage File Import Activities page.

  13. On the Setup and Maintenance work area, navigate to the Manage Banks or Manage Bank Branches pages. Verify that the bank or bank branch addresses are correctly imported.

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 statement file formats are supported:

  • BAI2

  • SWIFT MT940

  • EDIFACT FINSTA

  • ISO20022 CAMT052 V1 - camt.052.001.01

  • ISO20022 CAMT053 V1 - camt.053.001.01

  • ISO20022 CAMT053 V2 - camt.053.001.02

  • ISO20022 CAMT053 V3 - camt.053.001.03

The electronic bank statement process consists of the following three phases:

  1. Retrieve phase: Retrieves 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 computer or a file stored on the local computer.

  2. Load phase: Processes the retrieved electronic bank statement and populates the bank statement interface tables, also known as the staging area.

  3. Import phase: Processes the loaded bank statement data from the staging area against functional validations before populating the data into the bank statements tables. The parsing rules are executed during this phase.

If the process fails with import errors, correct 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 to process electronic bank statements.

Cash Management

Set up the following entities in Cash Management:

  • Bank Account

  • Balance Codes: The ISO 20022 balance codes for the opening and closing booked and available balances are provided and additional codes can be defined using the Balance Code lookup (CE_INTERNAL_BALANCE_CODES).

  • Transaction Codes

  • Parsing Rules: Parsing Rules setup is optional but relevant to Bank Statement Reconciliation.

Payments

Set up the following entities in Payments:

  • Code Map Group: Uses code map groups for mapping the balance codes and transaction codes that are reported on the external data file to the ones that are defined internally in the application. Each code map group is assigned to a format. Two code map groups mapping the BAI and EDIFACT opening and closing booked balance codes to the internal balance codes are provided. You can create transaction code mapping (CE_TRX_CODE ) to determine the flow indicator for configurable BAI2 transaction codes .SWIFT940 doesn't require a balance code mapping because it is position-based but you can create a code map group to map the transaction codes to the internally-defined transaction codes. The delivered code map groups provide only basic mappings. You can either modify or create code map groups according to your requirements.

  • Format: Cash Management delivers a single format for each of the bank statement formats supported. You can add additional formats.

You can load and import bank statements in Oracle Fusion Cash Management by any of the following methods:

  • Automatic Bank Statement File Import

  • Manual Bank Statement File Import through Oracle Web Center

Automatic Bank Statement File Import

Use the payment transmission configuration feature to automate the bank statement file import process. The process uses the payments transmission feature to connect to bank and download the bank statement file for subsequent processing and loading into the application.

Perform the following steps to set up automatic bank statement file import:

  1. Set up Payment System: Represents the financial institute or bank in Oracle Fusion Payments. For customers who access Oracle Fusion Applications through Oracle Public Cloud and other implementations, navigate to the Manage Payments System page from Setup and Maintenance to create a payment system.

  2. Set up Transmission Configuration: Contains the connectivity details for the financial institute or bank. This connectivity information is provided by the bank. The following protocols are supported for connecting and retrieving a file from bank server:

    • Secure File Transfer Retrieval Protocol for Static File Names (SFTP_GET): The bank provides the SFTP server details including SFTP server host/ip, port, credential details. Before using this protocol, you must log a service request with Oracle Support and provide the SFTP connectivity details. The SFTP_GET protocol currently supports only basic user name and password based authentication.

    • Http(s) GET Request: The bank provides the SSL enabled destination URL for connecting and retrieving the statement files. This URL can have authentication enabled. The HTTPS_GET protocol supports https connection but doesn't support the exchange of any dynamic tokens.

  3. Schedule Process Electronic Bank Statement Request: The process performs the following tasks:

    • Connects to the bank and retrieves the banks statement file

    • Processes and loads the bank statement file into the application

Manual Bank Statement File Import through Oracle Web Center

Use the document repository of Oracle Web Center Content Management to manually load and import bank statement files. The Web Center document repository is also available for customers who access Oracle Fusion Applications through other implementations. The account, fin/cashManagement/import, is created on the Web Center for the users of Oracle Fusion Cash Management.

Use the document repository of Oracle Web Center Content Management to manually load and import bank statement files. The Web Center document repository is also available for customers who access Oracle Fusion Applications through other implementations. The account, fin/cashManagement/import, is created on the Web Center for the users of Oracle Fusion Cash Management.

Example

The following example describes how to manually load and import 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. Using the File Import and Export functionality, transfer the .zip file to the Web Center document repository and place it in the account: fin/cashManagement/import.

    Note: For detailed information on the import and export process, see the hyperlink at the end of this topic for: Files for Import and Export: Explained.
  4. Run the Load and Import Bank Statement process. This process has the following parameters:

    • Format: Select the bank statement file format. For example, BAI2 format.

    • Data File: Select the .zip file from the WebCenter document repository. For example, bai2.zip from fin$/cashManagement$/import$ account.

    • Intraday: Select this parameter if you're importing an intraday statement. Intraday statement type can either be Cumulative or Incremental.

    • Submit Autoreconciliation: Use this parameter to submit the Autoreconciliation process immediately after the Load and Import Bank Statement process completes successfully. This option isn't available if Intraday is selected.

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

Bank Statement Validation

Prior Day Bank Statements:

  1. The Statement ID should be unique in a bank account within a calendar year.

  2. Multiple statements are allowed within the date range.

Intraday Bank Statements:

  1. The Statement ID should be unique in a bank account within a calendar year.

  2. Only one statement is allowed per day.

Intraday Bank Statements: Cumulative

  • The application deletes the existing intraday bank statement and imports the cumulative statement.

Intraday Bank Statements: Incremental

  • The application checks if there is a manual intraday statement within the same date range. If yes, the incremental statement is not imported and the process is completed with a status of :Import Error.

  • The application checks if there is an imported intraday statement within the same date range. If found, the statement lines from the incremental intraday bank statement is appended to the existing intraday bank statement. If not found, a new intraday statement is created.

The results 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: An error in fetching the data or 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 was populated in the interface and loaded successfully but some functional validations have failed. Example: Duplicate bank statement or a transaction code not set up. 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 are 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 (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 shows 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 starts 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 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 reprocess a data file that has been fetched in the application, then you have to resubmit the program Once a file is fetched, subsequent retry on that file does not recall 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 marks those 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 application.

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 use the existing transaction code, then you must define the transaction code.

Import Cash Management Bank Statements: How Data Is Processed

Use the Create Bank Statements in Spreadsheet template to create and import bank statements for any non-standard format into Oracle Fusion Cash Management.

To access the template, complete the following steps:

  1. Navigate to the File-Based Data Import for Oracle Financials Cloud guide.

  2. In the Table of Contents, click File-Based Data Imports.

  3. Click Import Bank Statements.

  4. In the File Links section, click the link to the Excel template.

Follow these guidelines when preparing your data in the worksheet:

  • Enter the required information for each column. Refer to the tool tips on each column header for detailed instructions.

  • Do not change the order of the columns in the template.

  • You can hide or skip the columns you do not use, but do not delete them.

Settings That Affect the Import Cash Management Bank Statements

Follow these guidelines when preparing your data in the worksheet:

  • Enter the required information for each column. Refer to the tool tips on each column header for detailed instructions.

  • Do not change the order of the columns in the template. Changing the order of the columns will cause the load process to fail.

  • You can hide or skip the columns you do not use, but do not delete them. Deleting columns will cause the load process to fail.

  • Each interface table represents a separate Excel sheet.

  • The first row in each sheet contains column headers that represent the interface table columns. The columns are in the order that the control file expects them to be in the data file.

  • Each column header contains (should this be tool tip) bubble text about the expected data type and, in some cases, instruction text.

  • You must enter data that conforms to what the control file can accept and process for the associated database column.

  • The format for date fields must be entered as MM/DD/YYYY.

  • Amount columns must not contain a thousand separators and must use a period (.) as the decimal separator.

  • Columns that must be whole numbers have data validation to allow only whole numbers.

  • Enter positive amounts and use the Debit orCredit indicator column to distinguish debit and credit amounts.

  • Columns have been formatted, where applicable, to match the expected data type to eliminate data entry errors.

  • For columns that require internal ID values, refer to the bubble text for additional guidance about finding these values.

  • For the Balance Code field, the valid values are from the lookup codes defined in lookup type CE_INTERNAL_BALANCE_CODES You can access the lookup types from the Manage Cash Management Lookups page. Enter the Balance Code in the spreadsheet.

The following are the Balance Codes delivered by Cash Management:

Balance Code Meaning

CLAV

Closing available

CLBD

Closing booked

OPAV

Opening available

OPBD

Opening booked

For the Transaction Type field, the valid values are from the lookup codes defined in lookup type CE_TRX_TYPE. You can access the lookup types from the Manage Cash Management Lookups page. Enter the transaction type meaning in the spreadsheet.

Transaction Type Transaction Type Meaning

ACH

Automated clearing house

BKA

Bank adjustment

BKF

Fee

CHK

Check

EFT

Electronic funds transfer

INT

Interest

LBX

Lockbox

MSC

Miscellaneous

ZBA

Zero balance

For Transaction Code, enter valid codes defined in Manage Bank Statement Transaction Codes task. The following are examples of transaction codes:

Transaction Code Description

100

Check-Payroll

115

Lockbox Deposit

475

Check paid

698

Miscellaneous Fee

How Import Cash Management Bank Statements is Processed

Once the bank statement information has been prepared, complete these steps in order:

Task Action Results

Generate the CSV file.

Click the Generate CSV File button.

A .zip file is created containing 6 CSV files. This creates a .zip file containing six CSV files.

Transfer the .zip file.

Navigate to Tools > File Import and Export.

Transfers the .zip file to the WebCenter document repository. Select "fin$/cashManagement$/import$" for the Account.

Load and import the data.

Run the program: Load Interface File for Import.

In the Process Details screen, for the Import Process, select Import Bank Statements in Spreadsheet. For the Data File, select the name of the .ZIP file that was transferred into the (fin$/cashManagement$/import$) repository in the UCM. The data from the .ZIP file will be loaded to the following interface tables: CE_STATEMENT_HEADERS_INT, CE_STATEMENT_LINES_INT, CE_STMT_BALANCES_INT, CE_STMT_BAL_AVALBTY_INT, CE_STMT_LINES_AVALBTY_INT, CE_STMT_LINES_CHARGES_INT After the load is successfully completed, the Import process imports the data from the interface tables into the corresponding bank statement tables. You are able to review the imported statements from the Manage Bank Statements page, the entry type is spreadsheet, then proceed with either manual or autoreconciliation.

Review import errors.

Review ESS Job Log files, fix the errors in the spreadsheet and restart the process again.

If there are errors during import after a successful load, the entire import fails and no records will be imported into bank statement tables from the interface tables. You can review the import errors from the ESS job log files. You must purge the current load from the Bank Statement and Reconciliation dashboard, fix the errors in the spreadsheet, and restart the process again.

FAQs for Manage Bank Statements

Use the Social link on the Edit Bank Statement page to invite others to a conversation to address the discrepancies.

For example, you are a cash manager reviewing the unreconciled items on a bank statement. The conversion rate the bank is using is different than what you expect. You need to confirm the conversion rate with the accounts payable manager.

From the Edit Bank Statement page:

  1. Click Social to open Oracle Social Network. Click the Share button, or click Join if collaboration has already been initiated.

  2. Create a new related conversation.

  3. Invite the accounts payable manager to join the conversation.

    The accounts payable manager confirms that the conversion rate used by the bank is different than what it should be.

    Based on this information, you can manually reconcile the statement line with the payment. The conversation serves as a record for the transaction.

Depending on your job role and permissions, you can access social networking features for the following Oracle Fusion Cash Management activities:

  • Bank statement

  • External cash transaction

Manage External Transactions

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

  • Manual Entry

  • Import

  • Balancing Transactions: Transactions created during reconciliation to record amount differences between the statement line and system transaction that may be due to bank fees, conversion rates, or other charges.

    Note

    For the 1-1 reconciliation matching type of payments and receipts, the reconciliation differences amount can be automatically split into the exchange gain or loss and bank charges accounts defined at business unit access level for the bank account..

    For all the other reconciliation matching type scenarios (1-M, M-1, M-M), and transaction sources, such as payroll, external transactions or journals, the reconciliation differences account defined at bank account setup is used.

  • Bank Statement: The bank statement transaction creation program allows you to configure rules to create transactions from unreconciled statement lines to record items such as bank charges, interest, or other miscellaneous items.

  • Bank Account Transfer

  • Ad Hoc Payment

  • Reversal Reconciliation

Import Cash Management External Transactions: How Data is Processed

Use the Cash Management External Transactions import process to create transactions from external applications and for high volume entries.

To access the template, complete the following steps:

  1. Navigate to the File-Based Data Import for Oracle Financials Cloud guide.

  2. In the Table of Contents, click File-Based Data Imports.

  3. Click the Cash Management External Transactions Import.

  4. In the File Links section, click the link to the Excel template.

Follow these guidelines when preparing your data in the worksheet:

  • Enter the required information for each column. Refer to the tool tips on each column header for detailed instructions.

  • Do not change the order of the columns in the template.

  • You can hide or skip the columns you do not use, but do not delete them.

Settings That Affect Cash Management External Transactions

The External Transactions Import Template contains then instructions tab and one tab that represent the table where the data is loaded:

Spreadsheet Tab Description

Instructions and CSV Generation

Contains instruction information about preparing and loading data, the format of the template, submitting the Import External Transactions process, and correcting import errors.

CE_EXTERNAL_TRANSACTIONS

Enter information about the external transaction that you are adding, such as bank account, amount, date, transaction type, reference, business unit, cash account, and offset account.

Recommended best practices for preparing data:

  • Manually enter the external transactions directly into this template.

  • Alternatively, extract data from external application into a temporary spreadsheet that contains the same columns and structure as this template. Then cut and paste the data from the temporary spreadsheet into the template.

How Cash Management External Transactions is Processed

Once the external data has been prepared, proceed with the following steps:

  1. Click the Generate CSV File button to generate a ZIP file containing the CSV file.

  2. Transfer the generated ZIP file to WebCenter document repository (UCM). Select fin$/cashManagement$/import$ account.

  3. Submit the ESS job Load Interface File for Import process.

  4. In the Process Details screen, for the Import Process, select Import External Transactions and for Data File, select the name of the ZIP file that was transferred to the fin$/cashManagement$/import$ repository in the UCM.

  5. The data from the ZIP file will be loaded to the interface table CE_EXTERNAL_TRANSACTIONS.

After the ESS Job Load Interface File for Import is completed successfully, the Import External Transactions ESS job will be automatically invoked.

If there are errors during import, the errors can be corrected and re-uploaded using the Correct Import Errors spreadsheet.

  1. From the Bank Statement and Reconciliation page, click on Correct Import Errors.

  2. This opens the Manage External Transactions spreadsheet.

  3. The worksheet will be pre-populated with rows that failed import. Review and correct the errors in the spreadsheet. Once the errors are corrected, click the Upload and Import button.

  4. Click the Download button to see if there are any rows returned. If the spreadsheet is empty, then all rows are successfully imported.

Manage Reconciliation

Automatic Reconciliation uses the reconciliation rule set assigned to the bank account to reconcile bank statement lines and system transactions. Use autoreconciliation to process a large volume of bank statements or to automate the reconciliation process.

Set up the following before performing automatic bank statement reconciliation:

Setup Prerequisites Description

Banks, Branches, and Accounts

Define banks, branches and accounts to keep track of all bank accounts in one place.

Parse Rule Sets

Use to parse inbound addenda and other fields into more granular constituent fields. A parse rule set is associated with a bank account and used as reference data for the parsing batch job or scheduled process.

Transaction Codes

Expand or modify existing delivered transaction codes or create transaction codes as required. Transaction codes must match your bank's transaction code.

Transaction Type Mapping

Based on the payment method, identify the transaction types for Payables and Receivables and provide a description.

Bank Statement Reconciliation Matching Rules

Use Reconciliation matching rules to determine how to match bank statement lines to system transactions.

Bank Statement Reconciliation Tolerance Rules

Use tolerance rules to specify date, amount and percentage tolerances that prevent or warn when reconciliation is a breach of a defined tolerance.

Bank Statement Automatic Reconciliation Matching Rule Set

Consists of one or more matching rules and tolerance rules. They must be prioritized or sequenced in the order in which they must be executed. Manage Bank Statement Reconciliation Rule Sets page

Transaction Creation Rules

Use to identify unreconciled or external bank statement lines, and create an account for a transaction. For example, bank fees and interest.

Define Subledger Accounting Rules

Configure predefined accounting rules for external entry transactions.

To start the autoreconciliation process you must:

  • Create a matching rule set and assign it to the bank account you want to use for autoreconciliation.

  • Submit the Autoreconciliation process in the Bank Statements and Reconciliation page.

  • Review the unreconciled and reconciled lines. You can either perform manual reconciliation or resubmit the autoreconciliation process from the Bank Statements and Reconciliation work area.

  • Review reconciliation exceptions from the Review Exception page.

  • Use the Mark Reviewed feature to prevent the accidental reversal of the reconciliation of a reconciled bank statement.

A reconciliation exception occurs when the autoreconciliation program cannot find an application transaction to match with a particular bank statement line.

Exceptions are classified as the following:

  • Ambiguous: This exception occurs when either there is more than one application transactions that could match to the line or the transaction could match to more than one statement line.

  • Date: This exception occurs when a system transaction meets all the matching criteria except the date of the transaction is out of the tolerance range.

  • Amount: This exception occurs when a system transaction meets all of the matching criteria except the amount of the transaction is outside the tolerance range

Automatic Reconciliation Exceptions

For each one to one automatic reconciliation rule, exceptions are looked for in the following order:

  1. Ambiguous

  2. Date

  3. 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 an application transaction is an exception to more than one bank statement line it can only be selected to reconcile with one of the statement lines.

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. You are allowed 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 see an entry of a $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 a $10.00 receipt is created to offset the original error entry. An additional correction entry is created as a $100.00 payment. With the reversal method, the error and reversal statement lines as well as the added correction entry line should all be reconciled to the check transaction.

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

Cash Positioning and Forecasting

Watch video

Watch: This video tutorial shows you how to prepare and review a cash position. The content of this video is also covered in text topics.

Watch video

Watch: This video tutorial shows you how to create and view a cash forecast for bank accounts. The content of this video is also covered in text topics.

Cash Positioning and Forecasting: Explained

The Oracle Cash Management Cash Positioning and Forecasting provide solutions to accurately report cash balances and position. This enables managers to make cash flows decisions such as investing and borrowing in a timely manner. It also effectively reports cash forecast information from different sources to help manage the cash requirements of the organization.

You have the flexibility to create detailed cash position and forecast reports by using SMART View and financial reports to meet reporting requirements. Use the setups in Oracle Functional Setup Manager to specify the requirements.

Sources and Scheduled Processes

You have visibility to a variety of sources available in the Essbase, such as invoices, receipts, and payment. Scheduled processes are designed to streamline the extraction and import of cash flow data from multiple applications such as:

  • Oracle Accounts Payable (AP)

  • Oracle Accounts Receivables (AR)

  • Oracle Payroll

  • Oracle Cash Management External Cash Transactions

  • Cash Management Bank Statements

The following ESS programs are used to create your cash position:

  • Cash Position Data Extraction: This program streamlines the extraction of data from all relevant sources. The Extraction Duration defined in the Specify Cash Positioning and Forecasting Options is used to get historical data. Submitting the program locks the following setup pages for Cash Positioning and Forecasting::

    • Specify Cash Positioning and Forecasting Options

    • Manage Cash Positioning and Forecasting Transaction Grouping

    All future system transactions will be stored in the cube.

  • Cash Position Data Transfer: This program automatically runs after a successful extraction takes place. It maintains the Essbase cubes, keeping the data in sync with the transaction data from different applications. The following results in successful extraction:

    • It maintains the Essbase cubes, keeping the data in sync with the transaction data from different applications.

    • Converts amounts in all four currencies stored in the cubes:

    1. Transaction

    2. Ledger

    3. Bank Account

    4. Reporting

  • Cash Position Data Deletion: Use this program to delete the cube prior to making changes to configure the dimensions or reporting options. The following occurs:

    • Deletes data from the interface tables.

    • Deletes the Cash Positioning cubes.

    • Unlocks the Specify Cash Positioning and Forecasting Options and the Manage Cash Positioning and Forecasting Transaction Grouping setup pages for Cash Positioning and Forecast:

Troubleshooting Conversion Rates

Warning Status:

  1. Review the failed transactions reported in the ValidationErrors.txt log file.

  2. Enter or correct the conversion rates for the failed transactions.

  3. Resubmit the Cash Position Extraction Job process.

  4. Review the status for the Cash Position Data Extraction and the Cash Position Data Transfer processes.

  5. Review log files for any further warnings or errors.

Bank Statements

  • If conversion rate is not defined for a specific bank statement date or booking date, the application searches going back up to 1 year to find the closest conversion rate to use.

  • For converting the bank account amount to the ledger amount, the application uses the Accounting Conversion Rate Type (GL_CUR_EXCHANGE_RATE_TYPE) defined in the bank account setup for the corresponding bank account.

  • For converting the bank account amount to the reporting amount, the application uses the default conversion type defined at Currency Rates Manager.

System Transactions

  • If the conversion rate is not defined for a specific transaction date, the application searches going back, up to 1 year to find the closest conversion rate.

  • For converting the transaction amount to the bank account amount the applications uses the Bank Conversion Rate Type (BANK_EXCHANGE_RATE_TYPE) from the bank account that corresponds to the transaction used.

  • For converting the transaction amount to the ledger amount, the application uses the conversion rate defined for the transaction.

  • For converting the transaction amount to the reporting amount, the application uses the default conversion type defined in the Currency Rates Manager.

Note: If the rate cannot be found, the default conversion type defined in the Currency Rates Manager is used.

Cash Positioning and Forecasting Solution Components

The following is used to create your cash position and forecast:

  • Essbase cube: This component stores the actual transaction data sources such as AP payments, AR receipts, and Payroll payments. This multidimensional database application stores the actual application data; bank statements and transactions. The following dimensions are delivered by Cash Management: Bank, Legal Entity, Currency, Currency Type, Transaction Type, Source of the Transaction (Bank Statements, AP Invoices, AP Overdue Invoices, AP Payments, AR Invoices, AR Overdue Invoices, AR Receipts, Payroll, and External Transactions), Reconciliation Status of the transaction, Time, and Flow indicator for the bank statement line.

  • SMART View and Excel: Is used to view the generated cash positioning and forecasting reports. You can drill down to view the transaction details by selecting the data cell from SMART View. The drill through is available from specified individual data cells. Cash Management delivers predefined drill through reports, but you have the ability to create your own.

    Note: To run Cash Position reports successfully, install a Smart View plugin later than the 11.1.2.5.500 version on the certified browsers Internet Explorer or Firefox.
  • Interface tables: Are created to allow the extraction of data from the various sources before transferring them to the Essbase cube.

  • ADF User Interface: The Bank Statement page enable view both intraday and prior-day bank statements.

  • ESS Job: The program is created to support loading of data from different sources to the Essbase cube. Sources such as the bank statement and transactions from AP payments, AR receipts, and Payroll payments. The existing Bank statement loader and import program supports loading and importing prior and intraday bank statements.

Setups in Functional Setup Manager

Specify Cash Positioning and Forecasting Options

You define the extraction duration of the transaction data in Essbase. You can also define reporting options such as:

  • the currency for cash balances.

  • the balance code to use from the bank statement in cash balances.

Manage Cash Positioning and Forecasting Transaction Grouping Setup

You create transaction grouping (transaction cube dimensions). You can create configurable dimensions to the transaction cube, in addition to the core dimensions delivered by Cash Management.

  • The configurable dimensions are available in Smart View for you to build configurable reports.

  • Dimensions available out of the box include Bank, Legal Entity, Currency, Currency Type, Transaction Type, Source of the Transaction (Bank Statements, AP Invoices, Payroll, AP Payments, AR Invoices, AR Receipts, External Transactions), Reconciliation Status of the transaction, Time, and Flow indicator for the bank statement line.

  • Design your configurable cube dimensions to meet the different reporting requirements for your organization.

Cash Positioning: Explained

Cash positioning is the planning tool to view your daily cash position. Project your cash needs and evaluate your company liquidity position. The daily cash positions are based on actual cash flows from data sources such as bank statements and external transactions.

You can generate a daily cash position based on the following dimensions:

  • Currency Type: Reporting, Accounting, Transaction currency, and Ledger currency

  • Currency

  • Flow Indicator

  • Reconciliation Status

  • Bank Name and Bank Account Name

  • Legal Entity

  • Region and Legal Entity

  • Application

  • Source

  • Type: Balance and Transaction

  • Time

ESSBASE and SMART View

The Essbase cube is used for generating the cash position such as the following:

  • Bank statements

  • Transaction data from external transactions

You can view or manipulate the data from the Essbase cube in Excel using SMART View. The cash positions generated in SMART View enable you to analyze the data easily and quickly. You can expand on the inflow and outflow summarized amounts and drill down to view the details of the source transaction.

Note: To run Cash Position reports successfully, install a Smart View plugin later than the 11.1.2.5.500 version on the certified browsers Internet Explorer or Firefox.

Balance Types

Banks can report different types of balances on the bank statements. You have the option to select which type of balances you want to use in SMART View as the opening balance in the cash position. Examples of the Balance Types are:

  • Opening ledger balance

  • Opening available balance

  • Opening 1 day and 2- day float

  • Closing ledger balance

  • Closing available balance

  • Closing 1 day and 2- day float

Import Cash Management Cash Position Data: How It Is Processed

Use the Cash Management Cash Position Data Import process to upload the cash positioning data from external systems into the Essbase Cash Position Cube.

The data imported into Cash Management are:

  • Bank Statement Headers

  • Bank Statement Lines

  • System Transactions

You can download the spreadsheet template to prepare your cash position data. The template contains an instruction sheet to help guide you through the process. To access the template, complete the following steps:

  1. Navigate to the File-Based Data Import for Oracle Financials Cloud guide.

  2. In the Table of Contents, click File-Based Data Imports.

  3. Click Cash Management Cash Position Data Import.

  4. In the File Links section, click the link to the Excel template.

Follow these guidelines when preparing your data in the worksheet

  • Enter the required information for each column. Refer to the tool tips on each column header for detailed instructions

  • Do not change the order of the columns in the template.

  • You can hide or skip the columns you do not use, but do not delete the

Settings That Affect the Cash Position Data Import Process

The following table displays the name of the tabs and descriptions for the Cash Position Data Import template:

Spreadsheet Tab Description

Instructions and CSV Generation

Contains instruction information about preparing and loading data, the format of the template, submitting the Cash Position Data Transfer process, and correcting import errors.

Bank Statement Headers

Enter information about the bank statement headers that you are adding, such as the source statement header ID, the source system, bank account name, and the legal entity name.

Bank Statement Lines

Enter information about the bank statement lines, such as the booking date, the transaction type, and amounts.

System Transactions

Enter information about the system transactions, such as AP payments, AR receipts, and external transactions.

Note: If a valid value cannot be provided for dimensional columns such as the bank name, bank account name, legal entity name, currency, and transaction type, provide the following default values namely: NO_BANK_VALUE, NO_BANK_ACCOUNT_VALUE, NO_LEGAL_ENTITY_VALUE, NO_CURR_VALUE, NO_TRANSACTION_TYPE_VALUE respectively.

How Cash Position Data Import Is Processed

After you finish preparing the data in the spreadsheet:

  1. Click the Generate CSV File button, on Instructions and CSV Generation tab, to generate a ZIP file containing 3 CSV files.

  2. Transfer the generated ZIP file to WebCenter document repository (UCM). Select fin$/cashManagement$/import$ account.

  3. Submit the ESS job Load Interface File for Import process.

  4. In the Process Details screen, for the Import Process, select Cash Position Data Transfer and for Data File, select the name of the ZIP file that was transferred to the fin$/cashManagement$/import$ repository in the UCM. The data from the ZIP file will be loaded to the interface tables CE_CP_STMT_HEADERS_INT, CE_CP_STMT_LINES_INT and CE_CP_SYS_TRX_INT.

  5. The data from the ZIP file will be loaded to the interface tables CE_CP_STMT_HEADERS_INT, CE_CP_STMT_LINES_INT and CE_CP_SYS_TRX_INT.

After the ESS Job Load Interface File for Import is completed successfully, the Cash Position Data Transfer ESS job will be automatically invoked. This process imports the data from the interface tables into the Cash Position Transaction Cube.

If there are errors during bank statements import, the errors can be corrected and re-uploaded to the cube using the Correct Bank Statement Import Errors spreadsheet:

  1. From the Cash Balances Dashboard page, go to task pane, and click on Correct Bank Statement Import Errors. This opens the Cash Position Bank Statements spreadsheet.

  2. The worksheet is pre-populated with rows that failed import

  3. Review and correct the errors in the spreadsheet.

  4. Once the errors are corrected, click the Upload and Import button.

  5. Click the Download button to see if there are any rows returned. If the spreadsheet is empty, then all rows have successfully been imported.

If there are errors during system transactions import, the errors can be corrected and re-loaded to the cube using the Correct Transaction Import Errors spreadsheet:

  1. From the Cash Balances Dashboard page, go to the task pane, and click on Correct Transaction Import Errors. This opens the Cash Position Transactions spreadsheet.

  2. The worksheet is -populated with rows that failed import.

  3. Review and correct the errors in the spreadsheet.

  4. Once the errors have been corrected, click the Upload and Import button.

  5. Click the Download button to see if there are any rows returned. If the spreadsheet is empty, then all rows have been successfully imported.

Cash Forecasting: Points to Consider

Prior to cash forecasting, cash positioning is usually performed on a daily basis by every cash management or treasury department. The goal of the cash position is to estimate with an acceptable degree of confidence the projected closing bank account balances. In doing so, cash forecasting decisions such as investing and borrowing, can be made in a timely manner.

Considerations

Consider the following when determining your investing or borrowing situations:

  • Cash Forecasting: Is the estimation of the cash position based on the following sources: Payables (Payables Invoices, Payables Payments), Receivables (Receivables Invoices, Receivables Receipts), Payroll (Payroll payments), and External transactions.

  • The Cash Forecast reports are now displaying Payables and Receivables invoices that are due and overdue, including unpaid or partially paid invoices. It ensures the right level of liquidity is represented and you are including all aspects of your cash outflows.

  • The overdue invoice amounts are displayed in the current date columns. By drilling down to the transaction, you can find the detail information such as invoice date and due date.

  • Prior Day Bank Statement: Statement or statements sent by the bank indicating previous day banking activity, cash transactions such as deposits or withdrawals, and account balances.

The Cash Management Dashboard: Overview

Oracle Fusion Cash Management provides a dashboard for you to easily review and drill down to activity in the application. The following is an overview of the five available infolets on the dashboard:

  1. Cash Balance: Displays the overall cash balance of the company across all its bank accounts.

  2. Unreconciled: Compares the total month-to-date unreconciled statement line amount against the system transaction amount.

  3. At Risk: Presents the overall deficit amount for the bank accounts with balances less than their target balances, and the number of bank accounts less than the target. You can click the Expanded View to view the balance and deficit for each bank account.

  4. 5 Day Forecast: Displays a bar graph representing the forecast of the overall cash balances for the next 5 days.

  5. Missing Statements: Indicates the number of bank accounts with missing bank statements.

Making an Ad Hoc Payment: Explained

The Manage Ad Hoc Payments page is used to transfer ad hoc funds from an internal bank account to an external payee bank account. Ad hoc payments may require an approval process prior to processing the payment. Processing the payment goes through formatting validation prior to transmission.

The following table lists the elements for making an ad hoc payment and the possible statues that may result with actions to take to correct issues.

Field Name Required Description

Payment Number

Yes, the payment reference is generated by the application.

The unique payment reference number.

Payment Number

Yes

The bank account initiating the payment.

Payee

Yes

Name of the payee.

Payee Account

Yes

The payee bank account receiving the payment.

Payment Date

Yes

Date of payment, application date defaults.

Amount

Yes

Amount to pay.

Currency

Yes

Payment currency.

Status

Yes, if Approvals are enabled.

Status of the payment. Valid values are:

  • Pending Approval

  • Approved

  • Rejected

  • Validated

  • Invalid

  • Settlement in Process

  • Failed

  • Completed

  • Voided

The Payment Status can be either nonactionable or actionable. The following table lists the possible statuses:

Nonactionable Status Description

Formatted

The payment has been formatted but transmission is not needed.

Transmitted

The payment has been formatted and transmitted.

Terminated

The payment has been terminated by the user.

Actionable Status Description

Pending action to address document validation errors.

Correction or missing data needed.

Pending action to address payment validation errors

Correction or missing data needed.

Failed validation and pending action

Correction or missing data needed.

Formatted and ready for transmission

Passed validation and ready to be transmitted.

Failed formatting and pending action

Correction or missing data needed.

Transmission failed

Correction or missing data needed.

Note: Cash Management calls the Resolve Document Validation Errors in Oracle Fusion Payment page to let you resolve issues encountered during the payment process request.

Transferring Funds Between Bank Accounts: Explained

Use the Manage Bank Account Transfers page to manage fund transfers between two internal bank accounts. The following list provides the elements for:

  • Payment status

  • Bank account information

  • Payment status details

Manage Bank Account Transfers Table:

Display Name Description

Transfer Number

Unique bank account transfer reference that is system generated.

From Account

The bank account that initiates the transfer.

To Account

The bank account receiving the transfer.

Transfer Date

Date of transfer.

Amount

Amount to transfer.

Currency

Currency of the amount transferred.

Status

Status of the bank account transfer. Valid values are:

  • Pending Approval

  • Approved

  • Rejected

  • Validated

  • Invalid

  • Settlement in Process

  • Failed

  • Completed

  • Voided

Payment Status

The status is a combination of the Payment Process Request and payment file. The payment status can be either nonactionable or actionable. The Action icon is only enabled if the payment status is actionable.

The following tables list the possible statuses:

Nonactionable Status Description

Formatted

The payment has been formatted but transmission is not needed.

Transmitted

The payment has been formatted and transmitted.

Terminated

The payment has been terminated by the user.

Actionable Status Description

Pending action to address document validation errors

Correction or missing data needed.

Pending action to address payment validation errors

Correction or missing data needed.

Failed validation and pending action

Correction or missing data needed.

Formatted and ready for transmission

Passed validation and ready to be transmitted.

Failed formatting and pending action

Correction or missing data needed.

Transmission failed

Correction or missing data needed.

Cash Management calls the Resolve Document Validation Errors in Oracle Fusion Payment to let you resolve issues encountered during the payment process request.

FAQs for Cash Positioning and Forecasting

Why can't I see the bank accounts for some transactions in the Cash Balances work area?

Cash balances, cash position and cash forecast reports retrieve data from the cash position cube. You must create the cash position cube by running the Cash Position Data Extraction program from the Scheduled Processes work area. You can see the bank accounts that affect your cash position after you run the program.

Why are system transactions available but the bank accounts are not displayed on the Cash Balances work area or the Cash Position page?

To accurately predict a cash position, the application requires an official prior day closing balance. Create or import a prior day bank statement with a reported closing balance to see the bank accounts in the Cash Balances work area or the Cash Position page.

How can I change the reporting currency for the Cash Management infolets, Cash Balances work area, and 5 Day Forecast after creating the cash position cube?

If you haven't yet submitted the Cash Position Data Extraction process, you can change the reporting currency in the Specify Cash Positioning and Forecasting Options page.

To change the reporting currency after creating the cash position cube:

  1. Submit the Cash Position Data Deletion process.

  2. Change the reporting currency on the Specify Cash Positioning and Forecasting Options page. This field is editable after you delete the data in the cash position cube.

  3. Click Save.

  4. Submit the Cash Position Data Extraction process to extract data to the cube. The Cash Position Data Transfer process runs automatically when you submit the process.

Why does the Cash Position Data Extraction program show error messages for missing conversion rates in the log file?

The cash position cube stores cash position amounts in four currencies:

  • Transaction

  • Ledger

  • Bank account

  • Reporting

If the currencies are different, the Cash Position Data Extraction program tries to convert transactions into a compatible currency. If one of the currency rates is missing, the conversion fails and the transaction isn't transferred to the cube resulting in an error message. To avoid conversion failures, add the missing currency conversion rates and rerun the extraction program to transfer the transactions.

When does the accounting for ad hoc payments take place?

Accounting for ad hoc payments occurs when the Create Accounting process is submitted from Cash Management to Oracle Fusion Subledger Accounting.

External transactions created for ad hoc payments have journal entries created by the process. Only one external transaction is created for the From Bank Account.

Any gain or loss calculation due to different currencies is handled by Subledger Accounting.

When does the accounting for bank transfers take place?

Accounting for bank transfers occurs when the Create Accounting process is submitted from Cash Management to Oracle Fusion Subledger Accounting.

The bank account transfer creates two external transactions.

  1. An outflow (payables) external transaction is created for the From Bank Account.

  2. An inflow (receivables) external transaction is created for the To Bank Account.

Bank account transfers can occur between an intercompany and intracompany.

External transactions created for bank account transfers have journal entries created by the Create Accounting process. Any gain or loss calculation due to different currencies is handled by Oracle Fusion Subledger Accounting.

Reports for Manage Cash Management and Banking

Oracle Fusion Cash Management Predefined Reports

Oracle Fusion Cash Management provides predefined reports that are used in the following areas:

  • Bank Statements

  • Cash Transit

  • Reconciling to the General Ledger

Scheduled Processes Work Area

You can schedule and run reports from the Scheduled Processes work area in the Tools section of the Navigator.

Reports and Analytics Work Area

In some cases, reports are also:

  • Accessed from the Reports and Analytics work area in the Tools section of the Navigator or from other work areas.

  • Opened using links that launch the Oracle Business Intelligence Catalog.

The following tables list the predefined reports by type:

Bank Statement Reports:

Report Name Description Parameters (*Required)

Bank Statement Report

Displays the bank statements that are used to analyze balances and transaction details.

  • *Bank Account

  • *From Statement End Date

  • *To Statement End Date

Bank Statement Analysis Report

Displays bank statements used to analyze balances and transaction details.

NA

Cash Transit Report

Report Name Description Parameters (*Required)

Cash in Transit Report

Lists all transactions for a specific bank account, that have been remitted to the bank but have not been cleared. The report excludes all voided transactions and all reversed transactions with a reversal date on or prior to the As of Date.

  • *Bank Account

  • Transaction Source

  • As-of Date

Cash to General Ledger Report

Report Name Description Parameters (*Required)

Cash to General Ledger Reconciliation Report

Displays bank statement transactions and general ledger accounting entries that have not been reconciled and can cause discrepancies. The report is used to reconcile bank balances to general ledger cash balances.

  • *Bank Account

  • *Accounting Period

To run predefined reports, navigate to the Scheduled Processes work area and follow these steps:

  1. Click the Schedule New Process button.

  2. Search the Process Name.

  3. Enter the parameters.

  4. Enter the applicable process options and schedule.

  5. Click Submit.

Cash Management Bank Statement Report: Explained

This topic includes details about the Cash Management Bank Statement Report.

Overview

The Cash Management Bank Statement Report displays bank account balances and transaction information for specific bank statements. The following figure is an example of the report:

This graphic illustrates the Bank Statement Report
in detail.

Key Insights

The Cash Management Bank Statement Report is used for reviewing activity of a specific bank account.

Report Parameters

The following table describes required process parameters:

Name Description

Bank Account

The specific bank account used to receive payments and disburse funds.

From Statement End Date

Starting date range of the activities for the account.

To Statement End Date

Ending date range of the activities for the account.

Frequently Asked Questions

The following table lists frequently asked questions about the Cash Management Bank Statement Report.

FAQ Answers

How do I find this report?

Schedule and run this report from the Scheduled Processes work area on the Navigator menu.

Who uses this report?

  • Cash Manager

  • Financial Manager

  • Financial Specialist

When do I use this report?

Use this report to review the bank statement of a specific bank account over a selected period.

What can I do with this report?

You can use this report to review bank statements and their reconciliation status.

What type of report is this?

Oracle Business Intelligence Publisher

Cash in Transit Report: Explained

This topic includes details about the Cash in Transit Report.

Overview

The Cash in Transit Report lists, for a specific bank account, all transactions that have been remitted to the bank but haven't been cleared. The Cash in Transit report excludes the following:

  • All voided transactions

  • All reversed transactions with a reversal date on or prior to the As of Date

The following figure is an example of the cash in transit report:

This graphic illustrates the Cash in Transit Report
payments made from the bank account selected.

Key Insights

The Cash in Transit Report lists the transactions that are created but haven't been cleared as of a specific date.

Report Parameters

The following table describes required process parameters:

Name Description

Bank Account

The specific bank account used to receive payments and disburse funds.

Transaction Source

The origin of the transaction, such as payables or receivables.

As of Date

The date when the transaction status is checked.

Frequently Asked Questions

The following table lists frequently asked questions about the Cash in Transit Report.

FAQ Answers

How do I find this report?

Schedule and run this report from the Scheduled Processes work area on the Navigator menu.

Who uses this report?

  • Cash Manager

  • Financial Manager

  • Financial Specialist

When do I use this report?

Use this report to review the transactions of a specific bank account that have been remitted but haven't been cleared.

What can I do with this report?

Identify transactions that haven't been cleared as of a specific date.

What type of report is this?

Oracle Business Intelligence

Cash to General Ledger Reconciliation Report: Explained

This topic provides information about the Cash to General Ledger Reconciliation Report.

Overview

The Cash to General Ledger Reconciliation Report compares the GL cash account balance against the bank account balance. It displays the unreconciled GL cash account journal entries and unreconciled bank statement lines that help identify the discrepancies between the balances. This is done based on the specified range of periods.

The body of the Cash to General Ledger Reconciliation
Report.

Key Insights

The Cash to General Ledger Reconciliation Report lists the subledger transactions that are accounted in GL but they are not reconciled in Cash Management.

Consider assigning a unique GL cash account for each bank account and using it to record all cash transactions to facilitate this book to bank reconciliation.

Report Parameters

The following table describes required process parameters:

Name Description

Bank Account

The specific bank account used to receive payments and disburse funds.

From Accounting Period

The first fiscal period a company uses to report financial results, such as a calendar month or fiscal period. A portion of time in which the accounting calendar may be divided. Accounting periods make up an accounting calendar.

To Accounting Period

The ending fiscal period a company uses to report financial results, such as a calendar month or fiscal period. A portion of time in which the accounting calendar may be divided. Accounting periods make up an accounting calendar.

Frequently Asked Questions

The following table lists frequently asked questions about the Cash to General Ledger Reconciliation Report.

FAQ Answers

How do I find these reports?

Schedule and run this report from the Scheduled Processes work area on the Navigator menu.

Who uses these reports?

  • Cash Manager

  • Financial Manager

  • Financial Specialist

When do I use these reports?

Use this report to:

  • Review and identify the discrepancies in the bank account balances in Cash Management and the GL cash account balance.

What can I do with this report?

Reconcile bank balances to the general ledger cash account balances.

What type of reports are these?

Oracle Business Intelligence Publisher

Cash Management Subject Areas, Folders, and Attributes: Explained

To create real-time analyses for Cash Management, you must be familiar with subject areas, folders, and attributes.

Subject Areas

To create an analysis, you begin by selecting a subject area from which you select columns of information to include in the analysis. For example, to create an analysis of bank statement balance information, you begin by selecting a Cash Management - Bank Statement Balances Real Time subject area. Subject areas are based around a business object or fact. In this example, the subject area is based on the column in the bank statement balance tables.

The following are the four cash management-specific subject areas:

  1. Cash Management - Bank Statement Balances Real Time

  2. Cash Management - Bank Statement Line Charges Real Time

  3. Cash Management - Bank Statements Real Time

  4. Cash Management - External Cash Transactions Real Time

Folders

Each subject area has one fact folder and a number of dimension folders. Fact folders contain measurable attributes, which are numeric values like balance code and credit, debit indicator. Fact folders are usually at the end of the list of folders, and are named after the subject area. Dimension folders contain attribute and hierarchical columns like entry type and legal sequence number.

Some folders appear in more than one subject area, such as Time. These are referred to as common folders or common dimensions.

Each folder within a subject area may have a different level of granularity. For example, Bank Statement Balance Detail has various attributes, and Bank Statement Detail has subfolders and attributes in the subfolders.

Attributes

Each dimension folder contains attributes or columns. For example, the folder Bank Statement Balance Detail contains the following attributes:

  • Balance Code

  • Balance Code Description

  • Credit Debit Indicator

  • Float Days

  • Funds Date

Bank Account Validation

Bank Account Validation by Country: Albania to Guatemala

This outlines the country specific bank account validation rules performed in Oracle Fusion Cash Management.

The following countries have country specific validations:

  • Albania

  • Algeria

  • Andorra

  • Argentina

  • Australia

  • Austria

  • Azerbaijan

  • Bahrain

  • Belarus

  • Belgium

  • Bosnia and Herzegovina

  • Brazil

  • British Virgin Islands

  • Bulgaria

  • Canada

  • Columbia

  • Costa Rica

  • Croatia

  • Cyprus

  • Czech Republic

  • Denmark

  • Dominican Republic

  • Egypt

  • El Salvador

  • Estonia

  • Faroe Islands

  • Finland

  • France

  • French Guiana

  • Georgia

  • Germany

  • Gibraltar

  • Greece

  • Greenland

  • Guadeloupe

  • Guatemala

When entering bank accounts, different countries can have certain rules governing the format and content of the following related fields:

  1. Bank Code

  2. Branch Number

  3. Account Number

  4. Check Digit

  5. IBAN

Use the Disable Country Specific Bank Validations profile option to disable the country-specific validations pertaining to the bank code, branch number, account number, check digit, and IBAN. You can set this profile option at the site or user level. The profile is predefined with a default value of No at the site level. If the profile is set to Yes, these validations are not performed. The checks for unique banks, branches, accounts, and the mandatory requirement of bank account number are not affected by this profile.

Albania

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Algeria

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 26 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Andorra

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Argentina

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

  • Length should be a maximum of 22 characters.

  • Spaces and hyphens are allowed.

Check Digit

  • Optional

IBAN

  • Optional

Australia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, the length should be either 2 or 3 numeric characters.

Branch Number

  • Mandatory

  • The combined length of the Branch Number and Bank Code should be 6 numeric characters. Hence, the valid length values (3,4,6) depend upon the Bank Code (3,2,0).

  • This field is labeled as Bank State Branch.

Account Number

  • Mandatory

  • Length should be between 5 to 10 characters.

  • If the account currency is Australian Dollar, account number should be numeric. For foreign currencies, alphanumeric values are allowed

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Austria

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • Length should be of 5 numeric characters.

Branch Number

  • Optional

  • Length should be of 5 numeric characters.

Account Number

  • Mandatory

  • Length should be between 4 to 11 numeric characters.

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 20 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Azerbaijan

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Bahrain

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 22 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Belarus

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Belgium

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

  • Length should be of 12 numeric characters.

  • It should be in the format 999-9999999-99.

  • A check algorithm is applied on the Account Number.

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 16 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Account Number

  1. The entered check digit CD1, is the last two digits of the Account Number

  2. The calculated check digit CD2, is derived by concatenating the first two sections of the Account Number and calculating the remainder on dividing this by 97. If the remainder is equal to 0, then the calculated check digit is taken to be 97.

  3. If the entered check digit (CD1) and calculated check digit (CD2) are equal, then the Account Number is valid, else the check has failed.

  4. Additionally, if the entered check digit (that is, the last section) is '00', then the Account Number is invalid because the calculated check digit can never be 00 as per the 3rd point.

    Example using account number 123-4567890-78

    • The entered check digit (CD1) is '78'. The concatenation of the first two sections gives '1234567890'

    • Divide the result by '97'. 1234567890 / 97 = 12727504

    • Derive the remainder. 1234567890 - (12727504 * 97) = 2 Therefore CD2 = 2

    • Here CD1 <> CD2, therefore the Account Number is not valid.

      In this case, a valid Account Number would be '123456789-02'.

Bosnia and Herzegovina

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 20 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Brazil

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Mandatory

  • Length should be a maximum of 3 numeric characters.

  • If the length is less than 3, then it is converted to a 3 digit number by prefixing it with as many leading zeroes as is necessary.

Branch Number

  • Mandatory

  • Length should be a maximum of 5 numeric characters.

Account Number

  • Mandatory

Check Digit

  • Optional

Company Code

  • Optional.

  • This is entered in the Account Creation form.

  • If entered, length should be a maximum of 15 numeric characters

Secondary Account Reference

  • This field is labeled as Company Code.

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 29 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

British Virgin Islands

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length can’t be more than 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Bulgaria

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 22 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Canada

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

  • This field is labeled as Routing Transit Number.

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Columbia

For Colombia, there are no validations for Bank Code, Branch Number, Account Number, or Check Digit fields as illustrated in the following table:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

Tax Payer ID

  • Optional

  • Length should be a maximum of 15 numeric characters 14 digits for Tax Payer ID plus the last digit for check digit.

  • It is unique within the country.

  • Cross Validations of Tax Payer ID in Customers, Suppliers, and Companies. If the Tax Payer ID is used by a Customer, Supplier, or a Company, then the Customer name, Supplier name, or the Company name should match with the Bank name.

  • A check digit is applied on the Tax Payer ID.

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Tax Payer ID

The first 15 digits are multiplied by the associated factor, as illustrated in the following table.

Digit Factor

1st

71

2nd

67

3rd

59

4th

53

5th

47

6th

43

7th

41

8th

37

9th

29

10th

23

11th

19

12th

17

13th

13

14th

7

15th

3

  1. These 15 products are added and the sum is divided by 11.

  2. If the remainder is 1 or 0, then the Check Digit should be 1 or 0 respectively.

  3. If the remainder is not 1 or 0, then the remainder is subtracted by 11 and that should be the Check Digit.

Costa Rica

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 22 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Croatia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 21 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Cyprus

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Czech Republic

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Denmark

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Length should be a maximum of 10 numeric characters

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 18 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Dominican Republic

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Egypt

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 27 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

El Salvador

.

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Estonia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 20 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Faroe Islands

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 18 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Finland

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

  • If entered, it should be 6 numeric characters.

Account Number

  • Mandatory

  • Length should be between 8 to 14 numeric characters.

  • A check algorithm is applied on the Account Number.

Check Digit

  • Optional

  • If entered, it should be 1 numeric digit.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 18 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

If 1st digit of Account Number is: Check Value Method

1

1

2

1

3

1

4

2

5

2

6

1

7

2

8

1

9

1

Method 1

The check is formed in the following two parts:

  • The first part of the check is formed from the first 6 digits of the Account Number. To illustrate, if the account number is 123456789, then the first part of check would be created as 123456.

  • The second part of check is formed as an eight digit value, comprising the 8th to 15th digits of the Account Number. If the length is less than 8, then it is converted to an 8 digit number by prefixing it with as many leading zeroes as is necessary. Using the same example, the second part of check would be created as 00000089. check is then formed by concatenating the two parts. So, in our example the check is formed as 12345600000089.

Method 2

The check is formed in the following three parts:

  • The first part of the check is formed from the first 6 digits of the Account Number. To illustrate, if the account number is 123456789, then the first part of check would be created as 123456.

  • The second part of check is formed as the 8th digit of the Account Number. Using the same example, the second part of check would be created as 8.

  • The third part of check is formed as a seven digit value, comprising the 9th to 15th digits of the Account Number. If the length is less than 7, then it is converted to a 7 digit number by prefixing it with as many leading zeroes as is necessary. Using the same example, the second part of check would be created as 0000009. The check is then formed by concatenating the three parts. So, in our example the check is formed as 12345680000009.

A computed sum is then calculated based on the value of the check. Different calculations are performed depending on the first two digits of the formed check value.

If the first two digits of the check are '88', then:

  • The Finnish government provides the following factor table. The 8th to 13th digits of the check number are multiplied by the associated factor. The computed sum is then calculated by summing the totals.

Digit Factor

8th

1

9th

3

10th

7

11th

1

12th

3

13th

7

Example using check number 88345600000089: Multiply the given digits with the given factor.

Digit Value Factor Result

8th Digit

0

1

0

9th Digit

0

3

0

10th Digit

0

7

0

11th Digit

0

7

0

12th Digit

0

3

0

13th Digit

8

7

56

Total

N/A

N/A

56

So the computed sum for this example is 56.

The test fails unless either of the following applies:

  • The 14th digit of the check should equal the value of 10 minus the last digit of the computed sum. For the check value is '88345600000089', the last digit of the computed sum is 6. So 10 - 6 = 4. So, the 14th digit of the check should equal 4. The test fails here as the 14th digit is 9.

  • Both the 14th digit of the check and the last digit of the computed sum are 0. Using the same example, the test fails here as both values are not 0.

If the first two digits of the check are NOT '88', then the computed sum is calculated for each of the first 13 digits by adding the even numbered digits to the following calculated sum for each odd numbered digit :

  • Multiply the digit by 2.

  • Divide the result by 10.

  • From the result add the integer to the remainder.

Example using account number 123456800000089:

Digit Value Multiply (a) Divide (b) Integer Remainder Result

1st

1

2

0.2

0

2

2

2nd

2

N/A

N/A

N/A

N/A

2

3rd

3

6

0.6

0

6

6

4th

4

N/A

N/A

N/A

N/A

4

5th

5

10

1

1

0

1

6th

6

N/A

N/A

N/A

N/A

6

7th

0

16

1.6

1

6

0

8th

0

N/A

N/A

N/A

N/A

0

9th

0

0

0

0

0

0

10th

0

N/A

N/A

N/A

N/A

0

11th

0

0

0

0

0

0

12th

0

N/A

N/A

N/A

N/A

0

13th

8

16

1.6

1

6

7

Total

N/A

N/A

N/A

N/A

N/A

28

The computed sum is then converted using the following process, before being used to see if the Account Number is valid:

  1. Computed sum is added to 9.

  2. The result is divided by 10.

  3. The integer result is multiplied by 10.

  4. The result is subtracted by the original computed sum.

So the computed sum '282 is converted to '2' as:

  1. 28 + 9 = 37

  2. 37/10 = 3.7. Integer result therefore = 3

  3. 3 * 10 = 30

  4. 30 - 28 = 2

This number is then compared to the 14th digit of the Account Number. If it matches, then the test is passed, else it is failed.

In our example, the test fails as the 14th digit of the account number is 9. If the 14th digit had been 2, then the test would have been passed.

France

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Mandatory

  • Length should be a maximum of 5 numeric characters.

  • If the length is less than 5, then it is converted to a 5 digit number by prefixing it with as many leading zeroes as is necessary.

Branch Number

  • Mandatory

  • Length should be a maximum of 5 numeric characters.

  • If the length is less than 5, then it is converted to a 5 digit number by prefixing it with as many leading zeroes as is necessary.

Account Number

  • Mandatory

  • Length should be a maximum of 11 numeric characters

  • Special characters and spaces are not allowed

Check Digit

  • Optional

  • If entered, length should be a maximum of 2 numeric characters.

  • A check algorithm is applied on the check digit.

Account Type

  • This field is labeled as Deposit Type.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 27 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Check Digit

A check digit is calculated (CD1) from the Account Number, Bank Code, and Branch Number in the following manner. This is then used as the basis for the check digit validity test.

CDI

For the check algorithm, the digits of the Account Number entered as characters A to Z. are converted to numeric values, the French government provides the following conversion table:

Value Conversion

A, J

1

B, K, S

2

C, L, T

3

D, M, U

4

E, N, V

5

F, O, W

6

G, P, X

7

H, Q, Y

8

I, R, Z

9

Example using account number A1234567890:

The letter A is converted by applying the table to 1, so the account number becomes 11234567890.

A value for CD1 is formed by joining together the bank fields in the following way:

  • The Bank Code is concatenated with Branch Number concatenated to the converted Account Number. To illustrate with the Bank Code as 12345, the Branch Number as 67890 and the converted Account Number as 11234567890. Then CD1 is created as 123456789011234567890.

  • To this concatenated value, 00 is added as a suffix and the resulting value is divided by 97. The remainder obtained as result of this division is then subtracted from 97. The result of this subtraction is the calculated check digit.

  • In our example, suffixing 00 gives 12345678901123456789000. Dividing by 97 and deriving the remainder. Mod (12345678901123456789000, 97) = 86 Subtract from 97. 97 - 86 = 11

  • If the user entered Check Digit is equal to this calculated value, then the validation is successful.

In the given example, as the user entered check digit is not 11, the check is not valid.

French Guiana

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Georgia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Germany

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, then the length should be 8 numeric characters.

Branch Number

  • Optional

  • If entered, then the length should be 8 numeric characters.

  • If the Bank Code and Branch Number are entered, then both values must match.

Account Number

  • Mandatory

  • Length should be a maximum of 10 numeric characters.

Check Digit

  • Optional

  • If a value is entered for the check digit, then it must be a single digit and must match the last digit of the Account Number.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 22 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Gibraltar

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 23 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Greece

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, then the length should be of 3 numeric characters.

Branch Number

  • Optional

  • If entered, then the length should be of 4 numeric characters.

Account Number

  • Mandatory

  • Length should be between 8 to 16 alphanumeric characters.

Check Digit

  • Optional

  • If a value is entered, then it must be one numeric character.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 27 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Greenland

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 18 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Guadeloupe

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 34 characters. Leading and trailing spaces are ignored. There should be no spaces in the middle. .

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Guatemala

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Bank Account Validation by Country: Hungary to Norway

This outlines the country-specific bank account validation rules performed in Oracle Fusion Cash Management.

The following countries have country-specific validations:

  • Hungary

  • Iceland

  • India

  • Ireland

  • Israel

  • Iran

  • Iraq

  • Italy

  • Ivory Coast

  • Japan

  • Jordan

  • Kazakhstan

  • Kosovo

  • Kuwait

  • Latvia

  • Lebanon

  • Liechtenstein

  • Lithuania

  • Luxembourg

  • Malta

  • Martinique

  • Mauritania

  • Mauritius

  • Mayotte

  • Mexico

  • Moldova

  • Monaco

  • Montenegro

  • Morocco

  • Netherlands

  • New Zealand

  • Norway

When entering bank accounts, different countries can have certain rules governing the format and content of the following related fields:

  1. Bank Code

  2. Branch Number

  3. Account Number

  4. Check Digit

  5. IBAN

Use the Disable Country Specific Bank Validations profile option to disable the country-specific validations pertaining to the bank code, branch number, account number, check digit, and IBAN. You can set this profile option at the site or user level. The profile is predefined with a default value of No at the site level. If the profile is set to Yes, these validations are not performed. The checks for unique banks, branches, accounts, and the mandatory requirement of bank account number are not affected by this profile.

Hungary

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Iceland

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, then the length should be of 4 numeric characters.

  • If the length is less than 4, then it is converted to a 4 digit number by prefixing it with as many leading zeroes as is necessary.

Branch Number

  • Optional

  • If entered, then the length should be of 4 numeric characters.

  • If the Bank Code and Branch Number are entered, then both values must match.

Account Number

  • Mandatory

  • Length should be a maximum of 18 numeric characters.

  • If the length is less than 18, then it is converted to an 18 digit number by prefixing it with as many leading zeroes as is necessary.

  • A check algorithm is applied on the Account Number.

Check Digit

  • Optional

  • If a value is entered for the check digit, then it must be a single digit and must match the seventeenth digit of the Account Number.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 26 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Account Number

  1. Check algorithm is performed against the Account Number (from digit 9 to 16). Each of these digits is multiplied with the factors as given in the following table:

Digit Factor

9th

3

10th

2

11th

7

12th

6

13th

5

14th

4

15th

3

16th

2

These products are added and the sum is divided by 11. The remainder obtained as a result of this division is subtracted from 11 to obtain the calculated check digit. If remainder is 0, then calculated check digit is taken as 0.

This calculated check digit should match the entered check digit (seventeenth digit of the Account Number), else the Account Number is not valid.

India

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

  • This field is labeled as the IFSC Code

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Ireland

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, then the length should be of 6 numeric characters.

Branch Number

  • Optional

  • If entered, then the length should be of 6 numeric characters.

  • If the Bank Code and Branch Number are entered, then both values must match.

Account Number

  • Mandatory

  • Length should be 8 numeric characters.

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 22 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Israel

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Mandatory

  • If entered, the length should be a maximum 2 numeric characters

Branch Number

  • Mandatory

  • Length should be 3 numeric characters.

Account Number

  • Mandatory

  • Length should be a maximum of 13 numeric characters.

  • Spaces are not allowed.

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 23 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Iran

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 26 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Iraq

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 23 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Italy

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Mandatory

  • Length should be a maximum of 5 numeric characters.

Branch Number

  • Mandatory

  • Length should be a maximum of 5 numeric characters.

Account Number

  • Mandatory

  • Length should be a maximum of 12 alphanumeric characters.

  • If the length is less than 12, then it is converted to a 12 digit number by prefixing it with as many leading zeroes as is necessary.

Check Digit

  • Optional

  • If entered, length should be a single alphabetic character and a check algorithm is applied on the Check Digit.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 27 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Check Digit

The check digit is used to validate against the Bank Code, Branch Number, and Account Number. These are concatenated to obtain a 22 character string.

Each character is assigned a value depending upon whether the character is in an odd position or an even position in the string as given in the following table:

Even Position Values Odd Position Values

A/0 = 0

A/0 = 1

B/1 = 1

B/1 = 0

C/2 = 2

C/2 = 5

D/3 = 3

D/3 = 7

E/4 = 4

E/4 = 9

F/5 = 5

F/5 = 13

G/6 = 6

G/6 = 15

H/7 = 7

H/7 = 17

I/8 = 8

I/8 = 19

J/9 = 9

J/9 = 21

K = 10

K = 2

L = 11

L = 4

M = 12

M = 18

N = 13

N = 20

O = 14

O = 11

P = 15

P = 3

Q = 16

Q = 6

R = 17

R = 8

S = 18

S = 12

T = 19

T = 14

U = 20

U = 16

V = 21

V = 10

W = 22

W = 22

X = 23

X = 25

Y = 24

Y = 24

Z = 25

Z = 23

The first character is an odd position. The values assigned are added up and the sum is divided 26.

The remainder obtained as a result of this division is converted into an alphabet as given in the following table:

Transformation Algorithm

Calculation Calculation Calculation

0 = A

9 = J

18 = S

1 = B

10 = K

19 = T

2 = C

11 = L

20 = U

3 = D

12 = M

21 = V

4 = E

13 = N

22 = W

5 = F

14 = O

23 = X

6 = G

15 = P

24 = Y

7 = H

16 = Q

25 = Z

8 = I

17 = R

N/A

This value should be the same as the user entered check digit or else the Check Digit validation fails.

Ivory Coast

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Japan

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Mandatory

  • Length should be 4 numeric characters

Alternate Bank Name

  • Optional

Branch Number

  • Mandatory

  • Length should be 3 numeric characters.

Alternate Branch Name

  • Optional

Account Number

  • Mandatory

Account Type

  • Mandatory

  • This field is labeled as Deposit Type.

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Jordan

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 30 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Kazakhstan

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 20 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Kosovo

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 20 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Kuwait

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

  • Length should be a maximum of 22 characters.

  • Spaces and hyphens are allowed.

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 30 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

Latvia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 21 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Lebanon

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Liechtenstein

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 21 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Lithuania

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 20 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Luxembourg

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, then the length should be 3 numeric characters.

Branch Number

  • Optional

  • If entered, then the length should be 3 numeric characters.

  • If the Bank Code and Branch Number are entered, then both values must match.

Account Number

  • Mandatory

  • Length should be a maximum of 13 characters.

Check Digit

  • Optional

  • If entered, then the length should be 2 numeric characters

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 20 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Malta

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 31 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Martinique

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Mauritania

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 27 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Mauritius

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 30 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Mayotte

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Mexico

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

  • Length should be between 10 to 11 numeric characters.

  • Spaces and hyphens are allowed.

Check Digit

  • Optional

IBAN

  • Optional

Secondary Account Reference

  • Optional

  • If entered:

    • Should be of 18 digits

    • Should be numeric

Moldova

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Monaco

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 27 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Montenegro

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 22 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Morocco

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Netherlands

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

  • Two types of account numbers are validated:

  • If the bank account number is numeric and consists of one of the following then bank account will be considered as Post or Giro Account.

    • length is 7 digits or less, or

    • prefixed with 000, or

    • prefixed with P or G

    There is no check digit validation for Post or Giro accounts.

  • For other account numbers, the length should be between 9 and 10 numeric characters. A check algorithm is applied on the Account Number.

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 18 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Non-Post or Giro Account Number

  1. If the length is less than 10, then it is converted to a 10 digit number by prefixing it with as many leading zeroes as is necessary.

  2. The Netherlands government provides the following factor table for each of the 10 digits:

Digit Factor

1st

10

2nd

9

3rd

8

4th

7

5th

6

6th

5

7th

4

8th

3

9th

2

10th

1

These are multiplied and the sum of the products is calculated 4.

If the result so obtained is perfectly divisible by 11 (that is, no remainder on division by 11), then the test is successful, otherwise the account number entered is not valid.

New Zealand

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Mandatory

  • Length should be 2 numeric characters.

Branch Number

  • Mandatory

  • Length should be 4 numeric characters.

  • This field is labeled Bank State Branch.

Account Number

  • Mandatory

  • Length should be a maximum of 8 numeric characters.

  • Account Suffix should be between 2 to 4 numeric characters.

Check Digit

  • Optional

Description

  • This field is labeled Reference.

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Norway

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

  • Length should be of 11 numeric characters.

  • A check algorithm is applied on the Account Number, if the 5th and 6th digits of the account number are not 00.

For example, for Account Number, 1234001234, the check algorithm will not be applied but for Account Number 02056439653, the check algorithm will be applied as outlined in the Check Algorithm for Account Number, following this table.

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 15 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Account Number

1. The check digit is set as the last (that is, the 11th digit) of the Account Number. For example, if the account number is 02056439653, then the check digit is set to 3.

2. The Norwegian government provides the following factor table:

Digit Factor

1st

5

2nd

4

3rd

3

4th

2

5th

7

6th

6

7th

5

8th

4

9th

3

10th

2

The first ten digits of the account number are multiplied by the associated factor. The computed sum is then calculated by summing the totals.

3. Example using account number 02056439653:

Multiply each digit with the given factor. The following table illustrates the factors that determine validation:

Digit Value Factor Result

1st

0

5

0

2nd

2

4

8

3rd

0

3

0

4th

5

2

10

5th

6

7

42

6th

4

6

24

7th

3

5

15

8th

9

4

36

9th

6

3

18

10th

5

2

10

Total

N/A

N/A

163

So the computed sum for this example is 163.

4. The computed sum is then added to the check digit. In the example, 163 + 3 = 166.

5. Divide the result by 11. 166 / 11 = 15 6.

6. Derive the remainder. 166 - (11 * 15) = 1.

7. If the remainder is '0', then the validation is successful, else the check fails.

8. In the given example, the check fails the Account Number as the remainder is 1. If the 11th digit of the Account Number was 2 (that is, the check digit would be 2), then the remainder would be 165 - (11 * 15) = 0 and the check on the Account Number would be successful.

Bank Account Validation by Country: Pakistan to the United States

This outlines the country specific bank account validation rules performed in Oracle Fusion Cash Management.

The following countries have country specific validations:

  • Pakistan

  • Palestine

  • Poland

  • Portugal

  • Qatar

  • Reunion

  • Romania

  • Saint Barthelemy

  • Saint Lucia

  • San Marino

  • Saint Martin

  • Saint Pierre and Miquelon

  • Saudi Arabia

  • Serbia

  • Serbia and Montenegro

  • Senegal

  • Seychelles

  • Singapore

  • Slovakia

  • Slovenia

  • Spain

  • Sweden

  • Switzerland

  • The Former Yugoslav Republic of Macedonia

  • Tunisia

  • Turkey

  • Ukraine

  • United Arab Emirates

  • United Kingdom

  • United States

When entering bank accounts, different countries can have certain rules governing the format and content of the following related fields:

  1. Bank Code

  2. Branch Number

  3. Account Number

  4. Check Digit

  5. IBAN

Use the Disable Country Specific Bank Validations profile option to disable the country-specific validations pertaining to the bank code, branch number, account number, check digit, and IBAN. You can set this profile option at the site or user level. The profile is predefined with a default value of No at the site level. If the profile is set to Yes, these validations are not performed. The checks for unique banks, branches, accounts, and the mandatory requirement of bank account number are not affected by this profile.

Pakistan

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed..

  • The first 2 characters are letters.

Palestine

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 29 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

Poland

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, the length should be of 8 numeric characters.

Branch Number

  • Optional

  • If entered, the length should be of 8 numeric characters.

  • If the Bank Code and Branch Number are entered, then both values must match

Account Number

  • Mandatory

  • Length should be a maximum of 16 alphanumeric characters.

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Portugal

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Mandatory

  • Length should be of 4 numeric characters.

Branch Number

  • Mandatory

  • Length should be of 4 numeric characters.

Account Number

  • Mandatory

  • Length should be a maximum of 11 numeric characters.

Check Digit

  • Optional

  • Length should be of 2 numeric characters.

  • If entered, a check algorithm is applied on the Check Digit.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 25 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Check Digit

  • A check digit is formed (CD1) from the Bank Code, Branch Number, and Account Number by concatenating the three numbers.

  • For example, using Bank Code 1234, Branch Number 5678, and Account Number 12345678901. Then CD1 is set as 1234567812345678901.

  • The Portuguese government provides the following factor table:

Digit Factor

1st

73

2nd

17

3rd

89

4th

38

5th

62

6th

45

7th

53

8th

15

9th

50

10th

5

11th

49

12th

34

13th

81

14th

76

15th

27

16th

90

17th

9

18th

30

19th

3

The nineteen digits of the created check digit (CD1) are multiplied by the associated factor. The multiple sum is then calculated by summing the totals.

Example using the value for CD1:

Digit Value Factor Result

1st

1

73

73

2nd

2

17

34

3rd

3

89

267

4th

4

38

152

5th

5

62

310

6th

6

45

270

7th

7

53

371

8th

8

15

120

9th

1

50

50

10th

2

5

10

11th

3

49

147

12th

4

34

136

13th

5

81

405

14th

6

76

456

15th

7

27

189

16th

8

90

720

17th

9

9

81

18th

0

30

0

19th

1

3

3

Total

N/A

N/A

3794

  • Divide the result by 97. 3794 / 97 = 39

  • Derive the remainder. 3794 - (39 * 97) = 11

  • CD1 is then derived by subtracting the remainder from 97. 97 - 11 = 86. So for this example CD1 = 86

  • If the calculated value for CD1 is not the same as the user entered check digit, then the check digit fails the validation. In the given example, unless the user entered check digit is 86, the validation will fail.

Qatar

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 29 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

Reunion

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Romania

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Saint Barthelemy

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Saint Lucia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 32 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

San Marino

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 27 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

Saint Martin (French Section)

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Saint Pierre and Miquelon

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Saudi Arabia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, then the length should be a maximum of 4 characters

Branch Number

  • Optional

Account Number

  • Mandatory

  • Length should be a maximum of 25 characters.

Check Digit

  • Optional

IBAN

  • Optional, if entered the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

Senegal

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 28 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

Serbia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory.

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 22 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Serbia and Montenegro

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Seychelles

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 31 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

Singapore

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Mandatory

  • Length should be 4 numeric characters.

Branch Number

  • Mandatory

  • Length should be 3 numeric characters.

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the rules following apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Slovakia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Slovenia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length cannot be more than 19 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Spain

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Mandatory

  • Length should be a maximum of 4 numeric characters.

  • If the bank code is less than 4 digits, then it is converted to a 4 digit number by prefixing it with as many leading zeroes as is necessary.

Branch Number

  • Mandatory

  • Length should be a maximum of 4 numeric characters.

  • If the bank code is less than 4 digits, then it is converted to a 4 digit number by prefixing it with as many leading zeroes as is necessary.

Account Number

  • Mandatory

  • Length should be 10 numeric characters.

Check Digit

  • Optional

  • If entered, length should be a maximum of 2 numeric characters.

  • A check algorithm is applied on the Check Digit.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Check Digit

Two check digits are calculated, CD1 from the Bank Code and Branch Number and CD2 from Account Number in the following manner; these are then used as the basis for the check digit validity test:

CD1

1. For the Bank Code, the Spanish government provides the following factor table:

Digit Factor

1st

4

2nd

8

3rd

5

4th

10

The four digits of the Bank Code are multiplied by the associated factor. The computed sum is then calculated by summing the totals.

Example using Bank Code '1234':

Multiply each digit with the given factor.

Digit Value Factor Result Digit Value Factor Result Digit Value Factor Result Digit Value Factor Result

1st

1

4

4

2nd

2

8

16

3rd

3

5

15

4th

4

10

40

Total

N/A

N/A

75

So the computed sum for this example is 75.

2. For the Branch Number, the Spanish government provides the following factor table:

Digit Factor

1st

9

2nd

7

3rd

3

4th

6

The four digits of the Branch Number are multiplied by the associated factor. The computed sum is then calculated by summing the totals.

Example using Branch Number '5678':

Multiply each digit with the given factor.

Digit Value Factor Result

1st

5

9

45

2nd

6

7

42

3rd

7

3

21

4th

8

6

48

Total

N/A

N/A

156

So the computed sum for this example is 156.

3. The computed sums from both the Bank Code and Branch Number calculations are then summed up. According to the example, it is 75 + 156 = 231.

4. Divide the result by 11.

231 / 11 = 21

5. Derive the remainder

231 - (11 * 21) = 0.

6.CD1 is then derived by subtracting the remainder from 11. If difference is 11, then CD1 is 0 and if difference is 10, then CD1 is 1 11 - 0 = 11. So for this example, CD1 = 11 = 0.

CD2

1. For the Account Number, the Spanish government provides the following factor table:

Digit Factor

1st

1

2nd

2

3rd

4

4th

8

5th

5

6th

10

7th

9

8th

7

9th

3

10th

6

The ten digits of the bank number are multiplied by the associated factor. The computed sum is then calculated by summing the totals.

Example using account number '1234567890':

Multiply each digit with the given factor.

Digit Value Factor Result

1st

1

1

1

2nd

2

2

4

3rd

3

4

12

4th

4

8

32

5th

5

5

25

6th

6

10

60

7th

7

9

63

8th

8

7

56

9th

9

3

27

10th

0

6

0

Total

N/A

N/A

280

So the computed sum for this example is 280.

2. Divide the result by 11

280 / 11 = 25

3. Derive the remainder.

280 - (11 * 25) = 5

4. CD2 is then derived by subtracting the remainder from 11. 11 - 5 = 6. So for this example CD2 = 6.

Check Digit Validity Test

The value in the user entered check digit field is compared to the calculated CD1 and CD2 using the following checks, if both of the checks are true, then the validation is unsuccessful.

Check Description

1

CD1 is compared to the first digit of the entered check digit field.

2

CD2 is compared to the second digit of the entered check digit field.

Example of the test using the previously calculated CD1 and CD2:

Where CD1 = 0 and CD2 = 6 and suppose the user entered Check Digit Value is '05'. As CD2 does not match, the check digit is invalid.

Sweden

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, then the length should be between 4 to 5 numeric characters.

Branch Number

  • Optional

  • If entered, then the length should be between 4 to 5 numeric characters.

  • If the Bank Code and Branch Number are entered, then both values must match.

Account Number

  • Mandatory

  • Length should be a maximum of 16 numeric characters.

Check Digit

  • Optional

  • Length should be a single numeric character.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 24 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Switzerland

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, then the length should be between 3 to 5 numeric characters.

Branch Number

  • Optional

  • If entered, then the length should be between 3 to 9 numeric characters.

Account Number

  • Mandatory

  • Length should be a maximum of 17 numeric characters.

Check Digit

  • Optional

Account Type

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 21 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

The Former Yugoslav Republic of Macedonia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed: IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN

  • Length should be 19 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Tunisia

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory.

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 22 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Turkey

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory.

Check Digit

  • Optional

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed, IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 26 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Ukraine

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

Branch Number

  • Optional

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 29 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

United Arab Emirates

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, the length should be a maximum of 4 characters.

Branch Number

  • Optional

Account Number

  • Mandatory

  • Length should be a maximum of 21 characters.

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 23 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

United Kingdom

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional

  • If entered, then the length should be 6 numeric characters.

Branch Number

  • Mandatory

  • It is unique within the country.

  • Length should be a maximum of 6 numeric characters.

  • If the length is less than 6, then it is converted to a 6 digit number by prefixing it with as many leading zeroes as is necessary.

  • This field is labeled as Sort Code.

Account Number

  • Mandatory

  • Length should be between 7 to 8 characters.

  • If the length is 7 characters, it is converted to 8 characters, by adding a zero as the lead or first character.

Check Digit

  • Optional

Secondary Account Reference

  • Optional

  • If entered, length should be a maximum of 18 characters.

  • This field is labeled as Building Society Roll Number.

IBAN

  • Mandatory

  • If the IBAN is not entered, a warning message is displayed, IBAN has not been entered. This bank account is defined in a country that requires IBAN for payment processing.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length should be 22 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

United States

Validation Rules

The fields are checked for validity by adopting the following rules:

Field Rule

Bank Code

  • Optional.

Branch Number

  • This field is labeled as Routing Transit Number.

  • Length should be a maximum of 9 numeric characters.

  • If the length is less than 9, then it is converted to a 9 digit number by prefixing it with as many leading zeroes as is necessary.

  • Note that on padding the number to 9 digits, the first 8 digits cannot be all zeroes.

  • For example, 001 and 000007 are invalid Routing Transit Numbers because on padding to 9 digits, they become - 000000001, 000000007, and thus having 8 leading zeroes.

  • A check algorithm is applied on the Routing Transit Number.

Account Number

  • Mandatory

Check Digit

  • Optional

IBAN

  • Optional, if entered, the following rules apply.

  • The modulus-97 rule is used to calculate the validity of the IBAN.

  • Length cannot be more than 34 characters. Spaces are removed from the left and right. Spaces in the middle are not removed.

  • The first 2 characters are letters.

  • The third and fourth characters are numbers.

Check Algorithm for Routing Transit Number

  1. The ninth digit of the Number field is used to represent the Check Digit.

  2. A calculated Check Digit is computed from the remaining 8 digits using Modulus 10 algorithm.

  3. Multiply each digit in the Routing Transit Number by a weighting factor. The weighting factors for each digit areas given in the following table:

Digit 1st 2nd 3rd 4th 5th 6th 7th 8th

Factor

3

7

1

3

7

1

3

7

  • The digits of the Routing Transit Number are multiplied by the associated factor. The computed sum is then calculated by summing the totals.

  • Subtract the sum from the next highest multiple of 10. The result is the calculated Check Digit. This should be the same as the 9th digit of the Branch Number or Routing Transit Number; otherwise the Branch Number or Routing Transit Number is invalid.

For Example:

Routing Number 0 7 6 4 0 1 2 5 Total

Multiply by

3

7

1

3

7

1

3

7

N/A

Sum

0

49

6

12

0

1

6

35

= 109

So the Check Digit = 1 (110 minus 109).

In this example, the Routing Transit Number 076401251 passes validation.