2.5 Exception Record Formats: Return (Addenda 99) & Notification of Change (Addenda 98) Layouts
Key Takeaways
- A Return Entry is built from a copy of the original Entry Detail Record plus a single Addenda Record carrying Addenda Type Code 99, which holds the Return Reason Code, the Original Entry Trace Number and the Original Receiving DFI Identification.
- A Notification of Change uses SEC Code COR with Addenda Type Code 98, carrying the Change Code and a 29-character Corrected Data field in positions 36-64 of the addenda record.
- Dishonored and contested dishonored returns reuse the Addenda Type Code 99 structure with their own reason codes, and a Refused Notification of Change reuses the 98 structure with Refused COR codes.
- In a Return or NOC the roles invert: the original RDFI becomes the originating party, so the batch is built under its own routing number and carries a new Trace Number while preserving the Original Entry Trace Number for matching.
- Every addenda record is 94 characters and begins with Record Type Code 7; the Addenda Type Code in positions 2-3 is what tells a receiving system how to parse the remaining 91 characters.
2.5 Exception Record Formats: Return (Addenda 99) & Notification of Change (Addenda 98) Layouts
Quick Reference: ACH File Formatting is only 8% of the AAP blueprint, but it is dense, factual and easy to bank if you learn the layouts. Exception traffic — returns, NOCs, dishonored returns, refused NOCs — is not a separate file format. It is the same 94-character record structure with a different Addenda Type Code in positions 2-3.
1. The Addenda Type Code Is the Parser
Every Addenda Record is Record Type Code 7 and exactly 94 characters. Positions 2-3 carry the Addenda Type Code, and that two-digit value tells a receiving system how to interpret the remaining 91 characters.
| Addenda Type Code | Used with | Carries |
|---|---|---|
02 | POS, MTE, SHR | Terminal identification, terminal city and state, transaction serial number |
05 | PPD, CCD, WEB (one addenda), CTX (up to 9,999) | Payment Related Information — invoice data, ASC X12 820 remittance |
10-18 | IAT | Types 10–16 are mandatory; Type 17 is optional remittance data; Type 18 is conditional correspondent-bank data |
98 | COR — Notification of Change and Refused NOC | Change Code and Corrected Data |
99 | Returns, dishonored returns, contested dishonored returns | Return Reason Code and original entry identifiers |
Memorize the pair that matters most: 98 corrects, 99 returns.
2. The Return Addenda Record (Addenda Type Code 99)
A Return Entry is not a free-form message. The RDFI takes a copy of the original Entry Detail Record, adjusts the Transaction Code as needed to reverse the direction of the item, and attaches one Addenda Record with Addenda Type Code 99.
| Field | Positions | Length | Contents |
|---|---|---|---|
| Record Type Code | 01-01 | 1 | Constant 7 |
| Addenda Type Code | 02-03 | 2 | Constant 99 |
| Return Reason Code | 04-06 | 3 | The R-code — R01, R10, R29 and so on |
| Original Entry Trace Number | 07-21 | 15 | The Trace Number of the entry being returned — the audit anchor |
| Date of Death | 22-27 | 6 | YYMMDD. Used only where the return reason involves a deceased Receiver |
| Original Receiving DFI Identification | 28-35 | 8 | First 8 digits of the RDFI routing number from the original entry |
| Addenda Information | 36-79 | 44 | Free-form supporting detail, used sparingly and by specific R-codes |
| Trace Number | 80-94 | 15 | The Trace Number assigned to this return, built from the returning institution's routing number |
The Role Inversion
When an RDFI returns an entry, it is originating the return. That means:
- the return travels in a batch built under the returning institution's routing number;
- the addenda carries a new Trace Number in positions 80-94;
- the Original Entry Trace Number in positions 07-21 is what lets the ODFI, the Originator and every downstream system match the return back to the payment.
If positions 07-21 are wrong, the return is functionally unmatched no matter how correct everything else is. This is why trace-number integrity is one of the first things an auditor samples in exception testing.
Dishonored and Contested Dishonored Returns
These reuse the same 99 structure. A dishonored return is the ODFI's response when it believes the RDFI's return was untimely or improper; a contested dishonored return is the RDFI's answer to a dishonor. They carry their own dedicated reason-code ranges, but the record architecture — Type 7 record, Addenda Type Code 99, Return Reason Code in 04-06, Original Entry Trace Number in 07-21 — is unchanged.
3. The Notification of Change Addenda Record (Addenda Type Code 98)
A Notification of Change is a zero-dollar, non-monetary entry the RDFI originates under SEC Code COR to tell the Originator that data in a live entry was posted but needs correcting for future entries.
| Field | Positions | Length | Contents |
|---|---|---|---|
| Record Type Code | 01-01 | 1 | Constant 7 |
| Addenda Type Code | 02-03 | 2 | Constant 98 |
| Change Code | 04-06 | 3 | C01 through the published range — identifies what is wrong |
| Original Entry Trace Number | 07-21 | 15 | Trace Number of the entry that prompted the NOC |
| Reserved | 22-27 | 6 | Blank |
| Original Receiving DFI Identification | 28-35 | 8 | First 8 digits of the RDFI routing number from the original entry |
| Corrected Data | 36-64 | 29 | The corrected value, left-justified and blank-filled |
| Reserved | 65-79 | 15 | Blank |
| Trace Number | 80-94 | 15 | Trace Number assigned to the COR entry |
The Corrected Data field is the whole point of the record, and its content is governed entirely by the Change Code. A C01 supplies a corrected account number; a C02 supplies a corrected routing number; a C03 supplies both a routing number and an account number packed into the single 29-character field. A receiving system that applies Corrected Data without first reading the Change Code will corrupt the customer record — which is precisely why the Originator's 6-Banking-Day update obligation is an operational rule, not a clerical one.
Refused Notification of Change
When the ODFI receives an NOC it cannot process — bad routing data, an untimely transmission by the RDFI, an unmatched trace — it originates a Refused NOC using the same 98 addenda structure with a Refused COR code, transmitted within 15 calendar days of the NOC's Settlement Date.
4. Worked Example: Tracing One Item Through Three Records
Northbrook Bank (routing 121000358) originates a PPD debit for entry sequence 4 in its batch.
- Original Entry Detail Record — Trace Number in positions 80-94 is
121000350000004(first 8 digits of the ODFI routing number plus a 7-digit ascending sequence). - The RDFI returns it R03 (No Account / Unable to Locate Account). The return addenda carries
99in positions 02-03,R03in 04-06, and121000350000004in positions 07-21. Positions 80-94 carry a new trace number built from the RDFI's routing number. - Alternatively the RDFI posts the item and sends a C01. The COR addenda carries
98in 02-03,C01in 04-06,121000350000004in 07-21, and the corrected 17-character account number left-justified in positions 36-64.
In both branches, positions 07-21 are identical. That is the field that stitches the exception back to the payment.
Exam trap: the Original Entry Trace Number is in the addenda record (positions 07-21), not in the Entry Detail Record of the return. The Entry Detail Record of a return carries its own trace in positions 80-94 like any other entry. Answer choices that place the original trace in the Type 6 record are wrong.
Which Addenda Type Code identifies a Notification of Change addenda record, and which field carries the corrected value?
An RDFI returns an entry that Northbrook Bank originated with Trace Number 121000350000004. Where does that trace number appear in the return, and what appears in positions 80-94 of the return addenda?
What is the record structure of a dishonored return?
Why must a receiving system read the Change Code before applying the Corrected Data field of a COR addenda record?