News & Updates
PROS AND CONS OF 823 EDI PROCESSING AND THE CCP
The C/LECT ® Cash Preprocessor (CCP) is being continuously enhanced. The latest option is EDI 823 processing. The 823 transaction is created by your lockbox bank and contains your daily lockbox deposit records. It can either be sent directly to you like your current lockbox file or through your VAN (Value Added Network).
Until this summer, all of our clients have been receiving their lockbox data in BAI format. Although BAI has a basic format, some of the specific fields vary in length such as check number, routing and transit number, demand deposit account number and check amount. The data received is limited to 68 characters which limits the keying of additional data at the item level.
One new client is using our Enhanced Bank Data Keying Option of the CCP. The bank keys the invoice number and net and discount amounts for each item. The bank also keys postmark date at the check level. They decided to have the bank send the lockbox data in 823 format so that the data could be expanded if needed. This proved to be an excellent decision because keying of an additional location field has been included for selected accounts to identify deductions to the correct bill-to account. This can now be done without a major revamp of the format.
Your EDI group can receive the bank’s 823 data and using a single map, format the data to our specifications. The CCP then brings in the data as a standard input file along with EDI 820, OCR scanner data, powerkeyed items and proprietary formatted files for automated application.
Using the 823 bank input, the CCP:
– Identifies the cash using MICR or invoice numbers;
– Matches the items to invoices, credit memos and adjustmentsusing customized lookup routines;
– Creates specific reason code adjustments based on a Customer Level Adjustment;
– Directs open debit memos to the correct bill-to account by cross-referencing the location fields.
There are two short comings with this format. Except for the bank transmission variations and expanded data keying options the 823 offers, there is no advantage to using this format. The banks are pushing it, probably more for their own portfolio (i.e.,”Yes we can handle 823 formats!”). We have also experienced an unusual result – the bank occasionally passes lower case alpha characters in the invoice number field, which is then passed to the A/R system, causing various problems. This has never happened with the BAI feeds. It appears that the BAI format has more stringent internal edits than the more flexible 823 format.
We at C/LECT ® advise, “If it works, don’t fix it.” However, if you need expanded bank data keying, or if you are starting up a new lockbox feed and you are EDI capable, consider using the 823 format.
ENHANCED BANK KEYING AND THE CASH PREPROCESSOR
The C/LECT ® Cash Preprocessor (CCP) has taken an exciting turn! By having the bank data key additional information beyond invoice number and net amount, the CCP can accurately create adjustments and place them on the proper account in your A/R system! All behind the scenes and for less money then you might expect. Let me tell you how.
Most large organizations already receive A/R deposits through the BAI format. Normally an A/R system can automatically close 25% to 40% of the items. In most cases, the accounts are either too large or there are adjustments which render the autocash routines useless. With C/LECT?s algorithm, statement and consecutive days processing options, we have reached application rates of 75% receiving only the MICR number and check amount from the bank.
By having the bank data key invoice numbers or invoice numbers and net amounts, we have achieved hit rates as high as 95% and can make some adjustments based on the short payment or deduction amounts.
Now the CCP, using customer tables (either stored on the parent customer or on spreadsheets uploaded to your system), can look for prefixes or suffixes on the keyed item and set up the adjustment. For example, the bank may key “DMG123456 – 874.32″. The CCP will know the account this is for and check the parent table. If there is a prefix of “DMG” which equates to “Damaged Goods ? Returned”, the CCP can then handle the adjustment appropriately, either writing off or charging it back, based on your own rules and reason codes.
The CCP can also use a prefix or suffix to assign an account number. For example, an “SF” prefix or suffix on an item could mean “San Francisco”, which equates to a specific customer. This logic can also be used for broker codes.
The CCP can also use combinations of these, so “CPN123456DM” is a coupon adjustment set up on the Des Moines account.
With some remittances, a location field must also be coded, along with the invoice/adjustment number. This can be used in a similar manner to assign the adjustments to a specific account or broker. Additionally, discount amount can be keyed by the bank so that accurate deductions can be made regarding discounts and short payments. The bank can also key the postmark date to accurately handle unearned discounts.
You can set up a separate lockbox to handle only the new bank keying requirements and move the accounts to the new lockbox that you want handled this way (following the 80/20 rule). For most customers, the keying costs of the bank (normally 0.5¢ to 1.5¢ per key stroke) easily offsets their manual application costs.
The CCP can also process the EDI 823 format, which banks can use instead of the limited BAI format. This will give you unlimited keying options from the bank and the CCP passes all deduction information to your A/R system automatically.