01 — Why it is awkward
Two formats, neither of them friendly
CAMT.053 is ISO 20022 XML: correct, complete, and unreadable by a person. Double-click it and a browser shows you a tree of tags.
MT940 is older and worse to look at — a run of lines beginning
:61:, :86: and so on, where the counterparty and the reference
are packed into one field with its own sub-codes. Plenty of German systems still export
exactly this.
Both are perfectly good data. They are just not a table, and the usual workaround — retyping from the PDF version — is how transpositions get into a reconciliation.
02 — The one thing worth checking
The closing balance is recomputed
A statement states an opening balance, a list of transactions, and a closing balance. Those three have to agree, and it takes one addition to find out.
If they do not agree, a transaction is missing from the file or one was counted twice — and that is worth knowing before the numbers go into a reconciliation, not after an afternoon of looking for the difference.
Bank CSV works too
Most banks also offer a CSV export, and every one of them is different: comma or semicolon, 1.234,56 or 1,234.56, dates in three orders, the header row not always first. Those guesses are made here rather than left to you — and where a guess cannot be made safely, the row is reported rather than quietly mangled.
Nothing is uploaded
A statement is every payment your company made and received, with names attached. It is read in the browser: open the developer tools, the Network tab, drop a file in — no request goes out. Or load the page, pull the network, and drop it anyway.
The same is true of the neighbouring tools: invoices into a spreadsheet and checking a payment file before the bank sees it.