Ach Iat Payment Method

8/10/2019 Ach Iat Payment Method

http://slidepdf.com/reader/full/ach-iat-payment-method 1/23

Generated by Jive on 2014-12-30+01:00

1

Implementation of ACH IAT payment methodin SAP ECC 6.0

Any company in international business today must deal in international transactions. Until afew 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 anda single vendor / payroll master database to maintain



Implementation of ACH IAT payment method in SAP ECC 6.0


2

Key ConceptRules 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.

http://en.wikipedia.org/wiki/Federal_Reserve

http://en.wikipedia.org/wiki/NACHA-The_Electronic_Payments_Association





3

Figure 1: ACH IAT payment process

Implementation Steps of ACH IAT paymentSAP 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.





4

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.







6

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.





7

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 numberand date)

• HR-PY - Note to payee for payment of wages (such as item text only)





8

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

http://scn.sap.com/servlet/JiveServlet/showImage/102-44609-1-253945/Capture6.JPG





9

Instructions

Instructions help the originating company to exactly state the purpose of the international transaction. Forautomatic 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 usingtransaction 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






10

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.





11

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





12

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 TransactionDuring 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 linkedwith 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.





13

Figure 12: Instruction Key field made optional

Now appropriate instructions given during the document entry process.

Figure 13: Appropriate payment instructions provided

Download Settings






14

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.





15

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:





16

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 usingthe 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)





17

• 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 ismaintained 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 aparticular 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 populatedreal 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) buthere 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.





18

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 entryoriginated is located.

All the entries are populated from the BNKA table.





19

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.





20

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 AddendaRecord 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. Thecount 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.





21

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 recordsin 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.

Changes effective on Required Change

16-Mar-2012 Verification of originator and receiver against OFAC

sanctions cannot be used to delay processing of IAT

payment





22

Certain functional processes like pre-notifications,

NOC, reversals etc. apply to outbound IAT entries

as supported by law and payment rules in receiving

country

Form and content of authorizations are governed bylaws and payment rules of receiving country

A foreign funding financial institution must be

identified in the 4th

IAT Addenda Record in

Originating DFI Branch Country Code, Identification,

Identification Number Qualifier and DFI Name fields

When ODFI has contractual agreement with a

Third Party Sender rather than originator, the tax

identification of third party or originator can be used in

the Originating DFI Identification Field

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.


When IAT carries secondary SEC Code of

ARC, BOC, MTE, POP, POS, RCK or SHR it

may contain additional data to be passed to

consumer’s bank statement like serial number,

Terminal City, State and Location

21-Sep-2012

Transaction Type code will be expanded to include

additional 3 digit field to identify business purpose ofthe transaction.

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.


R16 (Account Frozen) can be used by an RDFI upon

receiving OFAC instructions to receive an item

New Return Code (R85) and one new change code

(C14) were added to assist gateway operators when

handling domestic entries.

15-Mar-13

NOC descriptions have been updated for C04 and

C09 as they are related to IAT

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

Documents

Ach Iat Payment Method