An ACH file is a fixed-width ASCII payment file. Every line is a 94-character record, and each field occupies a prescribed position. Unlike JSON or XML, record order and field placement are part of the format, so a parser reads character ranges rather than flexible tags or delimiters. section 2.3 section 2.4.2
The format carries payment information between financial institutions. A payroll processor can send wage data to its bank; ACH operators sort transactions by routing transit number and create files for receiving banks, which post the transactions. Nacha defines the ACH file format used for this network. section 2.2
Figure 2.2 ACH file layout
Use the layout to see how file-level records contain batches and how batch-level records contain payment entries and optional addenda. section 2.3
An ACH file may contain six record types:
- Type 1: one file header record. section 2.3
- Type 5: batch header records; a file can contain multiple batches. section 2.3
- Type 6: entry-detail payment records; a batch can contain multiple entries. section 2.3
- Type 7: optional addenda records associated with an entry. section 2.3
- Type 8: a batch control record that encloses entry and addenda records. section 2.3
- Type 9: a file trailer or control record that encloses the batches. section 2.3
A practical parser can inspect the first character to select a parser for each record type, then slice fixed positions into named fields. For example, an entry-detail parser can extract its transaction code, receiving institution identifier, account number, and amount. Keeping each record type in a separate function makes the logic easier to test with both valid and invalid lines. section 2.3.1 section 2.4.2
Checking a malformed upload
Before treating a file as usable, check that every record is 94 characters and that records appear in the required hierarchy: files contain batches, batches contain entries and addenda, and both levels have control records. Rather than stopping at the first bad line, a parser can accumulate errors so unit tests can verify all expected failures. Short records can arise when trailing spaces were truncated during file transfer or when files were edited or retransmitted. section 2.6.1 section 2.4.2
Parsing makes the flat file useful to an application. Parsed files and their individual records can be stored in a relational database for querying, analytics, and integrity checks; otherwise, locating a historical transaction may require loading and parsing every file. An upload API can acknowledge receipt first and begin parsing as a separate task, avoiding a long wait while later processing may include account, balance, sanctions, or fraud checks. section 5.0 section 5.6
Generating focused test files
A BDD-style test can describe a file with a chosen destination, origin, batch count, debit entries, amounts, and company information. Programmatic generation supports small, repeatable scenarios for checking file creation, loading, parsing, APIs, and the user interface. Such generated files provide flexibility for testing but do not by themselves enforce all business rules for producing ACH files. section 7.6
An ACH dashboard can bring the workflow together: upload a file, parse and store it, then visualize the results. This replaces a workflow limited by delayed file availability, rudimentary totals, legacy-database reporting constraints, and restricted backend access. section 7.0 section 1.4
