ACH is how most US companies move money between bank accounts, and NACHA defines the file format that every ACH payment has to follow.
SAP delivers standard NACHA formats, but banks and clients almost always ask for something the standard does not produce, which is where customization comes in.
In this post, I will walk you through the SAP implementation of the standard NACHA (ACH) format, highlight possible future problems, and show how to customize ACH whether it is a function-module-based or DME-engine-based format.
In OBPM1 we can see all formats, both SAP standard ones and custom ones. Formats can be function-module-based or DME-engine-based. If there is no checkbox marked “Mapping using DME engine,” then it is an FM-based format; in other words, a hardcoded format. ACH is an example of such a format. If it is marked, then the format is created via the DME engine (transactions DMEE/DMEEX), which we can call configuration-based.
FM-based formats usually have a sequence of FMs that corresponds to the file structure. For example, the ACH format looks like this:
These FMs essentially hardcode the file structure: the file header (record starts with 1; highlighted yellow in the following figure), the batch header record (starts with 5, green), the detail record (starts with 6, blue), the batch control record (starts with 8, red), and the last record, the file trailer (starts with 9, purple).
Here is an ACH CCD file example:
705 is the addenda record, which we will discuss later, since it does not go through these FMs but through OBPM2 configuration.
Some sections are built by more than one FM. The FMs map to the file sections as follows:
FI_PAYMEDIUM_ACH_00, FI_PAYMEDIUM_ACH_05, and FI_PAYMEDIUM_ACH_20 – for the header
FI_PAYMEDIUM_ACH_30 – for the batch header and detail record
FI_PAYMEDIUM_ACH_40 – for the batch control record and trailer
Thus, when you want to override logic in a given part of the file, you need to use transaction OBPM3 with a custom FM: copy the corresponding standard FM, override the logic as needed, and assign the new FM to the matching customer event, as explained below.
In the SAP standard code of the Payment Medium Workbench (PMW) program SAPFPAYM, SAP calls a customer event after each standard FM and checks whether a custom FM is configured for that event in OBPM3; if so, it runs that FM. Each standard event has a customer event that follows it: after event 05 SAP calls 06, after 20 it calls 21, after 30 it calls 31, and after 40 it calls 41. Those four are the events you assign your custom FM to.
And so on:
So to customize one part of the ACH file, copy the standard FM that builds that part, delete the copied logic, write your own, and assign it to the customer event that follows it.
For example, if I wanted to customize the file name in a special format and override the Immediate Destination Name in the header, it would look like this:
For this, I need to use event 21, copy FM FI_PAYMEDIUM_ACH_20, and assign the new custom FM in OBPM3:
The content of the custom FM can look like this:
The settings in OBPM1 for standard formats are not supposed to be changed, so you should not override SAP standard FMs in OBPM1 itself; this way, all updates that come from SAP for this format will be applied automatically.
When it comes to the addenda section (records starting with 705), it is worth mentioning that ACH files come in three main types, plus subtypes of some of them, which I will cover later.
ACH can be CCD, PPD, or CTX. How do they differ? Let’s start with CCD.
For each detail record in the file (starting with 6), only one addenda line (starting with 705) is allowed. This format is used for payments to external vendors or for money transfers.
PPD is used for personal payments, usually employee (EE) salaries or reimbursements. It is the same as CCD from an addenda standpoint: only one addenda record is allowed per detail record. A detail record is created for each payment document.
CTX is like CCD, used for payments to external vendors, but up to 9,999 addenda lines are allowed per detail record. If you go to the OBPM1 configuration, section "Text fields for reference information," you will find this screen:
Then there is also CCD+, which allows two addenda records per detail record. And there is CTX for child support, which has a different addenda structure from standard CTX.
In SAP, the addenda record is essentially called the note to payee, and in OBPM2 we can find all existing addenda variants:
If we look at the SAP standard ones for CCD and CTX, we will see the same concept: you can use configuration for the addenda, custom code (a custom FM), or both.
If we look at what is configured as the addenda line, we will see this screen:
Here, internal payment structures are used to map values from the REGUP and REGUH tables, along with some constants.
I will come back to the structures FPAYP, FPAYH, and FPAYHX later. Now, if we look at the CTX one, you will see this:
It is a hardcoded one, based on the EDI 820 Payment Order/Remittance Advice Implementation Guide. These notes to payee have to be assigned in FBZP under Payment Method in Country:
In the Note to Payee by Origin section you will see this:
When you want to customize the note to payee, copy the standard one for the format you are targeting (CCD, CTX, or PPD) and then assign the custom one to the payment method (PM) in FBZP.
For example, I want to customize the addenda for the CCD format. The short text field (BSEG-SGTXT) on the invoice will be populated with the exact value that has to be placed in the addenda record. But the string can be longer than 50 characters, and if it is, I will instead get long text ID 0002 with the exact string to output in the addenda record. The fields will not be populated together; it will be one or the other depending on length.
For this requirement, I will create the following note to payee:
Configured as shown:
When you assign the item text this way, standard SAP behavior applies: if the string in the short text field (BSEG-SGTXT) starts with *, it automatically goes to the addenda record (the 705 line). For the situation where the string is in long text ID 0002, we have a custom FM assigned.
Another example is modifying the addenda of the standard ACH CTX based on where the needed information lives in your system. For example, you have invoices posted from a third-party system. The invoice number would be stored in BKPF-BKTXT or long text ID 0003. You need the invoice number populated in the addenda section after the “IV” string:
Here you need to copy the SAP ACH CTX note to payee itself, plus the FM from that note to payee, and modify the code for your requirements:
As I mentioned above, the structures FPAYP, FPAYH, and FPAYHX are used as the source of payment data for the code, since they are filled by SAP mostly from the REGUP and REGUH tables (the payment run results tables). The same structures are also used for DMEE tree mapping. SAP has a note with an Excel attachment showing how all fields of those structures map to the REGUH and REGUP tables; I have attached it here as well. See these SAP Notes:
This is the same ACH format, but as a DME-engine-based format.
Here, to modify the format (change the mapping), you will need to copy the format under a /Z* name and change the mapping per your requirement. The format has to be copied as a dependent format of the SAP standard US_ACH_DD so it inherits all SAP changes to the format.
For example, I need to output RENUM in the batch header, field BH4, to help the EBS (electronic bank statement) team apply an algorithm using RENUM to clear payments:
The mapping here should be FPAYHX-RENUM.
Or, for example, if I am going to use this format as CCD and need the short text field (SGTXT) in the addenda, I can map the FPAYP-SGTXT field:
For the source of the fields, see these SAP Notes:
When you need to modify the file name for a DME-engine-based format, you can assign a custom FM for event 21 to the format in OBPM3, and the logic will be applied as well.
I also advise checking these SAP Notes:
Getting the format right is only part of the work. The following issues come up often enough on ACH implementations that they are worth checking during your build rather than discovering when the bank rejects a file.
When invoices come into SAP S/4HANA via an interface, special characters may appear in XBLNR (the reference field) or the short text (SGTXT) field.
If special characters can get through, these two SAP Notes must be implemented:
File failures can be caused by UTF encoding. If the file is set to be saved to an AL11 folder and picked up from there for transmission to the bank, SAP S/4HANA saves the file in UTF-16 instead of the required UTF-8. To prevent this, we can choose the encoding in OBPM3:
By standard, SAP does not generate more than 26 file modifiers per day for the same house bank and house bank account combination, since the English alphabet has only 26 letters. Once the letters run out for the day, the file modifier will be empty in the file.
Here, the file modifier is the letter C in the header line, just before 094:
If the ACH format might run more than 26 times a day for the same house bank and house bank account combination, you need to be aware of this and be ready to fix it.
When can this happen? For example, your client moves money via ACH from one US treasury account to another, and the amounts are very large. This forces them to generate more than 26 transfers, since the maximum ACH payment is $99,999,999.99 per the NACHA specification, which is why OBPM1 allows only 10 digits here:
This number cannot be changed; otherwise you will have a format violation, and the file will be rejected by FedLine.
If the Federal Reserve Bank has special requirements for your ACH files, including a date and timestamp down to the second in the file name, be aware that if SAP Bank Communication Management (SAP BCM) is used along with the mass approval feature in the approval app, you might end up with two or more files generated with the same name.
Here, you might need to add milliseconds or use an SAP-generated number as the end of the file name if the file will be stored in an AL11 folder.
As we saw, formats can be FM-based or DME-engine based. FM-based formats require developers to make changes per client requirements, while DME-engine-based formats can mostly be handled by consultants alone, unless a mapping cannot be resolved via the internal structures and a custom FM must be mapped to a node. We also highlighted the situations to be aware of when implementing SAP standard formats.
This post was originally published 8/2026.