Formats for the Electronic Account Statement 

The following section contains an overview of the formats that are supported for the electronic account statement in Germany. This information also applies to all countries where the bank software package MultiCash is available or the MultiCash format is supported.

The following formats are supported:

This format is created from the account statement data received from the banks (usually SWIFT MT940) using the BCS (Banking Communication Standard) software.

Standard for all banks, it can be easily run using a spreadsheet program or a word processing program. It consists of two files in format AUSZUG.TXT and UMSATZ.TXT. The AUSZUG.TXT contains the header information for the account statements, UMSATZ.TXT the item information. This format allows you to import data from several account statements at the same time, including those from different banks.

BCS software is usually MultiCash software. This is often used by banks under a different name (Cotel - Commerzbank, Dretec - Dresdner Bank, ELKO - Sparkassen, ...). If the BCS program is from the Deutsche Bank, you must install the program ‘db-direct’.

Many banks provide account statements in the SWIFT MT940 format (with or without structured field 86).

SAP offers a certification program by which banks and BCS software providers are certified to deliver files in MT940 format. This format is compatible with SAP’s SWIFT MT940 format recommendation.

SWIFT MT940 should only be used in cases where it is not possible to use the MultiCash format.

The main advantage of the electronic account statement is that it ensures that all the business transactions contained in the statement are posted in your system.

The DTAUS format only contains a single business transaction (for example, cash receipt) per file and therefore only represents a fraction of the items processed in an account. Using the DTAUS format usually entails importing more than one file into the system. In addition, certain business transactions (that are not supported by this format) may need to be posted manually.

Moreover, the header record of DTAUS files does not contain any reference to the statement from which the items originated (such as statement date or number). This means that the import program cannot carry out the usual checks, such as those which prevent the same items being imported more than once, or which check that imported data is complete.

The DTAUS format originated in the mainframe era and has certain disadvantages; for example the individual data records are not separated by the special character denoting a "new line" (Carriage-Return Line-Feed <CR><LF> ) and this renders the search for errors extremely difficult in cases where the bank has transmitted defective files. Such problems occur relatively often in Germany, where the "Umlaut" character (ö, ü or ü) is frequently converted into a special character during the conversion from ASCII to EBCDIC code and back again, and thus not transmitted as a text character.

Another disadvantage of DTAUS files is that if just a single byte is missing from the file, the whole file is rendered unreadable, since every subsequent data record is displaced by one byte.

For the above reasons SAP does not recommend the use of the DTAUS format for posting account statement data in the system, unless of course there are unavoidable reasons for doing so.