Bank statement to JSON

Drop in a PDF or a photograph of a bank statement and get every transaction back as a spreadsheet – dates, descriptions, debits, credits and the running balance.

Accepts:PDFScanned PDFJPGPNGExports:JSONExcel (.xlsx)CSV

Start free

Try it on your own bank statement

One document, free, right now – no account and no card. You get the fields, the checks and the export, exactly as they come out of the pipeline below.

No document to hand? See it run on a sample – this does not use your free document.

Your document is read and not stored – it never reaches our file storage. Upload only documents you are entitled to share. Privacy Policy · Trust Center

How it works

The whole pipeline, in the order it runs. The document type decides which fields come out and which checks run; the path is the same either way.

The pipeline: read it, extract it, reconcile it, review it, export it – with a failed check routed to a person for review. 1 Read it 2 Extract it 3 Reconcile it 4 Review it 5 Export it anything unresolved goes to a person, not a guess
1

Read it

The statement is OCR’d and the transaction table located – including on a photograph or a scan, where there is no text layer to read.

2

Extract it

Each row becomes a record: date, description, reference, debit, credit, balance. Multi-page statements are stitched into one table rather than one per page.

3

Reconcile it

The extracted rows are re-added and walked against the opening and closing balances the statement itself states. A difference is reported, not absorbed.

4

Review it

Anything the extractor was not certain about is surfaced for a person, with the original page beside what was read.

5

Export it

Excel, CSV or JSON – or straight into a process that posts it, reconciles it and files it.

What it extracts, and what it checks

Extraction is the easy half. The checks are what turn a converted document into one you can post without reading it twice.

Extracted

  • Transaction date
  • Description and reference
  • Debit and credit amounts
  • Running balance
  • Account number and statement period
  • Opening and closing balance

Checked

  • Every transaction row is re-added and compared with the statement’s own totals.
  • The running balance is walked from the opening figure to the closing figure, row by row.
  • Debit and credit columns are separated even where the statement prints them in one.
  • Rows the extractor is unsure of are flagged rather than quietly filled in.
  • Dates are normalised to one format, so a statement that mixes them does not import as text.

What goes in, and what comes out

The document on one side, the fields pulled off it on the other – each one checked before it is handed over.

A bank statement on the left and the fields extracted from it on the right, each one ticked as checked. Bank statement (PDF) Structured, and checked read Transaction date Description and reference Debit and credit amounts Running balance Account number and statement period

JSON is the right answer when the data is going into another system and the structure matters. It is the only format here that keeps the document\u{2019}s real shape – line items stay nested inside their invoice, transactions inside their statement period – instead of being flattened into rows that have to be joined back together. It also carries what a spreadsheet has nowhere to put: per-field confidence, the validation result, and which page each value came from.

Same extraction, other formatsCSVAPIExcel

What a flagged document looks like

The original page on one side, the fields read off it on the other. Correct a reading and carry on – the point is that nobody re-types a document to fix one number.

A flagged bank statement in Automize: the statement PDF beside the fields read off it, with the failed check naming what is wrong – the file carries page 1 of 2.
A flagged bank statement: the page it came from beside the fields read off it, and the check that failed.

And then it does not have to stop there

A spreadsheet is the end of the job for most converters. Here it is a step: the same structured output can go straight into a process that posts it to your ledger, matches it against a purchase order, files the original, and asks a person only about the exceptions.

See what a Digital Worker does with it

Questions

Yes. A statement with no text layer is OCR’d first. Accuracy is highest on a PDF downloaded from the bank, because the text is already there to read – a photograph taken at an angle, in poor light, is the hardest case and the one most likely to come back with rows flagged for review.
You are told. The reconciliation compares what was extracted against the opening and closing balances printed on the statement, and reports the difference rather than adjusting a row to make it disappear. A statement that will not balance is usually a page missing from the upload, and that is worth knowing before the data reaches a ledger.
Excel if a person is going to look at it, CSV if a system is going to import it, and JSON if it is going into an integration. JSON carries the most – the transactions, the statement summary and the reconciliation result together.
Into your Automize company, under the same access control, retention and audit rules as everything else you store there. See the Trust Center for where the data lives and how long it is kept.
The document as one object: the header, the nested children, the totals, the currency, the confidence per field, the result of every check that ran, and a pointer back to the source page. It is the same canonical object the rest of the platform passes around, not an export shaped specially for download.

Try it on your own document

Create a free Automize company and upload a document. Extraction, the checks and the exports are all in the platform – and when the same document arrives every month, the process that reads it can post it too.

Start free See pricing