Record Type

Field

Validation

Literal

Required

Skip in Import

Defined as Mandatory Or Required Field by NACHA

Validation Based On

File Header

Record Type Code

Check Literal

"1"

Y

M**

Priority Code

Check Literal

"01"

Y

R****

Immediate Destination

Numeric digits only, plus correct check digit

N

Y

M**

Immediate Origin

Numeric digits only

N

Y

M**

This field may be mutually defined between the ODFI Originating depository financial institution a bank, thrift, or credit union, The FI issuing an ACH file(s) on behalf of its client. and Originator The originator is the individual or organization that is initiating the ACH transmission. For our purposes, the originator is the Commercial Customer using the Cash Management system..

File Creation Date

Check Date

Y

Y

M**

YYMMDD

File Creation Time

Check Time

N

Y

O***

HHMM

File Id Modifier

Check Alphanumeric

Y

N

M**

Record Size

Check Literal

"094"

Y

M**

Section 3.4 of Appendix Three of the NACHA rules stipulate that if these fields are not these values the file will be rejected

Blocking Factor

Check Literal

"10"

Y

M**

Format Code

Check Literal

"1"

Y

M**

Destination Name

Check Alphanumeric, no specific value

N

Y

O***

Origin Name

Check Alphanumeric, no specific value

N

Y

O***

Reference Code

Check Alphanumeric

N

Y

O***

Batch An ACH batch consists of a template The template contains the essential characteristics of the ACH batch, such as the name of the template, the type (class code) of ACH transmission (CCD or PPD Prearranged Payment or Deposit, the ACH payment format by which consumers may authorize credits or debits to their accounts by a company or financial institution. These are normally recurring payments in fixed amounts.), and the offset account. Although AXIS Cash Management only lists CCD & PPD, the application will create the appropriate CCD+/PPD+ ACH Batch if a participant with an addendum is associated with this batch. (see below) and a collection of transactions having the same purpose and effective date to be performed, and may also include addenda information. Header

Record Type Code

Check Literal

"5"

Y

M**

Service Class Code

Check Service Class Code

“200”, “220”, “225”

Y

Y

M**

Service Class Code 280 - ACH Automated Accounting Advices are not supported by cash management

Company Name

Check Alphanumeric

Y

M**

Company Discretion Data

Check Alphanumeric

N

O***

Company Identification

Check Alphanumeric, no specific value

Y

M**

Standard Entry Class Code

Check Standard Entry Class Code

“ CCD The ACH payment format used for concentration of funds between or within companies. A single 94-character record contains the standard entry class indicating the type of transaction, routing and transit numbers of the ODFI and RDFI and the originator and receiver account numbers. CCD is the only corporate ACH format that does not have space for additional addenda information, but it does contain space for a reference number. ”, “PPD”

Y

M**

Other standard entry class codes will be evaluated through our enhancement process

Company Entry Description

Check Alphanumeric

Y

M**

Company Descriptive Date

Check Alphanumeric

N

O***

Effective Entry Date

Year <50 assumed to be 20XX, otherwise 19XX

Y

Y

R****

Originator Status Code

Check Originator Status Code

“1”

Y

M**

ODFI Identification

Check against ACH Orig ABA# maintained in CM Admin. The check digit (9th number) of the ACH Orig ABA should be ignored.

Y

Y

M**

Ensures that the FI is named as the ODFI

Batch Number

Ascending from previous batch, but not necessarily consecutive

Y

M**

Entry Detail

Record Type Code

Check Literal

"6"

Y

M**

Transaction An ACH transaction is an entry within the NACHA file that indicates how the participant The participant is the individual or organization that will be affected by the ACH transaction (payee or draftee). An ACH transaction may debit or credit a participant's account, e.g., a payroll deposit or a payment for services rendered. The participant information is referenced by the ACH transaction.'s account should be affected. The transaction includes a reference to the participant, how the account is affected, and the amount. Code

"22", "27", "32", "37", "23", "28", "33", "38", credit transactions accepted only with Service Class Code "200" or "220", debits with "200" or "225"

Y

M**

Other transaction codes will be evaluated through our enhancment process

Receiving DFI Identification

Check Numeric

Y

M**

Check Digit

Check-digit verification on Receiving DFI ID

Y

M**

DFI Account Number

Check Alphanumeric

Y

R****

Amount

Check Numeric

Y

M**

Identification Number

Check Alphanumeric

N

O***

Receiving Company Name

Check Alphanumeric

N

O***

Discretionary Data

Check Alphanumeric

N

O***

Addenda Record Indicator

Check Numeric

Y

M**

Number of Addenda Records

CTX only (Not yet available)

Y

M**

Trace Number

ODFI portion must match ODFI id in Batch Header record; Entry Detail Sequence Number must be ascending in order

Y

Y

M**

Section 3.5 of Appendix Three

Addenda

Record Type Code

Check Literal

"7"

Y

M**

Addenda Type Code

Check Literal

"05"

Y

M**

Payment Related Information

Check Alphanumeric

N

O***

Addenda Sequence Number

Ascending in order and consecutive in sequence, first addenda record must be "1"

Y

M**

Section 2.3 Appendix Two

Entry Detail Sequence Number

Check Entry Detail Sequence Number

Y

M**

Section 2.3 Appendix Two

Must match trace number in current entry detail record

Y

Batch Control

Record Type Code

Check Literal

"8"

Y

M**

Service Class Code

Match corresponding field in Batch Header record

Y

Y

M**

Batch Entry/Addenda Count

Match total # of detail and addenda records in batch

Y

M**

These validations ensure that the batch is in balance and no data has been lost during the transmission of the file. If any of these validation do not pass the file is consider to be out of balance and will be rejected. (Section 3.5 Appendix Three NACHA Rules)

Batch Entry Hash

Match computed hash of Entry Detail records in batch

Y

M**

Batch Total Debit Amount

Match computed total of debit Entry Detail records in batch

Y

M**

Batch Total Credit Amount

Match computed total of credit Entry Detail records in batch

Y

M**

Company Identification

Match corresponding field in Batch Header record

Y

R****

Message Authentic Code

Check Alphanumeric

N

O***

Originating DFI Ident

Match corresponding field in Batch Header record

Y

M**

These validations ensure that the batch is in balance and no data has been lost during the transmission of the file. If any of these validation do not pass the file is consider to be out of balance and will be rejected. (Section 3.5 Appendix Three NACHA Rules)

Batch Number

Match corresponding field in Batch Header record

Y

M**

File Control

Record Type Code

Check Literal

"9"

Y

M**

File Batch Count

Match computed number of batches

Y

M**

These validations ensure that the file is in balance and no data has been lost during the transmission of the file. If any of these validation do not pass the file is consider to be out of balance and will be rejected. (Section 3.4 Appendix Three NACHA Rules)

File Block Count

Match number of 940 byte (10 record) blocks in file

Y

M**

File Entry/Addenda Count

Match total # of detail and addenda records in file

Y

M**

File Entry Hash

Match computed hash of Entry Detail records in file

Y

M**

File Total Debit Amount

Match computed total of debit Entry Detail records in file

Y

M**

File Total Credit Amount

Match computed total of credit Entry Detail records in file

Y

M**

**"Mandatory For ACH Processing - A "Mandatory" field is necessary to ensure the proper routing and/or posting of an ACH entry. Any "Mandatory" field not included in an ACH record will cause that entry, batch, or file to be rejected by the ACH Operator..." (Section 2.3 Appendix Two NACHA Rules)

***Optional for ACH Processing - The inclusion or omission of an "Optional" data dield is at the discretion of the Origiantor and ODFI. (Section 2.3 Appendix Two NACHA Rules)

****Required for ACH Processing - Data classified as "Required" should be included by the Originator and ODFI to avoid processing and control problems at the RDFI Receiving Depository Financial Institution, the FI that receives the ACH debits or credits on behalf of an individual, or business client.. (Section 2.3 Appendix Two NACHA Rules)