Designed for finance exports
The parser recognises date, description, amount, debit/credit, memo, category, and transaction id fields, including headers like Narration or Withdrawal Amt. used by many banks.
Finance file converter
Convert SWIFT MT940 statements into OFX for accounting import screens. Upload a file or paste its contents, check the parsed transactions, then download the OFX file.
1 · Source
2 · Result
Nothing converted yet
A sample MT940 file is loaded — press “Convert to OFX” to see how the output looks.
The parser recognises date, description, amount, debit/credit, memo, category, and transaction id fields, including headers like Narration or Withdrawal Amt. used by many banks.
Each conversion shows the parsed transactions with money in, money out, and date range, plus warnings about ambiguous dates or missing account details.
PDFs and text files are read by your browser and never sent to a server. Close the tab and the data is gone.
OFX is the bank-statement format that most accounting and personal finance programs can import, but many banks that send SWIFT MT940 statements do not offer OFX alongside them. This converter takes the :61: lines and :86: narratives from an MT940 file and writes an OFX 1.0.2 file, with one <STMTTRN> block for each transaction, so an OFX import screen can read the activity.
Each transaction keeps its value date, a signed amount, a name and a memo, and a unique transaction id taken from the bank reference after // in :61:. The bank identifier in the OFX header is configurable. The conversion runs in your browser, so the SWIFT text is not uploaded.
OFX is a header followed by a statement body. Each transaction block needs a TRNTYPE (DEBIT or CREDIT, set from the amount sign), a DTPOSTED date in YYYYMMDD form, a TRNAMT, and a FITID. The converter writes the :61: value date as DTPOSTED and the signed amount as TRNAMT.
The NAME field is limited to 32 characters. A counterparty name longer than that is cut at 32 characters. When the entry has no purpose text of its own, the full name is written to MEMO so nothing is lost. When it does have a purpose, the extra part of a long name is not kept in the OFX, so check long names against the MT940 file. Reversal entries (RC and RD) are signed the same way as the MT940 mark, so the sign follows the effect on the account.
The converter reads the MT940 transactions with the same rules as the MT940 to CSV converter, then writes each row as an STMTTRN block. The block contains the transaction type, posted date, signed amount, FITID, NAME and MEMO.
When two transactions share a bank reference, the second receives a numeric suffix in the FITID so every id in the file is unique.
MT940 (trimmed)
:61:2605030503DN39,99NTRFNONREF//BK-1001
:86:?00TRANSFER?20INVOICE 4411?32CLOUD HOSTING LTDOFX (transaction block, trimmed)
<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20260503
<TRNAMT>-39.99
<FITID>BK-1001
<NAME>CLOUD HOSTING LTD
<MEMO>INVOICE 4411
</STMTTRN>Trusting the placeholder header values. The currency comes from the first :60F: or :62F: balance line, and if none states one, USD is written with no warning. The account number is always 00000000 and the ledger balance always 0.00, so compare the total against the :62F: line instead of the OFX.
Expecting the purpose text to be in NAME. When a counterparty exists, NAME holds the counterparty and the purpose is in MEMO.
Combining several accounts. OFX statements are per account, so split the MT940 file by account before converting if it holds more than one.
Relying on categories. OFX has no category field, so any category from your bank or ledger must be added after the import.
Is the output the same as a bank’s own OFX file?
It has the same structure, but it is built from the MT940 text rather than from the bank’s OFX service. The currency is taken from the MT940 balance lines, while the account number is a placeholder (00000000) and the ledger balance is 0.00, so it does not match the bank’s own file.
Why do some FITIDs end in -2?
Two transactions in the file shared a bank reference. The second one gets a suffix so importers do not treat it as a duplicate of the first.
For more background on data formats and conversion workflows, read our format guides.