Bank Statement to XML Converter

What's inside the statement XML

The output opens with the account context — holder, account or IBAN, statement period, opening and closing balance — then lists each transaction as a structured element. Money out and money in are merged into one signed amount, and the running balance is carried on every row so a consumer can re-verify the arithmetic.

A trimmed example:

<?xml version="1.0" encoding="UTF-8"?>
<BankStatement xmlns="urn:parseflow:statement:1.0">
  <Account>
    <IBAN>GB29NWBK60161331926819</IBAN>
    <Period>2026-02-01 / 2026-02-28</Period>
    <OpeningBalance>1240.00</OpeningBalance>
    <ClosingBalance>1587.50</ClosingBalance>
  </Account>
  <Transactions>
    <Transaction>
      <Date>2026-02-03</Date>
      <Description>Card payment - Office Supplies</Description>
      <Amount>-42.30</Amount>
      <Balance>1197.70</Balance>
    </Transaction>
  </Transactions>
</BankStatement>

This is clean XML — not CAMT.053 or MT940

It is important to be exact about what this is. FlowParse produces its own clean, namespaced statement XML. It does not manufacture bank-native interchange formats such as CAMT.053 (the ISO 20022 bank-to-customer statement) or MT940 (the SWIFT format). Those are authored by your bank's systems and carry structured codes a PDF simply doesn't contain.

So use FlowParse's statement XML when you control the consumer — your own ERP import, a treasury tool that accepts generic XML, a transformation you write. When a counterparty strictly requires CAMT.053, get it from your bank. The distinction, side by side:

Why feed a statement as XML

When the next reader of a statement is a machine, XML is often what it wants: a treasury tool reconciling cash, an ERP posting transactions, a bespoke integration that expects tagged fields it can validate. XML keeps the account-and-transactions hierarchy intact and is self-describing, so the consumer never has to guess which column was the amount.

For a person doing analysis, Excel or CSV is friendlier; for a system, structured XML wins. The two aren't mutually exclusive — the same extraction produces either, so a team can ship XML to its ERP and Excel to its analysts from one upload.

Every field, mapped by meaning

FlowParse locates fields by what they mean, not by fixed coordinates, so it reads the same date, description, amount and balance across different banks and layouts. Direct debits, standing orders, card payments, transfers and fees all keep their description text exactly as printed.

Because extraction is layout-independent, a statement from one bank and a statement from another produce the same clean XML structure — which means a single downstream parser handles every account you feed it, regardless of who the bank is.

flowparse.io

XML, QBO, OFX or CSV — which to pick

The right output depends on the destination. If your accounting software imports a bank feed, a QBO or OFX file drops straight in with no mapping. If a system wants tagged data, XML fits. If a person will analyse it, Excel or CSV is simplest.

Signed amounts and running balance

A statement's meaning lives in its signs and its balance. FlowParse merges separate debit and credit columns into one signed amount, keeps the running balance on each transaction, and preserves opening and closing balances in the account block. That lets any consumer re-compute the closing balance from the opening balance plus the transactions.

That built-in checkability is exactly what a system reconciling cash needs. An importer can assert the arithmetic on ingest and reject a file that doesn't add up, catching a truncated or corrupted feed before it pollutes the ledger.

Why hand-building statement XML fails

Turning a month of transactions into XML manually means re-typing dozens of lines, escaping every awkward character, signing each amount and never breaking a tag — for one statement. Across many accounts and months it is unworkable, and a single malformed element fails the whole import.

FlowParse generates the markup from the extracted data, so it is always well-formed and always matches the source figures. What was an error-prone transcription job becomes a review-and-export step measured in seconds.

How to convert a statement to XML

Convert a year of statements to XML

Upload up to 100 statements and either export each as its own XML file or consolidate them first with Smart Merge into one reconciled dataset with duplicate detection and a source-file reference. Either way, multi-page statements are stitched into one continuous transaction list before export.

For a system that ingests a period at a time, one consolidated XML of a full quarter is often easier to handle than twelve separate monthly files — and Smart Merge removes the overlapping rows where one statement's closing balance repeats as the next one's opening.

Statement data over the API

For automated pipelines, the bank statement API returns the same structured data as JSON, which you can transform to XML in your own code — ideal when statements arrive continuously and no one opens a preview.

The extraction behind the API is identical to the app, so a workflow you validate by hand today can be moved onto the API tomorrow with the same field mapping and the same balance guarantees.

flowparse.io

Validated before it's produced

FlowParse reaches around 98% field-level accuracy on standard statement layouts and validates that the opening balance plus every transaction equals the closing balance. Anything that doesn't reconcile is flagged before the XML is generated, so a dropped or misread row is caught rather than exported.

That reconciliation is the safeguard that makes machine ingestion safe: you are handing your systems data that has already been proven to balance, not a best-effort transcription you have to trust blind.

Bank data handled carefully

Statements are sensitive, so 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. The XML output is yours alone.

Nothing is retained after your file is produced, so there is no accumulating store of account statements for an attacker to target.

flowparse.io

Feeding a reconciliation engine

Statement XML earns its keep in reconciliation. A cash-matching routine reads each transaction element, matches it against an expected payment or an open invoice, and posts or flags it — all without a human touching a spreadsheet. Because every amount is signed and every balance is carried, the engine can assert the account reconciles before it commits anything.

That is the difference between structured statement data and a scanned page: one can drive automated reconciliation, the other has to be re-keyed first. FlowParse turns the PDF into the former, so the matching logic downstream has clean, checkable input.

Many accounts, one consistent shape

Businesses rarely have one account. Operating accounts, savings, a card, a foreign-currency account — each issues its own statement in its own layout. FlowParse maps them all to the same element structure, so a system ingesting XML sees a consistent shape whether the source was one bank or five.

That consistency is what makes a single import routine viable. Add a new bank and the XML looks the same as every other; there is no per-bank template to build or maintain on your side.

Currencies, dates and decimals, normalised

Cross-border statements are where naive parsing falls apart: a comma decimal, a DD/MM date, a currency symbol in front of the amount. FlowParse normalises dates to ISO form and amounts to a consistent decimal representation in the XML, so a downstream system doesn't have to guess the locale of each file.

Where a statement is in a foreign currency, the amounts are captured as printed and kept with the account context, so your system knows both the figure and the currency it belongs to — essential for a treasury view that spans several accounts.

Statement periods and a continuous history

Each statement covers a period, and the XML records it in the account block so a consumer knows exactly which dates the transactions belong to. That is essential when you ingest a run of statements — the periods have to line up end to end for the history to be continuous and gap-free.

When you consolidate a year with Smart Merge, overlapping rows where one month's closing repeats as the next month's opening are removed, so a downstream system sees a single unbroken timeline rather than double-counted edges. The result is a clean, continuous transaction history assembled from separate monthly PDFs.

Integrating statement XML without surprises

The value of a consistent shape is a small, stable integration. Because every statement produces the same element structure regardless of bank, your ingestion code is written once and handles every source — no per-bank branch, no reformatting step, no surprise when a new account is added.

And because the data is validated and reconciled before it reaches you, the failure modes shrink to the ones you can guard against with a schema and a balance assertion. That predictability is what lets teams put statement XML into an automated flow and trust it to run unattended.

Opening and closing balances as anchors

The two most valuable numbers on a statement are the opening and closing balances, and the XML keeps them in the account block where a consumer can find them immediately. They are what let any downstream system prove the transaction list is complete: opening plus the sum of the signed amounts must equal closing.

That single equation is a powerful integrity check. An import routine can assert it on ingest and reject a file that fails, catching a page that didn't extract or a feed that arrived truncated before the data ever reaches the ledger.

It is also why FlowParse validates the same equation before it produces the XML in the first place — the file you receive has already passed the check your systems will run.

An audit trail from XML back to the PDF

Structured data is only trustworthy if you can trace it. Each transaction carries enough context — date, description, amount, balance — to be located on the original statement, and when statements are consolidated, a source-file reference travels with every row so a figure points back to the exact PDF it came from.

For an auditor or a reviewer, that trail is the difference between data they accept and data they have to re-check. The XML isn't a black box; every element maps to something a human can verify on the source document.

Credit-card and multi-currency statements

The same converter handles credit-card statements and foreign-currency accounts, not just current accounts. A card statement's purchases, refunds, interest and fees map to the same signed-amount structure; a foreign account's amounts are captured as printed and kept with their currency in the account context.

That breadth means a business with several account types feeds them all through one path and gets one consistent XML shape back — current account, savings, card and foreign account alike — instead of a different parser for each.

Who converts statements to XML

Developers integrating statements into an ERP or treasury system, fintech and lending teams that ingest tagged transaction data, and finance functions whose downstream tools expect structured XML rather than a spreadsheet.

When a system, not a person, will read the statement next, this is the format to hand it — reconstructed faithfully from the PDF, signed, balanced and ready to parse.

Frequently asked questions

Related