UNLOCKING THE SECRETS OF LOCKBOX

Transcription

1 UNLOCKING THE SECRETS OF LOCKBOX Cathy Cakebread Consultant ABSTRACT This presentation will provide tips for how to utilize Oracle's Automated Lockbox feature in Oracle Receivables. This paper includes: working with your bank, defining your data to Oracle, Lockbox processing flows, deciding whether the automated Lockbox is right for you. I have also included tips for getting better data from your bank and how to improve your "hit ratio." This paper is based on Release INTRODUCTION Lockbox is a service provided by banks and other service bureaus wherein your customers send payments directly to a lockbox (usually a P.O. Box) and the receipts are immediately deposited into your account. An example of a Lockbox is when you pay your home utility bills; they usually have you send your payment to a specific P.O. Box. If you have an Automated Lockbox (Auto Lockbox in Oracle terms) the bank records the information that you request such as check number, check amount, numbers and amount for the invoices to be paid. Your company receives the results of the banks keying -- usually by transmission or to your cash appliers PC. Oracle provides you with the tools to: Populate Oracle tables for the data received from the bank; Validate the data to see if it is accurate, complies with the internal controls provided by Oracle and is usable as sent; Correct the data (in several places); Create receipts; And, apply the receipts to your open invoices. A typical Lockbox transmission contains various different records, each with relevant data. Controls are provided at each level to ensure that the transmission was successful and to verify that the counts (number of records sent) and dollar amounts are consistent with what the bank indicated. These controls are at the transmission (the entire file), Lockbox (you may receive payments in more than one lockbox), batch and receipt levels. The records also contain information such as your bank account (by Lockbox) and the details for the receipts the bank received. The Lockbox may be used for checks, wires and any other receipts that you receive. You define what the data from the bank will look like and how you will use it. Copyright 2008 by Cathy Cakebread Page 1

2 Note: Auto Lockbox may not be useable for wire transfers due to the fact the content of the data usually sent by banks for these transactions is inconsistent and does not provide enough details. LOCKBOX DATA The data from the bank includes a field for "record type" that indicates the type of data to expect on this record. Oracle provides default set ups for records that comply with the BAI standards, but you may modify the layouts to meet your requirements. Typical records and (record types): Transmission Header (1) Service Header (2 - Optional) Batch Header (5) Payment (6) Overflow Receipt (4) Overflow Receipt (4) Receipt (6) Receipt (6) Overflow Receipt (4) Batch Trailer (7) Lockbox Trailer (8) Transmission Trailer (9) The header and trailer records provide the control counts and amounts and are used to verify the contents of your transmission. The receipt and overflow receipt records include the details of the receipts you are receiving and how they are to be applied (reflecting the information on the remittance advice). A receipt may have as many overflow receipt records as are necessary to provide you with all of the remittance information for example: if a single check is paying hundreds of invoices, you need lots of overflow records to contain all of the information. Note that Overflow records include an overflow sequence to insure that the records are processed in the correct order and that all applicable overflow records for a single receipt are properly identified. The default for the overflow sequence number is 2 digits but if you receive payments for more than 398 invoices on a single check you will run out of overflow sequences so you need to change this field to be 2 digits vs. the default of 2. LOCKBOX PROCESSING At a high level, the data is processed as follows: 1) Receive the data from the bank 2) Import the data into the Oracle lockbox tables Copyright 1999 by Cathy Cakebread Page 2

3 3) Validate the data to insure that it is accurate, the proper numbers of receipts are received, the amounts add up, the invoice numbers and amounts applied are valid 4) If the data is determined by Oracle to be valid the records are passed to the interim cash receipt tables 5) Run PostQuickCash to create the real receipts and apply the payments to the applicable invoices When the Lockbox data is received from the bank, you need to move it to the computer where you are running Oracle (work out a procedure with your technical support staff). Use the Submit Lockbox Processing form to "import" the data (move the data to a table within Oracle). Validation checks the data for relevance and compliance with your rules. You will generally need to run multiple validation passes until you get the data to be correct. You may correct any problems with the data using the Maintain Lockbox Transmission form. PostQuickCash creates the real receipts and applies them to the invoices. In the Submit Lockbox Processing form: 1 st Pass Import Use a standard naming convention for the directory and the files that contain the date transmitted from the bank. Watch use of capital and small letters when entering the Data File and Control File names they must be exactly correct. FIELD NAME ACTION/ENTRY New Transmission Transmission Name (List) Bank initials and the deposit date Submit Import Data File E.g., /u0/lockbox/xxmmddyy.dat (where xx is the bank and mmddyy is the deposit date) Control File name Transmission Format (List) name Alternate Name Search None Submit Validation Lockbox Complete Batches Only GL Date Allow Payment to Unrelated Invoices Report Format (List) The lockbox name The actual deposit date or the last date of the period (at period end only) NOT Checked for No (List) All Copyright 2008 by Cathy Cakebread Page 3

4 Invalid Transaction Number Handling Submit PostQuickCash Reject Entire Receipt Not Checked for No The Lockbox Execution Report will indicate if the data was imported and how the data fared in the validation. It also lists the possible exceptions and what they mean. If the data fails the import; the entire transmission fails and will need to be run again. There are different types of errors that you may encounter. If the control counts and dollar amounts are not consistent with the actual counts and amounts, you will get an error. These errors can occur at the transmission, Lockbox, batch and/or check levels. Errors at the transmission and Lockbox levels may indicate missing data in your transmission and should be investigated as soon as is possible. If there is no check number or if an invoice number provided is invalid or for a closed invoice, you will also get an error. You have different tools to investigate and correct these errors. You may use the Maintain Lockbox Transmission form (this is generally the first and primary form you will use to correct errors). Select the "Transmission Name" of the transmission you wish to fix and start your query. You will see all of the records that make up the transmission, along with the status for each record. Position the cursor on the record you wish to correct and Double Click. Correct the error on the appropriate page, and return to the first form. Move to the next record to fix and continue until you have corrected every error. Revalidate Return to the Submit Lockbox Processing form to re-run the validation: FIELD NAME ACTION/ENTRY New Transmission Not Checked for No Transmission Name (List) Bank initials and the deposit date Submit Import Not Checked for No Data File Control File Transmission Format Alternate Name Search None Submit Validation Lockbox Complete Batches Only The lockbox name - automatically filled in. Copyright 1999 by Cathy Cakebread Page 4

5 GL Date Allow Payment to Unrelated Invoices Report Format Invalid Transaction Number Handling Submit PostQuickCash Again the actual deposit date or the last date of the period (at period end only) NOT Checked for No (List) Rejects Only Reject Entire Receipt Not Checked for No Continue the cycle of correcting and validating the data until all records have been "transferred" as indicated on the Lockbox Execution Report. When all records are "transferred," they have been moved from the Lockbox tables to the tables used by QuickCash (the Interim Cash Receipt tables). If you have additional corrections to make, you may make them using the QuickCash form or wait and correct them in the Receipts form (the usual method). Since you Checked Complete Batches Only, you have not created lots of small batches, instead you have retained the batches as provided by the bank (which will make your reconciliation much easier). To create the actual receipts and apply them to the applicable invoices, use the Submit Lockbox Processing form. Select the "Transmission Name" and Check Submit PostQuickCash. You get the Post QuickCash Posting Execution Report that details how the receipts were applied and if not, why not. Return to the Submit Lockbox Processing form: Final Pass FIELD NAME ACTION/ENTRY New Transmission Not Checked for No Transmission Name (List) Bank initials and the deposit date Submit Import Not Checked for No Data File Control File Transmission Format Alternate Name Search None Submit Validation Lockbox Complete Batches Only GL Date The lockbox name - automatically filled in. The deposit date or the last date of Copyright 2008 by Cathy Cakebread Page 5

6 Allow Payment to Unrelated Invoices Report Format Invalid Transaction Number Handling Submit PostQuickCash the period (at period end only) NOT Checked for No (List) Rejects Only Post Partial Amount as Unapplied If additional corrections are needed, you may Query the batch using Receipt Batches or the Receipts screen and make the appropriate changes. Since the receipts are not real until you run the PostQuickCash process, you should strive to complete this process ASAP at least every day. Otherwise, your Collectors may be attempting to collect on invoices which have already been paid by the customers very embarrassing! Non-Accounts Receivable receipts that are received through the Lockbox will need to be changed to Type of Misc and the additional information added in the Receipts form. CUSTOMER DEDUCTIONS If your remittance advice includes customer deductions, you will need to handle them as follows: If the deduction is valid and refers to an existing credit memo, Auto Lockbox can process the credit but only if the amount is provided as e.g., If the deductions are not valid: You could create a pre-processing program to report on the actual details provided, and then strip off the deduction amounts provided. You then apply the credits using the Receipts form. If the deduction amount is offsetting an actual receipt amount, your check amount will no longer equal your applications total. You should correct as needed on the Maintain Lockbox Transmission form. You then later use the Receipts form to make the appropriate applications, utilize the credits, and create chargebacks. You need to create a procedure for handling the customer deductions. Will you create a debit memo for each deduction? And one credit memo for the total? See under Papers for a suggested procedure. You could use Oracle Trade Management (another Oracle product) to process the deductions. Copyright 1999 by Cathy Cakebread Page 6

7 PREPARING TO USE LOCKBOX There are several tasks you will need to perform before you can start using Lockbox. First, you need to work with your bank to define what data you would like to receive and how it will appear on each record. The model provided by Oracle is fairly standard and is generally a good starting point for working with the bank (see AR_TOP/bin/ardeft.ctl). Remember, you pay for EVERY piece of information that the bank keys and Oracle has certain minimal requirements for each record type (see the Open Interfaces Manual for Oracle's required fields). Ask the bank for a copy of your current layout and their typical layout. One optional field is the amount to be applied to each invoice. Though this is optional, it may provide you with better control of what is actually being applied. Tip: I highly recommend that you have the bank provide both the invoice numbers and the amounts to be applied from the remittance advice. With this information, the application will be done exactly as the customer intended and will require less re-work on your part. Tip: If the customer is passing credit memo numbers and amounts, the amount is usually negative but it must be provided with leading zeros." For instance, in a 12 digit field must be provided as " Ask your bank to provide the information accordingly. This is part of your layout definition. Tip: If you have a large number of invoices being paid with one check (more than 398), you may exceed the standard overflow sequence field which is only 2 characters long. You will need to work with your bank to expand this field. You will also need to decide if you want real or implied decimal points ( or for $100). Certain fields will be right justified (aligned to the right of the field -- usually numbers). Some will be left justified (aligned to the left of the field -- usually alphanumeric data). Watch out for items such as bank accounts and invoice numbers that are left justified, even though they are all generally numbers. Note: If all of your items continue to be created as unidentified," or you have problems with Auto Lockbox, check to be sure that you have the justification properly defined. Prior to actually going live with Auto Lockbox, you will also want your bank to provide sample files to ensure that the data you are receiving is the data you expect. Note: Banks often take 4-12 weeks to provide you with the data or with the changes that you requested, so start this step EARLY (even if you are only making small changes)! Once you have decided your layouts and banks, you need to define them for Oracle. Use the Banks form to set up your banks and banks accounts (if they don t already exist). Use the Define Lockboxes form to describe your Lockboxes, including: Copyright 2008 by Cathy Cakebread Page 7

8 The banks they are for; Whether or not you will use Auto Associate; How you want the GL Date to be determined. Usually this is the Deposit Date but you may use Constant Date if you wish to enter the date each time you run the Lockbox process. The Bank Origination Number is the actual account passed by the bank in the transmission. This value must be entered exactly as it is passed by the bank. Use the Transmission Formats form to describe the contents of each record from the bank. Note that you may use different transmission layouts for the different Lockboxes that you use. You may use the "Default" transmission format that is provided by Oracle and modify as needed, or you may define your own layouts. Use the layout from the bank to complete this information. Describe in detail each field that you will receive for each different record type, indicating: The actual starting and ending columns; If the field is right or left justified (List); The format of any dates used (List); If decimals are implied e.g., for$ (if Format Amount is Yes) or (if Format Amount is No). See the Oracle Receivables Reference Manual for more details on the possible record types and field types. Caution: If you have entered the information and realize that you need to change the starting and ending columns, you must revise in a certain way. Change the descriptions for the fields at the end of the record first, and then work your way toward the beginning of the record, saving as you change each field. This is necessary because the form has edits to ensure that you do not define overlapping fields. You need to be sure that the overflow indicator you specify is consistent with the indicator value provided by the bank. Also, the first invoice number on the overflow receipt record will be "Invoice 1" even though you may have also indicated an "Invoice 1" on the receipt record. Note that you cannot put invoice numbers and related amounts on separate records; they must be on the same record. Note: You will also need to define your layout in the SQL*LOADER control file (Oracle uses this in the import). Use a technical text editor (e.g., VI or EDIT) to create and/or change the file. Oracle provides a sample in $AR_TOP/bin/ardeft.ctl. You may use this layout or make a copy and modify as needed. This layout MUST be exactly the same as the layout you defined in the Transmission Formats form. You may have as many control files as you need to define your different Lockboxes. Note the actual name that you use and if any of the letters are capitals. This name will be used in the Submit Lockboxes form. Copyright 1999 by Cathy Cakebread Page 8

9 CUSTOMER MICR NUMBERS Customer MICR numbers are the customer bank account numbers (the funny looking numbers at the bottom of your checks). They contain two pieces: the transit routing number (the bank) and the customer s account number. MICR numbers are used by Oracle Receivables to match receipts to customers even when no invoice number is provided (if you choose to use Auto Associate see below). Oracle Receivables learns which MICR numbers belong to which customers as it does the processing. When a new MICR number is encountered, Oracle Receivables creates a record in the customer/micr number table with no customer. When a receipt is applied to an invoice, the system updates the customer/micr record with the customer id. When the MICR number is encountered again, the system already knows the customer from this record. So, the more you use Auto Lockbox, the number MICR numbers is learns. You may speed this process by using the Customers: Banks Tab to manually add the MICR numbers for your more active customers. Note that one MICR number may only be used for ONE customer. If you want the Auto Lockbox process to take advantage of your customer relationships, you need to use this region to add the MICR numbers for the parents before starting to use Auto Lockbox. Otherwise the system will assign them to the first "child" with an invoice number that matches. AUTO ASSOCIATE AND AUTOCASH Auto Associate means you want the Lockbox process to use the invoice or debit memo numbers provided to match a receipt to a customer. If the invoice number is used by more than one customer or is invalid, the receipt will be transferred as "unidentified" and you will need to correct it in the Receipts form. You indicate if you will take advantage of Auto Associate when you set up your Lockboxes (Define Lockboxes form); thus, you have the option of whether or not to use Auto Associate for different Lockboxes. AutoCash is the ability to define cash application rules for use in automatically matching receipts to invoices in Auto Lockbox. You indicate if you will use AutoCash on the Define System Parameters form. You also indicate the default AutoCash Hierarchy (the sequence in which the rules will be used) on that form. You may override the default AutoCash Hierarchy by customer, using the Maintain Credit Profiles tab. Describe your AutoCash rules using the Define AutoCash Rules form. You indicate which discounts (earned and unearned) are to be used, specify whether or not you want to include accrued finance charges, and determine if you want disputed items used in the open balance calculation. You indicate what to do with remaining amounts and whether you want automatic receipt of partial amounts. The standard AutoCash rules are: Match Receipt with Invoice; Copyright 2008 by Cathy Cakebread Page 9

10 Clear The Account Clear Past Due Invoices Clear Past Due Invoices Based On Payment Terms Apply To The Oldest First You define which of these rules and the sequence in which you want the Auto Lockbox to use these rules. Tip: I usually only use Match Receipt with Invoice." Otherwise, you may have Auto Lockbox applying the receipts in ways other than as intended by the customer (or you). ADDITIONAL LOCKBOX TIPS 1) Data that is moved from a PC may contain "^Z" at the end (this is the end of file marker and it will cause strange results in your Lockbox data). If you see this, you may need to write a script to strip off the ^Z before you do the import into Oracle. 2) If you have multiple customers whose invoices may be paid by a central location, but you have no separate customer set up as the "parent, you may want to set up a parent customer. Assign the children to the parent using the Customers: Relationships Tab and create the customer MICR record for the parent (using the Customers: Bank Accounts Tab). Then the "parent" can pay the "children's" invoices within Auto Lockbox and the other cash application forms. INCREASE YOUR HIT RATIO You may have followed all of the suggestions above but you still find that the hit ratio (number of receipts that are automatically matched to the applicable invoices) is still very low, the following may help: 1) Meet with your bank representative and discuss: a. What they are using as the invoice number? b. Provide them with examples and patterns of what the invoice numbers should look like (l like to provide lots of different examples) e.g., does the invoice number usually start with a 7? c. Ask what you can do to insure that they are keying the correct data 2) Train your customers a. Send a letter to the customers requesting that they provide the invoice number vs. the PO or order number (and provide examples) b. Request that they provide a copy of the invoice with the payment 3) Create a front end process to strip off funny data (e.g., a customer always inserts 10 before every invoice number 4) Be sure to periodically review the data you are receiving to insure that it is staying as accurate as is possible 5) Accept the fact that you will never receive perfect data Copyright 1999 by Cathy Cakebread Page 10

11 DATA CONVERSION Even if you do not use the Auto Lockbox for processing your daily receipts, you may use it to convert your historic receipts when you do your initial implementation of Oracle Receivables. Oracle provides a default SQL*LOADER control file called arconv.ctl (in $AR_TOP/bin) and a Transmission definition called CONVERT for you to use when you do this. The layouts are very basic and you do not need to create control records for the totals. By utilizing Auto Lockbox to convert your payment data you take advantage of the Oracle edits and ensure that all of the associated tables are properly populated. Note however that the GL date will be used as the apply date, so group your data accordingly. Tip: I usually convert all data in the period(s) prior to the period when we are going live. I then run the General Ledger Transfer program to mark all items as having been posted. Than, I have someone in GL delete the batch before it actually posts since it would impact the starting GL balances. Optionally, you may also create a script to update the records with the actual GL dates. Copyright 2008 by Cathy Cakebread Page 11

12 SHOULD YOU USE AUTO LOCKBOX? Given the limitations listed above, Lockbox may not be for everyone. Questions you should ask before implementing Lockbox include: How accurate is the data received from the customers? If it is usually inaccurate, you may end up re-keying most of the data. What is the volume of the data you receive daily? If low, it may be easier to enter manually. How frequently are unauthorized deductions included in the remittance advice? If it is often, you will be doing extra work. How many of your receipts are based on parent/child relationships? Will you be able to take advantage of the system capabilities? How long is the time between when you would receive the transmission and when you would receive the backup documents? How many banks do you use? Can you justify the cost for the bank charges? (You may often negotiate charges). Do you have more than one invoice with the same number? How much custom front-end work will be needed to make Lockbox work for you? If using Auto Lockbox will mean additional work and the accuracy/hit ratio will not be very high, it may be advisable to NOT use Auto Lockbox process your receipts. However, for control purposes, I always recommend that you have your customers send their payments to a Lockbox vs. to you directly. You still reports and details from the bank that you can use form manual enter of the receipts. About the Author I am an independent consultant specializing in Oracle Financials. I have over twenty nine years experience in designing, developing and implementing financial software and I was one of the original designers of Oracle Receivables and Revenue Accounting. I have assisted over 70 customers in implementing, upgrading and daily use of Oracle Receivables. You may contact me at cathyc@cathycakebread.com, or at (650) Copyright 2008 by Cathy Cakebread Copyright 1999 by Cathy Cakebread Page 12