FinStackCloud
RAILS · NACHA TRANSACTION CODES

NACHA transaction codes

The Transaction Code (positions 2-3 of the Entry Detail Record, type-6) is a 2-digit number that tells the RDFI two things at once: which type of account the entry should hit (checking, savings, GL, or loan), and what kind of entry it is (live debit, live credit, prenote, zero-dollar with remittance, or return/NOC). Get this wrong and the entry posts to the wrong account or gets bounced as R03 / R04 / NOC C05.

Last updated: May 4, 2026 Reading time: 12 min 20 codes covered
THE ONE THING TO REMEMBER
Transaction code = "which account, what kind of entry?" Every code is a two-digit number. The first digit tells you the account type (2 = checking, 3 = savings, 4 = bank GL, 5 = loan). The second digit tells you the entry purpose (2 / 7 = live credit / debit, 3 / 8 = prenote, 4 / 9 = zero-dollar with remittance, 1 / 6 = return or NOC). Once you see the pattern, the whole table memorizes itself.
How to read this page — NACHA mandate vs. industry practice. The transaction code itself is purely a NACHA mandate — every value comes from the Operating Rules, every position is fixed in the spec. The judgment calls are around which code to use when the receiver's account type is ambiguous, when to send a prenote vs. when to skip it, and how the various return / NOC codes flow back. Mandate-vs-practice tags below mark which is which.

Section 1 · The full map Every transaction code in one matrix

The transaction code space is small and orthogonal: 4 account types × roughly 5 entry purposes. The two tables below split it the way you'll actually consume it — the primary matrix covers checking and savings (which is essentially all production traffic), and a separate specialized matrix covers GL and loan codes that exist in the spec but you'll likely never generate.

Primary matrix · Checking + Savings · 16 codes ~99% of production traffic
Entry purpose Checking Savings
▾ Credits — money TO receiver
Live credit (deposit) 22 32
Credit prenote 23 33
Credit zero-$ remit CCD/CTX only 24 34
Credit return / NOC inbound only 21 31
▾ Debits — money FROM receiver
Live debit (payment) 27 37
Debit prenote 28 38
Debit zero-$ remit CCD/CTX only 29 39
Debit return / NOC inbound only 26 36
About the specialized matrix below. The 4x and 5x decades exist in the NACHA spec and are listed in every comprehensive bank reference, so we cover them for completeness. But for the typical fintech / SaaS / B2B originator: you will never generate these codes. Most ODFIs don't even enable 4x or 5x origination for non-FI clients. The codes show up in the wild only inside bank back-office operations and inter-institution settlement. If you're paying a loan via ACH autopay, you almost certainly want TC 27 (debit a checking account), not TC 52 — see the loan section for why.
Specialized matrix · GL + Loan · reference only Bank-internal use · most originators never generate these
Entry purpose GL Loan
▾ Credits
Live credit 42 52
Credit prenote 43 53
Credit zero-$ remit 44 54
Credit return / NOC 41 51
▾ Debits
Live debit 47 —
Debit prenote 48 —
Debit zero-$ remit 49 —
Debit return / NOC 46 55
How to read any transaction code at a glance
2
First digit
account type
7
Second digit
entry purpose
=
Live debit on a checking account
(SaaS billing, recurring autopay, etc.)

First digit — what kind of account?

2 Checking
3 Savings
4 Bank GL
5 Loan

Second digit — what kind of entry?

2 Live credit (deposit)
7 Live debit (payment)
3 Credit prenote
8 Debit prenote
4 Credit zero-$ w/ remit
9 Debit zero-$ w/ remit
1 Return / NOC of a credit
6 Return / NOC of a debit

Read it like an address. "32" = 3 (savings) + 2 (live credit) = automated savings deposit. "27" = 2 (checking) + 7 (live debit) = automated checking payment. "38" = 3 (savings) + 8 (debit prenote). The pattern never breaks.

Reality check on the primary matrix: ~99% of production traffic uses just 4 codes — 22, 27, 32, 37 (the live credit/debit pair for checking + savings). Prenotes (23/28, 33/38) come up only when validating new account info before live entries. Zero-dollar codes (24/29, 34/39) are restricted to CCD/CTX remittance-only entries. Returns/NOCs (21/26, 31/36) appear in your inbound feed from the ODFI, not in files you build. So even within the "primary" set, your day-to-day attention is really 4 codes.

One thing the matrix doesn't capture: Transaction codes don't differentiate consumer vs. business — that's the SEC code's job. You can use 22 with PPD (consumer payroll) or with CCD (B2B vendor payment); the receiver's account type is "checking" in both cases. So the transaction code answers "checking or savings?", the SEC code answers "how was this authorized?". Always pick both correctly.

Section 2 · Each code in detail What each transaction code actually does

Below: the codes you'll actually generate or process, grouped by account type. The 4 workhorses (22 / 27 / 32 / 37) get full deep-dives. The supporting codes (prenotes, zero-dollar, returns) get tight summaries because their behavior is identical across account types — the patterns memorize once.

22 Automated Deposit — Checking Live · Credit · Most common

The single most-used transaction code in the entire ACH network. Any time money is being credited (deposited) into a consumer or business checking account, this is the code. Direct deposit payroll, vendor AP runs, government benefits, refunds, P2P transfers in — all 22.

USE 22 WHEN
  • Receiver's account is a checking / demand deposit account
  • The entry is a live, dollar-amount credit (money flowing TO the receiver)
  • Examples: payroll, AP vendor payment, tax refund, P2P credit, government benefit deposit
DON'T USE 22 WHEN
  • Receiver's account is a savings / share account → use 32
  • You're collecting money from the receiver → that's a debit, use 27
  • It's a prenote (zero-dollar account validation) → use 23
  • It's a zero-dollar remittance entry alongside CCD/CTX → use 24

Format and pairing

Position in Entry Detail: 2-3 (right after the record type code "6").

Compatible SEC codes: All consumer and business credit-capable SEC codes — PPD, CCD, CTX, WEB (credit), CIE, IAT (when crediting a U.S. checking account). Most batches of 22 entries are PPD (payroll) or CCD (vendor payments).

Service Class Code in Batch Header: Usually 220 (credit-only) when the batch is all 22s, or 200 (mixed) when 22s share a batch with debits.

Amount field: Right-justified, zero-filled, in cents (no decimal). $1,250.00 = 0000125000.

Practice What if you don't know whether the receiver's account is checking or savings? Ask. There's no "either/or" code. Receivers commonly type their routing/account info into a form and forget that direct-deposit voided checks always reference a checking account by default — but credit-union members often have only a savings/share account and assume the same flow works. Sending 22 to a savings account triggers C05 (incorrect transaction code) NOC at best, R03 (no account) return at worst. When in doubt, ask the form to specify, or send a prenote first to verify (see TC 23).

Real file example

PPD payroll batch · TC 22 highlighted pos 2-3 of Entry Detail
File Header101 071000013 1234567890 2605041200A094101FEDERAL RESERVE BANK ACME PAYROLL CO 00000001 Batch Header5220ACME PAYROLL CO 1234567890PPDPAYROLL 260504260506 1071000010000001 Entry Detail62207100001399876543210 0000125000ID0001 SARAH JOHNSON 0107100001000001 Entry Detail62207100001312345678901 0000098500ID0002 MICHAEL CHEN 0107100001000002 Batch Control820000000207100001260000000000000000000022350001234567890 107100010000001
27 Automated Payment — Checking Live · Debit · Most common

The debit equivalent of 22. Any time money is being pulled from a checking account, this is the code. SaaS subscription billing, mortgage payments, utility bills, recurring B2B AR collections — all 27.

USE 27 WHEN
  • Receiver's account is a checking / demand deposit account
  • The entry is a live, dollar-amount debit (money flowing FROM the receiver)
  • Examples: subscription billing, utility autopay, mortgage debit, B2B invoice collection
DON'T USE 27 WHEN
  • Receiver's account is savings → use 37
  • You're sending money to the receiver → use 22 (credit)
  • It's a prenote for a debit → use 28
  • You're trying to re-present a bounced check → use 27 BUT under SEC code RCK (not PPD/WEB)

Format and pairing

Compatible SEC codes: All debit-capable SEC codes — PPD, CCD, CTX, WEB (debit), TEL, ARC, POP, BOC, RCK, IAT (debit). Most production volume is PPD/WEB/CCD.

Service Class Code: Usually 225 (debit-only) when the batch is all 27s, or 200 (mixed).

Same-Day eligibility: 27 entries are eligible for Same-Day ACH (subject to the per-entry $1M cap and ODFI cutoffs).

NACHA mandate WEB debits with TC 27 trigger account validation rules. When TC 27 is paired with SEC code WEB (consumer internet-authorized debit), the WEB Debit Account Validation Rule applies — originator must validate the account before first use. This combination — TC 27 + WEB — is one of the most-policed code pairings on the network because it's the dominant fraud surface.
32 Automated Deposit — Savings Live · Credit · Savings

Same as 22 but the receiver's account is a savings (or, at credit unions, a "share") account instead of checking. Functionally identical processing, just routed to a different account type at the RDFI. Common for direct deposits to savings accounts (some employees split their direct deposit into checking + savings) and for member dividend payouts at credit unions.

Use when: Receiver gave you a savings or share account number for credit deposit.

Compatible SEC codes: Same set as 22 — PPD, CCD, CTX, WEB credit, IAT, etc.

Common confusion: Money market accounts at most banks count as savings for ACH purposes (TC 32 / 37), but some institutions treat them as checking (TC 22 / 27). When the RDFI's records disagree with the originator, the result is a C05 NOC asking you to switch the transaction code — not a hard return.

37 Automated Payment — Savings Live · Debit · Savings

Same as 27 but on a savings account. Less common in practice than 27 because most consumers don't pay bills out of savings — but it's the right code when they do.

Use when: Receiver authorized a debit pulled from a savings or share account.

Compatible SEC codes: Same as 27 — PPD, CCD, WEB debit, TEL, ARC, POP, BOC, RCK, IAT.

Practice Reg D and the savings-debit limit. Historically, federal Regulation D capped certain "convenient" withdrawals from savings accounts at 6 per month, including ACH debits. The Federal Reserve removed this cap in April 2020 during COVID and has not reinstated it as of the most recent rule cycle. Many banks, though, still enforce their own internal version of the 6-per-month limit on savings withdrawals out of inertia or risk policy. So a TC 37 debit can occasionally be returned R20 (Non-Transaction Account) by an RDFI that's still applying old Reg D rules — even though the federal rule is gone. Worth knowing if you're billing recurring debits on savings accounts.
23 28 33 38 Prenotifications (prenotes) Zero-dollar · Account validation

Zero-dollar entries used to validate that an account number and routing number combination is real and accepts ACH before sending live entries. Same format as a normal entry, but the amount field is all zeros and the transaction code is one of the prenote variants (one-digit higher than the live equivalent).

23 = prenote of a checking credit (will become 22)

28 = prenote of a checking debit (will become 27)

33 = prenote of a savings credit (will become 32)

38 = prenote of a savings debit (will become 37)

NACHA mandate Wait period after a prenote. If you originate a prenote, you must wait at least 3 banking days after the settlement date before sending a live-dollar entry to the same account. This gives the RDFI time to return the prenote (R03 No Account, R04 Invalid Account, etc.) or send a NOC (C01 incorrect account, C02 incorrect routing, etc.) if the data is wrong. Skipping the 3-day wait is a Rules violation.
NACHA mandate 2024 update — prenotes can now be re-used. A NACHA rule change effective June 1, 2024 removed the language that limited prenotes to "before the first entry only." Originators can now send prenotes at any time — including to re-validate accounts that have been dormant for an extended period before resuming activity. The 3-day wait still applies.
Practice Prenotes are optional but useful — and they count as account validation for WEB. NACHA does not require prenotes for any SEC code. They're a tool, not a mandate. But for WEB debits, where account validation IS mandatory before first use, an originated prenote that doesn't come back returned satisfies the validation requirement — NACHA explicitly lists prenote as one of the accepted methods. This is one of the cheaper ways to comply with the WEB Account Validation Rule if you don't want to integrate a third-party API.
Practice Why prenotes have lost ground in consumer fintech. The 3-day wait is often longer than the entire customer signup → first charge timeline. A SaaS that bills customers within minutes of signup can't wait 3 banking days. Consumer-facing fintechs typically use real-time account validation APIs (Plaid Auth, Stripe Financial Connections, GIACT) instead. Prenotes still make sense for batch payroll setups (HR can wait 3 days), B2B vendor onboarding, recurring billing where a 3-day delay is fine, and credit-union-heavy receiver bases where third-party API coverage is thinner.
24 29 34 39 Zero-Dollar with Remittance Data CCD / CTX only · B2B remittance

Zero-dollar entries that exist solely to carry remittance information (invoice numbers, EDI segments) when the dollar settlement happens through a separate channel — typically a wire or a bulk ACH. Used in high-volume B2B and healthcare contexts where the remittance and the money are decoupled. Restricted to CCD and CTX SEC codes only.

24 = zero-dollar credit-side remittance, checking

29 = zero-dollar debit-side remittance, checking

34 = zero-dollar credit-side remittance, savings

39 = zero-dollar debit-side remittance, savings

NACHA mandate CCD / CTX SEC codes only. 24/29/34/39 cannot be used with PPD, WEB, TEL, or any consumer SEC code. They're a B2B-only construct — designed for cases where the remittance advice is itself the payload and the funds movement happened (or will happen) elsewhere.
Practice You'll mostly never generate these. Zero-dollar with remittance entries are specialized — common in healthcare claim adjudication (paired with X12 835 remittance advice for a wire-settled payment), in lockbox cash applications, and in consolidated treasury workflows. If you don't recognize the use case, you don't need this code. Most fintechs go from "I exist" to "we shipped to GA" without ever generating a 24/29/34/39.
21 26 31 36 Return / Notification of Change codes RDFI-originated · You receive these

Codes you'll see in your inbound ACH feed from the ODFI, not in files you build. When an RDFI returns one of your entries (because the account doesn't exist, NSF, customer disputed, etc.) or sends a Notification of Change (because account info needs updating), the returned/NOC entry comes back with one of these transaction codes — keyed off whether the original was a credit or debit, and whether it was checking or savings.

21 = return or NOC for an original credit to checking (i.e., reversing a 22, 23, or 24)

26 = return or NOC for an original debit to checking (reversing a 27, 28, or 29)

31 = return or NOC for an original credit to savings (reversing a 32, 33, or 34)

36 = return or NOC for an original debit to savings (reversing a 37, 38, or 39)

Practice Don't confuse the transaction code with the return reason code. The transaction code (21/26/31/36) tells you which direction and account type was reversed. The return reason code (R01, R02, R03, ..., R85) carried in the addenda record (type-99) tells you why. Both fields are needed to handle the return correctly. Same for NOCs: the change code (C01, C02, ...) is in the addenda, the transaction code says which entry type the change applies to.
NACHA mandate NOCs require correction within 6 banking days. When you receive a NOC (your inbound feed will show transaction codes 21/26/31/36 with addenda type 98 and a C0x change code), you must correct your records and apply the change within 6 banking days, or before the next entry to the same receiver — whichever is later. Failure to comply is a Rules violation that your ODFI will flag.
41 42 43 44 46 47 48 49 Financial Institution General Ledger Internal FI use · You won't generate these

Reserved for entries hitting a financial institution's own internal General Ledger account, not a customer-facing checking or savings account. Used between banks or by a bank's internal treasury operations to settle inter-bank obligations, shift money between branches, or post to suspense accounts via ACH. The 4x decade follows the same one's-digit pattern as the 2x and 3x: 42/47 are the live credit/debit pair, 43/48 are prenotes, 44/49 are zero-dollar remittance, 41/46 are returns/NOCs.

You'll generate these if: You work inside a financial institution's payment operations team, or you're building software for one (core banking, treasury management). Otherwise, no.

You'll receive these if: Almost never. GL entries are bank-to-bank, not bank-to-customer, so they don't appear in normal originator inbound feeds.

Origination access: Most ODFIs do not give corporate originator clients permission to send 4x entries. If you try to submit one and your platform allows it, your ODFI's risk team will likely intervene.

51 52 53 54 55 Loan accounts Specialized · Lender-side

Used when the receiver's "account" is a loan balance rather than a depository account. The 5x decade is the only one that's not symmetric across debit and credit — there's no "debit a loan account" entry, because loan disbursement (giving the borrower money) is conceptually a credit to a checking account, not a debit on the loan. Only codes 51-56 exist; the matrix's debit-side, debit-prenote, and debit-zero-$ cells are intentionally empty for loans.

52 = automated deposit to a loan account (i.e., loan payment received, paying down the balance)

53 = prenote of a loan-account credit

54 = zero-dollar with remittance to a loan account (CCD / CTX only)

51 = return / NOC of an original 52, 53, or 54

55 = reversal of a loan transaction (debit-side reverse)

Practice Most lenders don't use 52 — they use 27 to a checking account. When a borrower makes a loan payment via ACH autopay, the originator (the lender's billing system) is debiting the borrower's checking account (TC 27 with SEC code PPD or CCD), not crediting the loan account directly. The lender's internal system then applies the payment to the loan. So TC 52 is mostly used inside the lender's own back office or in inter-bank loan settlement, not in standard borrower-facing autopay flows. If you're a fintech doing loan billing, you'll be using 27, not 52.
Practice Origination access for 5x codes is restricted. Same as the 4x decade — most ODFIs don't enable 5x origination for non-FI clients. If you genuinely need to credit a loan account (e.g., you're a servicer applying funds), check with your ODFI before designing around it.

Section 3 · Codes that look alike Side-by-side comparisons of the easy-to-confuse pairs

Transaction codes follow a clean grid pattern, but a few cross-comparisons trip people up in production. The three below cover the questions that actually come up.

22 VS 32 Checking vs. savings credit
TL;DR — Identical entry purpose (live credit), different account type. Pick by what the receiver gave you. The wrong choice doesn't always hard-fail — many RDFIs send a C05 NOC asking you to switch — but consistent mismatches will eventually cause hard returns.
Dimension 22 (Checking) 32 (Savings)
Entry directionCredit (deposit)Credit (deposit)
Account type at RDFIChecking / DDASavings / share
Compatible SEC codesPPD, CCD, CTX, WEB credit, IAT, etc.Same set
Service Class typically220 or 200220 or 200
Common mismatch reactionC05 NOC ("change to 32") or R03C05 NOC ("change to 22") or R03
Best forPayroll, AP, refunds — primary deposit accountSplits to savings, credit-union member dividends
22 VS 27 Credit vs. debit on the same account type
TL;DR — Same account type (checking), opposite direction. 22 sends money TO the receiver. 27 pulls money FROM the receiver. Getting these reversed is the most expensive mistake in this whole table — sending what should be a debit as a credit means you've just paid the customer instead of charged them.
Dimension 22 (Credit) 27 (Debit)
Direction of moneyOriginator → ReceiverReceiver → Originator
Account typeCheckingChecking
Service Class typical220 (credit-only)225 (debit-only)
Authorization burdenLight — receiver wants the moneyHeavy — receiver must explicitly authorize the pull
Unauthorized return window (consumer)Limited — receiver welcomes credit; not really an "unauthorized" scenario in normal flow60 days (R10/R11) — the big risk surface for ACH
Common SEC pairingsPPD payroll, CCD APWEB SaaS billing, PPD recurring debits, TEL phone-pay, ARC/POP/BOC check conversion
What goes wrong if you flip themYou pay the customer when you meant to charge them. Hard to recover via ACH — usually requires a reversal entry within 5 banking days, otherwise it's a manual collections problemYou charge the customer when you meant to pay them. Triggers immediate dispute, potential R10 unauthorized return, and customer-relationship damage
22 VS 23 Live vs. prenote (same pattern for 27/28, 32/33, 37/38)
TL;DR — Same direction, same account type — but the prenote is zero-dollar. Use prenote as account validation; wait at least 3 banking days before sending the live equivalent. The pattern repeats across all four account-type decades.
Dimension 22 (Live credit) 23 (Prenote)
DirectionCreditCredit (testing)
Amount fieldReal dollar amountAll zeros (0000000000)
PurposeMove actual moneyValidate account / routing without moving money
Wait period before sending live entry—3 banking days minimum after settlement
Possible RDFI responsesPosts entry, or returns (R01, R03, R04, R10, etc.)Returns (R03 No Account, R04 Invalid Account) or NOC (C01-C09 with corrections), or silently posts and accepts
WEB account validation compliance—Yes — a successfully-posted prenote satisfies the WEB Account Validation Rule for the receiver's account
When to skip prenotes—Same-day signup flows where 3-day wait is too long; use Plaid / GIACT / Finicity API instead

Section 4 · Cases where only one code fits Scenarios where the transaction code is forced

Unlike SEC codes — where there's often "wiggle room" between similar codes — transaction codes are mostly forced once you know the receiver's account type and the entry direction. Below are the production scenarios where only one code is correct, and using anything else means a NOC, a return, or worse.

22 Direct deposit to a checking account
Payroll, government benefit, refund, P2P credit — anywhere money is going INTO a consumer or business checking account. There's no alternative; 32 is wrong (savings), 27 is wrong (debit direction).
27 Pulling a debit from a checking account
SaaS billing, recurring autopay, B2B AR collection from a checking account. The single most common debit code in production. Pair with the appropriate SEC code (PPD for paper-authorized, WEB for online, CCD for B2B, TEL for phone, ARC/POP/BOC for converted checks).
32 Direct deposit split to savings
When an employee tells payroll to send 80% to checking and 20% to savings, the savings half is a separate entry with TC 32. Two entries per person, different transaction codes, otherwise identical PPD format.
37 Debit from a savings account
Receiver explicitly authorized debits from their savings account. Be aware some RDFIs still apply a Reg-D-era 6-per-month limit on savings debits even though the federal rule is gone — extra returns possible (R20).
23 Validating a new checking-credit account
Pre-payroll validation: send a 23 prenote, wait 3 banking days, then live-fire 22. Especially useful when onboarding a new employee whose voided check or onboarding form might have a typo. Doesn't work if you need to charge them in <3 days.
28 Validating a new debit-billable account (and complying with WEB)
For WEB debits, NACHA requires account validation before first use. A successful 28 prenote (no return within the window) satisfies the rule. Cheaper than third-party API integration if your customer signup flow can tolerate the 3-day delay.
24 CCD / CTX zero-dollar remittance entry (B2B)
Healthcare claim payments, lockbox cash applications, treasury workflows — when remittance advice needs to flow over ACH but the actual money settles via wire or a separate ACH. Must be paired with CCD or CTX SEC code.
21 Receiving a return on your checking-credit batch
You sent a payroll batch of 22s yesterday. Today, two of them come back as 21 entries — the RDFI is returning your credits with a return reason code (R03 No Account, R04 Invalid Account, R02 Account Closed) in the addenda. You don't generate 21; you receive it.
How transaction codes interact with SEC codes. Transaction code answers "which account, which direction". SEC code answers "how was this authorized". They're orthogonal — every (TC, SEC) pair is either valid or not based on whether the SEC code supports debits/credits and whether it allows the account type. The Inspector cross-checks these combinations and flags invalid pairs (e.g., TC 24 zero-dollar remit with SEC code PPD — not allowed, must be CCD or CTX).
Validate transaction code × SEC code combinations
The Inspector cross-checks transaction code against SEC code, Service Class, and amount-field constraints — flagging combinations that look invalid before your ODFI sees the file.
Open Inspector →