Kyle Maloney
September 20, 2023

A Guide to Financial Reconciliation, Part III: How to Reconcile ACH Transfers

In this post, we explore how fintechs reconcile ACH transfers across ledgers and bank accounts.


Welcome to Part 3 of A Guide to Financial Reconciliation. If this is your first time here, we recommend checking out the prior posts in this series: 

In this post, we break down how to reconcile ACH transfers for fintechs. We’ll focus primarily on US-based ACH payments for now, but these concepts can be applied to other bank transfers where batch settlement processes are used. In future posts, we’ll cover additional payment rails, as well as the details of balance & cash reconciliations when working with FBO accounts. 

ACH Overview

ACH transfers are electronic transfers that move funds from one bank account to another. These transfers are facilitated via the ACH Network, and payments are processed in batches - meaning that rather than sending individual payments between banks in real time, ACH transfers are grouped, sorted by their destination, and sent all at once for processing between banks. Batch processing is a bit of a relic from a time when data exchange was not as cheap or efficient as it is today, but even so, many B2B and consumer payments still move via ACH rails.

For fintech companies, common use cases for ACH are:

  • Account funding
  • Vendor payments 
  • Payroll
  • Marketplace Payouts

The participants in the ACH Network

For every ACH transfer, there are a standard set of participants

  • Originator - the person or business that initiates the transfer. Originators can push funds to another bank account (ACH credits) or pull funds from a bank account (ACH debits)
  • ODFI - The Originating Depository Financial Institution (aka The originating bank) is the banking partner/institution who submits entries to the network.
  • Operator - The clearing facility that routes transfers between banks. The Operator receives all originations and ensures they go to the correct receiving bank.
  • RDFI - The Originating Depository Financial Institution (aka the receiving bank) is the banking partner/institution who receives entries initiated through the network.
  • Receiver - the person or business who is receiving the ACH entry. (Note that the receiver may have funds pushed into their account or pulled from their account.
  • Third Party service providers - Technology providers who sit in the middle of the data exchange process. Most commonly for fintech companies, third party service providers help with translating NACHA files into more consumable formats (JSON). 

How data (& money) moves

Since the ACH network moves funds in batches, data exchange happens at a different time from when money actually moves between banks. First, data is exchanged, then funds are settled on a net basis between institutions at a time specified by the ACH operator. This type of settlement is known as “net settlement”. Many payment systems use net settlement to move money between institutions, but it is becoming more common to see real-time payments, where data and money exchange is more or less synchronous between financial institutions - this type of settlement is known as “real time gross settlement”. 

ACH data is exchanged between banks via flat files known as NACHA files. Within these files, individual entries specify the amounts and accounts to be credited or debited, along with descriptive metadata and routing information for each entry. Each ACH transaction will include a few important dates that govern when funds should be made available & move between institutions: 

  • The effective date - the date the originator wants to effect the transaction (ie when the transaction should be applied)
  • The settlement date - the date that money moves between institutions

Depending on the type of ACH transaction and the rules that govern it under NACHA guidelines, the effective date & settlement date may be different dates - so fintechs should take care in understanding how different entries should be reconciled on their ledger and with their bank partners. 

Reconciling ACH transfers to product ledgers

Pending vs Settled transfers

Fintech product ledgers often leverage transaction states to indicate a transaction’s impact on a user’s available balance. Funds reflected in a “pending” state typically mean that the transaction has been created/initiated but not yet applied to the user’s available balance. Pending transfers indicate funds held in “suspense” - to make available to the accountholder or send via the network at a later time

On the settlement date of the ACH transfer, the transaction on the fintech’s product ledger will be updated to a “complete” or “available” state. Fintech’s should reconcile their ACH transfers to these transaction states to ensure funds have been made available correctly.

By reconciling both the pending & settled states of ACH transactions, fintechs can verify that 1) transactions have been properly applied to accounts and 2) they are conforming to network and regulatory guidelines for funds availability. 

Unique identifiers vs. Heuristics

For incoming ACH entries, there’s not a single unique identifier for the payment in the network, but NACHA guidelines imply that transactions be recognized as unique based on amount, individual name, batch numbers & trace numbers for a given file.

For fintechs, your reconciliation systems should parse and reconcile NACHA files to your product ledger based on these criteria. For outgoing ACH payments, it’s possible to leverage entry metadata fields that tie to unique identifiers of transactions on a fintech’s product ledger. But depending on the type of ACH transfer being initiated, you may not be able to include a full transaction uuid that will tie to a transaction on your internal system. So it’s ideal to consider how to implement additional heuristics for transaction matching.

Reconciling ACH transfers to bank accounts

Batch settlements

Banks often move funds in batch settlements, meaning that all ACH transfers will be moved in or out of a given bank account in a single funds movement. For fintechs who manage FBO accounts, it is important to be able to perform many-to-one reconciliation across your internal source of record and your bank statements. As mentioned above, the nature of the ACH network means that funds will be moved in batch across different windows, so your reconciliation system should be able to aggregate transfers across time windows to be able to tie out to your bank accounts. 

Typically, banks will move funds into and out of the FBO based on the transaction effective dates, with settlement happening between institutions via another set of accounts at the institution.  

BAI2 and bank reporting

When performing reconciliation at scale, it’s important to be able to automate processes around importing and verifying bank statement data. Today, most banks support BAI2 files for exchanging information about bank account activity and balances. The Bank Administration Institute (BAI) has standardized these concepts, so that each transaction affecting a bank account can be summarized & classified via an interoperable file specification.

Depending on your bank, BAI2 files can be made available throughout the day or at the end of the day, and summarize transactions using a set of summary codes and detail data for a given bank account.  

When reconciling ACH settlements, leveraging the BAI2 account identifier fields and transaction detail records can provide the details needed for performing reconciliation across systems. 


ACH is the primary way funds move between banks, and we hope that this post serves as a resource for how to reconcile ACH transfers. For any company who moves money, financial accuracy and regulatory compliance is a must. And maintaining scalable, repeatable reconciliation processes reduce huge potential issues for your customers and your business. In future posts, we’ll break down how to reconcile card transactions, as well as how to perform balance & cash reconciliations when working with FBO accounts. 

If you are looking to improve your reconciliation processes, Proper provides financial data infrastructure, purpose-built for fintech. We help stitch together sources of financial data into a single platform and provide tools for reconciliation and financial operations. Back office infrastructure is critical to financial services, and with Proper, companies can spend less time on financial ops tools and more time focused on their end-users.

Kyle Maloney
September 20, 2023

Some more posts

Changelog: January 2024

This month, we're focusing on providing you with more control and clarity over your data and processes.

February 7, 2024

Techniques in Financial Reconciliation, Part I: Data Acquisition & Transformation

In part 1 of our new series, we break down the key considerations for the first step of your financial reconciliation process: Data Acquisition and Transformation.

Kyle Maloney
February 3, 2024