|
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.
|
