See Demo
1-800-714-5153

Glossary: ACH Files

A blue file cabinet

Example of an ACH File Record

				
					101 031300012 2313801040123456789                   091202010000001
5200Company Name                         123456789 CCD 09120201   112
6222313801041234567890        0000010000               Jane Doe  0001
82000000020023138010400002000000000001000000000000200000000     112
90000010000010000000200231380104000020000000000010000000000020000000
99999999999999999999999999999999999999999999999999999999999999999999

What is an ACH File?

An Automated Clearing House (ACH) file is a standardized file format used for electronic payments and transactions in the United States. The ACH network facilitates the transfer of funds between banks and financial institutions, enabling a wide range of transactions, including payroll deposits, bill payments, and other automated money transfers.

Structure of an ACH File

ACH files are composed of a series of fixed-width, ASCII-encoded lines, each exactly 94 characters in length. These lines, known as “records,” follow a precise structure and order to ensure accurate processing. Each record type serves a specific purpose within the ACH file and is identified by a unique single-digit “type code.”

Key Components

  1. Records and Fields:

    • Records: Each line in an ACH file represents a record. Records are the building blocks of the file, containing specific information required for transaction processing.
    • Fields: Each record is divided into various fields, with each field occupying a specific position within the record. Fields can contain alphanumeric or numeric data and are used to store details such as routing numbers, account numbers, transaction amounts, and more.

  2. Batches and Transactions:

    • Batches: An ACH file can contain one or more batches. A batch groups together multiple transactions that share common attributes, such as the same originator and effective entry date.
    • Transactions: Within each batch, individual transactions represent the transfer of funds between accounts. Transactions include details about the sender (originator), the recipient (receiver), and the transaction amount.

Importance and Use Cases

ACH files play a critical role in the financial industry by providing a reliable and efficient method for processing large volumes of transactions. Common use cases include:

  • Payroll Processing: Employers use ACH files to deposit employee salaries directly into their bank accounts.
  • Bill Payments: Consumers and businesses use ACH files to pay recurring bills, such as utilities and mortgage payments.
  • Vendor Payments: Businesses use ACH files to pay suppliers and vendors electronically, reducing the need for paper checks.

Benefits of ACH Files

  • Efficiency: ACH files streamline the transfer of funds, reducing the need for manual processing and paper checks.
  • Cost-Effectiveness: Electronic transactions via ACH are typically less expensive than processing paper checks.
  • Accuracy: The standardized format and automated processing of ACH files minimize errors and ensure accurate transaction handling.
  • Security: ACH transactions are encrypted and processed through secure channels, providing a high level of protection against fraud.

Compliance and Standards

ACH files must adhere to the guidelines and rules set by Nacha (National Automated Clearing House Association), which oversees the ACH network. Compliance with these standards ensures that ACH transactions are processed consistently and securely across all participating financial institutions.

Table of Contents

  1. What is an ACH File?

    • Definition of ACH Files
    • Importance in Financial Transactions
    • Overview of Structure and Purpose

  2. ACH File Components

    • Records and Fields
      • Explanation of Records
      • Fixed-Width Format
      • ASCII Encoding
      • Structure of Records
    • Batches and Transactions
      • Definition and Structure of Batches
      • Transactions within Batches
      • Data Elements at Different Levels

  3. Record Sequence and Types

    • Overview of Record Sequence
      • General Sequence of Records
      • Header and Control Records
    • Detailed Record Types
      • File Header Record (Type 1)
      • Batch Header Record (Type 5)
      • Entry Detail Record (Type 6)
      • Addenda Record (Type 7)
      • Batch Control Record (Type 8)
      • File Control Record (Type 9)
      • File Padding Record (Type 9)

  4. Record Details

    • File Header Record
      • Field-by-Field Breakdown
      • Example Layout
    • Batch Header Record
      • Field-by-Field Breakdown
      • Example Layout
    • Entry Detail Record
      • Field-by-Field Breakdown
      • Example Layout
    • Addenda Record
      • Field-by-Field Breakdown
      • Example Layout
    • Batch Control Record
      • Field-by-Field Breakdown
      • Example Layout
    • File Control Record
      • Field-by-Field Breakdown
      • Example Layout

  5. Data Specifications

    • Alphanumeric Fields
      • Justification and Padding
      • Case Sensitivity
    • Numeric Fields
      • Justification and Padding
      • Unsigned Values
    • Codes and Special Fields
      • Uppercase Requirements
      • Trace Numbers

  6. Types of ACH Files

    • Balanced vs. Unbalanced Files
      • Definitions
      • Differences and Use Cases

  7. Effective Dates

    • Importance and Validation
    • ACH Processing Schedules
    • Pre-notifications and Authorization

  8. Same Day ACH

    • Definition and Benefits
    • Requirements and Limitations
    • Comparison with Traditional ACH

  9. Transaction Codes

    • Definition and Importance
    • Detailed List and Descriptions
    • Use in Entry Detail Records

  10. Service Class Codes

    • Definition and Importance
    • Detailed List and Descriptions
    • Use in Batch Header and Control Records

  11. Standard Entry Class (SEC) Codes

    • Overview and Purpose
    • Commonly Used SEC Codes

  12. ACH File Header and Trailer Records

    • File Header Record
      • Field-by-Field Breakdown
      • Example Layout
    • File Control Record
      • Field-by-Field Breakdown
      • Example Layout

  13. ACH Batch Header and Trailer Records

    • Batch Header Record
      • Field-by-Field Breakdown
      • Example Layout
    • Batch Control Record
      • Field-by-Field Breakdown
      • Example Layout

  14. Entry and Addenda Records

    • PPD, CCD, WEB, TEL Entry Records
      • Field-by-Field Breakdown
      • Example Layout
    • Addenda Records
      • Field-by-Field Breakdown
      • Example Layout

  15. Tax Payments

    • Use of ACH for Tax Payments
    • Addenda Records for Tax Payments (TXP)

  16. Compliance and Best Practices

    • Nacha Rules and Guidelines
    • Common Compliance Issues
    • Best Practices for ACH File Creation and Submission

ACH File Components

Records and Fields

Explanation of Records

Records are the fundamental building blocks of an ACH file. Each record consists of a single line of text, which includes multiple fields containing specific pieces of information. The purpose of these records is to convey all necessary details for processing transactions within the ACH network. Different types of records are used to mark the start and end of files and batches, as well as to detail individual transactions.

Fixed-Width Format

An ACH file adheres to a fixed-width format, meaning each record is exactly 94 characters long. This ensures that every line in the file aligns perfectly, facilitating accurate and efficient processing by computer systems. The fixed-width format requires careful attention to the placement and length of each field within the records.

ASCII Encoding

ACH files use ASCII (American Standard Code for Information Interchange) encoding. ASCII is a character encoding standard that represents text in computers and other devices that use text. By using ASCII encoding, ACH files maintain compatibility and readability across various systems and platforms.

Structure of Records

Each record in an ACH file is divided into specific fields, each occupying a predetermined position and length within the 94-character line. These fields can contain alphanumeric or numeric data and are used to store essential information such as routing numbers, account numbers, transaction amounts, and other relevant details. The structure of the records ensures that all necessary data is conveyed accurately for processing.

Batches and Transactions

Definition and Structure of Batches

A batch is a collection of multiple transactions within an ACH file that share common attributes. Each batch is marked by a Batch Header Record (type 5) at the beginning and a Batch Control Record (type 8) at the end. The batch header provides information about the batch, such as the originator’s details and the purpose of the transactions. The batch control record sums up the transactions within the batch, including totals and hash values for validation purposes.

Transactions within Batches

Transactions are the individual units of money transfer within a batch. Each transaction is detailed in an Entry Detail Record (type 6), which includes information about the receiver, such as their account number, name, and the transaction amount. Additional details about the transaction, such as special instructions or supplementary information, can be included in Addenda Records (type 7).

Data Elements at Different Levels (File, Batch, Transaction)

  • File Level: The overall structure of the ACH file is managed at the file level, starting with a File Header Record (type 1) and ending with a File Control Record (type 9). These records provide general information about the file, including the originator and the creation date.

  • Batch Level: At the batch level, data elements are grouped based on common attributes. The Batch Header Record (type 5) contains information specific to the entire batch, such as the originator’s details and the effective date of the transactions. The Batch Control Record (type 8) at the end of the batch includes totals and hash values for validation.

  • Transaction Level: Within each batch, the individual transactions are detailed at the transaction level. The Entry Detail Records (type 6) contain information about each transaction, including the receiver’s details and the transaction amount. Addenda Records (type 7) may be used to provide additional information related to specific transactions.

blue stack of papers offset

Table: Common SEC Codes

SEC Code ACH Application Application Use Debit / Credit Consumer / Corporate Authorization Requirements
ARC Accounts Receivable Entries A single ACH debit used by originator for the conversion of an eligible source document received via the U.S. mail or delivery service; at a lockbox location; or in person at a manned location for the payment of a bill. Debit Consumer to Corporate Notification is required prior to acceptance of the check.
BOC Back Office Conversion A single ACH debit initiated by an originator based on an eligible source document provided at the point-of-purchase or at a manned bill payment location for subsequent conversion during back office conversion. Debit Consumer to Corporate Notification is required prior to acceptance of the check.
CCD / CCD+ Corporate Credit or Debit A single or a recurring ACH credit or debit originated to a corporate account. Commonly used by Originators to pay vendors, concentrate funds from outlying accounts (cash concentration), to fund payroll, petty cash, or other disbursement accounts. CCD entries can contain a single addenda record to relay payment-related information. Credit / Debit/Nonmonetary Corporate to Corporate Agreement required for transfers between companies; written authorization implied.
CIE Customer Initiated Entries A credit entry initiated by consumer through a bill payment service provider to pay bills. Credit Consumer to Corporate Presumed agreement between consumer and company or paying agent.
CTX Corporate Trade Exchange A single or a recurring ACH credit or debit originated to a corporate account that supports up to 9,999 addenda records. Commonly used in trading partner relationships because a full ANSI ASC X12 message or payment-related UN/EDIFACT information can be sent with the CTX entry. Credit / Debit/Nonmonetary Corporate to Corporate Agreement required for transfers between companies; written authorization implied.
IAT International ACH Transaction An Entry that is part of a payment transaction involving a financial agency’s office that is not located within the territorial jurisdiction of the United States. Credit / Debit Corporate to Consumer / Corporate to Corporate For Consumer Credit Entries: oral/nonwritten; for Consumer Debit Entries: written; for Corporate Entries: agreement.
POP Point of Purchase A single ACH debit initiated by an originator based on an eligible source document provided at a point-of-purchase or manned bill payment location. Debit Corporate to Consumer / Corporate to Corporate Notification prior to acceptance of the check and written authorization required.
POS Point of Sale Initiated at an electronic terminal using merchant issued physical card or other access device. Debit Consumer Written authorization required.
PPD / PPD+ Pre-arranged Payment or Deposit A single or a recurring ACH credit or debit sent by an originator to a consumer account to make or collect a payment, where authorization is obtained in writing. Only one addenda record can be attached to each payment entry (the + denotes containing an addenda record). Credit / Debit Corporate to Consumer Direct Deposit; Oral/Nonwritten; Direct Payments; Written authorization required.
RCK Re-presented Check Entries Originators can re-present a check that has been processed through the check collection system as a paper or image item, and returned because of insufficient or uncollected funds. Debit Single Entry Corporate to Consumer Notification is required prior to acceptance of the check.
TEL Telephone Initiated Entries A single or a recurring ACH debit that occurs when the consumer’s authorization for a transfer of funds is received orally via the telephone. Debit Corporate to Consumer For Single, recorded oral authorization or written notice provided to the consumer confirming the oral authorization.* For Recurring, a copy of the authorization must be provided to the consumer.
WEB Internet-Initiated/Mobile Entries Credit WEB Entries: A Person-to-Person entry transmitted on behalf of one natural person to another natural person, or between accounts belonging to the same natural person. Debit WEB Entries: ACH entry initiated according to an authorization obtained via the internet or a wireless network (e.g. mobile device) except for an oral authorization via a telephone call. Credit / Debit Single Entry or Recurring Entry Corporate to Consumer For credit WEB Entries: no authorization by the Receiver. For debit WEB Entries: similarly authenticated.

Data Retrieved From: https://achdevguide.nacha.org/ach-file-details

A stack of blue papers

Type 1 File Header Record (Applies to All SEC Codes)

Field Number Field Name Position in Record Length Data Required? Content Description/Notes
1 Record Type Code 1 1 Y 1 Always "1"
2 Priority Code 2-3 2 Y 01 Always "01."
3 Immediate Destination 4-13 10 Y Bnnnnnnnn The nine-digit routing number of the institution receiving the ACH file for processing, preceded by a blank. Typically, this is your bank’s routing and transit number.
4 Immediate Origin 14-23 10 Y Bnnnnnnnn The nine-digit routing transit number of the institution sending (originating) the ACH file, preceded by a blank. (Often your ODFI will have you insert your company ID in this field.)
5 File Creation Date 24-29 6 Y YYMMDD The date that the ACH file was created.
6 File Creation Time 30-33 4 N HHMM The time that the ACH file was created using a 24-hour, military time format.
7 File ID Modifier 34 1 Y A-Z, 0-9 For a single processing day, each file submitted by the financial institution should have a unique ID to allow for thorough duplicate file identification.
8 Record Size 35-37 3 Y 094 Always "094" because every record contains 94 characters.
9 Blocking Factor 38-39 2 Y 10 Always "10" because the blocking factor is 10.
10 Format Code 40 1 Y 1 Always "1."
11 Immediate Destination Name 41-63 23 N alphanumeric Name of the financial institution receiving the payment file.
12 Immediate Origin Name 64-86 23 N alphanumeric Name of the financial institution sending the payment file.
13 Reference Code 87-94 8 N alphanumeric This field is reserved for information pertinent to the business.

Data Retrieved From: https://achdevguide.nacha.org/ach-file-details

Record Sequence and Types

Overview of Record Sequence

General Sequence of Records

The sequence of records in an ACH file is crucial for proper processing. The general sequence follows a hierarchical structure, starting with file-level records, moving to batch-level records, and finally detailing individual transactions. Each section begins with a header record and ends with a corresponding control record. This structure ensures that the file is correctly organized and that all necessary information is included for processing.

Header and Control Records

For every header record that starts a section, there is a corresponding control record that ends that section. These header and control records function like opening and closing tags in XML or braces in programming languages, marking the beginning and end of sections. This pairing helps maintain the integrity of the file and facilitates error checking during processing.

Detailed Record Types

File Header Record (Type 1)

  • Purpose: The File Header Record marks the beginning of the ACH file and contains information about the file itself.
  • Key Fields:
    • Record Type Code: Always “1”
    • Immediate Destination: The routing number of the receiving bank
    • Immediate Origin: The routing number of the originating bank
    • File Creation Date and Time
    • File ID Modifier: A unique identifier for the file
    • Record Size: Always “094”
    • Blocking Factor: Always “10”
    • Format Code: Always “1”
    • Immediate Destination Name and Immediate Origin Name
    • Reference Code: Optional field for additional information

Batch Header Record (Type 5)

  • Purpose: The Batch Header Record marks the beginning of a batch within the ACH file and contains details about the batch.
  • Key Fields:
    • Record Type Code: Always “5”
    • Service Class Code: Indicates whether the batch contains debits, credits, or both
    • Company Name: The name of the originating company
    • Company Identification: A unique identifier for the company
    • Standard Entry Class (SEC) Code: Indicates the type of transactions in the batch
    • Company Entry Description: A description of the batch’s purpose
    • Effective Entry Date: The date transactions should be processed
    • Originator Status Code: Indicates the originator’s status
    • Originating DFI Identification: The routing number of the originating financial institution
    • Batch Number: A unique identifier for the batch

Entry Detail Record (Type 6)

  • Purpose: The Entry Detail Record contains details about an individual transaction within a batch.
  • Key Fields:
    • Record Type Code: Always “6”
    • Transaction Code: Identifies the type of transaction (debit or credit)
    • Receiving DFI Identification: The routing number of the receiving bank
    • Check Digit: A single digit to validate the routing number
    • DFI Account Number: The receiver’s account number
    • Amount: The transaction amount
    • Individual Identification Number: An optional field for additional identification
    • Receiving Individual/Company Name: The name of the transaction’s recipient
    • Addenda Record Indicator: Indicates if there are addenda records
    • Trace Number: A unique identifier for the transaction

Addenda Record (Type 7)

  • Purpose: The Addenda Record provides additional information about a transaction that cannot be included in the Entry Detail Record.
  • Key Fields:
    • Record Type Code: Always “7”
    • Addenda Type Code: Indicates the type of addenda information
    • Payment Related Information: Freeform text field for additional details
    • Addenda Sequence Number: Indicates the order of the addenda records
    • Entry Detail Sequence Number: Matches the sequence number in the Entry Detail Record

Batch Control Record (Type 8)

  • Purpose: The Batch Control Record marks the end of a batch and contains summary information about the batch.
  • Key Fields:
    • Record Type Code: Always “8”
    • Service Class Code: Matches the Service Class Code in the Batch Header Record
    • Entry/Addenda Count: The total number of Entry Detail and Addenda Records
    • Entry Hash: A hash total of the routing numbers in the Entry Detail Records
    • Total Debit Entry Dollar Amount: The sum of all debit transactions in the batch
    • Total Credit Entry Dollar Amount: The sum of all credit transactions in the batch
    • Company Identification: Matches the Company Identification in the Batch Header Record
    • Originating DFI Identification: Matches the routing number in the Batch Header Record
    • Batch Number: Matches the Batch Number in the Batch Header Record

File Control Record (Type 9)

  • Purpose: The File Control Record marks the end of the ACH file and contains summary information about the entire file.
  • Key Fields:
    • Record Type Code: Always “9”
    • Batch Count: The total number of batches in the file
    • Block Count: The total number of blocks in the file
    • Entry/Addenda Count: The total number of Entry Detail and Addenda Records in the file
    • Entry Hash: A hash total of all the Entry Hash values in the Batch Control Records
    • Total Debit Entry Dollar Amount: The sum of all debit transactions in the file
    • Total Credit Entry Dollar Amount: The sum of all credit transactions in the file

File Padding Record (Type 9)

  • Purpose: The File Padding Record ensures that the total number of lines in the ACH file is a multiple of 10.
  • Key Fields:
    • Record Type Code: Always “9”
    • The remaining characters in the record are filled with “9”s to pad the file to the necessary length.

Record Details

File Header Record

The File Header Record is the first record in an ACH file and serves to identify the file and provide essential information about its origin and destination. This record contains details such as the routing numbers of the originating and receiving banks, the file creation date and time, and other pertinent metadata.

  • Record Type Code (01-01): Always “1” to indicate a File Header Record.
  • Priority Code (02-03): Always “01”.
  • Immediate Destination (04-13): The nine-digit routing number of the receiving bank, preceded by a blank space.
  • Immediate Origin (14-23): The nine-digit routing number of the originating bank, preceded by a blank space.
  • File Creation Date (24-29): The date the file was created (YYMMDD format).
  • File Creation Time (30-33): The time the file was created (HHMM format).
  • File ID Modifier (34-34): A unique identifier for the file (A-Z, 0-9).
  • Record Size (35-37): Always “094”.
  • Blocking Factor (38-39): Always “10”.
  • Format Code (40-40): Always “1”.
  • Immediate Destination Name (41-63): The name of the receiving bank.
  • Immediate Origin Name (64-86): The name of the originating bank.
  • Reference Code (87-94): An optional field for additional information.

Batch Header Record

The Batch Header Record marks the beginning of a batch within the ACH file. It contains information about the batch, such as the originator’s details, the type of transactions included, and the effective entry date. This record helps group transactions that share common attributes.

  • Record Type Code (01-01): Always “5” to indicate a Batch Header Record.
  • Service Class Code (02-04): Indicates whether the batch contains debits, credits, or both (e.g., “200” for mixed, “220” for credits only, “225” for debits only).
  • Company Name (05-20): The name of the originating company.
  • Company Discretionary Data (21-40): Optional field for the company’s use.
  • Company Identification (41-50): A unique identifier for the company.
  • Standard Entry Class (SEC) Code (51-53): Indicates the type of transactions in the batch (e.g., “PPD” for pre-arranged payment and deposits).
  • Company Entry Description (54-63): A description of the batch’s purpose.
  • Company Descriptive Date (64-69): An optional field for the company’s use.
  • Effective Entry Date (70-75): The date the transactions should be processed (YYMMDD format).
  • Settlement Date (76-78): Inserted by the ACH operator.
  • Originator Status Code (79-79): Indicates the originator’s status (typically “1”).
  • Originating DFI Identification (80-87): The routing number of the originating financial institution.
  • Batch Number (88-94): A unique identifier for the batch.

Entry Detail Record

The Entry Detail Record contains the details of an individual transaction within a batch. This record includes information about the receiver, such as their account number and name, as well as the transaction amount and type.

  • Record Type Code (01-01): Always “6” to indicate an Entry Detail Record.
  • Transaction Code (02-03): Identifies the type of transaction (e.g., “22” for credit to a checking account, “27” for debit from a checking account).
  • Receiving DFI Identification (04-11): The routing number of the receiving bank.
  • Check Digit (12-12): A single digit to validate the routing number.
  • DFI Account Number (13-29): The receiver’s account number.
  • Amount (30-39): The transaction amount in dollars and cents.
  • Individual Identification Number (40-54): An optional field for additional identification.
  • Receiving Individual/Company Name (55-76): The name of the transaction’s recipient.
  • Discretionary Data (77-78): Optional field for the company’s use.
  • Addenda Record Indicator (79-79): Indicates if there are addenda records (typically “0” for none, “1” for one or more).
  • Trace Number (80-94): A unique identifier for the transaction.

Addenda Record

The Addenda Record provides additional information about a transaction that cannot be included in the Entry Detail Record. It is used to convey supplementary details, instructions, or explanations related to the transaction.

  • Record Type Code (01-01): Always “7” to indicate an Addenda Record.
  • Addenda Type Code (02-03): Indicates the type of addenda information (e.g., “05” for payment-related information).
  • Payment Related Information (04-83): A freeform text field for additional details about the transaction.
  • Addenda Sequence Number (84-87): Indicates the order of the addenda records (e.g., “0001” for the first addenda record).
  • Entry Detail Sequence Number (88-94): Matches the sequence number in the Entry Detail Record.

Batch Control Record

The Batch Control Record marks the end of a batch and contains summary information about the batch. This record includes totals and hash values for validation purposes, ensuring the integrity and accuracy of the batch.

  • Record Type Code (01-01): Always “8” to indicate a Batch Control Record.
  • Service Class Code (02-04): Matches the Service Class Code in the Batch Header Record.
  • Entry/Addenda Count (05-10): The total number of Entry Detail and Addenda Records in the batch.
  • Entry Hash (11-20): A hash total of the routing numbers in the Entry Detail Records.
  • Total Debit Entry Dollar Amount (21-32): The sum of all debit transactions in the batch.
  • Total Credit Entry Dollar Amount (33-44): The sum of all credit transactions in the batch.
  • Company Identification (45-54): Matches the Company Identification in the Batch Header Record.
  • Message Authentication Code (55-73): Optional field for additional security.
  • Reserved (74-79): Blank spaces.
  • Originating DFI Identification (80-87): Matches the routing number in the Batch Header Record.
  • Batch Number (88-94): Matches the Batch Number in the Batch Header Record.

File Control Record

The File Control Record marks the end of the ACH file and contains summary information about the entire file. This record ensures the file’s integrity by providing totals and hash values for validation.

  • Record Type Code (01-01): Always “9” to indicate a File Control Record.
  • Batch Count (02-07): The total number of batches in the file.
  • Block Count (08-13): The total number of blocks in the file (each block contains 10 records).
  • Entry/Addenda Count (14-21): The total number of Entry Detail and Addenda Records in the file.
  • Entry Hash (22-31): A hash total of all the Entry Hash values in the Batch Control Records.
  • Total Debit Entry Dollar Amount (32-43): The sum of all debit transactions in the file.
  • Total Credit Entry Dollar Amount (44-55): The sum of all credit transactions in the file.
  • Reserved (56-94): Blank spaces.
A medium stack of blue papers

Example Layouts

File Header Record Example Layout

				
					101 031300012 2313801040123456789                   091202010000001

Batch Header Record Example Layout

				
					5200Company Name                         123456789 CCD 09120201   112

Entry Detail Record Example Layout

				
					6222313801041234567890        0000010000               Jane Doe  0001

Addenda Record Example Layout

				
					705Payment Related Information                                        0001

Batch Control Record Example Layout

				
					82000000020023138010400002000000000001000000000000200000000     112

File Control Record Example Layout

				
					90000010000010000000200231380104000020000000000010000000000020000000

Type 9 File Trailer Record (Applies to All SEC Codes)

Field Number Field Name Position in Record Length Data Required? Content Description/Notes
1 Record Type Code 01-01 1 Y 9 Always "9"
2 Batch Count 02-07 6 Y numeric Count of the number of batches within the file.
3 Block Count 08-13 6 Y numeric Count of the number of blocks of 10 rows within the file.
4 Entry/Addenda Count 14-21 8 Y numeric Total count of the number of entries and addenda records within the file.
5 Entry Hash 22-31 10 Y numeric The sum of the Entry Hash fields contained within the Company/Batch Control Records of the file.
6 Total Debit Entry Dollar Amount in File 32-43 12 Y $$$$$$$$$$cc Sum of the amount of debit entries contained within the file.
7 Total Credit Entry Dollar Amount in File 44-55 12 Y $$$$$$$$$$cc Sum of the amount of credit entries contained within the file.
8 Reserved 56-94 39 N/A blank

Data Retrieved From: https://achdevguide.nacha.org/ach-file-details

Blue post it notes

Type 5 Batch Header Record (Applies to All SEC Codes Except IAT)

Field Number Field Name Position in Record Length Data Required? Content Description/Notes
1 Record Type Code 01-01 1 Y 5 Always "5"
2 Service Class Code 02-04 3 Y numeric Identifies the general classification of dollar entries to be exchanged. [Click for Service Class Codes]
3 Company Name 05-20 16 Y alphanumeric Name of the Originator known and recognized by the Receiver.
4 Company Discretionary Data 21-40 20 N alphanumeric Originator/ODFI may include codes of significance only to them to enable specialized handling of all entries within the batch.
5 Company Identification 41-50 10 Y alphanumeric Used to identify the Originator. Assigned by the ODFI.
6 Standard Entry Class Code 51-53 3 Y alphanumeric Three-character code used to identify distinct types of entries. [Click for SEC Codes]
7 Company Entry Description 54-63 10 Y alphanumeric Originator inserts this field's value to provide the Receiver with a description of the entry's purpose; however some SEC Codes require specific values for this field.
8 Company Descriptive Date 64-69 6 N alphanumeric Originator establishes this field as the date it would like to see displayed to the Receiver for descriptive purposes.
9 Effective Entry Date 70-75 6 Y YYMMDD The banking day the Originator intends a batch of entries to be settled.
10 Settlement Date (Julian) 76-78 3 N numeric Inserted by ACH Operator.
11 Originator Status Code 79-79 1 N alphanumeric The code refers to the ODFI initiating the entry.
12 Originating DFI Identification 80-87 8 Y TTTTAAAA The routing number of the DFI originating the entries within the batch.
13 Batch Number 88-94 7 Y numeric The ODFI assigns this number in ascending sequence to each batch in a file of entries. The batch number in the Company/Batch Header record and the Company/Batch Control record must be the same.

Data Retrieved From: https://achdevguide.nacha.org/ach-file-details

Data Specifications

Alphanumeric Fields

Justification and Padding

Alphanumeric fields in ACH files are used to store textual information, such as names, descriptions, and discretionary data. These fields must be left-justified and post-padded with spaces to ensure they fit the fixed-width format of the file. This means that any unused space in the field should be filled with blank spaces, ensuring the text starts at the leftmost position.

Example:

If the field length is 20 characters and the actual text is “Company Name” (12 characters long), the field should be formatted as:

				
					"Company Name        "

Case Sensitivity

ACH file specifications typically require that alphanumeric fields use uppercase characters only. This standardization ensures consistency and reduces the risk of misinterpretation by processing systems. Lowercase characters should be converted to uppercase before inclusion in the file.

Example:

The text “company name” should be converted to:

				
					"COMPANY NAME"

Numeric Fields

Justification and Padding

Numeric fields in ACH files are used to store numerical information, such as amounts, counts, and identification numbers. These fields must be right-justified and pre-padded with zeros to fit the fixed-width format. This means that any unused space in the field should be filled with zeros, ensuring the number is aligned to the rightmost position.

Example:

If the field length is 10 characters and the actual number is 12345, the field should be formatted as:

				
					"0000012345"

Unsigned Values

Numeric fields in ACH files are always unsigned, meaning they do not indicate whether a number is positive or negative. All values are assumed to be positive. This simplifies the format and ensures that the fixed-width structure is maintained without additional characters for signs.

Example:

The amount -12345 should simply be formatted as:

				
					"0000012345"

Codes and Special Fields

Uppercase Requirements

Certain fields, such as codes and identifiers, must contain uppercase characters only. This requirement applies to various alphanumeric codes within the ACH file, such as Standard Entry Class (SEC) Codes, Service Class Codes, and transaction codes. Using uppercase characters ensures uniformity and avoids potential processing errors.

Example:

The SEC Code for pre-arranged payment and deposits should be:

				
					"PPD"

Trace Numbers

Trace numbers are unique identifiers assigned to each transaction within a batch. They are critical for tracking and reconciliation purposes. Trace numbers are composed of a 15-digit number, where the first eight digits represent the routing number of the originating financial institution, and the last seven digits are sequentially assigned numbers.

Structure:

  • First Eight Digits: Routing number of the originating bank.
  • Last Seven Digits: Sequential number assigned by the originator.

Example:

If the routing number is 12345678 and the sequential number is 0001234, the trace number should be:

				
					"123456780001234"

Types of ACH Files

Balanced vs. Unbalanced Files

Balanced ACH File: A balanced ACH file includes offsetting entries for all transactions. This means that each debit transaction has a corresponding credit transaction, and vice versa, within the same file. The file contains all the necessary information to balance the totals of debits and credits, ensuring that the sum of all transactions equals zero. Balanced files are typically used when the originator needs to settle the transactions directly.

Unbalanced ACH File: An unbalanced ACH file does not include offsetting entries for each transaction within the file. Instead, the offsetting entries are managed separately, often by the originating depository financial institution (ODFI). In unbalanced files, the total of all debits and credits might not equal zero within the file itself. The settlement is handled by the ODFI or another intermediary.

Differences and Use Cases

Balanced ACH File:

  • Structure: Contains both debit and credit entries that offset each other, ensuring that the file balances out to zero.
  • Use Cases:
    • Direct Settlements: Used when the originator manages the settlement process and needs to ensure that all transactions are balanced within the file. For example, a payroll processor might use a balanced file to ensure that the total amount debited from the employer’s account equals the total amount credited to employees’ accounts.
    • Internal Transfers: Ideal for internal fund transfers within the same organization where all entries must balance out within the file itself.
  • Advantages: Simplifies reconciliation as all transactions and their offsets are contained within the same file. Ensures immediate balancing without requiring external intervention.


Unbalanced ACH File:

  • Structure: Contains debit and credit entries without ensuring that they offset each other within the file. The offsetting entry, or “settlement entry,” is managed externally.
  • Use Cases:
    • Third-Party Payments: Commonly used by third-party payment processors who handle settlements separately. For example, a payment processor might collect debits from multiple payers and settle the credits separately.
    • High-Volume Transactions: Suitable for organizations handling large volumes of transactions where balancing each file internally is not feasible. The ODFI manages the overall settlement, allowing for more flexibility in file composition.
  • Advantages: Provides greater flexibility in managing transactions, especially for large volumes or complex settlement processes. Reduces the burden on the originator to balance each file.


Key Differences:

  • Balancing: Balanced files include all necessary offsets within the file, while unbalanced files rely on external offsets managed by the ODFI.
  • Reconciliation: Balanced files simplify reconciliation by containing all transactions and offsets in one place. Unbalanced files may require additional steps to reconcile.
  • Flexibility: Unbalanced files offer greater flexibility for handling large or complex transactions but depend on the ODFI for settlement.


Example Scenarios:

  • Balanced File Scenario: A company processes payroll for its employees. The file includes debits from the company’s account and corresponding credits to employees’ accounts, ensuring that the total debits equal the total credits.
  • Unbalanced File Scenario: A payment processor collects subscription fees from multiple customers. The file contains multiple debit entries for each customer payment but does not include the offsetting credit entry for the service provider. The ODFI handles the settlement separately.
A large stack of blue papers
A modern blue pen.

Effective Dates

Importance and Validation

Importance

The effective date in an ACH file is the date on which the originator wants the transactions to be processed and posted to the receiver’s account. This date is crucial for ensuring timely transactions and accurate financial planning. It impacts the following:

  • Cash Flow Management: Ensures funds are available when needed, aiding in accurate cash flow management for both the originator and the receiver.
  • Compliance: Adhering to the effective date requirements helps meet regulatory and contractual obligations.
  • Customer Satisfaction: Timely processing of transactions maintains trust and satisfaction among customers and employees.

Validation

Effective dates must be validated to ensure they are business days and fall within acceptable processing windows. Validation involves:

  • Checking against Federal Reserve Holidays: ACH transactions do not process on weekends or federal holidays. The effective date must be a valid business day.
  • Lead Time: Originators must consider the lead time required for ACH processing, typically one to two business days before the effective date.
  • Bank Cut-off Times: Transactions must be submitted before the bank’s cut-off time on the business day prior to the effective date to ensure timely processing.

ACH Processing Schedules

ACH transactions are processed according to a fixed schedule determined by the Federal Reserve. The schedule includes multiple processing windows throughout the day, allowing for timely settlement of transactions.

Processing Windows

  • Standard ACH: Typically includes three processing windows per day:
    • Morning
    • Midday
    • End of Day
  • Same Day ACH: Allows for expedited processing with additional windows, enabling transactions to be settled on the same business day if submitted by the specified cut-off times.

Non-Processing Days

ACH transactions are not processed on:

  • Weekends (Saturdays and Sundays)
  • Federal Reserve Holidays, which include:
    • New Year’s Day
    • Martin Luther King Jr. Day
    • Presidents Day
    • Memorial Day
    • Independence Day
    • Labor Day
    • Columbus Day
    • Veterans Day
    • Thanksgiving Day
    • Christmas Day

Originators must account for these non-processing days when determining the effective date to ensure transactions are processed as intended.

Pre-notifications and Authorization

Pre-notifications

Pre-notifications (prenotes) are optional, zero-dollar entries sent through the ACH network to verify the accuracy of the receiver’s banking information before initiating actual transactions. While not mandatory, prenotes help prevent errors and reduce the risk of transaction failures.

Key Points:

  • Timing: Prenotes should be sent at least three business days before the first live transaction.
  • Verification: Receivers’ banks validate the account information and report any errors or discrepancies.
  • Best Practices: Use prenotes when setting up new direct deposit accounts or changing existing account details to ensure accuracy.

Authorization

Authorization is a critical aspect of ACH transactions, ensuring that the originator has obtained proper consent from the receiver for the transaction.

Types of Authorization:

  • Written Authorization: Typically required for recurring transactions, such as direct deposits or automatic bill payments. The authorization must be signed and retained by the originator.
  • Oral Authorization: May be used for certain types of transactions, such as telephone-initiated entries (TEL). The oral authorization must be recorded and retained.
  • Implied Authorization: Applies to corporate transactions where an agreement between parties implies consent for ACH transactions.

Compliance:

  • Nacha Rules: Originators must comply with Nacha rules governing authorization, which stipulate the type and retention of authorization based on the transaction type.
  • Record Retention: Originators must retain authorization records for a specified period (typically two years) to provide proof of consent if required.

Same Day ACH

Same Day ACH is a service provided by the ACH network that allows for the faster processing of ACH transactions. Transactions submitted within specific cut-off times can be processed and settled on the same business day.

Benefits:

  • Speed: Enables the same-day movement of funds, improving cash flow management.
  • Efficiency: Reduces the time between transaction initiation and settlement, which is beneficial for urgent payments.
  • Flexibility: Supports a variety of use cases including payroll, bill payments, and emergency disbursements.
  • Customer Satisfaction: Enhances the customer experience by ensuring timely payments.

Requirements and Limitations

Requirements:

  • Submission Deadlines: Transactions must be submitted by the designated cut-off times to be eligible for same-day processing.
  • Transaction Amount: Must be less than or equal to $1,000,000.
  • SEC Codes: Certain SEC (Standard Entry Class) Codes such as IAT (International ACH Transactions) are not eligible for Same Day ACH.
  • Funds Availability: Receiving banks must make funds available to the receiver by the end of the business day.

Limitations:

  • Fees: Higher fees may apply for same-day transactions compared to standard ACH processing.
  • Cut-off Times: Transactions must meet strict submission deadlines for same-day processing.
  • Eligibility: Not all types of ACH transactions are eligible for same-day processing.

Comparison with Traditional ACH

  • Processing Speed:
    • Same Day ACH: Transactions are processed and settled on the same business day.
    • Traditional ACH: Transactions typically take one to two business days for processing and settlement.
  • Cost:
    • Same Day ACH: Higher fees due to expedited processing.
    • Traditional ACH: Lower fees, suitable for non-urgent transactions.
  • Use Cases:
    • Same Day ACH: Urgent payroll, bill payments, emergency disbursements.
    • Traditional ACH: Regular payroll, routine bill payments, non-urgent transfers.
Classic lightbulb with blue tint
A blue egg made of sponge

Transaction Codes

Transaction Codes are numeric codes used in ACH files to identify the type of transaction and the type of account involved (e.g., checking or savings). These codes are critical for routing transactions correctly and ensuring they are processed accurately.

Detailed List and Descriptions

Checking Accounts (DDA):

  • 22 – Credit to checking account
  • 23 – Credit prenote to checking account
  • 27 – Debit from checking account
  • 28 – Debit prenote to checking account

Savings Accounts:

  • 32 – Credit to savings account
  • 33 – Credit prenote to savings account
  • 37 – Debit from savings account
  • 38 – Debit prenote to savings account

Use in Entry Detail Records

In Entry Detail Records (Type 6), the transaction code is located in positions 02-03 and specifies the nature of the transaction. The code ensures that the transaction is processed correctly, directing the ACH operator on how to handle the entry.

Example: For a credit to a checking account:

				
					6222313801041234567890        0000010000               Jane Doe  0001

Transaction Code (02-03): 22 (indicating a credit to a checking account)

Service Class Codes

Service Class Codes are numeric codes used in ACH files to classify the general nature of transactions within a batch. They indicate whether the batch contains debits, credits, or both, and are essential for processing and balancing ACH files.

Detailed List and Descriptions

  • 200 – Mixed debits and credits
  • 220 – Credits only
  • 225 – Debits only

Use in Batch Header and Control Records

Service Class Codes are used in both the Batch Header Record (Type 5) and the Batch Control Record (Type 8) to define the nature of the transactions in the batch.

Batch Header Record (Type 5):

				
					5200Company Name                         123456789 CCD 09120201   112
  • Service Class Code (02-04): 220 (indicating credits only)

Batch Control Record (Type 8):

				
					82000000020023138010400002000000000001000000000000200000000     112
  • Service Class Code (02-04): 220 (matching the Batch Header Record)
A blue USB plug into a cloud
A blue mail emoticon

Standard Entry Class (SEC) Codes

Standard Entry Class (SEC) Codes are three-character codes used in ACH files to identify the type of transaction and the payment method. These codes provide important information about the nature of the transaction, whether it is consumer or corporate, and the format of the data being transmitted. SEC Codes ensure that transactions are processed correctly and efficiently within the ACH network.

Commonly Used SEC Codes

ARC (Accounts Receivable Entries)

Overview: Used for the conversion of checks received at a lockbox location or via mail for bill payments. Purpose: Allows businesses to convert paper checks into electronic ACH debits. Transaction Type: Debit Use Case: Utility companies, insurance payments.

BOC (Back Office Conversion)

Overview: Used for the conversion of checks received at the point-of-purchase or manned bill payment locations, processed later in a back-office environment. Purpose: Allows businesses to convert checks into electronic ACH debits after the point of sale. Transaction Type: Debit Use Case: Retail stores, bill payment centers.

CCD (Corporate Credit or Debit)

Overview: Used for transactions between corporate entities, including both credit and debit entries. Purpose: Facilitates business-to-business payments. Transaction Type: Credit or Debit Use Case: Vendor payments, corporate disbursements.

CIE (Customer Initiated Entries)

Overview: Used for credit transactions initiated by consumers through a bill payment service provider. Purpose: Allows consumers to make payments to businesses electronically. Transaction Type: Credit Use Case: Online bill payments.

CTX (Corporate Trade Exchange)

Overview: Used for complex corporate transactions that may include multiple addenda records. Purpose: Facilitates detailed business-to-business transactions with extensive remittance information. Transaction Type: Credit or Debit Use Case: Large-scale corporate payments, trade payments.

IAT (International ACH Transaction)

Overview: Used for transactions involving a financial agency’s office located outside the territorial jurisdiction of the United States. Purpose: Supports cross-border ACH transactions. Transaction Type: Credit or Debit Use Case: International payroll, cross-border payments.

POP (Point of Purchase)

Overview: Used for the conversion of checks received at the point of purchase into ACH debits. Purpose: Allows retailers to convert paper checks into electronic debits at the time of sale. Transaction Type: Debit Use Case: Retail stores, service providers.

POS (Point of Sale)

Overview: Used for debit transactions initiated at electronic terminals using a card or other access device. Purpose: Facilitates electronic payments at the point of sale. Transaction Type: Debit Use Case: In-store purchases, ATM withdrawals.

PPD (Prearranged Payment and Deposit)

Overview: Used for recurring consumer transactions, including direct deposits and direct payments. Purpose: Automates recurring transactions between consumers and businesses. Transaction Type: Credit or Debit Use Case: Payroll deposits, subscription services.

RCK (Re-presented Check Entries)

Overview: Used to represent a check that was previously processed and returned due to insufficient or uncollected funds. Purpose: Allows businesses to electronically re-present returned checks for payment. Transaction Type: Debit Use Case: Check re-presentment, collections.

TEL (Telephone Initiated Entries)

Overview: Used for transactions authorized by consumers over the telephone. Purpose: Enables businesses to initiate ACH debits based on verbal authorization. Transaction Type: Debit Use Case: Telemarketing payments, bill payments over the phone.

WEB (Internet-Initiated/Mobile Entries)

Overview: Used for transactions authorized by consumers through the internet or mobile devices. Purpose: Facilitates electronic payments initiated online or via mobile apps. Transaction Type: Credit or Debit Use Case: Online shopping, mobile payments.

ACH File Header and Trailer Records

File Header Record

Field-by-Field Breakdown

The File Header Record marks the beginning of the ACH file and provides essential information about the file’s origin and destination. Here is a detailed breakdown of each field:

  1. Record Type Code (01-01):

    • Position: 1-1
    • Length: 1
    • Content: Always “1”
    • Description: Identifies the record as a File Header Record.

  2. Priority Code (02-03):

    • Position: 2-3
    • Length: 2
    • Content: Always “01”
    • Description: Indicates the file’s priority level.

  3. Immediate Destination (04-13):

    • Position: 4-13
    • Length: 10
    • Content: Bnnnnnnnn (9-digit routing number preceded by a blank)
    • Description: The routing number of the institution receiving the ACH file.

  4. Immediate Origin (14-23):

    • Position: 14-23
    • Length: 10
    • Content: Bnnnnnnnn (9-digit routing number preceded by a blank)
    • Description: The routing number of the institution sending the ACH file.

  5. File Creation Date (24-29):

    • Position: 24-29
    • Length: 6
    • Content: YYMMDD
    • Description: The date the ACH file was created.

  6. File Creation Time (30-33):

    • Position: 30-33
    • Length: 4
    • Content: HHMM
    • Description: The time the ACH file was created using a 24-hour format.

  7. File ID Modifier (34-34):

    • Position: 34-34
    • Length: 1
    • Content: A-Z, 0-9
    • Description: A unique identifier for the file, ensuring no duplicate files on the same day.

  8. Record Size (35-37):

    • Position: 35-37
    • Length: 3
    • Content: Always “094”
    • Description: Specifies the length of each record.

  9. Blocking Factor (38-39):

    • Position: 38-39
    • Length: 2
    • Content: Always “10”
    • Description: Specifies the number of records in a block.

  10. Format Code (40-40):

    • Position: 40-40
    • Length: 1
    • Content: Always “1”
    • Description: Identifies the file format.

  11. Immediate Destination Name (41-63):

    • Position: 41-63
    • Length: 23
    • Content: Alphanumeric
    • Description: Name of the receiving institution.

  12. Immediate Origin Name (64-86):

    • Position: 64-86
    • Length: 23
    • Content: Alphanumeric
    • Description: Name of the originating institution.

  13. Reference Code (87-94):

    • Position: 87-94
    • Length: 8
    • Content: Alphanumeric
    • Description: Optional field for additional information pertinent to the file.

Example Layout

				
					101 031300012 2313801040123456789                   091202010000001

File Control Record

Field-by-Field Breakdown

The File Control Record marks the end of the ACH file and provides summary information about the entire file. Here is a detailed breakdown of each field:

  1. Record Type Code (01-01):

    • Position: 1-1
    • Length: 1
    • Content: Always “9”
    • Description: Identifies the record as a File Control Record.

  2. Batch Count (02-07):

    • Position: 2-7
    • Length: 6
    • Content: Numeric
    • Description: The total number of batches in the file.

  3. Block Count (08-13):

    • Position: 8-13
    • Length: 6
    • Content: Numeric
    • Description: The total number of blocks in the file. Each block contains 10 records.

  4. Entry/Addenda Count (14-21):

    • Position: 14-21
    • Length: 8
    • Content: Numeric
    • Description: The total number of Entry Detail and Addenda Records in the file.

  5. Entry Hash (22-31):

    • Position: 22-31
    • Length: 10
    • Content: Numeric
    • Description: The hash total of all the routing numbers in the Entry Detail Records.

  6. Total Debit Entry Dollar Amount in File (32-43):

    • Position: 32-43
    • Length: 12
    • Content: $$$$$$$$$$cc
    • Description: The sum of all debit transactions in the file.

  7. Total Credit Entry Dollar Amount in File (44-55):

    • Position: 44-55
    • Length: 12
    • Content: $$$$$$$$$$cc
    • Description: The sum of all credit transactions in the file.

  8. Reserved (56-94):

    • Position: 56-94
    • Length: 39
    • Content: Blank
    • Description: Reserved for future use and should be blank.

Example Layout

				
					90000010000010000000200231380104000020000000000010000000000020000000
A blue key
A group of blue figures

Table: Type 8 Batch Trailer Record (Applies to all SEC codes except IAT)

Field Number Field Name Position in Record Length Data Required? Content Description/Notes
1 Record Type Code 01-01 1 Y 8 Always "8."
2 Service Class Code 02-04 3 Y numeric Identifies the general classification of dollar entries to be exchanged.
3 Entry/Addenda Count 05-10 6 Y numeric A tally of each Entry Detail record and each Addenda Record processed within the batch.
4 Entry Hash 11-20 10 Y numeric The sum of all the Receiving DFI Identification fields contained within the Entry Detail Records in a batch.
5 Total Debit Entry Dollar Amount 21-32 12 Y numeric Contains the accumulated entry detail debit totals within the batch.
6 Total Credit Entry Dollar Amount 33-44 12 Y numeric Contains the accumulated entry detail credit totals within the batch.
7 Company Identification 45-54 10 Y alphanumeric Contains the value of the Company Identification field 5 in the Company/Batch Header record.
8 Message Authentication Code 55-73 19 N numeric The 8-character code from a special key used in conjunction with the DES algorithm. It is used to validate the authenticity of the ACH Entries.
9 Reserved 74-79 6 N/A blanks
10 Originating DFI Identification 80-87 8 Y numeric Contains the value of the Originating DFI Identification field 12 of the Company/Batch Header record.
11 Batch Number 88-94 7 Y numeric Contains the value of the Batch Number in field 13 of the Company/Batch Header Record.

Data Retrieved From: https://achdevguide.nacha.org/ach-file-details

ACH Batch Header and Trailer Records

Batch Header Record

Field-by-Field Breakdown

The Batch Header Record marks the beginning of a batch within the ACH file and contains information about the originator, the type of transactions, and the intended processing date. Here is a detailed breakdown of each field:

  1. Record Type Code (01-01):

    • Position: 1-1
    • Length: 1
    • Content: Always “5”
    • Description: Identifies the record as a Batch Header Record.

  2. Service Class Code (02-04):

    • Position: 2-4
    • Length: 3
    • Content: Numeric (200, 220, or 225)
    • Description: Indicates whether the batch contains credits, debits, or both.

  3. Company Name (05-20):

    • Position: 5-20
    • Length: 16
    • Content: Alphanumeric
    • Description: Name of the originator company.

  4. Company Discretionary Data (21-40):

    • Position: 21-40
    • Length: 20
    • Content: Alphanumeric
    • Description: Optional field for company-specific information.

  5. Company Identification (41-50):

    • Position: 41-50
    • Length: 10
    • Content: Alphanumeric
    • Description: Unique identifier assigned to the originator by the ODFI.

  6. Standard Entry Class Code (51-53):

    • Position: 51-53
    • Length: 3
    • Content: Alphanumeric (e.g., PPD, CCD)
    • Description: Indicates the type of transactions within the batch.

  7. Company Entry Description (54-63):

    • Position: 54-63
    • Length: 10
    • Content: Alphanumeric
    • Description: Description of the purpose of the transactions (e.g., Payroll, Rent).

  8. Company Descriptive Date (64-69):

    • Position: 64-69
    • Length: 6
    • Content: Alphanumeric
    • Description: Optional field for a date related to the transactions.

  9. Effective Entry Date (70-75):

    • Position: 70-75
    • Length: 6
    • Content: YYMMDD
    • Description: Date the transactions are intended to be processed.

  10. Settlement Date (Julian) (76-78):

    • Position: 76-78
    • Length: 3
    • Content: Numeric
    • Description: Inserted by the ACH operator.

  11. Originator Status Code (79-79):

    • Position: 79-79
    • Length: 1
    • Content: Numeric (usually “1”)
    • Description: Indicates the originator’s status.

  12. Originating DFI Identification (80-87):

    • Position: 80-87
    • Length: 8
    • Content: TTTTAAAA (Routing number of the originating financial institution)
    • Description: Routing number of the ODFI.

  13. Batch Number (88-94):

    • Position: 88-94
    • Length: 7
    • Content: Numeric
    • Description: Sequential number assigned to the batch within the file.

Example Layout

				
					5200Company Name                         123456789 CCD 09120201   112

Batch Control Record

Field-by-Field Breakdown

The Batch Control Record marks the end of a batch within the ACH file and contains summary information about the transactions within the batch. Here is a detailed breakdown of each field:

  1. Record Type Code (01-01):

    • Position: 1-1
    • Length: 1
    • Content: Always “8”
    • Description: Identifies the record as a Batch Control Record.

  2. Service Class Code (02-04):

    • Position: 2-4
    • Length: 3
    • Content: Numeric (must match the Service Class Code in the Batch Header Record)
    • Description: Indicates whether the batch contains credits, debits, or both.

  3. Entry/Addenda Count (05-10):

    • Position: 5-10
    • Length: 6
    • Content: Numeric
    • Description: Total number of Entry Detail and Addenda Records in the batch.

  4. Entry Hash (11-20):

    • Position: 11-20
    • Length: 10
    • Content: Numeric
    • Description: Hash total of the routing numbers in the Entry Detail Records.

  5. Total Debit Entry Dollar Amount (21-32):

    • Position: 21-32
    • Length: 12
    • Content: $$$$$$$$$$cc
    • Description: Sum of all debit transactions in the batch.

  6. Total Credit Entry Dollar Amount (33-44):

    • Position: 33-44
    • Length: 12
    • Content: $$$$$$$$$$cc
    • Description: Sum of all credit transactions in the batch.

  7. Company Identification (45-54):

    • Position: 45-54
    • Length: 10
    • Content: Alphanumeric (must match the Company Identification in the Batch Header Record)
    • Description: Unique identifier assigned to the originator by the ODFI.

  8. Message Authentication Code (55-73):

    • Position: 55-73
    • Length: 19
    • Content: Alphanumeric
    • Description: Optional field used for additional security.

  9. Reserved (74-79):

    • Position: 74-79
    • Length: 6
    • Content: Blank
    • Description: Reserved for future use.

  10. Originating DFI Identification (80-87):

    • Position: 80-87
    • Length: 8
    • Content: TTTTAAAA (Routing number of the originating financial institution)
    • Description: Routing number of the ODFI.

  11. Batch Number (88-94):

    • Position: 88-94
    • Length: 7
    • Content: Numeric (must match the Batch Number in the Batch Header Record)
    • Description: Sequential number assigned to the batch within the file.

Example Layout

				
					82000000020023138010400002000000000001000000000000200000000     112

Entry and Addenda Records

PPD, CCD, WEB, TEL Entry Records

Field-by-Field Breakdown

The Entry Detail Record (Type 6) contains the details of individual transactions within a batch. Below is a breakdown of the key fields for PPD (Prearranged Payment and Deposit), CCD (Corporate Credit or Debit), WEB (Internet-Initiated/Mobile Entries), and TEL (Telephone-Initiated Entries) entry records:

  1. Record Type Code (01-01):

    • Position: 1-1
    • Length: 1
    • Content: Always “6”
    • Description: Identifies the record as an Entry Detail Record.

  2. Transaction Code (02-03):

    • Position: 2-3
    • Length: 2
    • Content: Numeric (e.g., 22 for credit to checking, 27 for debit from checking)
    • Description: Identifies the type of transaction and the type of account.

  3. Receiving DFI Identification (04-11):

    • Position: 4-11
    • Length: 8
    • Content: TTTTAAAA (Routing number of the receiving bank)
    • Description: Routing number of the receiving financial institution.

  4. Check Digit (12-12):

    • Position: 12-12
    • Length: 1
    • Content: Numeric
    • Description: A single digit to validate the routing number.

  5. DFI Account Number (13-29):

    • Position: 13-29
    • Length: 17
    • Content: Alphanumeric
    • Description: The account number of the receiver.

  6. Amount (30-39):

    • Position: 30-39
    • Length: 10
    • Content: $$$$$$$$cc
    • Description: The amount of the transaction.

  7. Identification Number (40-54):

    • Position: 40-54
    • Length: 15
    • Content: Alphanumeric
    • Description: Optional field for additional identification of the transaction.

  8. Receiving Individual/Company Name (55-76):

    • Position: 55-76
    • Length: 22
    • Content: Alphanumeric
    • Description: The name of the receiver.

  9. Discretionary Data (77-78):

    • Position: 77-78
    • Length: 2
    • Content: Alphanumeric
    • Description: Optional field for additional information.

  10. Addenda Record Indicator (79-79):

    • Position: 79-79
    • Length: 1
    • Content: Numeric (0 for no addenda, 1 for addenda present)
    • Description: Indicates whether an addenda record is attached.

  11. Trace Number (80-94):

    • Position: 80-94
    • Length: 15
    • Content: Numeric (TTTTAAAA#########)
    • Description: A unique identifier for the transaction, including the originating DFI identification and a unique number.

Example Layout

				
					6222313801041234567890        0000010000               Jane Doe  0001

Addenda Records

Field-by-Field Breakdown

The Addenda Record (Type 7) provides additional information related to the Entry Detail Record. It is used to convey supplementary details, instructions, or explanations about the transaction.

  1. Record Type Code (01-01):

    • Position: 1-1
    • Length: 1
    • Content: Always “7”
    • Description: Identifies the record as an Addenda Record.

  2. Addenda Type Code (02-03):

    • Position: 2-3
    • Length: 2
    • Content: Numeric (e.g., 05 for payment-related information)
    • Description: Indicates the type of information provided in the addenda record.

  3. Payment Related Information (04-83):

    • Position: 4-83
    • Length: 80
    • Content: Alphanumeric
    • Description: Contains freeform text for additional details about the transaction.

  4. Addenda Sequence Number (84-87):

    • Position: 84-87
    • Length: 4
    • Content: Numeric
    • Description: Sequence number of the addenda record, starting with 1.

  5. Entry Detail Sequence Number (88-94):

    • Position: 88-94
    • Length: 7
    • Content: Numeric (matches the last seven digits of the trace number of the related Entry Detail Record)
    • Description: Identifies the corresponding Entry Detail Record.

Example Layout

				
					705Payment Related Information                                        0001001
A perfectly curled blue ribbon.

Table: PPD and CCD Entry

Field Number Field Name Position in Record Length Data Required? Content Description/Notes
1 Record Type Code 01-01 1 Y 6 Always "6."
2 Transaction Code 02-03 2 Y numeric Trancode for the transaction - see Common Data Elements for trancode definitions.
3 Receiving DFI Identification 04-11 8 Y TTTTAAAA This is the first 8 digits of the routing and transit number of the receiving bank (where the recipient account is located).
4 Check Digit 12-12 1 Y numeric This is the check digit (9th digit) of the routing and transit number of the receiving bank (where the recipient account is located).
5 DFI Account Number 13-29 17 Y alphanumeric This is the account number of the recipient.
6 Amount 30-39 10 Y $$$$$$$$cc This is the amount of the transaction.
7 Identification Number 40-54 15 N alphanumeric This is an optional field to identify the transaction to the Receiver.
8 Receiving Individual/Company Name 55-76 22 Y alphanumeric Entered by the Originator to provide additional identification of the Receiver and may be helpful in identifying return entries. PPD Return Fee entries authorized by notice must contain the same information identified within the Individual Name field of the ARC, BOC, or POP entry to which the Return Fee Entry relates.
9 Discretionary Data 77-78 2 N alphanumeric ODFI may include codes, of significance to them, to enable specialized handling of the entry.
10 Addenda Record Indicator 79-79 1 Y numeric For Health Care EFT Transactions (except Prenotification Entries), the Addenda Record Indicator of the CCD Entry must always contain a value of "1."
11 Trace Number 80-94 15 Y numeric Assigned by the ODFI in ascending sequence that uniquely identifies each entry within a batch and the file.

Data Retrieved From: https://achdevguide.nacha.org/ach-file-details

PPD, CCD & WEB Addenda Records

Field Number Field Name Position in Record Length Data Required? Content Description/Notes
1 Record Type Code 01-01 1 Y 7 Always "7."
2 Addenda Type Code 02-03 2 Y 05 Always "05."
3 Payment Related Information 04-83 80 N alphanumeric This is an optional freeform text field that will travel with the payment instruction to the RDFI. Please note that this information may or may not be displayed to the recipient, based on the bank's capabilities, and method of access (i.e., online banking, statement, etc.) For Health Care EFT Transactions, this must always contain the ASC X12 Version 5010 835 TRN Segment.
4 Addenda Sequence Number 84-87 4 Y numeric PPD, CCD and WEB only allow for one addenda per record, therefore the value will always be "1."
5 Entry Detail Sequence Number 88-94 7 Y numeric This number is the same as the last seven digits of the trace number of the related Entry or Corporate Entry Detail Record.

Data Retrieved From: https://achdevguide.nacha.org/ach-file-details

A blue geolocation pin made of stone

WEB & TEL Entry:

Field Number Field Name Position in Record Length Data Required? Content Description/Notes
1 Record Type Code 01-01 1 Y 6 Always "6."
2 Transaction Code 02-03 2 Y numeric Trancode for the transaction - see Common Data Elements for trancode definitions.
3 Receiving DFI Identification 04-11 8 Y TTTTAAAA This is the first 8 digits of the routing and transit number of the receiving bank (where the recipient account is located).
4 Check Digit 12-12 1 Y numeric This is the check digit (9th digit) of the routing and transit number of the receiving bank (where the recipient account is located).
5 DFI Account Number 13-29 17 Y alphanumeric This is the account number of the recipient.
6 Amount 30-39 10 Y $$$$$$$$cc This is the amount of the transaction.
7 Individual Identification Number 40-54 15 N alphanumeric For Person-to-Person WEB credit Entries, this field is required and contains the name of the consumer Originator. For WEB debit Entries, this field is optional and is used at the discretion of the Originator.
8 Individual Name 55-76 22 Y alphanumeric Entered by the Originator to provide additional identification of the Receiver and may be helpful in identifying return entries.
9 Payment Type Code 77-78 2 Y alphanumeric For recurring TEL and WEB entries, this field must contain the value "R". For Single-Entry TEL, this field must either be the value "S" or space-filed. For Single-Entry WEB, this field must contain the value "S." Beginning on Sept. 17, 2021, this field will allow Originators to include codes, of significance to them, to enable specialized handling of the entry. There is no standardized interpretation for the value of this field.
10 Addenda Record Indicator 79-79 1 Y numeric For TEL, the value will be "0" - TEL does not allow for an addenda record. For WEB, the value will be "0" or "1" - WEB allows for one optional addenda record.
11 Trace Number 80-94 15 Y numeric Assigned by the ODFI in ascending sequence that uniquely identifies each entry within a batch and the file.

Data Retrieved From: https://achdevguide.nacha.org/ach-file-details

Tax Payments

Use of ACH for Tax Payments

ACH (Automated Clearing House) is widely used for tax payments, offering a secure, efficient, and convenient method for businesses and individuals to pay taxes electronically. ACH transactions for tax payments streamline the process, reducing paperwork and ensuring timely delivery of funds to tax authorities.

Benefits of Using ACH for Tax Payments

  • Efficiency: ACH payments automate the tax payment process, reducing the need for manual checks and paperwork.
  • Timeliness: Payments are processed quickly, ensuring that tax payments are made on time, avoiding late fees and penalties.
  • Security: ACH transactions are encrypted and processed through secure channels, providing a high level of security for sensitive financial information.
  • Convenience: Taxpayers can schedule recurring payments, simplifying the management of regular tax obligations.

Common Tax Payments via ACH

  • Federal Taxes: Payments to the IRS, including income taxes, payroll taxes, and estimated taxes.
  • State Taxes: Payments to state tax authorities, including sales taxes, income taxes, and other state-specific tax obligations.
  • Local Taxes: Payments to local tax authorities for property taxes, local income taxes, and other local tax requirements.

Addenda Records for Tax Payments (TXP)

Addenda Records play a crucial role in ACH transactions for tax payments, as they provide the necessary details that accompany the payment. The TXP (Tax Payment) addenda record format is used to convey specific tax-related information to the tax authority, ensuring that the payment is accurately applied to the correct taxpayer and tax obligation.

Key Fields in a TXP Addenda Record

The TXP addenda record typically includes the following fields:

  1. TXP01 – Taxpayer Identification Number:

    • Content: The taxpayer’s identification number (e.g., Employer Identification Number (EIN) or Social Security Number (SSN)).
    • Purpose: Identifies the taxpayer making the payment.

  2. TXP02 – Tax Payment Type Code:

    • Content: A code that specifies the type of tax being paid (e.g., federal income tax, state sales tax).
    • Purpose: Indicates the nature of the tax payment.

  3. TXP03 – Tax Period End Date:

    • Content: The end date of the tax period for which the payment is being made (formatted as YYMMDD).
    • Purpose: Specifies the tax period associated with the payment.

  4. TXP04 – Amount Type:

    • Content: A code that indicates the type of amount being paid (e.g., T for tax, P for penalty, I for interest).
    • Purpose: Identifies the type of payment.

  5. TXP05 – Amount:

    • Content: The amount of the tax payment.
    • Purpose: Specifies the monetary amount of the tax payment.

  6. TXP06 – Settlement Date:

    • Content: The date on which the payment should be settled (formatted as YYMMDD).
    • Purpose: Indicates when the funds should be transferred.

Example Layout of a TXP Addenda Record

A typical TXP addenda record might look like this:

				
					705TXP*123456789*00100*230331*T*00012345.67*230401<pre data-line="" class="highlight-height language-javascript line-numbers">
<code readonly="true" class="language-javascript">
<xmp>705TXP*123456789*00100*230331*T*00012345.67*230401\0001001
01001
  • 705: Record Type Code indicating an addenda record.
  • TXP: Tax Payment identifier.
  • 123456789: Taxpayer Identification Number.
  • 00100: Tax Payment Type Code.
  • 230331: Tax Period End Date (March 31, 2023).
  • T: Amount Type Code (Tax).
  • 00012345.67: Amount of the tax payment ($12,345.67).
  • 230401: Settlement Date (April 1, 2023).
  • 0001: Addenda Sequence Number.
  • \0001001: Entry Detail Sequence Number.

Benefits of Using TXP Addenda Records

  • Accuracy: Ensures that tax payments are applied correctly to the taxpayer’s account and the intended tax period.
  • Detail: Provides tax authorities with all necessary information to process the payment without ambiguity.
  • Compliance: Helps meet regulatory requirements for electronic tax payments.

Compliance and Best Practices

Nacha Rules and Guidelines

Nacha (National Automated Clearing House Association) governs the ACH network and sets the rules and guidelines that ensure the secure and efficient processing of ACH transactions. Adhering to Nacha rules is essential for maintaining compliance and avoiding penalties.

Key Nacha Rules and Guidelines

  1. Authorization Requirements:

    • Obtain proper authorization from the receiver before initiating ACH transactions.
    • Maintain records of authorization for a specified period (typically two years).

  2. Transaction Limits:

    • Adhere to transaction limits, including those for Same Day ACH transactions, which must be less than or equal to $1,000,000.

  3. Data Security:

    • Ensure sensitive information, such as account numbers and personal identification details, are securely encrypted during transmission and storage.

  4. ACH Entry Formatting:

    • Follow the prescribed format for ACH files, including record lengths, field positions, and content specifications.

  5. Timely Processing:

    • Submit ACH files within the appropriate processing windows and cut-off times to ensure timely settlement.

  6. Error Resolution:

    • Implement procedures for handling and resolving errors, returns, and disputed transactions promptly and in accordance with Nacha rules.

Common Compliance Issues

  1. Unauthorized Transactions:

    • Initiating transactions without proper authorization from the receiver can lead to disputes and penalties.
    • Best Practice: Always obtain and retain authorization records.

  2. Data Security Breaches:

    • Failing to protect sensitive information can result in data breaches and financial loss.
    • Best Practice: Use strong encryption and secure storage methods for sensitive data.

  3. Incorrect Formatting:

    • Submitting ACH files with incorrect formats or missing fields can cause delays and rejections.
    • Best Practice: Validate ACH file formats before submission.

  4. Late Submissions:

    • Missing cut-off times for ACH submissions can delay the processing of transactions.
    • Best Practice: Schedule submissions well in advance of cut-off times.

  5. Return Rate Violations:

    • High rates of returned transactions due to errors or insufficient funds can lead to increased scrutiny and penalties.
    • Best Practice: Monitor and manage return rates, and address issues promptly.

Best Practices for ACH File Creation and Submission

  1. Obtain and Retain Proper Authorizations:

    • Ensure all transactions are authorized by the receiver.
    • Maintain records of authorization for future reference and compliance audits.

  2. Use Secure Systems and Processes:

    • Implement robust security measures to protect sensitive data.
    • Use encryption for data transmission and secure storage for records.

  3. Validate ACH File Formats:

    • Use software tools to validate the format and content of ACH files before submission.
    • Check for correct field lengths, data types, and mandatory fields.

  4. Submit ACH Files Timely:

    • Plan submissions to meet processing windows and cut-off times.
    • Allow for any potential delays or issues that might arise.

  5. Monitor and Manage Return Rates:

    • Regularly review transaction reports to identify and address issues leading to returns.
    • Work with receivers to resolve any recurring issues.

  6. Conduct Regular Audits and Reviews:

    • Perform periodic audits of ACH processes and records to ensure compliance with Nacha rules.
    • Review and update internal policies and procedures as needed.

  7. Stay Informed About Regulatory Changes:

    • Keep up to date with changes in Nacha rules and other regulatory requirements.
    • Adjust practices and procedures accordingly to maintain compliance.

  8. Provide Training for Staff:

    • Train employees involved in ACH processing on Nacha rules and best practices.
    • Ensure staff are aware of the importance of compliance and data security.
A light blue matte globe

Disclaimer: The content provided on this webpage is for informational purposes only and is not intended to be a substitute for professional advice. While we strive to ensure the accuracy and timeliness of the information presented here, the details may change over time or vary in different jurisdictions. Therefore, we do not guarantee the completeness, reliability, or absolute accuracy of this information. The information on this page should not be used as a basis for making legal, financial, or any other key decisions. We strongly advise consulting with a qualified professional or expert in the relevant field for specific advice, guidance, or services. By using this webpage, you acknowledge that the information is offered “as is” and that we are not liable for any errors, omissions, or inaccuracies in the content, nor for any actions taken based on the information provided. We shall not be held liable for any direct, indirect, incidental, consequential, or punitive damages arising out of your access to, use of, or reliance on any content on this page.

Trusted By

Trusted by 3.2M+ Employees: 20 Years of Service Across Startups to Fortune 500 Enterprises

Join our ever-growing community of satisfied customers today and experience the unparalleled benefits of TimeTrex.

Logo for H&R Block
Hilton Hotels and Resorts logo
HP computers logo
Oracle logo black and white
PWC brand logo
Texas A&M University logo
Mcdonald's brand logo
New York Stock Exchange Logo black and white
Walmart brand logo
London Drugs logo black and white

Strength In Numbers

Join The Companies Already Benefiting From TimeTrex

Users
0
Companies
0
Years
0

Time To Clock-In

Start your 30-day free trial!

Experience the Ultimate Workforce Solution and Revolutionize Your Business Today

Get Started For Free
  • Eliminate Errors
  • Simple & Easy To Use
  • Real-time Reporting
TimeTrex Mobile App Hand
TimeTrex Logo

Saving businesses time and money through better workforce management since 2003.

Contact Us

Facebook-f Twitter Youtube Linkedin-in

Solutions

Products

Services

Guides & Tools

Support

Company

Copyright © 2023 TimeTrex. All Rights Reserved.

Privacy Policy
Terms of Use