This note provides an overview of the electronic bank statement formats supported in Germany. But it also refers to all countries (Switzerland, Austria, Netherlands, etc...) offering Multicash banking software or supporting the Multicash format.
The following formats are described:
- Multicash
- SWIFT MT940
- DTAUS
- BAZ
- MAOBE
- SAP.TXT and SAPKURZ.TXT
Consultation
Multicash format
================
- recommended, available since Release 2.1
This format is generated from SWIFT MT940 formats by using BCS software (Banking Communication Standard). SAP recommends this format for posting electronic bank statements.
The format is the same for all banks and is easy to control by using a table calculation or text processing program. The format consists of two files in AUSZUG.TXT and UMSATZ.TXT format. AUSZUG.TXT contains the header information from bank statements, and UMSATZ.TXT contains the line item information. This format enables you to import several bank statements from various banks at the same time.
Multicash is usually used as BCS software. Many banks offer Multicash software, however, calling it a different name (Cotel by Commerzbank, Dretec by Dresdner Bank, ELKO by Sparkassen, ...). If you use the BCS program from Deutsche Bank, you must install the "db-direct" program.
SWIFT MT940
===========
- partially recommended, available as of Release 3.0
Banks basically deliver account statements in SWIFT MT940 format (with or without structured field 86).
From prior experience, SAP recommends not importing these files directly into the SAP system because many banks deliver this format in an unstandardized form. Therefore, you should convert these formats to Multicash format by using BCS software (see Multicash format).
DTAUS format
============
- not recommended, available as of Release 3.0
Many banks recommend posting account statement data via DTAUS format. Banks make this recommendation because they are unfamiliar with SAP functionality and because of their internal, bank accounting procedures.
Accounting is usually structured at banks so that only one record (the total of the line items) is stored when the DTAUS file is transferred. If all data integrated with the account statement is transferred, which all banks can do, an accounting record is saved for each line item in the account statement in the bank's accounting department. Banks want to avoid this because otherwise their accounting systems would become overloaded and extraodinary costs would arise. This argument, however, is no longer valid since these postings are automatically generated by DP programs and storage space per 1MB hard disk is no longer a relevant cost factor.
This procedure considerably deteriorates the overall optimum of the SAP user in order to obtain a less than optimum condition at the bank.
The SAP System is different from other products and especially from in-house-developed systems in such a way that the SAP System can post ALL business transactions that are in an account statement.
DTAUS format contains only one business transaction (i.e. cash inflow) per file, and therefore constitutes only a partial number of the line items posted to a bank account. When using the DTAUS format, you usually have to import several files as well as post some business transactions manually since they can not be transferred with this format. This procedure requires you to continue to carry out personnel-intensive comparisons of transactions. As an SAP user, you cannot take full advantage of SAP's functionality.
DTAUS format has other weaknesses too. A reference to a specific bank statement (statement date, statement number) to which the record belongs does not exist in the header records. Without this reference, the program cannot check whether the statement is complete or whether it is already imported and thus avoid duplicate import transactions. These checks must then be established with organizational rules.
Since DTAUS format was used with mainframes and individual data records are not separated by the special character for a "new line" (Carriage Return Line Feed
Unfortunately this occurs often because during the conversion from ASCII to EBCDIC code and back, umlauts (ie, ä, ö, ü) frequently become special characters which are not transferred.
If a byte is missing in DTAUS, you cannot process the entire file because each record that follows is moved one byte. The worst scenario in Multicash is that a single data record is damaged, which you can easily repair.
Banks are able to transfer via electronic bank statement all information transferable via DTAUS format. Only the electronic bank statement offers complete and integrated processing.
DTAUS format is only recommended for posting bank statement information if there are no other alternatives. 99% of SAP customers, however, have other alternatives.
BAZ format
============
- not supported by SAP
BAZ format is a special format used only be the German postal bank.
The same problems exist with this format as with the DTAUS format.
MAOBE
=====
- not recommended, no longer offered as of Release 3.0
MAOBE format is used predominantly to transfer data on cashed checks.
Since banks will not support MAOBE format in future and data on cashed checks can be posted with the electronic bank statement as of Release 2.1, the RFSHRU00 program for posting data on cashed checks is no longer offered as of Release 3.0.
By using the electronic bank statement, you can post all cash transactions to a bank account. The bank statement offers more options than program RFSHRU00, which only posts data on cashed checks.
SAP.TXT or SAPKURZ.TXT
========================
- not supported
SAP.TXT and SAPKURZ.TXT only exist due to certain conditions pertaining
in the past. They were originally created in response to restrictions
in the R/2 System. Since then they have been used less and are now
not even recommended in the R/2 System.
For this reason the formats for SAP.TXT and SAP.KURZTXT will not be
delivered with the next version of MultiCash software (Release after 1.24).
The R/3 System does not support these formats because they do not
contain all necessary and available fields on a bank
statement. With a fixed record format, users are advised to work with the standard MultiCash files, AUSZUG.TXT and UMSATZ.TXT, which can be further processed.
These files have the following advantages:
a) AUSZUG.TXT and UMSATZ.TXT have become an industry standard
(same format for all banks).
b) If formats are enhanced (new fields), the customer
does not have to make any modifications.
c) They hold more information than SAP.TXT and SAPKURZ.TXT
(e.g. business transaction code, customer's bank details).
Keyword: Elec. bank statement
No comments:
Post a Comment