Can Amazon Textract Convert a Bank Statement to Excel?

Last updated July 2026.

Amazon Textract can read a bank statement, but it cannot convert one to Excel. Textract returns JSON block objects describing detected text, tables, cells, and their positions on the page. Producing an XLSX file with dates, signed amounts, and an intact running balance is an application you write on top of that response. Textract is the reading step, not the spreadsheet.

That distinction is worth being precise about, because the answer to the question depends entirely on what you mean by convert. If you mean can it see the transactions, yes, and it does that well. If you mean can it hand a bookkeeper a file they can open in Excel, no, and no amount of configuration changes that.

What Amazon Textract actually returns for a bank statement

Textract has several APIs, and which one you call changes what you get back.

Rates from the Amazon Textract pricing page, US West Oregon, first one million pages a month, checked July 2026. Rates vary by region.

For a statement you almost always want Analyze Document with the Tables feature. Layout is included free when you use Tables, which helps you tell the transaction register apart from the summary boxes. What comes back is a JSON structure of BLOCK objects: PAGE blocks containing TABLE blocks containing CELL blocks containing WORD blocks, each carrying geometry and a confidence score.

What the missing code has to do

Between that JSON and a usable spreadsheet sits a specific list of problems. None of them are hard individually. Together they are a small product.

• Pick the right table. A statement page often contains three or four detected tables: the account summary, the transaction register, a fee recap, sometimes an interest breakdown. Your code has to decide which one holds transactions.
• Stitch across page breaks. Textract analyses pages independently. A statement is one continuous register. Rows have to be concatenated in order, and repeated header rows have to be dropped rather than turned into transactions.
• Get the signs right. Some banks print separate debit and credit columns. Some print one amount column with negatives. Some use a trailing CR marker. Your parser needs a rule per layout, and the rules do not generalize.
• Parse dates that lack a year. Many registers print 12/28 and 01/03 with no year at all. The year comes from the statement period in the header, and a period that crosses December means incrementing partway down the column.
• Handle wrapped descriptions. A long ACH description that spills onto a second line arrives as a second row with no amount. Merged wrongly, you get a phantom transaction; dropped wrongly, you lose half the memo.
• Check that it foots. This is the one that matters. Opening balance plus credits minus debits should equal the closing balance printed on the last page. If it does not, something was missed, and without that check nobody knows.

That last point is the reason a bank statement is harder than an invoice. An invoice extraction that gets nine of ten fields is 90 percent useful. A statement extraction that gets 399 of 400 rows is not 99.75 percent useful, it is wrong, and the error is buried somewhere in four hundred lines.

How much does Amazon Textract cost for bank statements?

The unit price is low and the page count is higher than people expect. A business checking account with a few hundred transactions a month commonly prints eight to twelve pages. That makes one account-year roughly 60 to 140 pages, and a three year lookback for a loan file or an audit can pass a thousand pages for a single client.

At $15 per 1,000 pages for Tables, a thousand-page client costs about $15 in API charges. That is genuinely cheap. The cost that decides the project is the engineering: the ingestion code, the parser, the per-bank rules, the validation, and the ongoing maintenance as banks redesign their statements. Teams routinely scope that as one sprint and discover it is a product with an owner.

Does Amazon Textract have a free tier?

Yes, for the first three months on a new AWS account, and it is smaller than it looks for this use case. The free tier covers 1,000 pages a month of Detect Document Text but only 100 pages a month of Analyze Document with Forms, Tables, or Layout. Since Tables is the feature you need, 100 pages is roughly one year of statements for a single account, and it ends after three months.

What about Analyze Lending?

Analyze Lending is the closest thing AWS offers to statement awareness. It was built for mortgage loan packages: it classifies each page into a document type such as bank statement, pay stub, W2, or 1099, splits the package accordingly, and extracts data from the recognized types. If you are a lender ingesting complete borrower packages, that classification step saves real work.

It is still an API returning JSON, it is priced at $70 per 1,000 pages, and it is oriented around US mortgage document types rather than around producing a reconciliation-ready ledger. It solves the sorting problem, not the spreadsheet problem. For a fuller side by side, see the Amazon Textract alternative comparison.

When Textract is the right choice

Three conditions, and you want all three. Extraction has to run without a person present, at continuous volume, inside software your team operates. Your compliance posture benefits from documents staying inside your own AWS account and region. And you have engineering capacity to own a parser long term.

A lending platform processing fifty thousand borrower documents a month meets all three easily, and the per-page rate is trivial next to the headcount it replaces. Teams that already run their document data extraction workloads in the cloud usually find the marginal cost of adding statements to be small.

When a converter is the right choice

When a person is doing the work anyway and the deliverable is a file. A bookkeeper catching up nine months for a client, a CPA assembling workpapers before a filing deadline, a controller rebuilding a cash schedule the bank feed never covered: in each case the work is bounded, there is no pipeline to automate, and the output is a spreadsheet somebody opens.

A purpose-built converter has already written the parser, the per-bank rules, and the footing check. Uploading the PDF to a bank statement converter returns the XLSX directly, with the running balance in its own column. If you want automation without building the statement layer yourself, a bank statement converter API gives you statement-shaped output rather than raw blocks.

The quick test either way

Take your messiest statement, ideally a scanned one from a smaller bank, and run it through whatever you are evaluating. Check three things. Does the row count match the PDF? Does the closing balance foot? Are debits and credits signed correctly? Whichever approach passes on your own documents is the right one, regardless of what any comparison says. Once the data is in a sheet, the next step is usually to categorize the transactions or run a bank reconciliation.