Why NACHA File Amounts Have No Decimal Point (Implied Decimals Explained)

Last updated July 2026.

NACHA file amounts have no decimal point because the amount field stores the value in cents as a right-justified, zero-filled 10-digit number. A payment of $1,234.56 is written as 0000123456, and $9.00 is written as 0000000900. There is no dollar sign, no comma, and no period anywhere in the record. To read the real dollar amount you divide the field by 100, or put a decimal two places from the right. Miss that and every amount in the file looks 100 times too large, which is the single most common mistake when someone opens an ACH file in a spreadsheet.

Where the amount sits in a NACHA record

A NACHA (ACH) file is a stack of fixed-width 94-character records, not a spreadsheet. The dollar amounts live in the Entry Detail records (record type 6), one per transaction. In a standard PPD or CCD entry, the amount is a 10-character field at positions 30 through 39, formatted as cents with leading zeros. Because the field is fixed width, a small payment is padded on the left with zeros so it still fills all 10 characters.

Why cents-based amounts exist

The format dates to fixed-width mainframe files, where storing amounts as whole cents avoids the rounding and parsing problems that a floating decimal introduces. Every ACH participant reads the same 10-digit field the same way, so a payroll file written by one bank's software totals correctly when the receiving bank processes it. The tradeoff is that the file is not human-friendly: you cannot eyeball an amount, and any tool that imports it has to know the field is in cents.

How to convert the amounts when you open a NACHA file in Excel

If you import a NACHA file into a spreadsheet as fixed-width columns, the amount column comes in as a 10-digit integer like 123456. Add a formula column that divides by 100 to get the real value: =A2/100 gives 1234.56. Format that column as currency and the file reads like money. Two cautions. First, do not let Excel strip the leading zeros on the routing or account fields when you import, or you will corrupt them; bring those columns in as text. Second, check your grand total against the file's Batch Control and File Control records, which carry their own entry-count and dollar totals so you can prove the import is complete.

The manual fixed-width import works for one file, but it is fiddly and easy to get wrong. To skip the column-mapping and the divide-by-100 step entirely, a NACHA file to Excel converter reads the record layout, applies the implied decimal, and returns dated rows with real dollar amounts. The full manual walkthrough, including the fixed-width import and Power Query, is in how to open a NACHA file in Excel or convert it to CSV.

Validate the totals before you trust the sheet

Once the amounts are in dollars, tie them out. Sum your Entry Detail amounts and compare against the total debit and total credit dollar amounts in the Batch Control record (record type 8) and the File Control record (record type 9). Compare the entry count too. If the divide-by-100 was applied to the wrong column, or a record was dropped on import, the totals will not match and you will catch it here. Reconciling the file against the money that actually posts to the account is a separate check, covered in how to reconcile an ACH file against your bank statement.

Reading vs generating ACH files

Everything above is about reading amounts out of a NACHA file. If you are on the other side, building a file to send to the bank, the same rule runs in reverse: multiply the dollar amount by 100 and write the whole number of cents into the 10-digit field with leading zeros. For the field-by-field layout of every record type, see how to read a NACHA file. Finance teams that generate ACH files to pay vendors at volume usually move that work into accounts payable automation software so the file is built, validated, and sent without hand-editing cent fields.

Other records where amounts appear

The Entry Detail record is where per-transaction amounts live, but the same cents-with-no-decimal rule applies everywhere a dollar figure appears in the file. The Batch Control record (type 8) carries a total debit amount and a total credit amount for the batch, each a 12-digit field in cents. The File Control record (type 9) carries file-wide total debit and credit amounts as even longer fields, again in cents. When you validate, apply the same divide-by-100 to those control totals before comparing them to your summed Entry Detail rows, or the comparison will be off by a factor of 100 and look like a failure when the file is fine.

Returns and notifications of change

If you are reading a return file, the returned Entry Detail records still carry the original amount in the same 10-digit cents field, alongside a return reason in the addenda. A Notification of Change (NOC, an R record with a COR addenda) corrects account or routing information and generally echoes a zero or the original amount rather than moving new money. The point for categorization is simple: read the amount field the same way in every record type, then let the return or NOC code tell you what actually happened to the money.

Symptoms of the decimal mistake

You can spot a botched implied decimal at a glance. If a $500 payroll entry shows as $50,000, or your batch total is exactly 100 times the money that posted to the account, the divide-by-100 step was skipped. If amounts show as 1234.56 but the routing and account numbers lost their leading zeros, the import treated numeric-looking fields as numbers instead of text. Both are import errors, not file errors, and both disappear when a converter that understands the ACH layout does the parsing for you.