ACH Explained: Following a Payroll Transaction Through the U.S. Banking System

Most people know ACH as the system behind direct deposit and bill payments. Fewer understand how it actually works. Even fewer understand what happens when something goes wrong.

The ACH network processes more than 30 billion transactions every year—33.6 billion payments in 2024, according to NACHA—and moves trillions of dollars throughout the U.S. economy. Yet despite its importance, ACH remains one of the least understood pieces of financial infrastructure.

In this post, we’ll follow a payroll transaction from an employer to an employee and then explore what happens when a payment fails. Along the way, we’ll examine the responsibilities of every participant in the ACH ecosystem and explain how routing, clearing, settlement, corrections, and returns actually work.

This is a deep dive into the ACH rail introduced in U.S. Domestic Payment Rails, the first in a series of per-rail explorations.

ACH Payroll Data Flow

Key Organizations

Before we dive into the flow, it’s helpful to understand the major participants.

A common misconception is that ACH is a single system operated by the Federal Reserve.

In reality, ACH is a network governed by NACHA and operated by multiple institutions.

ACH Is a Network, Not a System

At a high level, the ecosystem includes:

• Employer (IBM)
• Payroll Provider (ADP, Workday, Paychex)
• ODFI (Originating Depository Financial Institution)
• ACH Operator (FedACH or EPN)
• RDFI (Receiving Depository Financial Institution)
• Employee (Receiver)
• NACHA (National Automated Clearing House Association)

NACHA is responsible for governing the ACH Network.

NACHA defines:

• Operating rules
• File formats
• Settlement windows
• Return procedures
• Risk-management standards
• Participation requirements

While NACHA governs the network, it does not move money or process transactions.

Those responsibilities belong to ACH Operators such as FedACH and EPN.

The Payroll Scenario

Let’s assume IBM is processing payroll for 100,000 employees.

Those employees maintain accounts at hundreds of different banks:

• Chase
• Bank of America
• Wells Fargo
• Capital One
• PNC
• Regional community banks
• Credit unions

IBM does not maintain separate integrations with every receiving institution.

Instead, IBM sends a single payroll file into the ACH network.

The network takes responsibility for routing each payment to the correct destination.

Why Routing Numbers Exist

Each employee provides:

• Routing Number
• Account Number
• Account Type

For example:

The routing number identifies the destination bank.

The account number identifies the destination account within that bank.

A useful analogy is postal mail:

The ACH network uses the routing number.

The receiving bank uses the account number.

Enter the Payroll Provider

Many large employers do not generate NACHA files directly.

Instead, they use providers such as:

• ADP
• Workday
• Paychex

The payroll provider:

• Calculates net pay
• Validates employee banking information
• Generates NACHA files
• Handles exception processing
• Produces operational reports

Conceptually:

IBM
  |
  v
ADP / Workday
  |
  v
ODFI

The payroll provider becomes an important operational layer between the employer and the banking network.

Understanding the ODFI

The Originating Depository Financial Institution (ODFI) is the bank responsible for introducing ACH transactions into the network.

Examples include:

• JPMorgan Chase
• Bank of America
• Wells Fargo
• Citi

The ODFI:

• Receives the NACHA file
• Validates formatting
• Applies risk controls
• Assigns trace numbers
• Sends entries to the ACH operator

The ODFI effectively sponsors the transaction into the ACH network.

The ACH Operator: FedACH and EPN

Once the file reaches the ACH operator, routing begins.

The operator examines the routing number on every entry.

For example:

021000021 -> Chase
026009593 -> Bank of America
121000248 -> Wells Fargo

The operator sorts entries and distributes them to receiving institutions.

This is why IBM can pay employees at hundreds of banks without maintaining hundreds of separate integrations.

The ACH network provides universal reach.

Deferred Net Settlement

Many engineers assume that ACH moves money transaction by transaction.

It does not.

ACH uses deferred net settlement.

Suppose:

Rather than settling every transaction individually, the system calculates net obligations.

Only the net difference is settled.

This dramatically reduces liquidity requirements and operational overhead.

Settlement is also time-bound. Standard ACH settles on a T+1 or T+2 schedule, while Same Day ACH—introduced in 2016—clears within defined same-day windows and cutoff times. Either way, settlement happens on a deferred, batched schedule rather than instantly, which is the fundamental trade-off ACH makes in exchange for scale and low cost.

The NACHA File Format

One of the most surprising aspects of ACH is that it is still fundamentally a fixed-width text file format.

A NACHA file consists of:

File Header (1)
  Batch Header (5)
    Entry Detail (6)
    Entry Detail (6)
    Entry Detail (6)
  Batch Control (8)
File Control (9)

Each employee payment is represented by an Entry Detail record.

Each record contains:

• Routing Number
• Account Number
• Amount
• Employee Information
• Trace Number

The Trace Number becomes critically important later.

ACH Is Not All-or-Nothing

This is one of the most important concepts for software architects.

Suppose IBM submits payroll for 100,000 employees.

One employee enters an invalid account number.

Does the entire payroll fail?

No.

ACH processes entries independently.

Result:

• Three payments succeed
• One payment returns

The batch continues processing.

ACH was designed for massive-scale transaction processing decades before modern distributed systems became popular.

What Happens When Something Fails?

Now we arrive at the most interesting part of the system.

ACH does not report failures using exceptions.

Instead, ACH creates new business messages.

Suppose Mike entered an invalid account number.

The receiving bank cannot post the transaction.

The RDFI creates a Return Entry.

The flow reverses:

RDFI
  |
  v
ACH Operator
  |
  v
ODFI
  |
  v
Payroll Provider
  |
  v
IBM

The return contains a return code.

Examples:

Rather than throwing an error, ACH generates a new event describing the failure.

Correlation: How Do We Know Which Payment Failed?

Consider an employee who splits payroll across multiple accounts.

For example:

If one deposit fails, employee name alone is not enough to identify the failed transaction.

This is why every ACH entry carries a Trace Number.

Think of it as a distributed-system correlation identifier.

Original Payment
Trace Number: 123456

Return Entry
Trace Number: 123456

The payroll system can match the return to the original payment without relying on names or amounts.

In addition to the Trace Number, many payroll systems include employee identifiers in the NACHA entry, allowing automated reconciliation and reporting.

Notification of Change (NOC)

Not every exception is a failure.

Sometimes the payment succeeds but the receiving bank wants the originator to correct future instructions.

Examples:

In these cases the payment may still post successfully while the RDFI requests a correction for future transactions.

This is called a Notification of Change (NOC).

Reversals

Returns and NOCs are initiated by the receiving side. Reversals are different—they are initiated by the originator.

If IBM accidentally pays an employee twice, or sends the wrong amount, NACHA rules allow the originator to submit a reversing entry to undo the erroneous transaction. Reversals are tightly constrained: they must correct a genuine error such as a duplicate or an incorrect amount, and they must be transmitted within a limited window, generally within five banking days of the original settlement date.

A reversal is not guaranteed to recover funds. If the receiver has already withdrawn the money or the account is closed, the reversal may itself be returned. This is why originators treat reversals as best-effort corrections, not as a reliable rollback mechanism.

ACH Through the Lens of Event-Driven Architecture

For software architects, ACH feels surprisingly modern.

Conceptually, the lifecycle looks like:

PayrollSubmitted
        |
        +--> PayrollPosted
        |
        +--> PayrollReturned
        |
        +--> NotificationOfChange
        |
        +--> PayrollReversed

Notice something important.

The failure is not an exception.

The failure is another event.

ACH was solving correlation, reconciliation, and asynchronous exception handling decades before Kafka, event sourcing, and modern distributed systems became mainstream.

Final Thoughts

Most people think of ACH as direct deposit.

In reality, ACH is a sophisticated network involving employers, payroll providers, banks, clearing operators, settlement mechanisms, routing infrastructure, and exception-processing workflows.

Understanding the happy path explains how payroll works.

Understanding returns, corrections, trace numbers, and reconciliation explains how ACH operates in the real world.

The next time you receive a direct deposit, remember that the transaction likely traveled through multiple institutions, was routed using banking metadata, settled through a netting process, and remains fully traceable through a chain of identifiers designed decades before modern event-driven architecture became fashionable.