What Is ACH Discretionary Data?

1. What Is the Discretionary Data Field?

Every ACH payment in a NACHA file is represented by an Entry Detail record (record type 6). Within that 94-character record, positions 77 and 78 are reserved for a field called Discretionary Data.

This is a 2-character alphanumeric field that the originator — the company initiating the ACH payment — can use for any internal purpose. It is entirely optional. If you don't need it, you fill the two positions with spaces. If you do use it, you can assign any meaning you want to those two characters.

The field is not standardized beyond its position and length. Nacha does not define what values are valid (other than requiring alphanumeric characters), and the RDFI (Receiving Depository Financial Institution) does not act on the value. It exists purely as a convenience for the originator.

2. Where It Appears in NACHA Files

The discretionary data field lives in the Entry Detail record (type 6). Here is how the full record is structured, with the discretionary data field highlighted:

Record Type 6 — Entry Detail Record (94 characters)
─────────────────────────────────────────────────────────
Position  Length  Field Name
───────── ──────  ──────────────────────────────────
01-01       1     Record Type Code ("6")
02-03       2     Transaction Code
04-11       8     RDFI Routing (first 8 digits)
12-12       1     Check Digit
13-29      17     DFI Account Number
30-39      10     Amount (in cents)
40-54      15     Individual Identification Number
55-76      22     Individual Name
77-78       2     Discretionary Data    ◄── HERE
79-79       1     Addenda Record Indicator
80-94      15     Trace Number

In a real NACHA file, it looks like this (positions 77-78 shown between markers):

6271210000360123456789      0000150000EMP-1042       John Smith            S10061000010000001

In this example, the originator has placed S1 in the discretionary data field, which might represent “Salary, Division 1” in their internal coding system.

3. Common Uses

Because the field is entirely originator-defined, usage varies widely. Here are the most common patterns:

Internal Department Codes

Companies with multiple divisions use the field to tag which department originated the payment. For example, HR for payroll, AP for accounts payable, or FN for finance.

Batch Identifiers

When a company runs multiple ACH batches per day, the discretionary data can tag entries with a batch sequence like B1, B2, etc. This helps during reconciliation when investigating returns or exceptions.

Processing Flags

Some originators use the field to signal downstream processing instructions to their own systems. For example, RP might mean “repeat payment” or NW might flag a new vendor's first payment for additional review.

Payment Category Markers

Categorize entries by type: VN for vendor payment, RF for refund, PN for prenote, or TX for tax payment. This simplifies post-processing reports and GL mapping.

4. Rules and Restrictions

While the field is flexible, there are a few hard rules:

The key point is that this field is purely internal metadata. It travels with the ACH file through the Federal Reserve or EPN clearing network, but the receiving bank ignores it and the payee never sees it.

5. Best Practices

Keep Codes Consistent

If you use AP for accounts payable entries today, use it every time. Inconsistent usage defeats the purpose of the field and makes historical analysis unreliable.

Document Your Code System

Maintain a simple lookup table that maps each two-character code to its meaning. Share this with your treasury and accounting teams so everyone interprets the codes the same way.

Use It for Reconciliation

The field is most valuable when it helps you match returned or rejected entries back to their source. Tagging entries with a department or batch code makes it much faster to investigate issues.

Don't Over-Rely on Two Characters

Two characters can encode at most 1,296 unique values (36 x 36). For more complex tagging needs, use the Individual Identification Number field (15 characters) or addenda records instead.

6. How BatchPay QB Handles It

BatchPay QB supports the discretionary data field as part of its NACHA file generation. When creating ACH files — whether from QuickBooks transactions or from scratch — you can optionally specify a two-character discretionary data value for your entries.

The application validates that the value is exactly two alphanumeric characters and places it at the correct position (77-78) in each Entry Detail record. If you leave it blank, the field is automatically filled with two spaces to maintain proper line length.

Frequently Asked Questions

What is the discretionary data field in an ACH entry?

The discretionary data field is a 2-character alphanumeric field in the Entry Detail (type 6) record of a NACHA file, located at positions 77-78. It is optional and reserved for use by the originator.

Does the receiver see the ACH discretionary data?

No. The discretionary data field is for the originator's internal use only. It is not transmitted to or visible by the receiver of the ACH payment.

What can I put in the ACH discretionary data field?

You can use any two alphanumeric characters. Common uses include department codes, batch identifiers, processing flags, or internal category markers for reconciliation purposes.

Is the discretionary data field required in a NACHA file?

No, it is optional. If you do not use it, the field should be filled with two spaces to maintain the required 94-character line length.