How to Convert a Bank Statement to XML

Short answer: to convert a bank statement to XML, extract the transactions from the PDF into structured fields, then serialize them into the XML format your target system expects. The two established XML standards for bank statements are OFX 2.x (an XML-based version of Open Financial Exchange) and ISO 20022 CAMT.053, the bank-to-customer statement standard used by treasury and ERP systems worldwide. Many integrations also accept a simple custom XML with one node per transaction. Upload the PDF to a converter, get the transactions as structured data, and export or map them into the XML schema you need. If you just need machine-readable data and control the parser, JSON is often easier than XML, so it is worth confirming which your system actually requires before you start.

Can you convert a bank statement to XML?

Yes. A PDF statement holds the same transactions any XML file would, they are just locked in a page layout meant for printing. Converting to XML is a two-step job: first read every transaction into structured fields (date, description, amount, debit or credit, and running balance), then write those fields into a valid XML document. You can target a standard schema like OFX or CAMT.053, or a lightweight custom structure your own code parses. The hard part is the accurate extraction from the PDF; once the data is structured, serializing it to XML is straightforward.

What XML formats do bank statements use?

Three come up most often. OFX 2.x is XML-based and carries transactions with type, date, amount, and a unique ID per line. ISO 20022 CAMT.053 is the modern bank-to-customer statement standard, a richly structured XML that treasury and ERP platforms consume for reconciliation. A custom or flat XML is anything your own integration defines, usually one element per transaction with child elements for each field. Here is how they compare.

MT940 is another common bank statement format, but note it is a flat SWIFT message, not XML. If a system asks for MT940 it wants that tagged text layout, not an XML document, so do not confuse the two.

Is OFX an XML format?

OFX 2.x is valid XML, but older OFX 1.x is not. The version 1.x files that many banks still produce use an SGML-style syntax where tags are not always closed, so a strict XML parser rejects them. OFX 2.x switched to well-formed XML with proper opening and closing tags. If you need genuine XML and your source is an OFX 1.x file, you either upgrade it to 2.x or extract the data and re-serialize it. Converting straight from the PDF sidesteps the version problem, because you build clean, well-formed output from the transactions themselves.

What is CAMT.053?

CAMT.053 is the ISO 20022 bank-to-customer account statement message, an XML document that reports a closed period of activity on an account with opening and closing balances, entries, and detailed transaction information. Banks and corporates use it for end-of-day statements and automated reconciliation, and most modern ERPs and treasury management systems can import it. Because it is schema-validated, a CAMT.053 file is predictable to parse, which is why finance-integration teams prefer it over ad hoc formats. If your accounting or treasury platform lists CAMT.053 support, that is usually the cleanest XML target for a statement.

How to convert a PDF statement to XML

The reliable path is to extract first, then serialize. Upload the PDF to a converter that reads the transaction table into structured fields, then take that structured output into the XML shape you need. Two practical routes: pull the data as JSON or CSV and transform it into XML in your own pipeline, or map it directly if your tool exports the schema you want. For developers who want machine-readable output to work with, the bank statement JSON export gives you clean, typed fields that map one-to-one onto XML nodes, and the bank statement converter API lets you automate the whole extraction so a statement dropped into your system comes back as structured data without anyone touching a spreadsheet. If your target is the ISO 20022 world, start from the CAMT.053 converter, and for cash-management BAI files see the BAI to Excel converter. Teams that process high volumes of mixed financial documents into structured data often standardize this step with a dedicated document data extraction platform so statements, invoices, and forms all land in the same pipeline.

Mapping statement fields to XML

Whatever schema you target, the core fields are the same, so the mapping is mechanical once the data is structured. A typical transaction node carries a date, a description or memo, an amount, a sign or a debit and credit split, and often a unique ID and the post-transaction balance. Keep amounts as decimals without currency symbols or thousands separators, use ISO date formatting (YYYY-MM-DD) so downstream systems parse dates unambiguously, and preserve the running balance if your reconciliation depends on it. Validate the finished file against the target schema before you load it; a statement that parses cleanly in a validator will import cleanly into the ERP.

Should you use XML or JSON?

Use XML when a standard or a system requires it, such as CAMT.053 for treasury reconciliation or OFX for an accounting import. Use JSON when you control the consumer and just want structured data to work with in code, because it is lighter to parse and maps directly to objects in most languages. Both carry the identical transaction fields, so the choice is about what reads the file at the other end, not about the data itself. When you are unsure, check the target system's import documentation first, then convert the statement to that exact format rather than converting twice.

Frequently asked questions

Can you convert a bank statement to XML?

Yes. The transactions in a PDF statement can be extracted into structured fields and then written into a valid XML document. You can target a standard schema such as OFX 2.x or ISO 20022 CAMT.053, or a custom XML your own integration defines. The accurate extraction from the PDF is the real work; serializing structured data to XML afterward is straightforward.

What XML format do bank statements use?

The two established standards are OFX 2.x, an XML-based version of Open Financial Exchange used by accounting and finance apps, and ISO 20022 CAMT.053, the bank-to-customer statement standard used by treasury systems and ERPs. Many in-house integrations also accept a simple custom XML with one element per transaction. MT940 is common too but is flat SWIFT text, not XML.

Is OFX an XML format?

OFX 2.x is valid, well-formed XML, but older OFX 1.x uses an SGML-style syntax that a strict XML parser rejects because tags are not always closed. If you need true XML from an OFX 1.x file, upgrade it to 2.x or extract and re-serialize the data. Converting directly from the PDF avoids the version issue by building clean output from the transactions.

What is CAMT.053?

CAMT.053 is the ISO 20022 bank-to-customer account statement message, an XML document that reports a period of account activity with opening and closing balances, entries, and detailed transaction data. Banks and corporates use it for end-of-day statements and automated reconciliation, and most modern ERPs and treasury systems can import it because it is schema-validated and predictable to parse.

How do I import a bank statement into an ERP?

Check which format your ERP accepts, usually CAMT.053, BAI, OFX, or CSV, then convert the PDF statement to that exact format instead of importing the PDF. Extract the transactions into structured fields, map them to the ERP's schema, validate the file, and load it. For recurring imports, an API that returns structured data lets you automate the extraction so statements flow in without manual steps.

Should I use XML or JSON for statement data?

Use XML when a standard or system requires it, such as CAMT.053 for treasury or OFX for accounting imports. Use JSON when you control the consumer and want lightweight structured data that maps directly to objects in code. Both carry the same transaction fields, so the decision depends on what reads the file, not on the data itself.