Preprocessing of bank statements during upload

Hello SAPers!

Best practice approach to processing of electronic bank statements implies that we load them “as is” without any modification (either manual or automatic). However, sometimes banks provide electronic bank statements that are not fully compliant with MT940-format and you are not able to load them without preliminary modifications. I’ll present some typical cases and elaborate how they can be resolved with minimal efforts and a bit of ABAP of course:-).

Long (alternative) bank account numbers

SAP recommends maintaining alternative bank account number, if bank account number in bank statement differs from bank account number in customizing (i.e. FI12). However, the length of this field is restricted to 24 characters. Therefore, if alternative bank account number is longer, you’re not able to maintain it.

I faced similar issue recently with regards to introduction of IBAN-accounts in Ukraine. Client managed multicurrency bank accounts at local bank and this bank provided bank account numbers in MT940 as concatenation of bank account + currency:

• UA203003790000002600354456789UAH
• UA203003790000002600354456789USD
• UA203003790000002600354456789EUR

As a side note, multicurrency account is special type of bank account that allows the company to manage funds in different currencies while bank account number remains the same. See OSS-note 1978526 for recommendations on how to manage such accounts in SAP.

Before introduction of IBAN, bank account was shorter (e.g. 2600354456789UAH) and it was possible to maintain it in SAP. Currently it has length of 37 characters, and it is no longer possible to maintain it.

The following solution can be used to deal with this issue. New customizing table should be created to store mapping between source bank account and alternative bank account number from customizing.

Mapping between account numbers should be configured:

Custom logic should be implemented within user exit EXIT_RFEKA400_001 / include ZXF01U06. Source code can be found below:

FUNCTION EXIT_RFEKA400_001.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"       TABLES
*"              T_RAW_DATA STRUCTURE  RAW_DATA
*"       EXCEPTIONS
*"              ERROR_OCCURED
*"----------------------------------------------------------------------

  INCLUDE ZXF01U06 .

ENDFUNCTION.

*&---------------------------------------------------------------------*
*&  Include           ZXF01U06
*&---------------------------------------------------------------------*

constants: lc_acc_no_pattern type string value '\:25\:([a-zA-Z0-9\/]+)'.

data:
   lv_src_acc_no type char50,
   lv_alt_acc_no type bnkn2.

field-symbols: <raw_line> type raw_data.

loop at t_raw_data assigning <raw_line>.
  clear: lv_src_acc_no, lv_alt_acc_no.

  " Checking if line contains pattern for bank account number
  find regex lc_acc_no_pattern in <raw_line>-line
    ignoring case
    submatches lv_src_acc_no.

  if sy-subrc is initial.
    " Select alternative bank account number from custom table
    select single bnkn2
      into lv_alt_acc_no
      from zsfin_bank_accs
      where zsrc_bnkn = lv_src_acc_no.

    if sy-subrc is initial.
      replace first occurence of lv_src_acc_no in <raw_line>-line with lv_alt_acc_no.
    endif.

  endif.

endloop.

The logic behind enhancement is as follows:

• The program is looking for a statement line that begins with fixed value “:25:” (line, which stores bank account number in MT940 bank statement) and retrieves bank account number.
• Once bank account number was identified, it checks if there is a mapping in custom table with alternative bank account number;
• If mapping is maintained, the program replaces bank account number in bank statement with bank account number from custom table.

Once this logic was executed, we no longer need to do anything. Standard interpretation mechanisms will take care of everything else.

Wrong format of bank account number

Field :25: might contain bank key. Standard upload program will recognize bank key / bank account number if they are provided in format BANK_KEY/BANK_ACCOUNT. however, sometimes banks provide this information in different formats (see examples below):

• BANK_KEY-BANK_ACCOUNT – this format is not supported by SAP;
• SWIFT_CODE/BANK_ACCOUNT – this format is also not supported.

If your bank provides bank account number in wrong format you can also use the approach with custom mapping table presented above. Alternatively, you can implement your own logic that will search for special characters and replace them or remove unnecessary information altogether (e.g. SWIFT code).

One final tip for troubleshooting. I’ve stumbled upon a lot of questions on SAP-related forums inquiring why this user exit is not triggered during bank statement upload at all. If you do new implementation, make sure that enhancement FEB00004 is activated. Go to transaction SMOD, indicate enhancement and press “Test” button:

Check if user exit is activated (has green indicator) and if it is not, activate it.

By the way, this approach to resolution is even recommended by SAP (see OSS note 2641115 “IBAN number plus currency in tag 25 for MT940 format“).

Before you implement any enhancements get in touch with technical department of respective bank and clarify if bank can change anything in presentation of field values in MT940 bank statements. In my experience, banks can usually customize format of this field so that it will contain correct values recognized by SAP.

Examples in this post might seem trivial and you might wonder why we need this post at all. The trouble is that sometimes functional consultants are not fully aware of all enhancement options and simply pass on the requirement to ABAP consultants. On one of my previous projects I’ve stumbled upon similar requirement and was quite surprised that the solution in legacy system involved development of new transaction code and new custom program, which was reading the file, updating it and then passing it on to standard upload program. At the end it turned out that bank could have simply adjusted the format of account without any development at all. The solution was literally one mail away…

I hope you will find this post useful! Your suggestions and comments are welcome!

Best regards,

Bohdan Petrushchak

P.S. Disclaimer.

All sensitive information (bank accounts, company names etc.) used in this example was invented. If there is some coincidence with real-life companies, it is a purely accidental one.