Skip to content
Guide

MT940 and CAMT.053: what is actually in a bank statement file

By the LiquidityLens editorial team · Updated: November 2026 · 7 min read

CAMT.053 is the ISO 20022 XML format for a bank’s end-of-day account statement; MT940 is the older SWIFT text format doing the same job. Both bundle one day’s finalized transactions — opening balance, booked transactions, closing balance — into a file a system can read automatically, instead of just showing them in online banking. Which of the two you get, and in which format, depends on your bank.

For cash flow forecasting, that is more than a technical footnote: the bank statement is how you check whether the payments you forecast actually arrived. This guide explains what the two formats contain, how you get the files, and how to use them alongside your open items for a weekly forecast.

CAMT.053 vs. MT940 — and where CAMT.052 fits in

Both formats describe the same thing, just in different technical shapes:

  • MT940 is a SWIFT message format: a compact text message carrying the end-of-day statement — opening balance, the day’s booked transactions, and closing balance.
  • CAMT.053 is the ISO 20022 equivalent: the same end-of-day statement, but as structured XML rather than a SWIFT text message. That makes it easier for accounting and forecasting systems to parse automatically than the older SWIFT syntax.
  • CAMT.052 is not an alternative to either — it is their intraday counterpart: an intraday transaction report, a provisional snapshot during the day that gets confirmed and summarized by the end-of-day statement once the day closes.

In practice, MT940 and CAMT.053 are interchangeable as long as your accounting or forecasting tool can read one of the two — technically, CAMT.053 is the more modern, better-structured of the pair.

What is in a CAMT.053 file — and how the MT940 format differs

Whichever of the two your bank delivers, the content is the same statement: the balance the day opened with, the transactions the bank booked as final during it, and the balance it closed with. The difference is the container. CAMT.053 wraps that in ISO 20022 XML, where every element is named and typed, so a parser can pick out amount, value date, counterparty and reference without guessing. MT940 carries the same information as a compact SWIFT text message built from numbered fields — readable, but it has to be parsed by position and field tag rather than by element name.

If you want the field-by-field definition rather than a description of it, go to the specification, not to a sample file: for the DACH route, Annex 3 of the DFÜ-Abkommen (“Spezifikation der Datenformate”) is what holds the format specifications, including account balance information in the SWIFT format and in the XML format (camt). Your own bank’s documentation tells you which of those variants it actually fills and with which transaction codes — that part is bank-specific, so ask for it rather than assuming it from a sample published by another bank.

Two things about the message families are worth knowing before you build anything on top of a statement file:

  • The names follow a pattern. On the ISO 20022 side, camt.053 is the day’s statement and camt.052 the intraday report. On the SWIFT side, the Deutsche Bundesbank’s own message set lists MT940 as the statement as an end-of-day statement, MT942 as the intraday transaction report, MT941 as the intraday balance report and MT920 as the request for intraday transaction and balance information. That table is written for account holders with a bank code at the Bundesbank, so read it as the logic of the family rather than as a rule every bank applies to every corporate customer.
  • Statement numbering is its own topic. For accounts held at the Bundesbank, camt.052 messages always start at 1, and when a customer switches from MT940 to camt.053, the camt.053 continues with the next sequence number the MT940 would have had — camt.052 and camt.053 numbering running independently of each other and of the paper statements. Again, that is documented as a Bundesbank rule for its own account holders, not as a general rule for every bank. It is still the right question to put to your bank before a switch, because the sequence number is what tells your system whether a statement is missing or arrived twice.

How you get the files

There are two general routes to a statement file:

  • EBICS. The German Banking Industry Committee’s standard for data transfer between a corporate customer and its bank — used across Germany, Austria and Switzerland — is multi-bank capable: one piece of software reaches every bank that offers EBICS. Through EBICS, the bank makes the end-of-day statement available for pickup in MT940 or CAMT.053, plus intraday movements separately as CAMT.052. This is formally specified in the DFÜ-Abkommen (the German banking industry’s data-transfer agreement), whose Annex 3 contains the format specifications for payments and account balance information.
  • Account information service (the PSD2 route). Under the EU’s PSD2 payments directive, as transposed into German law in the Payment Services Supervision Act (Zahlungsdiensteaufsichtsgesetz, ZAG) § 1(34), this is defined as an online service that reports consolidated information on one or more payment accounts held with one or more payment service providers. This route runs through an API rather than a file you pick up, and it is the better fit when you need to consolidate several bank relationships into one feed.

For most mid-market companies in the DACH region (Germany, Austria, Switzerland), EBICS is the established route, because it is already used for payment processing — the statement arrives through the same channel. Many banks also offer a manual download through their corporate portal if no EBICS connection is set up. Which format and route your bank actually supports is fastest to confirm directly with them — this varies from bank to bank.

Using bank statements in a cash flow forecast

A 13-week cash flow forecast runs on the expected payments from your open items list plus recurring and scheduled payments. The bank statement adds two things that matter for the weekly cycle:

  • A starting point. The current balance from the end-of-day statement is the opening balance for the next forecast week — without it, every rollover starts from an estimate instead of a fact.
  • An actuals check. The booked transactions show which of the forecast receipts and payments actually arrived and which are still outstanding. Only that comparison tells you whether the forecast still holds or the next low point has shifted.

If you already export open items from DATEV (the accounting and payroll platform used by most German small and mid-sized companies) or SAP Business One, the bank statement fills in the side that never shows up in an open items list: actual incoming payments, bank fees, direct debits, and anything else that moves through the account without an open invoice behind it. This is where LiquidityLens comes in: you upload your open items and current account balance as an Excel or CSV export — from DATEV, SAP Business One or another system, with a one-time column mapping and no integration project — and the software rolls the 13-week forecast forward with AI from there.

If you just want a quick look at the low point over the next 13 weeks, you can also load your open receivables, open payables and current balance straight into the 13-week forecast generator — it calculates in your browser, nothing to upload.

Account balance and open items, forecast week by week

LiquidityLens turns your uploaded account balances and open items into a rolling 13-week forecast — with automatic categorisation and low-point warnings.

See the Liquidity Control Sprint
Free Excel template: 13-week cash flow forecast

A starting point built around your current account balance and open items — weekly grid, receipts and payments, low-point warning. Ready to use.

Get the free template

Four things that trip people up

Four spots regularly cause confusion or duplicated work when bank statements enter a forecast:

  • CAMT.052 is not a substitute for CAMT.053. The intraday transaction report is a provisional snapshot — for the weekly forecast, only the final end-of-day statement (CAMT.053 or MT940) counts as the confirmed position.
  • Switching formats can create duplicates. If both the old and the new statement are processed during a transition period, check transactions against their statement or booking reference for duplicates rather than relying on the date alone.
  • The payment reference is free text. Automatically matching transactions to open items or categories only works reliably if the payment chain consistently carries a reference (invoice number, customer number) in that field.
  • Without a fixed rhythm, the actuals check goes stale. A statement that is only pulled occasionally doesn’t give you a reliable starting balance for the current week — like the open items export, this step needs a fixed, at least weekly routine.

Frequently asked questions

The most common questions on MT940, CAMT.053 and their role in cash flow forecasting are gathered at the end of this page.

Frequently asked questions

What is CAMT.053?
CAMT.053 is the ISO 20022 message for the end-of-day bank statement, delivered as an XML file: opening balance, the transactions the bank booked as final that day, and closing balance. Its intraday counterpart is camt.052. In the DACH region a bank makes it available for pickup through EBICS, and the binding field specification for that route sits in Annex 3 of the DFÜ-Abkommen, not in any single bank's documentation.
What does a file in MT940 format contain?
The same end-of-day statement as CAMT.053 — opening balance, the day's booked transactions, closing balance — but as a compact SWIFT text message instead of XML. In the Deutsche Bundesbank's own SWIFT message set, MT940 is the statement as an end-of-day statement, MT942 the intraday transaction report, MT941 the intraday balance report and MT920 the request for intraday transaction and balance information; that table applies to account holders with a bank code at the Bundesbank, so treat it as the naming logic of the family, not as a rule every bank applies to every corporate customer.
Do the statement numbers keep running when you switch from MT940 to CAMT.053?
For accounts held at the Deutsche Bundesbank, yes: a camt.053 continues with the next sequence number the next MT940 would have had, while camt.052 messages always start at 1, and camt.052 and camt.053 numbering runs independently of each other and of the paper statements. That is documented as a Bundesbank rule for its own account holders, not as a general rule for all banks — so during a format switch, confirm the numbering with your own bank and check for duplicates against the statement or booking reference.
What is the difference between CAMT.053 and MT940?
MT940 is the older SWIFT format for the end-of-day bank statement. CAMT.053 is the newer ISO 20022 format with the same role, just structured as XML instead of a SWIFT text message. Banks typically make both available for pickup through EBICS, the German/Austrian/Swiss standard for corporate-to-bank data transfer.
What is the difference between CAMT.053 and CAMT.052?
CAMT.053 is the end-of-day statement — once a day, with the transactions booked as final. CAMT.052 is the intraday transaction report: a provisional snapshot during the day that the end-of-day statement later confirms and summarizes.
How do you get your bank statements in CAMT.053 or MT940 format?
Through EBICS (Electronic Banking Internet Communication Standard), the German Banking Industry Committee's standard for data transfer between a corporate customer and its bank. It is multi-bank capable — one piece of software reaches every bank that supports EBICS — and the bank makes the end-of-day statement available for pickup in either format, plus intraday movements as camt.052. Many banks also offer a manual download through their corporate online banking portal. Which format and which route your bank supports is best confirmed directly with them, since this varies by bank.
Is MT940 being phased out?
Whether and when a given bank retires MT940 from its corporate portal is a decision each bank makes on its own; there is no generally documented, universal shutdown date. If this matters to you, the fastest way to find out is to ask your bank directly which format its portal supports today and going forward.
Why do I need bank statements if I already forecast from open items?
Open items show what is expected; the bank statement shows what actually happened. Only comparing the two tells you whether the forecast still holds or needs adjusting.