Bank statement data API

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:APIExcel (.xlsx)CSVJSON

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

The API is the right answer when this stops being something a person does. The same extraction and the same checks run behind an HTTP call, so the document is read where it already arrives – in your loan origination system, your intake form, your creditors mailbox – instead of somebody downloading it, uploading it here, and carrying the result back by hand.

Same extraction, other formatsCSVJSONExcel

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.
It does not, which is the point: the same extraction, the same checks and the same canonical JSON. What changes is who calls it. Authentication is a scoped API key, the call is synchronous for a single document and asynchronous with a callback for a batch.

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