MT940 Converter — and the Import-Ready Alternative

What MT940 actually is

MT940 (Customer Statement Message) is a SWIFT text format banks use to deliver end-of-day statement data to customers and their accounting systems. It is a tag-based structure — fields like :20: (reference), :25: (account), :60: (opening balance), :61: (each transaction) and :86: (transaction details).

A fragment looks like this:

:20:STMT-2026-02
:25:NL91ABNA0417164300
:60F:C260201EUR1240,00
:61:2603030303D42,30NTRFNONREF
:86:Card payment Office Supplies
:62F:C260228EUR1587,50

Why accounting tools ask for MT940

In Europe, MT940 became the common language for importing bank activity into accounting and ERP software — DATEV, Exact, and many local packages read it natively. It carries balances, value dates and structured transaction codes, which is why finance teams treat it as the gold-standard feed when their bank offers it.

The key phrase is when their bank offers it. MT940 is meant to come from the bank's electronic-banking channel, not from a scanned or downloaded PDF. When the bank feed is available, use it; the question this page answers is what to do when it isn't.

Why you can't reliably build MT940 from a PDF

A PDF statement doesn't contain the structured codes MT940 requires — the transaction-type identifiers, the SWIFT reference fields, the precise balance markers. Those exist in the bank's back-end feed, not on the printed page. Any tool that claims to turn a PDF into MT940 is inventing that structure, and an accounting system that trusts those invented codes can post the wrong thing.

FlowParse won't do that. It extracts what the statement genuinely contains — dates, descriptions, signed amounts, running balance — and hands it over in honest, import-ready formats rather than a fabricated bank message. The distinction is the whole point: a plausible-looking MT940 built on guessed codes is more dangerous than a clean CSV, because the guesses are invisible once they're in your books.

The import that works just as well

Most software that imports MT940 also accepts other feeds. The table maps the practical route for the common tools:

When you genuinely need MT940 — and where to get it

If your workflow strictly requires MT940 and nothing else, get it from the source: your bank's online-banking portal almost always offers an MT940 (or CAMT) download alongside the PDF. That file carries the real codes and is the one your accountant should use.

FlowParse comes in when that native feed isn't available — historical months, a closed account, a foreign bank, or a statement that only ever existed as a PDF — and you still need the transactions in usable form. Those gaps are exactly where a PDF is often the only surviving record.

What FlowParse extracts from the statement

From the PDF, FlowParse reads the account summary and every transaction: date, description, a single signed amount, and the running balance, with opening and closing balances preserved. Direct debits, standing orders, transfers, card payments and fees keep their description text as printed.

That is the same transaction data MT940 would carry — delivered in a format your tool can actually import. What you lose versus a native feed is the bank's internal codes; what you keep is the activity that matters for bookkeeping.

flowparse.io

How to get your statement into your accounting tool

The DATEV route for German bookkeeping

German practices that would normally take MT940 into DATEV can take FlowParse's DATEV-EXTF export instead — a booking-stapel the software imports directly. When a client only has PDFs, that keeps the workflow moving without waiting on a bank feed.

It is the same honest principle: rather than fake a SWIFT message, FlowParse produces the DATEV-native import file that a German Steuerberater's software is designed to read.

A whole year, consolidated

Upload up to 100 statements and Smart Merge consolidates them into one reconciled dataset with duplicate detection and a source-file reference, ready to export in your chosen import format. A year of catch-up becomes minutes of work rather than a manual reconstruction.

For a bookkeeper onboarding a client who arrives with a folder of PDFs and no bank feed, that consolidation is often the difference between taking the job and turning it away.

MT940, OFX and CSV compared

For getting transactions into software, the practical hierarchy is simple: a native bank feed (MT940/OFX/QBO) imports with the least mapping; a CSV is universal but sometimes needs column matching.

Accurate, reconciled data

FlowParse reaches around 98% field-level accuracy on standard layouts and validates opening balance plus transactions against the closing balance, flagging discrepancies in the editable preview. You import data you have reviewed, not numbers you have to trust blind.

That review-and-reconcile step is what makes the alternative genuinely equivalent to a bank feed for bookkeeping purposes — the figures are proven to balance before they reach your ledger.

Handled with care

Uploads run over TLS, processing is EU-hosted, the original PDF is deleted immediately after processing, and your documents are never used to train AI models.

Nothing is kept once your import file is produced, so there is no lingering copy of a client's bank statements to worry about.

What the MT940 tags mean — and what a PDF has

It helps to see where a PDF and an MT940 overlap and where they don't. The :61: line encodes a value date, a debit/credit mark, the amount and a transaction-type code; the :86: line holds the free-text details. A PDF statement clearly shows the date, amount and description — so those map across — but the SWIFT transaction-type code and the machine references in :61: are bank-internal and simply aren't printed.

That is why FlowParse can faithfully give you the date, signed amount, description and balance, but not a compliant :61:/:86: structure with real codes. The overlap is the bookkeeping-relevant data; the gap is the interbank machinery — and inventing the machinery is exactly what an honest tool shouldn't do.

How the common EU tools actually import

The right FlowParse export depends on the tool. DATEV takes a DATEV-EXTF booking file directly; Exact and several local packages that prefer MT940 also accept CSV imports for accounts without a feed; QuickBooks and Quicken take native QBO/QFX/OFX. In practice, very few tools accept only MT940 and nothing else.

So the honest workflow is: check what your software imports besides MT940 — almost always CSV at minimum, often OFX — and use that. FlowParse produces whichever of those fits, from the same statement, in one step.

Historical years and foreign banks

The clearest case for this workflow is the statement with no feed behind it. A bank feed only reaches back so far, a closed account has none at all, and a foreign bank may never have offered MT940 to begin with. Yet those are precisely the statements an accountant is often handed as a stack of PDFs during a catch-up or an audit.

FlowParse turns that stack into reconciled, importable data — QBO, OFX, DATEV or CSV — so a historical or foreign account posts into the books like any other, without waiting on a feed that will never arrive.

A note on MT940 dialects and banks

Even MT940 is not perfectly uniform. Banks fill the free-text :86: field differently, structure the details with their own sub-tags, and vary how they encode a transaction's type — which is why importing MT940 from a new bank sometimes needs a tweak on the accounting side. The format is a standard in name more than in every detail.

That variability is another reason not to fake it from a PDF: you would be guessing not just the codes but the specific bank's dialect of them. FlowParse's approach — extract the plain transaction data and hand it over in a format the software maps cleanly — sidesteps the dialect problem entirely, because a CSV or an OFX doesn't carry bank-specific SWIFT quirks to get wrong.

So whether your client's bank writes a terse :86: or a verbose one, the FlowParse output looks the same to your accounting tool: dated, signed, described transactions that reconcile.

MT940, MT942 and the other statement messages

MT940 has relatives. MT942 is an interim (intraday) report rather than an end-of-day statement, and MT950 is a simpler statement variant. They all share the tag-based SWIFT grammar and the same fundamental limitation from a PDF's point of view: the structured codes live in the bank's systems, not on the printed page.

Knowing which your software actually wants matters, because it is easy to chase MT940 when the tool would happily take a CSV or an OFX. FlowParse's role is unchanged across all of them: it gives you the genuine transaction data from the PDF, in a format your software imports, rather than a synthetic SWIFT message of any flavour.

What your accountant actually needs

When an accountant asks for MT940, what they usually need is not the format itself but its outcome: every transaction, correctly dated and signed, imported into the books without manual entry. MT940 is simply the pipe their software happened to standardise on.

Framed that way, a clean QBO, DATEV or CSV that lands the same transactions in the same ledger meets the real requirement. The conversation with your accountant becomes easy: 'the bank feed isn't available for these months, but here is the reconciled import in the format the software takes' — which is a better answer than a fabricated MT940 nobody can vouch for.

A worked example: PDF to booked transactions

Say you are catching up six months of a client's bookkeeping and the bank feed only goes back sixty days. You have six PDF statements and a DATEV-based practice. You upload all six, Smart Merge consolidates them, the balance check confirms each month reconciles, and you export a single DATEV-EXTF file.

That file imports into DATEV as a booking batch; the transactions post, the accounts reconcile, and the six-month gap closes in minutes. No MT940 was invented, no line was re-typed, and the numbers were proven to balance before they were booked.

The time and risk this removes

Manual entry of a busy statement is roughly a transaction a line, plus the sign-fixing and date-parsing, plus a reconciliation that only tells you something is wrong, not where. Across a backlog that is hours of work and a real chance of a silent error.

Converting instead turns each statement into a reviewed, reconciled import in well under a minute, and the balance check makes completeness provable rather than hoped-for. The honest alternative to MT940 is not a compromise on quality — it is usually faster and safer than the manual route people fall back on when a feed isn't there.

Who this is for

European bookkeepers and accountants whose software expects MT940 but whose client only has PDFs, finance teams handling historical or foreign statements without a native feed, and anyone who values an honest import over a fabricated bank message.

You get the transactions in cleanly — without pretending a PDF is something it isn't, and without the risk that comes from importing invented SWIFT codes.

Frequently asked questions

Related