Overview of ACH

Learn about ACH Payments and review example ACH files.

🏁 Get Started


1. Learn

If you are just learning about TabaPay you can begin at Getting Started, and About TabaPay.

2. Chat

To Make your first API Call, you will first need access to Sandbox. Talk to sales to discuss your use case or get help at [email protected].

3. Test

Once you have access to sandbox from TabaPay Support, look at some code samples with recipes or feel free to post your questions in the developer forum.

📘

Payload Should Be Condensed

Each API request body should be formatted in condensed json when sending a request to the TabaPay API

Note: If you don’t have access to sandbox, please reach out to [email protected] .

ACH Network is the National Automated Clearing House (ACH) for electronic funds transfers. It processes financial transactions for consumers, businesses, and federal, state, and local governments. ACH processes large volumes of credit and debit transactions in batches. Short for "Automated Clearing House", ACH credit transfers include direct deposit for payroll, Social Security and other benefit payments, tax refunds, and vendor payments. ACH direct debit transfers include consumer payments on insurance premiums, mortgage loans, and other kinds of bills.

The rules and regulations that govern the ACH network are established by National Automated Clearing House Association (NACHA). In 2018, the network processed 23 billion transactions with a total value of $51.2 trillion.

👍

Available in Unified API

TabaPay ACH is available via both our Unified API as well as via file-based exchanges.

For more information please look at our ACH via API guide.

Want to get enabled for ACH in Unified API? Email [email protected]

How ACH Payments Work

For each ACH payment from a payor's bank account to a payee's bank account, there are effectively two ACH transactions created and transmitted, namely an ACH Debit transaction and an ACH Credit transaction. In the case of a payor and payee having an account at the same financial institution, there is only one ACH transaction, which is often called an "on-us" transaction.

ACH Debit transaction

The payee's sending institution creates, batches, and transmits an ACH Debit transaction to the payor's receiving institution. The ACH Debit transaction instructs the receiving institution to withdraw and transmit the funds from the payor's bank account to the sending institution.

The receiving institution must send the return to the sending institution by the end of the following business day if it is unable to debit the funds from the payor's account, such if the account was not found, the account was closed, or the account was frozen.

For an ACH Debit transaction, the sending institution may be a third-party bank, rather than the payee's bank.

ACH Credit transaction

The payor's sending institution creates, batches, and transmits an ACH credit to the payee's receiving institution. The ACH Credit transaction instructs the receiving institution to credit the funds to the payee's bank account.

The receiving institution must send the return to the sending institution by the end of the following business day if it is unable to credit the funds to the payee's account, such if the account was not found, the account was closed, or the account was frozen.

For an ACH Credit, the sending institution may not be a third-party bank, rather than the payor's bank.


Same Day vs Next Day

There are two types of ACH settlements.

Next-day ACH

ACH debits and credits are transactions that are created, batched, and transmitted typically by way of a financial institution's connection to the ACH Network.

With next-day ACH, each ACH transaction is cleared overnight. The sending institution (called the Originating Depository Financial Institution) sends the transaction to the receiving institution (called the Receiving Depository Financial Institution). When the receiving institution receives the transaction, it has until the end of the next working day to send a rejection to the sending institution. If the sending institution does not receive a return from the receiving institution by the morning of the third business day, then the transaction is deemed to be successful.

Same-day ACH

With same-day ACH, settlement can happen the same day. The sending institution can transmit files to the receiving institution the same day, expediting the processing of ACH transactions. The receiving institution still has two business days in which to send a return, so there will still be a delay of two business days in same-day ACH debit transactions. On the other hand, ACH credit transactions can be credited on the same business day as along as the receiving institution receives the ACH transaction within the correct window.

Transactions exceeding $1,000,000 and international transactions are not eligible for same-day ACH.


API Integration

For how ACH API integration works, refer ACH via API

ACH Files

Refer to ACH File Overview by NACHA to understand ACH file formatting.

File Details

  • File sharing details will be provided to the client
  • Input File name: yyyymmdd_ISO_MID_ACHInput_N_v2-5.csv (sent to TabaPay)
  • Output File name: yyyymmdd_ISO_MID_ACHOutput.csv (received from TabaPay)
  • Processed file: yyyymmdd_ISO_MID_ACHProcessed_A.csv (received from TabaPay)
    • yyyymmdd=file date
    • N=sequence number (1..n) if multiple files per cycle used
    • A=file modifier (A..Z)
    • For ISO, do not use MID
  • Comma separator for each field

Input files

  • Merchant deposits input file(s) into the file sharing tool.
  • All input files since last batch are processed.
  • TabaPay moves Input files to 'Inboxprocessed' after processing.
  • Email to [email protected] with copy to [email protected]: subject: NAME ACH; total debits and $s, total credits and $s
  • Cut-off times:
    • File based -> Same day: 7:00 AM PT; Next day: 5:30 PM PT
    • API -> Same day and Next day: 12:00 PM PT (Same window)
  • File cutoff missed will be moved to next window
  • Confirmation of processing email to merchant
  • TabaPay output files, processed files, return files:
  • Merchant Pickup return files, Processed files, and Output files in the 'Outbox'
  • Processed file delivered within minutes of ACH files being processed by bank; One file for each merchant batch.
  • Output file delivered next business day; same format as Processed file - with Trace ID and processed time from bank

Guidelines

  • All files received prior to same day cutoff are processed as same day, otherwise processed as next day.
  • ISO+MID assigned by TabaPay.
  • CompanyName, CompanyID assigned by TabaPay.
  • IIN must be unique by CompanyName, CompanyID as traceIDs and returns provided by IIN. 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.
  • Offset account is always merchant's DDA at ODFI. Option to include offset records (default is no offset).

Explanation for each file

There are 4 files associated with ACH.

  1. Input file -> this file is generated by the merchant and contains the transaction requests.
  2. Processed file -> this file is generated by TabaPay. It indicates that transactions that have been sent to the bank.
    1. Status: Processed -> Transaction has been sent to the bank.
    2. Status: Rejected -> Transaction was rejected, status codes below.

📘

Processed File Is Not a Completed File

A processed file that is generated by does not indicate the payment has been completed, but only that the transaction has been sent to the bank.

  1. Output file (Conditional) -> This file is generated by some banks to let us know when the transaction was sent to the Fed. This file has the exact same format as the Processed file, and will include the Trace ID from the Fed. Might take up to 2 days to be sent.
  2. Return file -> This file contains a list of returned transactions. Can come back 6 to 7 days later.

SFTP Push. TabaPay pushes ACH files via SFTP. Security options can include:

  1. Merchant whitelists TabaPay IP
  2. SFTP ID and Password
  3. TabaPay public key for SFTP security (ID or ID+PW)
  4. File encryption using Merchant public PGP key

ACH Request

Refer to ACH API for fields in the API request. View the following file format option for ACH file requests, or view a NACHA file format.

For file based format refer to ACH File Exchange


ACH Response

Response and Processed File Format

ISO

Assigned by TabaPay

MID

Assigned by TabaPay

Entry Type

CCD, PPD, Web

3 alpha

Status

Output file: Complete, Error. Processed file: Accepted or Rejected

See Response Codes

Result

0, Response Code

See Response Codes

Same Day or Next Day

S, N

1 alpha

Same Day must be in by cutoff time or converts to next day

Processed date

mm-dd-yyyy

Settlement date

mm-dd-yyyy

Amount

########.##

999999.99

2 decimal places

IIN

abcdefghijklmnop

15 alpha-numeric

No commas, no blanks. No symbols

Trace ID

################

15 numeric

Output file only - from bank

First name

doe

22 alpha-numeric combined First Name and Last Name

No commas, blanks allowed.  No symbols 

Last name

doe

No commas, blanks allowed.  No symbols 

Account type

C/S/L/BC/BS/G

Up to 2 Alphabet (C, S, L, G, BC, BS)

Checking(C), Savings(S), Loan (L) Business Checking (BC), Business Savings (BS) General Ledger (G)

RTN

#########

Exactly 9 digits; must have checksum

Destination Bank Routing Number

Account

###############

4-17 numeric

Destination Bank account number

Credit-Debit

C

1 alpha C, D

Credit or Debit (C or D)

Fee

##.##

4 numeric with decimal (signed)

##.##

Message

Processed file contains a descriptive reason of any Rejected entries

ACH Response File Sample

To zoom in for smaller table values, pinch out on your trackpad. For an Apple Mac, type CMD and the plus sign (⌘ and +). For PC, use CTRL and +.

ISO

MID

Status

Result

ACH Type

Processed date

Settlement date

Entry Type

Entry Description

Credit-Debit

Amount

Trace ID

IIN

First name

Last name

Account Type

RTN

Account

Fee

1000

1

Complete

0

N

03-11-24

03-12-24

CCD

D

100

9234000001

Samwise

Gamgee

C

123456789

4444444444

0.25

1000

2

Error

422: Duplicate IIN

N

03-11-24

03-12-24

CCD

D

101

9234000002

Samwise

Gamgee

C

123456789

4444444445

0.25

1000

2

Error

422: ACHType

S

03-11-24

03-12-24

CCD

C

102

9234000003

Samwise

Gamgee

BC

233456789

3333333335

0.25

1000

2

Error

422: EntryType

N

03-11-24

03-12-24

PPD

D

101

9234000004

Samwise

Gamgee

BC

123456789

4444444445

0.25

1000

2

Complete

0

S

03-11-24

03-12-24

CCD

C

102

9234000005

Samwise

Gamgee

C

233456789

3333333335

0.25

1000

2

Complete

0

S

03-11-24

03-12-24

CCD

C

102

9234000006

Samwise

Gamgee

C

233456789

3333333335

0.25


ACH Returns (Includes "Rejects" and "NOCs")

ACH Return File Format

ISO

ISO

MID

MID

Return date

Date (5_70_75)

Amount

Amount (6_30_39)

Account

Account (6_13_29)

RTN

ABA/Routing (6_04_12)

Name

Individual Name (6_55_76)

IIN

Individual ID (6_40_54)

Matches IIN from input

ACH RC

Transaction Code (6_02_03)

Trace

Trace (80_94)

Bank Discretionary

Bank Discretionary (6_77_78)

Addenda

Addenda (7_04_83)

Descriptive Date

Descriptive Date (5_64_69)

Company Name

Company Name (5_05_20)

IIN unique to company name and ID

Company Discretionary

Company Discretionary (5_21_40)

Company ID

Company ID (5_41_50)


Class

Class (5_51_53)

Entry Description

Company Entry Description (5_54_63)

Batch

Batch (5_88_94)

ODFI

Originating DFI (5_80_87)

Immediate Destination

Immediate Destination (1_04_13)

Immediate Origin

Immediate Origin (1_14_23)

File Date

File Date (1_24_29)

File Time

File Time (1_30_33)

File modifier

File Modifier (1_34_34)

Immediate destination name

Immediate Destination Name (1_41_63)

Immediate origin name

Immediate Origin Name (1_87_94)

Amount

Amount_Unsigned (no dollar or comma)

Service CC

Service Class 2xx (5_02_04)

Julian Date

Julian_Settle_Date (5_76_78)

Text4

Text4

Text5

Text5

Return Code

Return Code (7_04_06)


Return Description

Return Description


Original Trace #

Original Trace (7_07_21)

Optional Date

Optional Date (7_22_27)

Original RDFI

Original Receiving DFI (7_28_35)

Addenda Text

Addenda Text (7_36_79)

Addenda Trace

Addenda Trace (7_80_94)

Addenda Type

Addenda Type (7_02_03)

Returns Origin ID

Returns Origination Transaction Code (calculated)

Returns RTN

Returns ABA 9 digit (concatenated)

Amount

Amount_Unsigned (no dollar or comma)


ACH Return Codes

Code

 Description

Detail

R01

Insufficient funds

Available balance is not sufficient to cover the amount of the debit entry

R02

Bank account closed

Previously active amount has been closed by the customer of RDFI

R03

No bank account/unable   to locate account

Account number does not correspond to the individual identified in the entry, or the account number designated is not an open account

R04

Invalid bank account number

Account number structure is not valid

R06

Returned per ODFI request

ODFI requested the RDFI to return the entry

R07

Authorization revoked by customer

Receiver has revoked authorization

R08

Payment stopped

Receiver of a recurring debit has stopped payment of an entry

R09

Uncollected funds

Collected funds are not sufficient for payment of the debit entry

R10

Customer advises not authorized

Receiver has advised RDFI that originator is not authorized to debit his bank account

R11

Check truncation entry return

To be used when returning a check truncation entry

R12

Branch sold to another RDFI

RDFI unable to post entry destined for a bank account maintained at a branch sold to another financial institution

R13

RDFI not qualified to participate

Financial institution does not receive commercial ACH entries

R14

Representative payee deceased or unable to continue in that capacity

The representative payee authorized to accept entries on behalf of a beneficiary is either deceased or unable to continue in that capacity

R15

Beneficiary or bank account holder

(Other than representative payee) deceased* - (1) the beneficiary entitled to payments is deceased or (2) the bank account holder other than a representative payee is deceased

R16

Bank account frozen

Funds in bank account are unavailable due to action by RDFI or legal order

R17

File record edit criteria

Fields rejected by RDFI processing (identified in return addenda)

R18

Improper effective entry date

Entries have been presented prior to the first available processing window for the effective date.

R19

Amount field error

Improper formatting of the amount field

R20

Non-payment bank account

Entry destined for non-payment bank account defined by reg. 

R21

Invalid company ID number

The company ID information not valid (normally CIE entries)

R22

Invalid individual ID number

Individual id used by receiver is incorrect (CIE entries)

R23

Credit entry refused by receiver

Receiver returned entry because minimum or exact amount not remitted, bank account is subject to litigation, or payment represents an overpayment, originator is not known to receiver or receiver has not authorized this credit entry to this bank account

R24

Duplicate entry

RDFI has received a duplicate entry

R25

Addenda error

Improper formatting of the addenda record information

R26

Mandatory field error

Improper information in one of the mandatory fields

R27

Trace number error

Original entry trace number is not valid for return entry; or addenda trace numbers do not correspond with entry detail record

R28

Transit routing number check digit error

Check digit for the transit routing number is incorrect

R29

Corporate customer advises not authorized

RDFI has bee notified by corporate receiver that debit entry of originator is not authorized

R30

RDFI not participant in check truncation program

Financial institution not participating in automated check safekeeping application

R31

Permissible return entry (CCD and CTX only)

RDFI has been notified by the ODFI that it agrees to accept a CCD or CTX return entry

R32

RDFI non-settlement

RDFI is not able to settle the entry

R33

Return of XCK entry

RDFI determines at its sole discretion to return an XCK entry; an XCK return entry may be initiated by midnight of the sixtieth day following the settlement date if the XCK entry

R34

Limited participation RDFI

RDFI participation has been limited by a federal or state supervisor

R35

Return of improper debit entry

ACH debit not permitted for use with the CIE standard entry class code (except for reversals)


TabaPay Response Codes

Status

Result

File

Message

Accepted

0

Processed

Rejected

423

Processed

Invalid input record length

Rejected

440

Processed

Invalid entry class

Rejected

430

Processed

Invalid ISO

Rejected

431

Processed

Invalid MID

Rejected

432

Processed

invalid ISO format

Rejected

428

Processed

Duplicate or re-used IIN

Rejected

409

Processed

Duplicate or re-used IIN

Rejected

427

Processed

Invalid entry type

Rejected

426

Processed

Invalid ACH type (S, N, R)

Rejected

425

Processed

Invalid account type

Rejected

452

Processed

Invalid debit or credit indicator

Rejected

422

Processed

Invalid RTN

Rejected

448

Processed

Invalid amount formt

Rejected

449

Processed

Limit exceeded

Complete

0

Output

Error

100

Output

Rejected by ODFI

Notification of Change (NOC)

A Notification of Change (NOC) is just a heads-up that there’s a small update needed for a customer’s bank account info, like the account or routing number. It’s sent by the customer’s bank to notify you to update their records.

When you get an NOC, there's usually no major action needed—your ACH payment should still go through. The key thing is to update the customer’s info to avoid any issues with future payments.

  1. Receiving Depository Financial Institution (RDFI): The recipient's bank detects the issue with the payment details and sends an NOC to the sender's bank.
  2. Originating Depository Financial Institution (ODFI): The sender's bank receives the NOC from the RDFI and passes it along to you, or the payment service provider to update the ledger.
  3. Payment Service Provider, or Sender’s Organization: The initiator of the ACH payment, such as a business or organization that is sending the funds, receives the NOC. They must update their records to correct any mistakes in the customer's bank details to ensure future payments are processed accurately.

📘

Updating Customer Records

In most cases when you receive an NOC, your ACH transaction should still process as expected.

After receiving an NOC, you will need to update your customer records to reflect the change to their account and ensure that future ACH transactions can be processed correctly.

Refer to the National Automated Clearing House Association (NACHA) Operating rules and Guidelines for more information.

NOC Correction (COR) Codes

Clients receiving a NOC Class = COR must incorporate the change (e.g. C04 - account name change).

NOC CodeDescription
C01Incorrect bank account number
C02Incorrect transit/routing number
C03Incorrect transit/routing number and bank account number
C04Bank account name change
C05Incorrect payment code
C06Incorrect bank account number and transit code
C07Incorrect transit/routing number, bank account number and payment code
C08Corrected foreign routing number
C09Incorrect individual ID number
C10Incorrect company name