16 Define Cash Management and Banking Configuration

This chapter contains the following:

Creating Accounts: Points to Consider

Parse Rule Sets: Overview

Transaction Type Mapping: Overview

Tolerance Rules: Overview

Reconciliation Matching Rules: Overview

Reconciliation Rules Sets: Overview

Creating Accounts: Points to Consider

Banks, branches and accounts fit together on the premise of the Bank Account model. The Bank Account model allows you to define and keep track of all bank accounts in one place and explicitly grant account access to multiple business units, functions, and users. Consider the following when you set up bank accounts:

Assigning a unique general ledger cash account to each account and use it to record all cash transactions for the account. This will facilitate book to bank reconciliation

Granting bank account security; bank account security consists of bank account use security, bank account access security, and user and role security.

Account Use

Account use refers to accounts created for Oracle Fusion Payables, Oracle Fusion Receivables and Oracle Fusion Payroll. When creating an account to be used in one or more of these applications you must select the appropriate use or uses.

Account Access

Payables and Receivables account access is secured by business unit. In addition to selecting the appropriate application use or uses, one or more business units must be granted access before the bank account can be used by Payables and Receivables. Only business units who use the same ledger as the bank accounts owning legal entity can be assigned access

User and Role Security

You have the option to further secure the bank account so that it can only be used by certain users and roles. The default value for secure bank account by users and roles is No. In Payables and Receivables even if the secure bank account by users and roles is no, you must have the proper Multi-Organization Access Control (also known as MOAC) to access a bank account. If the secure bank account by users and roles is set to Yes, you must be named or you must carry a role that is named expressly on the bank account in order to use it.

Note

The security role Bank and Branch Management Duty is used to set up banks and branches.

The security role Bank Account Management Duty is used to set up accounts.

Parse Rule Sets: Overview

Oracle Fusion Cash Management supports parse rule sets to transform data during the bank statement import process. Parse rules are used to move data from one field to another. The parse rule set is associated to a bank account in the bank account setup and is most commonly used to parse data from the statement line addenda field into more specific statement line fields. Each parse rule within a parse rule set consists of the following fields:

Sequence - determines the order in which to process the rules

Transaction Code - the code used to determine the statement line type

Source - the interface table field that contains the data to be parsed

Target - the statement line field that the data will be parsed to

Rule - contains the syntax for determining the data within the source field that will be parsed

Overwrite - used to control whether to overwrite existing data in a target field or skip parsing the data

The parse rule syntax is described below:

[LITERAL](<[MATCHING TOKEN],[START-END]>)[LITERAL]

Where

LITERAL = A string or character value represented by an identifier that should match the source data exactly.

MATCHING TOKEN = A token (or set of tokens) which describes the data to extract. Valid tokens are:

N = Extract a valid number
. = Decimal position
X = Extract an alpha numeric
~ = Extract everything in the source field from the parse position to either the end of the data or up to the next literal.
START = A position to begin extracting data, offset by the parse position. It must be a valid numeric.
END = A position to stop extracting data. END can be either a valid numeric or the ~ token.

Listed in the table below are some examples:

Description	Source Data	Rule	Target Data
Extract numeric rate data from a source field	EST/TRX RTE 3.76 USD/LIBOR CPTY: PRU	RTE (N.NN)	3.76
Extract a rate type from a source field	EST/TRX RTE 3.76 USD/LIBOR CPTY: PRU	(XXXXX)	LIBOR
Another way to extract a rate type from the same source field	EST/TRX RTE 3.76 USD/LIBOR CPTY: PRU	/(X~) CPTY	LIBOR
Extract the currency from the same source field using positional matching.	EST/TRX RTE 3.76 USD/LIBOR CPTY: PRU	RTE(7-9)	USD
Extract the counterparty of an unknown string length from the same source field	EST/TRX RTE 3.76 USD/LIBOR CPTY: PRU	CPTY: (X~)	PRU

Transaction Type Mapping: Overview

The transaction type mapping allows you to associate a cash transaction type to a system transaction. To create this association payables and receivables payment methods and payroll payment types can be mapped to cash transaction types. Assigning cash transaction types to application transactions can be helpful for bank statement reconciliation. Bank statement lines are also associated with cash transaction types and matching rules can be created using this common attribute.

Tolerance Rules: Overview

Tolerance rules allows you to specify date and amount tolerances, that prevent or warn you when reconciliation would be a breach of a defined tolerance. Amount tolerances are most often used when reconciling foreign currency transactions where there may be differences due to rounding or fluctuations in the exchange rate. They can also be used if a bank includes a processing fee in the bank statement line amount. Date tolerances are primarily used for checks that may be issued on one day and not clear the bank until days or weeks later. By applying tolerances you can automate the reconciliation and accounting for these types of transactions. If no date or amount tolerance is defined within a rule, it requires an exact match. For manual reconciliation, a tolerance rule can optionally be assigned to a bank account. For automatic reconciliation, a tolerance rule can be associated with a matching rule in the Rule Set setup and can be applied if the matching rule matches on date and amount or both. The one exception occurs when you assigns a tolerance rule that includes amount tolerances to a non one to one match type matching rule. In this non one to one match, the amount tolerance is ignored and amounts must match exactly.

Date Tolerance

Reconciliation date tolerances are defined as day ranges. The date tolerances are to validate that the source transaction date or dates are within a certain number of days before and after the bank statement line date or dates.

In manual reconciliation, if a date tolerance is specified in the tolerance rule assigned to the bank account it applies to all matching scenarios. In the event of a date tolerance breach, a warning message is displayed, but the user is allowed to reconcile the statement line or lines and the transaction or transactions. If no date tolerance is assigned or specified it is required to be an exact date match and a warning message is displayed.

In automatic reconciliation, a tolerance rule that includes date tolerances can be associated with a matching rule. If the matching rule matches on the date, then the date tolerance is applied. In this scenario a date tolerance breach prevents reconciliation.

Amount Tolerance

Reconciliation amount tolerances can only be used in one to one matching scenarios for both manual and automatic reconciliation. No reconciliation amount tolerances are allowed in one to many, many to one, or many to many matching scenarios. In these scenarios the amount of the bank statement line or lines must be equal to the amount of the transaction or transactions. Reconciliation amount tolerances can be defined as percentage or amount ranges or both. If both percentages and amounts are applied, the application uses the most conservative tolerance depending upon the statement line amount. For example, if the amount tolerance equals plus or minus $5, the percentage tolerance equals plus or minus 1%, and the statement line amount is $100, the application first calculates the percentage amount (1% of $100 dollars = $1). It then compares this to the $5 amount and uses the smaller amount. In this case it is $1 dollar, so to reconcile a transaction to this line it must be between $99 and $101.

In automatic reconciliation, a tolerance rule that includes percentage, amount, or both types of tolerance ranges can be associated with a matching rule, but the tolerance will only be applied if the matching rule is a one to one match type rule. In this scenario of a one to one type match, any amount difference within tolerance is automatically created as an external transaction in cash management.

Reconciliation Matching Rules: Overview

Matching rules allow you to determine how to match bank statement lines and system transactions, and help to achieve a higher match rate in automatic reconciliation, minimizing the need for manual intervention. You define bank statement automatic reconciliation matching rules and assign them to bank statement automatic reconciliation rule sets.

As part of each rule, you specify the following:

Transaction source or sources
Match type: one to one, one to many, many to one, or many to many
Group by attributes for bank statement lines or system transactions, depending upon match type
Matching Criteria: Includes a list of commonly used matching attributes. You can simply check the attributes to include in their matching rule.
Advanced Matching Criteria: Allows you to specify additional matching logic or filtering conditions that must be true for the bank statement line or lines and transaction or transactions to be matched successfully.
- Only group by and amount fields should be used for matching if grouping is used.

You can select one or multiple transaction sources in a rule. If multiple sources are selected in a one to one or many to one matching rule, then the autoreconciliation program looks for a matching transaction across the selected sources. If multiple sources are selected in a one to many or many to many matching rule, then the program first finds all available transactions across the selected sources and then applies grouping rule to the whole data pool. This means that statement lines can be reconciled to a group that includes transactions across the different sources. If you want transactions included in a group to be from the same transaction source then you can specify Transaction Source as a grouping attribute.

Reconciliation Rules Sets: Overview

Bank statement reconciliation rule sets are a group of matching rules and tolerance rules. They are assigned to a bank account and used to reconcile bank statement lines with transactions. You build the rule set and the rule set detail as a parent-child relationship. Each rule set consists of one or more matching rules that can be prioritized or sequenced. The rules should be ordered to achieve a greater reconciliation success rate. It is strongly recommended that one to one rules be sequenced above rules of other types. To provide an optimum reconciliation rate, you should change the sequence number depending on how accurately the given rule is likely to reconcile against the correct bank transactions. For example, transactions from sources for which the bank provides you a reference ID are likely to have a higher reconciliation rate. These rules should be placed at the top with a lower sequence number. Conversely, transactions with no reference ID are likely to have duplicates or lower reconciliation rates, and you should place them at the bottom with a higher sequence number.