SAP OSS Note 13283 contains details of a know issue related to Description of electronic bank statement formats
. THIS INCLUDES ANY ASSOCIATED SYMPTOMS and instructions on how to fix it, see below for full details. Also check out the comments section to view/add related contributions, questions or screen shots, based on real life experience of this oss note and problem.
...For more information about the SAP support system known as OSS please check out the SAP OSS NOTES SECTION, which includes HOW TO DOWNLOAD & IMPLEMENT them onto your SAP system using transaction code SNOTE.
Keyword: Elec. bank statement
This note provides an overview of the electronic bank statement formats
supported in Germany. But it also refers to all countries (Swi
tzerland, Austria, Netherlands, etc...) offering Multicash banking
software or supporting the Multicash format.
The following formats are described:
SAP.TXT and SAPKURZ.TXT
Cause of the problem and Pre-requisites
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 f
or 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 consis
ts of two files in AUSZUG.TXT and UMSATZ.TXT format. AUSZUG.TXT contains
the header information from bank statements, and UMSATZ.TXT c
ontains 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 Commerz
bank, Dretec by Dresdner Bank, ELKO by Sparkassen, ...). If you use the
BCS program from Deutsche Bank, you must install the "db-direc
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).
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
Accounting is usually structured at banks so that only one record (the
total of the line items) is stored when the DTAUS file is trans
ferred. If all data integrated with the account statement is
transferred, which all banks can do, an accounting record is saved for
ch 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 a
re 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 b
The SAP System is different from other products and especially from
in-house-developed systems in such a way that the SAP System can p
ost 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 th
e line items posted to a bank account. When using the DTAUS format, you
usually have to import several files as well as post some busi
ness transactions manually since they can not be transferred with this
format. This procedure requires you to continue to carry out pe
rsonnel-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 w
hether it is already imported and thus avoid duplicate import
transactions. These checks must then be established with organizational
Since DTAUS format was used with mainframes and individual data records
are not separated by the special character for a "new line" (C
arriage Return Line Feed <(><<)>CR><(><<)>LF> ), troubleshooting is
extremely laborious if the bank transfers faulty files.
Unfortunately this occurs often because during the conversion from ASCII
to EBCDIC code and back, umlauts (ie, ä, ö, ü) frequently bec
ome 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 scenar
io in Multicash is that a single data record is damaged, which you can
Banks are able to transfer via electronic bank statement all information
transferable via DTAUS format. Only the electronic bank state
ment 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, howe
ver, have other alternatives.
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.
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 R
elease 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 t
han program RFSHRU00, which only posts data on cashed checks.
SAP.TXT or SAPKURZ.TXT
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
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 c
an 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).
Description of problem