Any company in international business today must deal in international transactions. Until a few years ago, overseas payments originating out of the US were sent via wire transfers or checks. Automated Clearing House (ACH) is an electronic fund transfer network in the US that enables financial institutions and organizations to deal in electronic payments. Domestically in the US, there is one clearing system, with standardized settlement times and initiation formats. Internationally, however, not all countries have an ACH-like clearing system, and those with clearing systems have different settlement times and formats. Earlier ACH payments used to be difficult as the sender needed to have a foreign banking relationship with the bank at the other end of the transaction, which, in turn, should have been a member of the foreign country’s clearing system.

Over the past few years, the National Automated Clearing House Association (NACHA) has worked with the Office of Foreign Assets Control (OFAC) to amend ACH operating rules, minimize vulnerabilities in the ACH network and prevent entities banned by OFAC from using the network as a conduit to send or receive overseas funds. In 2009, the NACHA International ACH Transaction (IAT) rule change included a new kind of payment system – IAT which made international payments easier, more cost effective and more secure. All participants in the ACH network – from financial institutions, ACH Operators and corporate practitioners had to comply to the new system by September 18, 2009 with the regulatory mandate.

Now international payments from and to banks in US are easily possible without having a foreign bank account. If more than a particular number of international payments are made to countries with ACH clearing systems, business can save money by making / receiving payments via IAT. Though wire transfer still remains the best payment method for immediate, non-urgent payments, IAT payment method was introduced to enhance the security of the international transactions. In addition to potential cost savings and payment security aspects IAT payments can also be used for following purposes:

• Negotiate better payment terms with vendors
• Provide better, more reliable and predictable cash flow projections
• Eliminate the necessity of maintaining multiple country specific payment formats
• Ability to combine payment categories (payroll, accounts payable and royalties) into a single payment file
• Integrate with an ERP system or in-house treasury system, providing a single-point of data entry and a single vendor / payroll master database to maintain

Key Concept

Rules and regulations governing the ACH network are established by NACHA and the Federal Reserve. An International ACH Transaction (IAT) is a debit or credit entry that is part of a payment transaction involving a financial agency not located in the territorial jurisdiction of USA. A financial agency / institution is said to be involved in the IAT transaction if it satisfies at least any of the following conditions:

• Holds an account that is credited / debited as part of a payment transaction
• Receives funds or makes payment directly as part of a payment transaction
• Serves as an intermediary in the settlement of any part of a payment transaction

This new rule applies to all ACH participants and simplifies the process of identifying international transactions by requiring that IAT entries include specific data elements defined by the Bank Secrecy Act’s (BSA) “Travel Rule”. Travel Rule ensures that specific information is provided with each payment, including the identity of all parties relevant to that transaction. This information enables a Receiving Depository Financial Institution (RDFI) to easily identify the transaction’s origin and ensures that it meets the existing requirements for file processing and complies with all applicable policies. OFAC violations regarding implementation of IAT transactions can result in judicial proceedings against the ACH receivers and originators as well as blocking of the payment itself by the originating company. Violations can also result in substantial financial implications.

This paper demonstrates the implementation process of IAT payment method in SAP R/3 ECC 6.0 system. The approach had to deviate from the standard SAP recommended solution in several aspects to get the desired results. This required several trial runs of the IAT file with the corresponding bank.

Figure 1: ACH IAT payment process

Implementation Steps of ACH IAT payment

SAP had introduced several OSS Notes for ACH IAT payment method listed below:

• SAP Note : 1343600
• SAP Note : 1362993

The overall configuration steps emphasize on the introduction of the following information in the final DME (output) file which will be eventually processed by the bank:

• Name and physical address of the originator
• Name and physical address of the receiver (beneficiary)
• Originating bank name, identification number and branch country code
• Correspondent bank name, identification number and branch country code (if applicable)
• Receiving bank name, identification number and branch country code
• Reason for the payment

SAP recommends use of Payment Medium Workbench compared to Classic Payment medium as it provides superior control, verification of the payment procedure and better performance with mass payments. It also makes it easier to adapt to a customer or bank specific formats.

Note to Payee

A new “Note to Payee” is introduced for the payment medium workbench. It suggests checking the following structures for the note:

• Note to payee layout using Customizing
• Note to payee layout using function module

As mentioned in the SAP note 1343600 the function module suggested therein - "FI_PAYMEDIUM_ACH_DETAILS" was evaluated to see whether it would meet the requirements. It may be noted here that this FM is used for processing payroll data. It was observed that this FM was suppressing the generation of a particular piece of information in the final output file – “no. of addenda record”. The payment process was attempted without this FM and was observed that the missing information was now available.

Figure 2: Note to payee configuration

IAT entries will accommodate the transmission of optional remittance information which will be used in the optional remittance addenda record. SAP note 1343600 suggests a maximum of two optional addenda records to accompany an IAT entry. In accordance with the note two line items were created with types '1' and '2' with the desired text as the default note to payee. These two line items would have been populated in the final output file as 717 record types with the desired text. As our bank wanted only a single instance of a 717 record type, only one record was retained eventually.

Figure 3: Addenda records for optional remittance information

Event Module

The DME file format – final ACH IAT output file is determined with the help of event modules. They are implemented using various function modules stacked up together to form a payment pattern. The events to call these modules are defined in the payment program (event 00) and in the payment medium program (all other events). Interfaces are determined using the various function modules. Only those parameters that are required for the DME file creation are maintained as shown below.

Figure 4: Maintenance of Event Modules

This functionality is nothing new, and has been present in SAP since DMEE was first introduced. However, it was essential to mention this feature as such, before we attempt to explain what IAT has changed, where, how and why – which is what the rest of this paper is all about.

Format parameter

The IAT method makes it mandatory for the payment transaction to state the information about the foreign correspondent bank in the output file. This bank is to be used as an intermediary between the originator and receiver’s bank through which the payment has been routed. This information will be populated in a 718 record type in the final DME file. It may be noted here that this line information (a 718 record type) is not mandatory for all banks and it would depend on whether your banking partner requires it or not. In our case, the bank made this information mandatory in the file.

Configuration of this information is not mentioned in any SAP note and this required substantial trial and error from a configuration perspective. Eventually, we figured out that all information pertaining to the foreign correspondent bank would not be populated from the payment run, but rather would have to be maintained in a variant for the payment program. This information would then be auto-populated in all the files generated out of that payment run. For our file, the mandatory fields to be maintained were:

• Company Identification
• Foreign Correspondent Bank Branch Country Code
• Foreign Correspondent Bank Name
• Foreign Correspondent Bank ID
• Foreign Correspondent Bank ID Qualifier (This field identifies the numbering scheme used in the Foreign Correspondent Bank Identification Number field.  Values for this field are :

a.    01 - National Clearing Number System

b.    02 - Business Identifier Code (BIC)

c.    03 - IBAN

Maintaining all the above as required fields in this format specific parameter would make them mandatory whenever a variant is maintained for the print program. They are maintained using transaction OBPM1. So the final DME file generated will be having these information in the line item 718 record type.

Figure 5: Format Parameter Required Fields

The information to be provided in the particular variant is shown in the section 'Variant Selection' below.

Payment method Configuration (FBZP)

In this step, the regular payment medium workbench configuration settings have been maintained for the new payment method in Country and Company Code (FBZP) referred to as ‘J’. The ‘Note to Payee’ for a payment medium is dependent on a number of factors. It is used to cover the various contents and structure requirements. The note to payee is assigned to a payment method for a certain application area. The data origin which has triggered this payment is generally highlighted in the note to payee configuration. In this case, the origin - together with the payment method - determines the structure of the note to payee. The following Note to Payee are maintained in the configuration in accordance to the specific requirement for this DME file:

• FI-AP - Note to payee for payments of vendor invoices and credit memos (such as invoice number and date)
• HR-PY - Note to payee for payment of wages (such as item text only)

Figure 6: Note to Payee by Origin

Appropriate payment advice DME structure scripts are also maintained in the payment method configuration.

Figure 7: Payment Advice script and DME scripts maintained

Instructions

Instructions help the originating company to exactly state the purpose of the international transaction. For automatic payment transactions this field along with house bank country and particular payment method control the information given to banks for carrying out the payment process. Instruction keys are maintained either in customer/vendor master record or in the system configuration for house bank. The following rule holds true: If instruction key is maintained in the vendor/customer record (sub-ledger account) then this record is preferred (gets populated in the output file) over house bank record. If no instruction key exists in the master record then default one maintained in the house bank is used. If the instruction keys are maintained in the master record during the F110 process the system will prompt for these instructions during vendor selection and proceed with the payment.

Instruction keys for house banks are maintained per country and payment method using transaction OB47. The instruction key have been maintained for country US and payment method ‘J’ – ACH IAT. Instruction key is maintained as 01 for this payment method. This has to be maintained in the first place in order to maintain the range of payment instructions for the DME file. 

Figure 8: Instruction key format for the payment method

Instruction keys 1,2,3,4 are used to cater to the requirements of specific countries like Germany, Austria, Japan and Netherlands where additional information are required mostly for foreign payments. They can also be used to generate additional information for other transactions as well. They are only used for additional information and may not be maintained if not required. These four fields can be overridden by giving instruction keys while posting a document (“Additional Data” screen in the customer/vendor line)

Actual reasons for the payments – the range of instructions are needed to be maintained per country. They are not pre-configured but have to be maintained for each country defined previously. For bank country US the following instructions are maintained:

Figure 9:  Instructions for payments

These instruction keys are used during document creation. Only one instruction key is allowed per invoice. Its’ corresponding information will be transferred to addenda record 7 in the final DME file. It is to be noted that we may need to adjust field status for the additional screen in case the keys are not already available.

Variant Selection

The payment program is run using a variant which needs to be maintained for the ACH payment. This variant is maintained for the particular Company Code and the House Bank from which payment needs to be made. In this example payment is made using sample Company Code – US01 and sample House Bank - BNYDL. Thus in OBPM4 screen variant TEST is maintained accordingly.

Figure 10: Creation of variant for the payment run

While maintaining the payment medium format the system asks for the Corresponding Bank Information to be maintained simultaneously (which have been earlier maintained as mandatory).

Figure 11: Maintenance of Foreign Correspondent Bank Information

The important parameter is “Company Identification” which is generally the tax number or some other free number used by the company. One particular identification number is agreed between the company and the bank. The pre-agreed information is populated real time in the output DME file during program execution.

Along with the maintenance of the payment medium format some other important parameters are maintained simultaneously as shown below:

• Data Medium Exchange
• Payment Summary
• Error Log
• Appropriate file path for the output file storage
• Form for the payment medium

Payment Transaction

During document (invoice) entry, an appropriate reason of the invoice should be given. In most real-world setups that we analyzed, this instruction function was found suppressed during invoice entry. Instructions can be defined at any of the following places:

• The (invoice) document
• The customer/vendor master record using an instruction key
• The house bank DME data using the default instruction key

The instructions specified in the document over-ride any other instruction keys available from any master data, provided that one of the four fields (see figure no. 12 below) has been filled out. The instruction key is linked with the corresponding GL account involved with this transaction. In the case of a vendor invoice document, this GL would be the corresponding reconciliation account. When the field status of the instruction key is modified for the reconciliation account category (see figure no. 11 below), then the instruction key will appear on the payment screen.

Figure 12: Instruction Key field made optional

Now appropriate instructions given during the document entry process.

Figure 13: Appropriate payment instructions provided

Download Settings

After a successful payment run when the output file was downloaded it was observed that the output file is coming in the following format:

Figure 14: Initial IAT output file

Here the system is adding an unwanted space between each character of the file. Eventually, I figured out that appropriate character encoding system needed to be set up for the downloadable DME file. In this case, UTF-8 (UCS Transformation Format – 8 bit), which  is a variable-width encoding representing every character in the Unicode character set needed to be defined. In SAP, the UTF-8 character encoding has code page number 4110. Once this was maintained in OBPM3 as shown below, the extra spaces disappeared.

Figure 15: Appropriate Code Page maintenance for the format

Output File

Finally after the document payment process the final output file gets created in the appropriate location in the directory. A sample final DME file is shown below:

Figure 15: Appropriate Code Page maintenance for the format

The final output DME file gets its data from various master and transactional tables. Like any other regular payment process in SAP, after a successful payment process all the related information gets populated in the REGU*tables. The file refers master data tables like T001, ADRC, LFA1 and KNA1. Information related to the payer and receiver’s banks are populated using the BNKA table. The information related to Foreign Correspondent Bank is populated real time during file generation. Some information is hardcoded by the standard SAP program. Detailed analysis of each line item of the file is shown below. Although a general ACH IAT file format exists, the required information varies depending on the actual Bank involved. For certain banks, certain fields and in some cases complete line items are omitted as those data fields are not necessary for that bank. I will cover some of the important data fields in the line items along with how they get populated. This will help in trouble-shooting for the reader

Header: File header record introduces the file. It designates the physical file characteristics and identifies the sender and the receiver of the file. This record starts with record type 1.

• Position 4-13 is the bank routing number or the house bank number populated from table REGUH (field UBNKL)
• Position14-23 gives the company identification which is used for creating the ACH file. The particular identification to be used is mutually decided between the bank and the company. This information is maintained in the program variant which gets populated real time to the output file
• This record also introduces the date, time and the file identification fields to specifically identify a particular file. They are populated from REGUT table (fields TSDAT and TSTIM)
• It also populates the immediate originating bank name from BNKA (field BANKA) and the originating company name from T001(field BUKRS)

Company / Batch Header Record: Identifies the originator and briefly describes the purpose of the entry. This record starts with record type 5.

• Position 41-50 populates the originator bank id
• Position 54-63 gives the description of the purpose of the entry. In this case it is "VENDOR PMT" (Vendor Payment). These values are maintained in the program variant and gets populated real time during program execution.
• Position 64-69 gives the ISO 4217 code for the originating and destination currency.
• Position 80-87 incorporates the routing number or the bank number from REGUH (field UBNKL) but here only first eight characters get populated

IAT Entry Detail record – Original Entry: This record contains information about the receiver and receiver’s financial institution. It starts with record type 6.

• Position 04-12 contains the routing number that identifies the US RDFI in which the receiver maintains the account. It populates from REGUH table(field ZBNKL)
• Position 13-16 gives the number of addenda records with the entry details record i.e. the number of line items starting with 7 and 8 present in the file. This value was getting suppressed when the function module "FI_PAYMEDIUM_ACH_DETAILS" was activated as mentioned previously
• Position 30-39 gives the document amount from REGUH table(field RBETR)
• Position 40-74 gives the foreign receiver’s account number from REGUH table (field ZBNKN)
• Position 80-94 is the trace number assigned by ODFI to uniquely identify each entry within a batch.

Receiver Information 1: IAT Addenda Record 710 identifies the receiver of the transaction and the dollar amount of payment.

Position 04-06 identifies the type of transaction which gets populated from the instruction field while submitting an invoice. The instruction codes get stored from the REGUH table in field DTWS1. It takes this value and goes to table T015W1 and matches this value with value in field DTWSX for the specified application area. Then the system populates the corresponding information in field CODE. For inbound payments along with the options available a secondary SEC code may also be used.

Position 47-81 populates the name of the receiver / vendor from the REGUH table(field KOINH) 

Originator Information: Addenda Records 711 and 712 contain information related to the originator of the entry. They contain the originator name and it's detailed address. To populate these two rows system links two tables - T001 and ADRC. For the originator company code the system goes to the master table T001 and picks up the value from the field ADRNR. The system maps this value in table ADRC with field (ADDRNUMBER) and populates the relevant fields in the output file.

Originating Financial Institution: Fourth IAT Addenda Record line item is populated with record 713. This contains information of the financial institution originating the entry.

• Position 04-38 contains the name of the foreign originating DFI for an inbound IAT entry.
• Position 41-74 contains the original DFI Identification number
• Position 75-77 contains the identity of the country in which the bank branch where the entry originated is located.

All the entries are populated from the BNKA table.

Receiving Depository Financial Institution: Fifth IAT Addenda Record line item is populated in record numbers 713 and 714. These contain information of the financial institution holding the receiver's account. All the records are populated in a similar manner as the originating financial institution fetching the information from the BNKA table.

Receiver Information 2: Record No. 715 and 716 contain information related to the receiver of the payment. They contain the receiver name and detailed address. All the information here gets populated from the vendor details table - LFA1.

Remittance Information: IAT entries will accommodate the transmission of optional remittance information. Record No. 717 contains free form text as desired which highlights the transaction details. Maximum of two optional addenda records will be able to accompany an IAT entry.

Foreign Correspondent Bank Information: Record No. 718 gives information about the Foreign Correspondent Bank through which the payment gets routed from the originator to the receiver. It contains the following information:

• Foreign Correspondent Bank Name
• Foreign Correspondent Bank Identifier Number Qualifier
• Foreign Correspondent Bank Identification Number
• Foreign Correspondent Bank Branch Country Code

All these information are directly maintained in the program variant. When the payment program is executed with that particular variant, the Foreign Correspondent Bank information is populated in the output DME file real time. Position 84-87 represents the addenda sequence number. This number is consecutively assigned to each Addenda Record following an Entry Detail Record. The first addenda sequence must always be "1". Each Foreign Correspondent Bank Involved in the processing of an IAT entry must be identified with an Addenda Record for IAT Foreign Correspondent Bank Information.

Batch Control Record: The Company / Batch Control Record (Record Type 8) summarizes the information in the file. This record shows the number of transactions and the total value of all transactions in a particular IAT batch file.

• Position 05-10 indicates the tally of all entry records and addenda records processed in this file. The count here is "30" because the file has 27 addenda records (beginning with "7") and 3 entry records (beginning with "6"). If multiple payments are made in the same file then this value will increase accordingly.
• Position 11-20 indicates the Routing Number of the vendor bank which accepts only 8 characters.
• Positions 21-32 and 33-44 give the total debit and credit amounts respectively in the file.
• Position 45-54 convey the same information contained in the original identification field of the Company/Batch header record.
• Position 80-87 incorporates the routing number or the bank number from REGUH (field UBNKL) but here only the first eight characters get populated.

File Control Record: The File Control Record summarizes the information carried in the Company / Batch Control Records. It contains the amount, entries and total accumulations of the Company / Batch control records in the file. It also contains count of the number of blocks and the number of batches within the file.

• Position 02-07 gives the value of the batch count field equal to the Company / Batch header records in the file.
• Position 08-13 gives the number of transaction blocks within the file.
• Position 14-21 gives the tally of each Entry Detail and Addenda Record processed within the batch.
• Position 22-31 indicates the Routing Number of the vendor bank and accepts only 8 characters.
• Positions 32-43 and 44-55 give the total debit and credit amounts in the file respectively.

Conclusion

ACH IAT payment medium has seen several new incorporations in it's payment rules. NACHA had decided to introduce modifications to the IAT file in a phased manner identifying three dates to complete these implementations of the changes.

Effective March 16, 2012: Changes incorporated to clarify and enhance the rules to support more efficient processing of IAT entries.

                         Table 1: Changes to be incorporated in ACH IAT – Mar 16, 2012

Effective September 21, 2012: Changes to clarify minimum descriptive standards and addition of transaction type code to identifying IAT entries carrying remittances.

                         Table 2: Changes to be incorporated in ACH IAT – Sep 21, 2012

Effective March 15, 2013: Changes to clarify the return code and notifications of change code which applies to IAT in certain situations. They primarily impact gateway operators.

                          Table 3: Changes to be incorporated in ACH IAT – Mar 15, 2013