USING ORACLE SOA SUITE AND CASH MANGEMENT WITHIN A COMPLEX BANKING ENVIORNMENT

Colleen Roden Oregon Health & Science University Leslie Marti Impac Consulting Introduction
Oregon Health & Science University (OHSU) is Oregons only health and research university and is the largest employer in Portland, OR with over 13,000 employees. With a projected operating budget for 2012 of over $2 billion, OHSU brings together patient care, research, education of the next generation of health care providers and scientists and community service to improve the health and well-being of all Oregonians. OHSU has over 200 cash service sites supporting the diverse needs of the university, hospitals and clinics which include: Schools of Medicine, Dentistry, Nursing and Science & Engineering Doernbecher Childrens and OHSU Hospitals Dozens of primary and specialty care clinics Major research institutes Each of the distinct business models process funds from many sources such as patient billings, insurance payments, grants, miscellaneous departmental receipts, student tuition payments, parking receipts, payroll and supplier payments just to list a few. Funds can be in the form of cash, checks, wires, ACH, lockboxes, credit cards and online payment processors. OHSU requires multiple transactional systems to support these processes which include Oracle eBS, EPIC and Banner. In 2011, OHSU recognized the need to address the complexity facing the organization and funded a project to streamline the cash management systems, processes and procedures.

Goals of Project
The goals of the OHSU Cash Management project focused on three main themes: Streamline the bank reconciliation processes Promote effective resource utilization Increase visibility to cash Streamline bank reconciliation processes: Prior to the introduction of the Cash Management project, OHSU was only using the Oracle Cash Management module to automatically reconcile the Oracle Accounts Payable checks. This reconciliation only represented a portion of one of many bank accounts. All other accounts were reconciled manually or through the use of an access database. One goal of this project was to integrate the additional transactional systems, both Oracle and nonOracle, with the Oracle Cash Management module to centralize and automate the bank reconciliation processes.

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

Promote effective resource utilization: As with many organizations, OHSU is looking to do more with less. One key goal of this project was to automate as many manual processes as possible to free up resource time to focus on analysis and exception resolution. Many processes related to cash were not automated. In addition to manual bank reconciliation processes, users were performing additional manual activities such as downloading and uploading bank statement and positive pay files, recording bank transfers and sweeps through manual journal entries and recording bank fees through manual journal entries. Increase visibility to cash: With the volatility in todays market place, OHSU was looking for better tools to analyze the daily cash position across all accounts to take advantage of short term investments as well as long term cash forecasting.

Bank Structure Overview

The bank structure at OHSU consists of many accounts that capture the daily cash transactions. Nightly, these accounts swept to/from a master account, a typical zero balance account structure. The master account also has daily activity such as non ZBA transfers, interest wires, and ach transactions that originate from all transactional systems. The funds from this master account are swept out each night to an overnight investment account and deposited back into the account the following day. Each of the child accounts are defined for a specific purpose, The controlled disbursements account captures outgoing cash, primarily checks from the Oracle Accounts Payable system, but also include student refund checks processed though the Banner Student system. The payroll account funds the payroll activity for both the hospital and the university. The receipts account captures incoming funds for the university activity and is structured with subaccounts that identify the deposits from cash intake sites, called service sites.. This account is funded from transactions that originate in both Oracle Accounts Receivables and the Banner Student system.

Figure 1

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

Challenges
The above bank structure presented some immediate challenges. As you can see from the diagram above we had several non-Oracle sources that needed to feed cash management. Therefore, we have multiple systems that feed one bank account in Cash Management. Being a health education institution we often had one large payment from government agencies that need to be applied to transactions that reside in multiple source systems. E.g. an AR invoice in Oracle, and a Student Receivable in the non-Oracle system. Another immediate challenge was the transaction detail in the source systems did not match the bank statement detail. E.g a single receipt entered in Oracle for our commercial deposit departments were made up of checks, cash, and credit card transactions. The bank statement file used for reconciliation contains a record based on how the transaction is deposited. Credit cards transactions are deposited as a single line per terminal settlement, while cash and checks are grouped together into a single deposit. In addition, we found issues with reference information used to match transactions missing in both the source system as well as the bank statement file. To add to the complexity we discovered issues in the timing of when the deposits reached the bank from when the receipts were entered into the source systems. Credit card terminals settled automatically each night, however each department may have waited several days before providing the information to be entered into the source system. We also discovered the Oracle organizational setup did not support the reconciliation of Oracle Payroll transactions with Cash Management. To use Oracle Payroll with CM the Business Group organization also must be the LE and OU organization and our structure was setup with three individual organizations.(BG, LE, OU). Therefore, we had to consider Oracle Payroll an outside source for Cash Management activity. And lastly, we had several manual processes in place that we knew needed to change. We manually downloaded the bank statement file daily, but it only included the AP disbursement account. Bank fees and Daily ZBA transfers were recorded at the end of the month usinga manual journal entry.. Since we wanted the bank statement reconciliation was to become a daily process, we would did not have transactions to match to until the end of the month.

Approach
The majority of the effort of the project focused on the first goal, streamlining the bank reconciliation processes. Automating the bank reconciliation was not as easy as just loading the additional bank statements into the Oracle Cash Management module because the majority bank lines for incoming cash would have never automatically matched to transactions. In order to automate the matching process, we went through the following steps: 1. Identified all cash inflow/outflow transactions for each account and mapped to standard BAI bank codes: (e.g. checks, credit card settlements, cash & check deposits, coin currency purchases, wires, incoming/outgoing ACH, ACH returns, NSF returns, lockbox, account transfers, bank fees, bank adjustments etc.) Identified the source transactional system for each bank transaction identified in step 1. Compare the system transactions to the detail information provided in the bank statement files to determine any issues with grouping, timing or missing reference information that would prevent automatic matching. (e.g. third party payment processors depositing net of fees, AmEx card transactions deposited separately than remaining credit card settlement, bank not providing any unique reference number for credit card deposits etc.) Identified any system configuration or process changes needed to support automated matching. This could include items such as grouping checks and cash as a single deposit and recording deposit slip information, identifying a common reference number between the bank and transaction system for credit card settlements or NSF. Changing Receipt Methods in Oracle Receivables to support remittance setup. Identify any additional reference information missing from bank statement files to support automated matching. (e.g. missing deposit slip number, missing check number on NSF, missing subaccount detail etc.) Identified any bank transactions in step that could be automated using Oracle Cash Management functionality such as the recording of ZBA sweeps and recurring bank fees.

2.

3.

4. 5.

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

Once all of the relevant information was identified we were able to move forward with solutions to automate the reconciliation process for additional bank accounts as well as automate some manual processes.

Solutions
Automating Bank Statement Reconciliation Process: Once the source system transactions had been mapped to bank codes and rules had been defined to determine how transactions would be identified between the bank and the source system, we were able to implement a solution. The solution required several steps: 1. Utilize the Cash Management open interface process to integrate our non-Oracle transaction systems and Oracle Payroll with the bank reconciliation process. Utilized PLSQL and SOA processes to transform data and load into Oracle interface tables. a. The Cash Management open interface utilizes a view CE_99_Interface_v that we modified to utilize custom Oracle tables that contain the transaction data from the source systems. Our custom tables were designed to capture batch, transaction and transaction detail as needed for reporting and referencing back to the source system, while the view only utilized the transaction level information as required by the open interface process. Bank code setups were modified to look to the correct sources for reconciliation. (e.g. open interface, Oracle Receivables, Oracle Cash Management, Oracle Payables etc) Bank code transactions that need to look to the open interface as well as an Oracle system were defined for the multiple sources.

b.

c.

Open interface controls must be defined in the bank account setup for each bank account that utilizes the open interface for reconciliation. You must have open interface defined and must define a float and clear status that match the values in the interface view. This tells Oracle that it should look to the open interface as an additional reconciliation source. You also determine the matching criteria, transaction number or amount, which determines how the bank reconciliation process will try to match to a transaction.

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

2.

Implemented configuration and process changes in Oracle Accounts Receivable and non-Oracle systems to facilitate automatic matching of transactions to bank statement lines: a. Used receipt methods and descriptive flexfields on the receipt methods to capture the bank subaccount that the cash service site deposits into as well as identifies the tender types such as cash, check and credit cards.

b.

Introduced the Oracle remittance batching process to group cash and checks into a single deposit as well as credit card transactions into a single settlement.

c.

Introduced receipt naming standards to identify transactions. Utilized the deposit slip # on remitted batches and on the receipt number for commercial deposit. For commercial deposit credit card settlements used the merchant id number.

3.

Implemented changes to the bank statement mapping definitions to capture changes to the bank statement files provided by the bank

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

4.

Implemented SOA processes to communicate with the bank to automatically retrieve bank statement files and to upload positive pay files. a. b. Established bank as a trading partner in B2B Connect to the bank via SFTP to retrieve previous day transaction file for reconciliation and to send positive pay files

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

5.

Utilize SOA processes to transform the bank statement data to populate transaction, reference and account information used for automatic matching. a. Calls concurrent processes to load bank file into the statement interface tables

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

b.

Use business rules to map key data from previous day file to transaction and reference fields used in the statement interface

c.

Use fault policy framework to handle common system errors across SOA composites

Automating Manual Processes Bank Transfers and Cash Flows: The Oracle Cash Management module provides functionality to automatically create bank transfers for ZBA sweep transactions between parent and child bank accounts from the bank statement lines. In addition, you can create manual bank transfers for non-ZBA transfers between bank accounts. Both types of transfers generate the journal entries to move the funds from one GL cash account to the other, eliminating the need to generate manual journal entries for these activities. In Oracle Cash Management a bank transfer is a transfer of funds between two bank accounts, on the same day and for the same amount. A bank transfer creates a cash flow and a cash flow is reconciled to a bank statement line. A bank transfer creates a debit/credit to the bank GL accounts when each side of the transfer is reconciled or cleared, and uses intercompany accounting as the offset. Once all transfers are either reconciled or cleared, the net effect to the intercompany account is zero. To setup a Bank Transfer you must first grant the responsibility performing the transfer or creating the sweep access to bank transfers. This is done in the User Management responsibility, Roles and Inheritance Page. The access is granted by Legal entity. If you do not grant this access you are not able to create bank transfers.

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

The next step is to setup a Cash Pool. This is how Cash Management knows what accounts have a ZBA or Sweep relationship. The Cash Pool type must be Physical and bank initiated Sweep set to Yes. Create a Cash Pool name and assign the Parent Account

Figure 2

Add the Subaccounts to the Parent account (these are the children accounts)

Figure 3

The bank statement file should indicate which transactions are ZBA/Sweep transactions by bank code. You must setup a bank transaction code for these types of transaction. The type is a sweep in or a sweep out and the Source must be set to Cash Management. This mapping tells oracle that this bank statement line should have a bank transfer created.

Figure 4

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

And finally, you need to setup Intercompany balancing rules for Source Cash Management and Category Bank Transfers (1)

Figure 5

To complete the setup of the bank transfer, the bank statement file needs to provide the bank account number for the corresponding transfer in the Agent Bank Account field. When the Agent Bank Account field is populated this tells CM which bank account has the other side of the sweep.

Figure 6

Once the bank statement file has been imported into Oracle Cash Management, run the Sweep Transaction Generation concurrent process to create the bank transfers. This process creates a bank transfer and a cash flow. The cash flow will be available for reconciliation to the bank statement line and will automatically reconcile when the AutoReconcilation process is run for the accounts.

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

10

Cash flow

Figure 7

Cash flow line is now available for reconciliation to the bank statement line.

Figure 8

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

11

In addition to using Bank Transfers we utilized the Bank Statement Cash flow mapping. Setup>Banks>Cash Flow Statement Mapping This mapping creates a cash flow in Oracle Cash Management that can be reconciled to the bank statement line that it was generated from. A cash flow mapping uses the bank code and search criteria to generate a GL entry to the account string defined on the Cash flow Mapping form. Cash flow mappings are very specific to the string that is provided in the bank statement, therefore, if you have a string that is constant except the reference number you can substitute constants with %. The spacing and placement of the % must be exact to the string in the bank file. For Example: The Bank file has this text string. PROGRAM 12345 COMMERICAL PAPER SWEEP INTEREST 0515 IMMEDIATE PROGRAM%COMMERICAL PAPER% (this wont work because it isnt the complete string) It must be done like the string below for the CM to recognize the string.

Figure 9

Implementation Challenges As with many system implementations, OHSU encountered system and process challenges that we have or are in process of resolving. Some of these challenges include:
OHSU manually records wire payments to vendors in Oracle Payables which automatically generates a document number similar to a check number. This number does not match any wire number or information provided by the bank to be used for matching. We are currently manually matching wire transactions to bank statement lines. The ACH transactions generated from Oracle Payables do not match to the level of detail recorded in the bank. The bank transaction is recorded as one transaction for the total amount of the batch, while Oracle records each individual transaction. Oracle doesnt automatically match to the total of the batch a mount like it will for batched deposits in Oracle Receivables. We are currently manually matching a single bank statement line to multiple ACH payments. When we receive an NSF for a check recorded in Oracle Receivables we reverse that receipt. If this receipt was included in a remittance batch as a deposit, and that remittance batch had not previously been reconciled, then the amount available to reconcile of the remittance batch is reduced by the NSF amount, preventing us from being able to reconcile the remittance batch correctly. We currently have an SR open on this issue and are waiting for a response from Oracle.

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

12

We are currently working to address similar changes to additional bank accounts so we can include the accounts in the automatic reconciliation process. One of our systems is not current integrated with Oracle Cash Management so we reconcile receipts from this system as External. On occasion a single wire receipt may need to be applied against transactions in both Oracle and this external system. In these cases, if we only match the portion of the wire to the Oracle receipt it leaves the available amount to reconcile outstanding and we cannot match the remainder as External. Currently there are no reports to monitor the cash flow and bank transfers created in Oracle Cash Management. It is critical that bank transfers are cleared or reconciled in the correct period to record the journal entry to move the funds in the GL. Reconciling or clearing the transfers is what generates the journal entry as is based on the GL date of the reconciliation. We are currently in process of developing reports to help users verify that transfers have been cleared and recorded in the GL. On occasion, users have forgotten to approve a remittance batch. Remittance batches are not available for reconciliation until approved. Users can use the Remittance Batch Management Report report to identify the status of the remittance batches. There are many different reasons that bank lines do not match to system transactions. These reasons can include bank errors such as incorrect check number, ACH returns, detail in the transaction system doesnt match detail from bank, credit card settlemen ts dont match transactions recorded in transaction system. In order to address many of these issues we find you must match a bank statement line to multiple transactions and other bank statement lines to net to the total amounts. We found that the frequency of these adjustments required us to setup two new bank codes that we use to match to bank statement lines. We called these codes PADJ for Misc Payment Adjustments and RADJ for Misc Receipt Adjustments. These codes were defined with matching criterion that allowed them to be match against MISC transactions as well as against bank statement lines. Only codes that have matching criteria against the statement can be used to net a statement line to transactions. Some of the conditions we use this process for include: o An individual receipt recorded in Oracle Receivables needs to match against multiple bank lines. This may occur when the AmEx portion of a settlement are deposited at a different time than Visa transactions. You cannot match multiple bank lines to a single receipt. When an ACH return is processed in the bank, Oracle Payables requires that ACH transaction to be voided, but you cannot reconcile a voided transaction if the reconciliation controls are set to exclude voided transactions. You can use the above process to net any newly processed ACH to the original ACH statement line to net the amount. Misc sweep transactions within same account due to bank entry errors. Occasionally the bank does not record check transactions in the controlled disbursements account correctly to do keying errors. In these cases they have recorded a sweep in and a sweep out transaction in the controlled disbursements account without corresponding sweeps in the general account. The transactions on the bank statement do not have any matching transactions in a source system so the bank lines are reconciled against one another.

COLLABORATE 12

Copyright 2012 by Colleen Roden OHSU and Leslie Marti Impac

13