Technical Articles
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.
Hey, nice article. I had one question though, in the MT940 file I'm not able to figure out how to find the details of the party who has made the transaction. 86 tag talks about it in some files but then it's a non-mandatory tag and could be left empty. Is there any way to know that?
Hi ankit barthwal,
Everything depends on the layout of actual MT940 bank statement that your bank offers. Some banks provide well structured MT940 statements, which have customer information. Other banks offer unstructured MT940 statements, which contain just basic transaction info. Check the example from your bank and you'll immediately see what it offers.
Regards,
Bohdan
Hi Bohdan,
I have error error “fv 151” when processing file MT40 format. I saw that OSS-note 1978526 is not applicable for S4/Hana release 1909. However in the customer’s system there isn’t implemented a custom logic to find out the alternative bank account. Do you suggest to implement both of your suggestion? Implement logic for alternative bank account and the EXIT_RFEKA400_001 / include ZXF01U06?
Kind regards
Davide
Hi Davide Parente,
I’m not sure how I can be of any help here. First of all, the topic of this blog doesn’t cover format issues for MT940 (e.g. error FV151). Second, OSS-note 1978526 is mentioned as a reference here, because it has a clear recommendations how to handle multi-currency bank accounts. It might not be applicable for S4 Hana, but the logic still can be used. Third, I’m also not sure what you mean by two solutions, because this blog post specifically describes one custom solution.
Regards,
Bohdan
This is very useful. Thanks a lot.