Build a NACHA ACH Payment File

Skill: Convert a payment batch into a NACHA-formatted ACH file

Region: United States Category: Payments — ACH (NACHA Operating Rules) Does: Takes a payment batch (originator, ODFI, and one or more receiver entries) and produces a NACHA-formatted ACH file — a fixed-width, 94-character-per-line flat file built from File Header (1), Batch Header (5), Entry Detail (6), Addenda (7), Batch Control (8), and File Control (9) records, balanced by entry hash and debit/credit totals and padded to a 10-record block. Standard: NACHA Operating Rules & Guidelines — ACH file specification (94-character records, blocking factor 10)

An ACH file is a fixed-width flat file delivered to your ODFI (Originating Depository Financial Institution) or a payment processor, not an XML or JSON document and not something you submit directly to a Federal Reserve / clearing operator yourself. Every record line is exactly 94 characters; the file's total record count must be a multiple of 10 (padded with all-9 filler lines). Always confirm the exact format (immediate origin/destination, SEC code, effective entry date, batch numbering) with your bank's implementation guide before transmission, and verify routing numbers with the ABA mod-10 check digit. The NACHA Rules change annually — confirm the current edition.

When this applies

• An Originator (employer, biller, lender, platform) wants to push or pull funds electronically through the ACH network and must hand its bank (the ODFI) a NACHA file.
• Typical uses: payroll direct deposit (PPD credits), vendor payments (CCD credits), consumer debits for bill payment or web-authorized one-time pulls (WEB), and cross-border entries (IAT).
• Not for wire transfers (Fedwire/CHIPS), RTP/FedNow instant payments, or card networks — those use entirely different formats.

Record types (file layout)

Each NACHA file is a strict sequence of fixed-width records. Record Type Code is position 1 of every line.

Conversion procedure

1. Read the source — accept CSV/JSON/pasted payment rows. Each row needs: receiver name, receiving DFI routing number (9 digits), account number, account type (checking/savings), amount, and credit/debit direction. Read the originator/ODFI block once (company name, company ID, ODFI routing number, immediate origin/destination).
2. Extract & validate identifiers — verify every 9-digit routing number against the ABA mod-10 check digit (see Calculation rules). If a routing number fails, stop and ask; do not guess a digit.
3. Choose the SEC code — PPD for consumer prearranged (payroll, bill pay with standing authorization), CCD for corporate/vendor, WEB for internet-authorized consumer debits, IAT for international. The SEC code goes in the Batch Header and dictates addenda rules.
4. Assign transaction codes — map each entry's account type + direction to a 2-digit transaction code (22/32 checking/savings credit, 27/37 checking/savings debit; see Code tables).
5. Compute the entry hash — sum the first 8 digits of each entry's RDFI routing number across the batch (and file), keeping the rightmost 10 digits.
6. Compute batch totals — entry/addenda count, total debit dollar amount, total credit dollar amount, for the Batch Control (8) record; repeat the same totals at file level for the File Control (9).
7. Emit fixed-width records — every line exactly 94 characters, right-justified zero-filled numerics, left-justified space-filled alphanumerics. Reference the worked example as the byte-for-byte template.
8. Block the file — append all-9 filler lines until the total number of physical records is a multiple of 10 (blocking factor 10).
9. Validate — run the validation checklist before handing the file to the ODFI.

Source → NACHA field map

Document structure

File Header (1)                       ← one per file; immediate dest/origin, creation date
└── Batch (one or more)
    ├── Batch Header (5)              ← service class, company, SEC code, effective date
    │   ├── Entry Detail (6)          ← one per transaction: txn code, RDFI, account, amount
    │   │   └── Addenda (7)           ← optional (PPD/CCD: 0 or 1; WEB: payment info; IAT: 7+)
    │   ├── Entry Detail (6) ...
    │   └── Batch Control (8)         ← entry/addenda count, entry hash, total debit, total credit
    └── Batch Header (5) ...          ← additional batches (e.g. one per SEC code)
File Control (9)                      ← batch count, block count, entry/addenda count, file hash, totals
9999999999999999... (filler)          ← all-9 lines padding to a multiple of 10 records

Notes: a batch is single-SEC — group entries by SEC code into separate 5/8 batches. The Service Class Code (200 mixed / 220 credits-only / 225 debits-only) must match the entries inside. PPD/CCD allow at most one 7 addenda per entry; WEB/IAT have their own addenda requirements.

Code tables

Standard Entry Class (SEC) codes (Batch Header pos 51–53)

Service Class Code (Batch Header pos 2–4 / Batch Control pos 2–4)

Transaction codes (Entry Detail pos 2–3, selected)

Record Type Codes (position 1)

Calculation rules

• Routing-number check digit (ABA mod-10): for the 8-digit routing prefix d1 d2 d3 d4 d5 d6 d7 d8, the 9th (check) digit makes the following weighted sum a multiple of 10: 3(d1+d4+d7) + 7(d2+d5+d8) + 1(d3+d6) + checkdigit ≡ 0 (mod 10). Example for 02100002 → 3(0+0+0)+7(2+0+0)+1(1+0)=15; check digit = 10 − (15 mod 10) = 5; full routing 021000025. Reject any entry whose stated routing number fails this test.
• Amount fields are in cents with no decimal point, right-justified, zero-filled to 10 digits ($1,250.00 → 0000125000).
• Entry hash = sum of the first 8 digits of each Entry Detail's RDFI routing number across the batch; keep the rightmost 10 digits (drop any overflow on the left). The File Control hash is the sum across all batches, same rule.
• Entry/Addenda Count = count of 6 records + count of 7 records in the batch (Batch Control) or file (File Control).
• Total Debit / Total Credit Entry Dollar Amount = sum of amounts on debit (27/37) entries and credit (22/32) entries respectively, in cents, right-justified zero-filled (12 digits batch, 12 digits file).
• Block Count (File Control pos 2–6) = total physical records ÷ 10, rounded up; pad with all-9 lines so the count is exact.
• Balanced file: for an offset/balanced file, total debits must equal total credits; for an unbalanced credit-only file (Service Class 220) total debit = 0.
• Always recompute every count, hash, and total from the entries — never copy a figure asserted in the source; flag any mismatch.

Worked example (end-to-end)

Originator ACME PAYROLL INC (company ID 1234567890) at ODFI First Bank (routing 091000019) sends a PPD payroll credit batch (Service Class 220, credits only) on file creation date 2026-06-13. One employee entry: JOHN DOE, checking account 1234567890 at RDFI routing 021000025, $1,250.00.

Computed values: transaction code 22 (checking credit); amount 0000125000; entry hash = first 8 digits of 021000025 = 02100002 → hash 0021000020 per record (10-digit, here one entry → 0021000020); entry/addenda count 1; total credit 000000125000; total debit 000000000000. Six records → pad with four 9 filler lines to reach 10 (blocking factor 10), block count 1.

101 091000019123456789026061312250101First Bank             ACME PAYROLL INC       
5220ACME PAYROLL INC                    1234567890PPDPAYROLL   260613   1091000010000001
62202100002512345678901   0000125000               JOHN DOE              0091000010000001
82200000010002100002000000000000000000125000123456789                         091000010000001
9000001000001000000010021000020000000000000000000125000                                       
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

Each line above is exactly 94 characters. Reading the records: the 1 File Header carries immediate destination 091000019 and origin 1234567890; the 5 Batch Header sets Service Class 220, SEC PPD, entry description PAYROLL, effective date 260613, ODFI prefix 09100001; the 6 Entry Detail carries transaction code 22, RDFI 02100002 + check digit 5, account, amount 0000125000, receiver name, and a 15-digit trace number (ODFI prefix + sequence); the 8 Batch Control restates Service Class 220, count 000001, hash 0021000020, total debit 000000000000, total credit 000000125000; the 9 File Control gives batch count 000001, block count 000001, entry/addenda count 00000001, file hash 0021000020, and file debit/credit totals. The four trailing 9 lines pad the 6 data records up to a 10-record block.

Normalisations shown: $1,250.00 → 0000125000 (cents, no point, 10-digit zero-fill); routing 021000025 → prefix 02100002 + check digit 5 (mod-10 verified); date 2026-06-13 → 260613 (YYMMDD); account type checking + credit → transaction code 22; Service Class 220 because the batch is credits-only.

Validation checklist

• Every record line is exactly 94 characters; numerics right-justified zero-filled, alphanumerics left-justified space-filled
• First line is the 1 File Header; the 9 File Control follows the last 8 Batch Control
• Every routing number passes the ABA mod-10 check digit; AI asked about any that failed rather than guessing
• SEC code matches the entries (PPD consumer / CCD corporate / WEB internet-debit / IAT cross-border); one SEC per batch
• Service Class Code (200/220/225) consistent between Batch Header, entries, and Batch Control
• Each entry's transaction code (22/27/32/37) matches account type + debit/credit direction
• Amounts in cents, no decimal point, 10-digit zero-filled
• Entry/Addenda Count, Entry Hash, Total Debit, and Total Credit recomputed and reconciled at batch (8) and file (9) level
• Effective Entry Date is a valid future banking day in the ODFI's window
• File padded with all-9 filler so total records ÷ 10 is whole; Block Count matches
• File confirmed against the ODFI's implementation guide and the current NACHA Operating Rules before transmission

Last updated: 2026-06-13 — verify the current NACHA Operating Rules edition, your ODFI's implementation guide (immediate origin/destination, batch numbering, addenda requirements per SEC code), and the 94-character/blocking-factor-10 layout before use.