OFX, QIF, MT940, CAMT.053 and BAI2 explained for accountants

Your accounting software asks for a file format you have never heard of. Here is what each one actually is, which programs read which, and why a native format imports silently while a CSV always asks questions.

Why the format matters more than the data

Two files can contain exactly the same transactions and behave completely differently on import. A CSV is a spreadsheet: the importer has no idea whether your third column is a withdrawal, a deposit or a balance, so it has to ask. A native banking format is self-describing: it states the account, the currency, the statement period, and for each line whether it is a debit or a credit. There is nothing left to map, which is why those imports feel instant.

This is the whole reason Tally imports feel effortless — Tally XML is Tally's own published format. Giving every other program its own equivalent produces the same effortless result.

The formats, one by one

OFX (.ofx / .qfx)

What it is: Open Financial Exchange — an XML-style file created for online banking downloads. Carries account identity, currency, a statement period and one <STMTTRN> block per transaction with a type, date, signed amount and a unique transaction id.

Reads it: QuickBooks (Desktop and Online), Xero, Kashoo, Manager.io, Wave, Moneydance, and most personal-finance software.

Why it is used: The transaction id lets the importer recognise a line it has already seen, so re-importing an overlapping period does not create duplicates. Signed amounts mean there is no withdrawal/deposit column to map.

QIF (.qif)

What it is: Quicken Interchange Format — an old, deliberately simple line-based text format. Each transaction is a handful of tagged lines (D for date, T for amount, P for payee, M for memo) closed with a caret.

Reads it: Sage 50, MYOB, Reckon, KashFlow, GnuCash, older Quicken versions.

Why it is used: Almost nothing can go wrong with it, and it is the most widely accepted fallback in older desktop software. The trade-off: no account number, no currency, no transaction id, and dates are ambiguous unless the importer is told the order.

MT940 (.sta / .940)

What it is: A SWIFT interbank message type, used as an end-of-day statement. Fixed field tags — :20: reference, :25: account, :60F: opening balance, :61: each transaction, :86: its narration, :62F: closing balance.

Reads it: SAP (Business One and ECC/S4 via the electronic bank statement programs), and most European corporate banking portals.

Why it is used: It carries the opening and closing balance inside the file, so the importer can verify the statement is complete and in balance before posting anything. That is why corporate finance systems prefer it.

CAMT.053 (.xml)

What it is: ISO 20022 bank-to-customer statement — the modern, strictly-schema-validated XML replacement for MT940. Structured entries with booking and value dates, credit/debit indicators, bank transaction codes and rich remittance information.

Reads it: Microsoft Dynamics 365 Business Central and Finance, SAP S/4HANA, Oracle Fusion, and most new European bank feeds.

Why it is used: It is the format banking is standardising on globally. Because it validates against a published schema, an importer can reject a malformed file rather than half-posting it.

BAI2 (.bai / .txt)

What it is: Bank Administration Institute cash-management format. Positional records identified by a leading code — 01 file header, 02 group, 03 account, 16 transaction detail, 88 continuation, 49/98/99 trailers with control totals.

Reads it: Oracle Fusion Cloud, NetSuite, Sage Intacct, Acumatica, and US corporate cash-management systems.

Why it is used: The trailer records carry control totals, so a truncated file is detected instantly. Amounts are in the smallest currency unit with no decimal point, which removes rounding ambiguity.

CSV / Excel

What it is: Not a banking standard at all — just rows and columns. Every program defines its own expected headers, date order and sign convention.

Reads it: Everything, as a fallback. It is the only route for Busy, Marg, Vyapar and many regional ERPs.

Why it is used: Universal, but the importer has to ask you which column is which, at least the first time. Save the mapping as a template and later files go in without questions.

Choosing one for your software

TallyPrime — Tally XML for creating vouchers; statement CSV/Excel for Banking reconciliation.
QuickBooks, Xero — OFX. Both also accept CSV, but OFX avoids duplicate lines.
Zoho Books — OFX or its documented CSV columns.
Sage 50, MYOB, Reckon, KashFlow — QIF or OFX.
SAP Business One — MT940.
Dynamics 365 Business Central — CAMT.053.
Oracle Fusion, NetSuite, Sage Intacct, Acumatica — BAI2.
Busy, Marg, Vyapar, most regional ERPs — CSV or Excel with their documented headers. There is no native option; their importers are template-driven by design.

If your software is not listed, check its import screen: the file-type dropdown is the definitive answer, and it is usually one of the six above.

A note on dates and signs

Two things break more imports than anything else. Date order: 03/04/2026 is 3 April in India and 4 March in the United States, and a CSV does not say which. Prefer a format with unambiguous dates, or set the date order explicitly in the import wizard. Sign convention: some importers want one signed amount column, others want separate withdrawal and deposit columns. Sending a signed amount into a two-column layout puts every debit in the wrong place.

Duplicate protection

Only OFX and CAMT.053 carry a per-transaction unique id, so only they let an importer say "I have already posted this line". With QIF, CSV or Excel, protection is your discipline: import strictly non-overlapping date ranges and record the last date imported for each account.