[EDI-L Mailing List Archive Home] [Message List] [Reply To This Message]

RE: Purpose of the 820

From: "Bill Morey" <bill.morey@...>
Date: Tue Jun 21, 2005  12:30 am
Subject: RE: [EDI-L] Purpose of the 820
Gina,

Here is my Financial EDI 101 (jammed into as small of a nutshell as I am
able).

There are a few items to be aware of regarding the ACH Network and X12
Transactions like the 820 (or 835 for Health Care):

The ACH Network only pass data formatted according to the ACH Rules of
the National Automated Clearing House Association (NACHA).

There are 5 basic components to the ACH Network;
1)"Originator" (Company A),
2)"ODFI" - Originating Depository Financial Institution (Bank A),
3)"ACH Operators" (Data Processors that pass NACHA formatted data
between each other),
4)"RDFI" - Receiving Depository Financial Institution (Bank Z),
5)"Receiver" (Company Z).

Virtually all Financial Institutions can accept and process ACH
transactions. If they can't they are likely to have a correspondent
Financial Institution that can & will process ACH transactions for them.

Not all Financial Institutions can or will handle native X12
transactions, but those that do will usually charge a premium to
re-format the incoming 820 into an ACH transaction (or vice-versa from
ACH to outgoing 820).

In general, you will want to keep the data in a format as close to the
original as possible. For example, if your Accounting application
creates or imports ACH natively, stick with that, unless there is a
reason to switch (like you have already purchased the EDI translator
that your Trading Partner has mandated).

ACH Transactions are primarily intended to move dollars, X12
Transactions are primarily intended to move data. In order for data and
dollars to move together through the ACH Network, the X12 must be
'wrapped' inside of an ACH Transaction. An ACH Transaction format is
called a "Standard Entry Class".

ACH files are made up of the following records (Record Type is indicated
by the first two positions of the record). All ACH Records are 94 bytes
in length:
"01" - File Header Record (Contains Originator or Receiver information)
"05" - Batch Header Record (Contains Trading Partner account
information)
"06" - Entry Detail Record (Contains Individual Payment information)
"07" - Addenda Record - optional (Contains 80 characters of Payment
related additional information)
"08" - Batch Trailer Record (Closes the batch for the corresponding
"05")
"09" - File Trailer Record (Closes the ACH file for the corresponding
"01")
"99" - Filler (Added to block the file in 10 record blocks)

Two ACH Standard Entry Classes are used for sending X12 related
information through the ACH Network. They are the Corporate Trade
Exchange "CTX", and the Cash Concentration and Disbursement (plus
addenda) "CCD+".

The CCD+ has one Entry Detail Record with the payment information, and
one Addenda Record with enough of the X12 data to facilitate a
'reassociation' of the ACH payment and the X12 820 Remittance Advice.

The CTX has one Entry Detail Record with the payment information, and up
to 9,999 consecutive Addenda Records which hold the original X12 820
broken into 80 character chunks.


Here are several issues to consider when deciding whether or not to
send/receive 820s to/from the bank:

Are you mostly an originator, or a receiver?
Do you already originate or receive ACH, X12, either, or neither?
Do you have skilled in-house programmers?
Do your bank balances off-set your account analysis charges enough to
cover any Financial EDI expenses?
Can your Bank handle X12 correctly, Do they support the same X12 version
as you need?
Can your Trading Partner handle ACH, X12, either, or neither?

In relation to your individual answers to the above questions, here are
a few possible pathways:

If you are the Originator:
1) ACH (CCD+) to ODFI, 820 to Trading Partner; This requires that your
Trading Partner maintain a process to 'reassociate' the ACH data to the
820 on the receiving end. This is usually the cheapest way as far as
ACH charges, [Monthly ACH origination Fee; 1 Entry Detail, 1 Addenda
Record]
2) ACH (CTX) to ODFI; Data and dollars stay together. Does not require
reassociation by TP, but you pay the bank for the Entry plus each ACH
Addenda Record. [Monthly ACH origination Fee; 1 Entry Detail, minimum of
12 Addenda Records (based upon a 1KB 820)]
3) X12 (820) to ODFI, 820 to Trading Partner; ODFI makes CCD+ from 820,
discards rest of 820 into 'bit bucket'. You pay the bank to create your
ACH entry. [Monthly ACH origination Fee; Monthly EDI Services Fee; 1 EDI
Translation Fee, 1 Entry Detail, 1 Addenda Record]
4) X12 (820) to ODFI; ODFI makes CCD+ from 820, sends full 820 on to
your Trading Partner on your behalf. You pay the bank to create your
ACH, plus you pay additional fee for the bank to act as a VAN. [Monthly
ACH origination Fee; Monthly EDI Services Fee; 1 EDI Translation Fee, 1
Entry Detail, 1 Addenda Record; Monthly VAN Connection Fee, 1 VAN
Transaction Fee]
5) X12 (820) to ODFI; ODFI makes CTX from 820, Data and Dollars stay
together, You pay the bank to create your ACH entry, plus fees for ACH.
[Monthly ACH origination Fee; Monthly EDI Services Fee; 1 EDI
Translation Fee, 1 Entry Detail, minimum of 12 Addenda Records (based
upon a 1KB 820)]

If you are the Receiver:
1) ACH (CCD+) File from RDFI, 820 from Trading Partner; [Monthly ACH
receiver Fee; 1 Entry Detail, 1 Addenda Record]
2) ACH (CTX) File from RDFI; [Monthly ACH receiver Fee; 1 Entry Detail,
minimum of 12 Addenda Records (based on 1KB 820)]
3) ACH (CCD+) File from RDFI, 820 from Trading Partner's Bank; [Monthly
ACH origination Fee; 1 Entry Detail, 1 Addenda Record, Monthly VAN
Connection Fee, 1 Van Transaction Fee]
4) X12 (820) File from ACH (CCD+) from RDFI, 820 from Trading Partner;
[Monthly ACH receiver Fee; Monthly EDI receiver Fee; 1 EDI Translation
Fee, 1 Entry Detail, 1 Addenda Record]
5) X12 (820) File from ACH (CTX) from RDFI; [Monthly ACH receiver Fee;
Monthly EDI receiver Fee; 1 EDI Translation Fee, 1 Entry Detail, minimum
of 12 Addenda Records (based on 1KB 820)]

There are more possible scenarios (like sending money through Fedwire -
more expensive, but same day settlement), but these are the most likely
used methods. As a rule, I recommend choice #1 as an originator, and a
combination of #1 and #2 as a receiver. With the caveat, that there are
valid business rules applicable to choosing each one of the options
listed.

820s and ACH files are not interchangeable, but they can be used in
cooperation. To send money through the ACH Network, you MUST use ACH,
but the Standard Entry Class you use, and who actually creates it can
have have an impact on the associated cost.

I believe the nutshell is overflowing, so I'll end my discourse.

Good luck.

Bill

Bill Morey
Financial Interfaces
Intermountain Health Care


-----Original Message-----
From: [mailto: On Behalf Of
Gina Coomer
Sent: Tuesday, June 14, 2005 12:25 PM
To: EDI-L Mailing List
Subject: [EDI-L] Purpose of the 820

Hello Group
I'm gettlng a little confused about the purpose of an 820.
Our customer is currently sending ACH transactions to the bank
directly.
Would the 820 transaction replace this?
If so, should we now send the 820 to the bank or the trading partner?
With ACH the money gets transferred to the bank.
How would an 820 accomplish this if we are sending it to our supplier?
Any insight is appreciated.

Gina Ann Coomer
Smith Heating Supplies



.
Please use the following Message Identifiers as your subject prefix:
<SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the
list online at: http://groups.yahoo.com/group/EDI-L

Yahoo! Groups Links










 
EDI to XML Mapping for EDIFACT/X12 Convert EDIFACT/X12 Schemas to XML Schema Legacy Data Conversion Tools Access Relational Data as XML Visual XSLT and XQuery Mapping Tools Simplify EDI Data Integration with Stylus Studio XML Enterprise Suite - Free Download!
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2007 All Rights Reserved.