ACH
The Automated Clearing House (ACH) is an electronic funds-transfer system that facilitates payments. ACH is run by the National Automated Clearing House Association (Nacha), the governing organization of ACH networks. There are two ACH networks in the US: FedACH and EPN. FedACH is the Federal Reserve Bank's ACH service and handles public transfers. EPN is The Clearing House's ACH Service and only handles private transfers.
ACH is a common payment method, typically used for direct deposits and bill payments.
ACH offers two services for domestic transactions:
-
Same Day: The ACH transaction is processed and settled on the same business day. There is a limit of $1,000,000.00 per Same Day ACH transaction.
-
Standard: The ACH transaction is processed but settles on the next business day. Credit transactions may be processed up to two business days prior to the settlement date.
An ACH transaction is either a push or pull depending on your role in the transaction. Both the originator and the receiver can push or pull funds.
-
The Originating Depository Financial Institution (ODFI) sends fund or sends a pull requests (to receive money)
-
The Receiving Depository Financial Institution (RDFI) receives funds or receives a pull request (to send money)
Difference between Same Day ACH (SDACH) and Instant Payments (RTP/FedNow)
Same Day ACH payments are cleared in batches and settle after the payments clear.
Instant Payments clear and settle individually in real time immediately.
Nacha settlement rules and limitations

-
According to Nacha rules, settlement happens the day after the transaction is initiated.
-
Nacha operating rules require standard ACH credits to settle in 1-2 business days.
-
ACH debits settle the next business day.
-
There is no settlement on weekends or federal holidays.
-
Same day settlement happens on the same day as the transaction is originated.
-
The entry must be processed by FedACH before 4:45pm EST for it to be settled on the same day.
-
-
Domestic transactions must be less than $1,000,000
-
Same day ACH transactions with an international leg are ineligible
-
Transactions can take up to 90 days to finalize.
ACH transactions may be rejected because of non sufficient funds or because it is unauthorized, for up to 90 days after the date of the transaction
ACH parties

Participant |
Explanation |
---|---|
Originator |
The party - individual or company - that originates a credit, debit, or non-monetary entry into the ACH payment system for receipt by the Receiver account. The Originator must have an arrangement with the ODFI directly or through a third-party sender and an authorization from the Receiver to initiate the transaction. |
Originating Depository Financial Institution (ODFI) |
The financial institution that originates the payment and forwards it to the ACH Operator. |
ACH Operator |
Receives entries from ODFIs, sends the entries to appropriate RDFIs, and performs settlement functions for the financial institutions. The two primary ACH Operators in the US are the Federal Reserve Bank (FedACH) and the The Clearing House (EPN). |
Receiving Depository Financial Institution (RDFI) |
The financial institution that receives the credit or debit entry from the ODFI and posts it in the receiver account. |
Receiver |
The party - individual or company - that receives the debit or credit entry. |
Third-party service provider (optional) |
Acts on behalf of the originator, ODFI, or RDFI regarding ACH entries and transactions. This includes creating ACH files for an originator or ODFI and acting as a sending or receiving point for an ODFI or RDFI. A third-party sender acts on behalf of the originator when there is no agreement between the ODFI and originator for ACH origination services. A third-party sender is never the originator for entries it transmits on behalf of another organization. A third-party sender of entries may be an originator of other entries. Cross River can act as the ODFI for outbound ACH transactions or the RDFI for inbound ACH transactions. |
A Depository Financial Institution (DFI) can act as an RDFI without being an ODFI. If a DFI wants to originate ACH entries, it must act as both the ODFI and the RDFI. The ODFI must be able to receive payment returns.
All parties in an ACH transaction must comply with the Nacha rules.
Credit entries

Posting entries and funds availability are determined by the Settlement Date in the Company Batch Header Record.
Standard ACH credit entries
Standard ACH credits are made available to the RDFI by the ACH Operator no earlier than two banking days prior to the Settlement Date. It is recommended that credits be posted or at a minimum, memo-posted, prior to opening of business on Settlement Date. However, credit entries can be posted prior to the Settlement Date if the RDFI cannot warehouse the entry. The RDFI should consider the effect of posting credits and making funds available to the Receiver prior to the date on which the RDFI receives settlement for those credits.
The Nacha Operating Rules require that credit entries be made available for withdrawal by the customer on the Settlement Date. An RDFI can satisfy this obligation by making the entry available for withdrawal at the RDFI teller facilities by the close of business on the Settlement Date or at an ATM by midnight on the Settlement Date.
The RDFI must make funds available for withdrawal or cash withdrawal for any standard processing credit entry:
-
No later than 9 am. (RDFI local time) on the Settlement Date.
-
The entry is made available to the RDFI by the ACH Operator no later than 5:00 pm. RDFI local time on the banking day prior to the Settlement Date.
This rule applies to all credit entries that meet the timing requirement, regardless of Standard Entry Class Code. An entry or entry data is made available to an RDFI or its receiving point when the entry or entry data is processed by the RDFI ACH Operator and is ready for distribution.
Same-day processing ACH credit entries
Same-day processing ACH credits will be delivered to the RDFI on the Settlement Date.
-
RDFIs must generally make available for withdrawal the amount of a same-day credit entry received in the first same-day processing window.
-
They must do this no later than 1:30 pm. RDFI local time on the Settlement Date.
An RDFI that reasonably suspects that a credit entry is unauthorized is exempt from these requirements, subject to applicable legal requirements. An RDFI invoking such an exemption must promptly notify the ODFI.
For a same-day credit entry received in the second same-day processing window, most RDFIs are required to make funds available for withdrawal no later than 5:00 pm. RDFI local time on Settlement Date.
Debit entries

Standard processing ACH debit entries
Standard processing of ACH debits will be made available to an RDFI no earlier than one banking day prior to the Settlement Date.
Same-day processing ACH debit entries
Same-day processing of ACH debits will be made available to the RDFI on the Settlement Date. The Nacha Operating Rules prohibit RDFIs from posting debits prior to the Settlement Date.
For more detailed information on the ACH processing schedule, see here.
ACH transactions only settle on business days (no settlement on weekends or federal holidays). Transactions only occur on business days (no support on weekends or banking holidays).
Common ACH Standard Entry Class (SEC) codes
International ACH support (IAT)

The SEC transaction code for international transactions with a foreign leg is IAT. This code indicates to organizations in the transfer chain that the payment is international. This includes payments that began in foreign countries and are converted to ACH transactions within the US and payments that ultimately complete abroad. In either case, Cross River passes information to the intermediary FI and not to the overseas FI.
If you want to transfer funds internationally using CR and ACH, CR transfers the funds to a US bank that can do international transfers. And if you want to receive funds from outside the US using ACH, the funds will first be transferred to a US bank that can do international transfers, and from there be transferred to CR.
Any payment over the ACH network that originates or ends in a foreign FI must use the IAT SEC code. The CR service type will always be Standard.
The payment information and data you send to Cross River must conform with the Nacha SEC codes and Nacha transaction rules.
ACH addenda records
ACH addenda records provide supplemental data to identify an account holder or provide information about the payment. This may include details such as invoice numbers.
ACH at Cross River
The Cross River ACH API allows you to both originate and receive payments through the Federal Reserve ACH network. We receive your transaction details as an API call, process them, and release them to the Federal Reserve. The API set includes endpoints and webhooks. We can process ACH transactions sent as:
-
An API call for a single payment
-
An API call for multiple payments (batch)
Cross River validates the payments before releasing them to the Federal Reserve. The transaction is sent to the Federal Reserve and is routed to the designated FI.
-
ACH transactions settle on business days. There is no settlement on weekends or federal holidays.
-
Transactions occur on business days. There is no support on weekends or banking holidays.
Supported transaction types

Standard
Standard processing of ACH debits is made available to an RDFI no earlier than one banking day prior to the Settlement Date.
Same day
Same day ACH transactions debit and credit funds on the same day that the transaction is initiated. This makes the funds available to the RDFI on the settlement date. The Nacha Operating Rules prohibit RDFIs from posting debits prior to the settlement date. There is a limit of $100,000.00 per Same Day ACH transaction.
Domestic IAT
IAT is a Nacha SEC code. Cross River can originate or receive IAT payments to or from the US intermediary FI of an account at an FI outside the US. Cross River passes information to the intermediary FI. See International ACH support.
The payment information and data you send to Cross River must conform with the Nacha SEC codes and Nacha transaction rules.

Outbound from the originator |
Inbound to the receiver |
The originator pushes funds to the receiver.
The balance in the originator account decreases and the balance in the receiver account increases. |
Outbound from the receiver after receiving a request for funds |
Inbound to the originator |
The originator sends a request for funds to the receiver.
The balance in the originator account increases and the balance in the receiver account decreases. |
Account settlements and time windows

-
Any transaction tied to an ACH payment executes on the effective date of the payment.
-
The
serviceType
(either Standard or Same Day) and the configured cutoff time influence the effective payment date.Example-
A Same Day payment originates on Tuesday, 8/24 at 12 pm. The cut off time is configured for 1 pm. The
effectiveDate
of the payment is 08/24. -
A Same Day payment originates on Tuesday, 8/24 at 3 pm. The cut off time is configured for 1 pm Same Day cutoff. The
effectiveDate
of the payment is 08/25 because the payment originated after the cutoff time. The service type remains SameDay in the system, despite the next-day effective date. -
A Standard payment originates on Tuesday, 08/24. The
effectiveDate
of the payment is 08/25.
-
-
When the payment is released to the Federal Reserve and receipt of payment is acknowledged, we execute the transactions on the payment
effectiveDate
.
Cross River time windows
Cross River batch-sends files received throughout the day. To process a payment for any time window, the files must go through the due diligence process before the cutoff time.
Same day Domestic US |
10 AM EST, 1 PM EST, 2 PM EST |
Standard/Next Day Domestic US |
10 AM EST, 11 AM EST, 1 PM EST, 2 PM EST, 3 PM EST, 330 PM EST, 4 PM EST, 5 PM EST, 6 PM EST |
Standard/Next Day Domestic IAT |
10 AM EST, 12 PM EST, 2 PM EST |
Hold days
ACH allows FIs to delay the availability of credits to accounts which results from outbound pull payments. This ensures that funds are available before the transaction is approved. This helps prevent losses that result from returned outbound pull payments. Hold days use a business day logic and start with the effective date of the ACH payment.
When a pull transaction return occurs during the hold period, the hold is manually removed. This is done to net the credit to the account holder for the outbound pull payment with the debit resulting from the ACH return.
You can determine when funds will be available in your account by reviewing the details of the schedule included in the payment core transaction.

-
Locate the
coreTransactionId
for the payment. -
Use the
coreTransactionId
in theGET /core/v1/transactions/{id}
endpoint to view the availability schedule.The schedule is displayed in the schedule attribute.
CopySample Get Transaction by ID
{
"id": "eb2f24bb-f25e-4fd7-b628-bc82d8b92cc3",
"traceNumber": "T222271777297136J",
"status": "Complete",
"debit": {
"transactionType": "Debit",
"accountType": "GeneralLedger",
"masterAccountNumber": "123456789",
"subAccountNumber": "123456789",
"partnerId": "13eb292e-cb33-402a-af11-610b0955dbc1",
"productId": "45be4bca-d962-4105-8e54-df9146649598",
"result": {
"success": true,
"code": "OK",
"message": "OK"
}
},
"credit": {
"transactionType": "Credit",
"accountType": "Deposit",
"masterAccountNumber": "2223334445",
"subAccountNumber": "2223334445",
"partnerId": "13eb292e-cb33-402a-af11-610b0955dbc1",
"productId": "45be4bca-d962-4105-8e54-df9146649598",
"result": {
"success": true,
"code": "OK",
"message": "OK"
}
},
"transactionCode": "Outgoing ACH",
"amount": 100,
"currency": "usd",
"description": "Bob Smith TRANSFER ACH WEB REF: A123Z456C78A",
"rail": "Ach",
"railId": "payment/89f83e89-806e-4b59-a02e-e71fa5c079fc",
"flags": [
"DIR:Outbound",
"TYP:Origination",
"FRC"
],
"schedule": [
0,
0,
0,
0,
0,
0,
100
],
"proposedAt": "2021-11-23T17:34:29.347-05:00",
"executedAt": "2021-11-24T01:54:29.51-05:00",
"effectiveAt": "2021-11-24T01:54:29-05:00",
"lastModifiedAt": "2021-11-24T01:54:29.511742-05:00"
}The schedule always displays the total number of values equal to the number of calendar days from when the funds are held to when they are made available.
Sample Get Payment by ID
{
"id": "89f83e89-806e-4b59-a02e-e71fa5c079fc",
"accountNumber": "2223334445",
"referenceId": "A123Z456C78A",
"paymentType": "Origination",
"direction": "Outbound",
"status": "Complete",
"source": "Api",
"postingType": "Individual",
"fedBatchId": "8719a7b1-f32d-4b7f-a2cc-e713a3ee86a5",
"fedBatchSequence": 61,
"coreTransactionId": "eb2f24bb-f25e-4fd7-b628-bc82d8b92cc3",
"memoPostId": "14ba1090-eff6-4fae-8d73-968c6276a2fb",
"postingCode": "OK",
"posting": "Posted",
"originator": {
"routingNumber": "021214891",
"accountNumber": "2223334445",
"accountType": "Checking",
"name": "Upgrade CRB",
"identification": "5555512345"
},
"receiver": {
"routingNumber": "026009593",
"accountNumber": "42424242652",
"accountType": "Checking",
"name": "Bob Smith"
},
"secCode": "WEB",
"description": "Transfer",
"transactionType": "Pull",
"amount": 100,
"serviceType": "SameDay",
"extendedDetails": {
"paymentType": "0"
},
"effectiveDate": "211124",
"traceNumber": "021214899990142",
"wasReturned": false,
"wasCorrected": false,
"holdDays": 3,
"original": {
"paymentId": "89f83e89-806e-4b59-a02e-e71fa5c079fc"
},
"createdAt": "2021-11-23T13:49:34.907-05:00",
"processedAt": "2021-11-23T17:34:29.123-05:00",
"completedAt": "2021-11-24T01:54:29.593-05:00",
"postedAt": "2021-11-24T01:54:29.593-05:00",
"partnerId": "13eb292e-cb33-402a-af11-610b0955dbc1",
"productId": "45be4bca-d962-4105-8e54-df9146649598",
"lastModifiedAt": "2021-11-24T01:54:29.5947471-05:00"
}

In the example response above, there are 7 values in the schedule because there are a total of 7 calendar days from 11/24 to 11/30.
Since the effective date is Wednesday 11/24/2021, the funds will be available on Tuesday 11/30/2021, because the number of pull hold days configured for this account is 3. This means the funds will be held for 3 business days:
Wednesday 11/24
Friday 11/26
*Monday 11/29
Here's a more detailed breakdown of the schedule that's illustrated in the sample code above:
Calendar Date | Hold Day | Amount Available |
---|---|---|
11/24/2021 | 1 | $0 |
11/25/2021 | N/A - Federal Holiday | $0 |
11/26/2021 | 2 | $0 |
11/27/2021 | N/A - Weekend/Non-Business Day | $0 |
11/28/2021 | N/A - Weekend/Non-Business Day | $0 |
11/29/2021 | 3 | $0 |
11/30/2021 | Funds become available | $1.00 |
Holidays and weekends are not considered business days.
Client batches

Once a batch is accepted, it will be broken into individual payment records that may go on hold or be sent to the Federal Reserve independently. Webhook events will be fired as usual on each of these individual payments. The overall payment workflow is identical to that of payments originated individually.
It is important to note that client batch origination requests are asynchronous and the associated payment records may not be available immediately. You can monitor the progress via the status
and importCount
fields of the batch object.
Business reference information

The ACH API supports the following SEC codes:
Code |
Description |
---|---|
CCD |
Cash Concentration or Disbursement. Payments between corporate entities |
IAT |
International payments (payments with an international leg) |
POS |
Point of Sale payments |
PPD |
Prearranged Payments to consumers |
TEL |
Payments initiated by telephone |
WEB |
Payments initiated via the internet |
Which code should I use?
Your Operations Support Team will guide with this based on the use case you are trying to support.

Direction |
Description |
---|---|
Inbound |
Payment we received from another bank |
Outbound |
Payment we are sending to another bank |

Type |
Description |
---|---|
Standard |
Payment will be effective the following day. International payments must use this type. See International ACH support. |
SameDay |
Payment will be effective the same day it was originated provided it was originated before the daily cutoff time. Not available for international payments or those that are over $1,000,000. |

Type |
Description |
---|---|
Push |
A credit payment being sent from an originator to a receiver |
Pull |
A debit payment being taken from a receiver and given to the originator. |

Type |
Description |
---|---|
Origination |
A new payment originating from either Cross River or another bank. Most payments are of this type. |
Return |
Related to a previous origination that has been returned by the receiving bank. |
DishonoredReturn |
Related to a previous return, that has been dishonored by the receiving bank. |
Correction |
Related to a previous origination. The receiving bank accepted the original payment but is now notifying you of information you should correct next time you send a payment to this receiver (e.g. use a different account number) |

Status |
Description |
---|---|
Created |
We have received the payment, but have not started processing it yet. This status should only appear briefly under normal circumstances. |
Pending |
The payment is waiting to be batched and sent to the Federal Reserve. |
Hold |
Payment is being held at the moment and reviewed by our Operations Team. |
Batched |
The payment has been batched is a final review is being done before we send it out in a file to the Federal Reserve. |
Processing |
For inbound payments, we are attempting to post the payment to the receiving account. For outbound payments, the payment has been sent to the Federal Reserve, but has not posted yet. An outbound standard payment may remain in this status for a day or more. Same day payments will transition to Complete soon after Processing. |
Complete |
The payment has been posted and accepted by the Federal Reserve (in the case of outbound payments). This is a final status. |
Rejected |
Our Operations Team wasn't able to process the payment and has rejected it. In the case of inbound, the payment has been returned to the originating bank. This is a final status. |
Canceled |
An outbound payment has be canceled at the request of the partner. A payment may only be canceled while either pending or on hold. This is a final status. |
Blocked |
The CR compliance team blocked the payment |

Code |
Description |
---|---|
R01 |
Insufficient Funds |
R02 |
Account closed |
R03 |
No account or unable to locate account |
R04 |
Invalid account number |
R05 |
Unauthorized debit to consumer account |
R06 |
Returned per ODFI's request |
R07 |
Authorization revoked by customer |
R08 |
Payment stopped or stop payment on item |
R09 |
Uncollected funds |
R10 |
Customer advises not authorized |
R11 |
Customer Advises Entry Not in Accordance with the Terms of the Authorization |
R12 |
Branch sold to another DFI |
R13 |
Invalid ACH routing number |
R14 |
Representment payee deceased or unable to continue in that capacity |
R15 |
Beneficiary of account holder deceased |
R16 |
Account frozen |
R17 |
File record edit criteria |
R18 |
Improper effective entry date |
R19 |
Amount field error |
R20 |
Non-transaction account |
R21 |
Invalid company identification |
R22 |
Invalid individual ID number |
R23 |
Credit entry refused by receiver |
R24 |
Duplicate entry |
R25 |
Addenda error |
R26 |
Mandatory field error |
R27 |
Trace number error |
R28 |
Routing number or check digit error |
R29 |
Corporate customer advises not authorized |
R30 |
RDFI not participant in check truncation program |
R31 |
Permissible return entry |
R32 |
RDFI nonsettlement |
R33 |
Return of XCK entry |
R34 |
Limited participation DFI |
R35 |
Return of improper debit entry |
R36 |
Return of improper credit entry |
R37 |
Source Document Presented for Payment |
R38 |
Stop payment on source document |
R39 | Improper Source Document |
R40 |
Return of ENR |
R41 |
Invalid Transaction Code |
R42 |
Routing No. / Check Digit Error |
R43 |
Invalid DFI Account No. |
R44 |
Invalid Individual ID No. |
R45 |
Invalid Individual / Company Name |
R46 |
Invalid Representative Payee Indicator |
R47 |
Duplicate Enrollment |
R50 |
State Law Affecting RCK Acceptance |
R51 |
Ineligible / Improper Item Related to RCK |
R52 |
Stop Payment on Item Related to RCK |
R53 |
Item and RCK Presented for Payment |
R73 |
Timely Original Return |
R74 |
Corrected Return |
R75 |
Return Not Duplicate |
R76 |
No Errors Found |
R77 |
Non-Acceptance of R62 |
R80 |
IAT Coding Error |
R81 |
Non-Participant in IAT Program |
R82 |
Invalid Foreign RDFI Identification |
R83 |
Foreign RDFI Unable to Settle |
R84 |
Not Processed by Gateway |
R85 |
Incorrectly Coded Outbound Int’l Payment |

Code |
Description |
---|---|
R61 |
Misrouted return |
R62 |
Return of Erroneous or Reversing Debit |
R63 |
Incorrect dollar amount |
R64 |
Incorrect individual identification |
R65 |
Incorrect transaction code |
R66 |
Incorrect company identification |
R67 |
Duplicate return |
R68 |
Untimely return |
R69 |
Multiple errors |
R70 |
Permissible return entry not accepted |
R71 |
Misrouted Dishonored Return |
R72 |
Untimely Dishonored Return |

Code |
Description |
---|---|
C01 |
Incorrect DFI Account Number |
C02 |
Incorrect Routing Number |
C03 |
Incorrect Routing Number and Incorrect DFI Number |
C04 |
Incorrect Individual Name/Receiving Company Name |
C05 |
Incorrect Transaction Code |
C06 |
Incorrect DFI Account Number and Incorrect Transaction Code |
C07 |
Incorrect Routing Number, Incorrect DFI Account Number, and Incorrect Transaction Code |
C08 |
Incorrect Receiving DFI Identification (IAT only) |
C09 |
Incorrect Identification Number |
C13 |
Addenda Format Error |
C14 |
Incorrect SEC Code for Outbound International Payment |

Type |
Description |
---|---|
01 |
Purchase of goods |
02 |
Cash |
03 |
Return Reversal |
11 |
Purchase Reversal |
12 |
Cash Reversal |
13 |
Return |
21 |
Adjustment |
99 |
Misc. Transaction |

Type |
Description |
---|---|
S |
Single payment |
R |
Recurring payment |

Code |
Description |
---|---|
1000 |
General exception |
1001 |
Payment required |
2000 |
General exception |
2001 |
Invalid payment status |
2002 |
Invalid posting status |
2003 |
Payment cannot be canceled |
2004 |
Account not found |
2005 |
Payment must be outbound |
2006 |
Payment must be inbound |
2007 |
Payment must be an inbound origination |
2008 |
Payment must be status completed or rejected to be corrected |
2009 |
Invalid change code |
2010 |
Payment must be an inbound return |
2011 |
Payment must be an origination |
2012 |
Payment must be status completed or rejected to be returned |
2013 |
Payment must be status completed or rejected to be dishonored |
2014 |
Invalid return code |
2015 |
Invalid dishonored return code |
2016 |
Original payment not found |
2017 |
Cannot link to same payment ID |
2018 |
Payment type must be return or notification of change |
2019 |
Original payment must be completed |
2020 |
Payment must be on hold to request a rescan |
2021 |
No scan lists are configured for account |
2022 |
Scan already pending |
2023 |
Previous payment not found |
2024 |
Previous payment must be a completed outbound origination |
2025 |
Receiver account not found |
2026 |
Active holds found |
2027 |
Posting account cannot be changed due to current payment status |
2028 |
Posting status must be pending or failed to change posting account |
2029 |
Posting status must be failed to attempt a retry |
2030 |
Originator profile address missing or invalid |
2200 |
Batch not authorizing |
2201 |
Batch requires one or more payment |
2202 |
No filters were found on the request |

Common Nacha to API field mappings
Nacha Record |
Nacha Field |
Cross River API Field |
---|---|---|
Batch |
Company Name |
Originator.Name |
Batch |
Company Discretionary Data |
Originator.Data |
Batch |
Company Identification |
Originator.Identification |
Batch |
Standard Entry Class Code |
SecCode |
Batch |
Company Entry Description |
Description |
Batch |
Company Descriptive Date |
N/A |
Batch |
Effective Entry Date |
EffectiveDate |
Batch |
Settlement Date |
SettlementDate |
Batch |
Originator Status Code |
N/A |
Batch
|
Originating DFI Identification
|
Originator.RoutingNumber
|
Entry
|
Transaction Code
|
TransactionType / Receiver.AccountType
|
Entry
|
Receiving DFI Identification
|
Receiver.RoutingNumber |
Entry |
DFI Account Number |
Receiver.AccountNumber |
Entry |
Amount |
Amount |
Entry |
Individual Identification Number |
Receiver.Identification |
Entry |
Individual Name |
Receiver.Name |
Entry |
Discretionary Data |
Receiver.Data /ExtendedDetails.PaymentType (WEB/TEL only) |
Entry |
Trace Number |
TraceNumber |
Addenda (05) |
Payment Related Information |
Addenda (only one informational addenda record is supported) |