Background documentationFormats for the Electronic Bank Statement

 

The following section contains an overview of the formats that are supported for the electronic bank statement:

MultiCash Format

This format is created from the bank statement data received from the banks (usually SWIFT MT940) using the Banking Communication Standard (BCS) 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 bank statements, UMSATZ.TXT the item information. This format allows you to import data from several bank statements at the same time, including those from different banks.

BCS software usually involves 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.

Swift MT940

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.

camt.053.001.02

The XSL transformation delivered supports this XML format in accordance with the standards laid down by the Common Global Implementation (CGI) initiative for ISO 20022 messages. You can if necessary create a copy of this transformation, and adapt it to the requirements of your bank.

For additional information, see Customizing for Bank Accounting under Start of the navigation path Business Transactions Next navigation step Payment Transactions Next navigation step Electronic Bank Statement Next navigation step XML Format and Bank-Specific Formats End of the navigation path.

camt.054.001.02

This format applies to files containing collective postings and related details. In Germany, this format is the replacement for bank statement format DTAUS. The XSL transformation delivered and the implementation of the BAdI for mapping the bank statement to internal structures supports this XML format in accordance with the standards laid down by the Common Global Implementation (CGI) initiative for ISO 20022 messages. You can if necessary create a copy of the implementation, and adapt it to the requirements of your bank.

For additional information, see Customizing for Bank Accounting under Start of the navigation path Business Transactions Next navigation step Payment Transactions Next navigation step Electronic Bank Statement Next navigation step XML Format and Bank-Specific Formats End of the navigation path.

DTAUS Format

The main advantage of the electronic bank statement is that it ensures that all the business transactions contained in a bank 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 being processed in a bank account. Using the DTAUS format usually entails importing more than one file into the system. In addition, certain business transactions (that cannot be transferred using 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 make 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 and 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 (ä,ö,ü) is frequently converted into a special character during the conversion from ASCII to EBCDIC code and back again, and thus not transferred.

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 bank statement data in the system, unless of course there are unavoidable reasons for doing so.