Can Azure Document Intelligence Read Bank Statements?

Last updated August 2026.

Azure AI Document Intelligence reads bank statements with a dedicated model. Microsoft ships prebuilt-bankStatement.us, a US bank statement model that reached general availability in version 4.0, alongside prebuilt models for invoices, receipts, ID documents, W2s and pay stubs. It extracts account information, bank and statement details, transaction details and fees, and since the 4.0 GA release it also pulls check tables from US statements. The alternatives are the general Layout model, which detects tables, or a custom model trained on your own labeled statements. Whichever you pick, the output is JSON, not a spreadsheet.

If you are choosing between cloud OCR services for statement work, the short version is that Azure sits in the same category as Amazon Textract and Google Document AI: excellent reading, no statement-specific structure, and a parser you own.

What Azure gives you on a bank statement

Since the bank statement model went GA, it is the sensible default for US statements, and Layout is the fallback for anything it does not cover. Layout returns a JSON document with tables broken into cells, each cell carrying its row index, column index, spans, and bounding region. On a clean statement from a large bank, the transaction register usually comes back as a recognizable table. On a scanned statement from a small credit union, with faint print and a summary box that Layout reads as part of the register, it takes more work.

How much does Azure Document Intelligence cost?

Layout and the prebuilt models, including the bank statement model, are published at $10 per 1,000 pages, which puts Azure at the lower end of structured extraction pricing alongside Google Layout Parser and just under Amazon Textract Tables at $15. There is a limited free tier for evaluation, and a standard paid tier beyond it.

As always with per-page pricing, the number that matters is your page count. A business checking account commonly prints eight to twelve pages a month, so one account-year is roughly 60 to 140 pages and a three year lookback for a loan file can pass a thousand pages for a single client. At $10 per 1,000 pages, that thousand-page client costs about $10 in API charges, which is not the expensive part of the project. For the full cross-vendor comparison, see the breakdown of OCR API pricing for bank statements, and for a side by side on what you get for that rate, the Azure Document Intelligence alternative comparison.

Why a prebuilt model still does not finish the job

Prebuilt models work well when a document type has a stable set of fields in a predictable place: an invoice has a number, a date, a total, a tax amount, a supplier. A bank statement is different. Beyond the header it is a table that runs for pages, where every row matters and the correctness test is arithmetic rather than field matching. Opening balance plus credits minus debits must equal the closing balance printed on the last page.

Microsoft trained a statement model that identifies the register and returns transaction details as fields, which is a real advantage over a generic table detector. What it does not do is tell you when it has silently dropped a row, reconcile the running balance, or hand back a file. That check is arithmetic your own code has to perform on the JSON, and it is the difference between an extraction that looks right and one you can sign off on. The full cost breakdown across every meter is in the Azure Document Intelligence pricing guide.

What you still have to build

Whether you use Layout or a custom model, the same list of problems sits between the JSON and a spreadsheet an accountant will accept.

• Identify the register. A page often contains three or four detected tables. Your code decides which holds transactions.
• Stitch across pages. Layout analyses the document but returns tables per region. A statement is one continuous register, and repeated header rows must be dropped rather than treated as transactions.
• Normalize signs. Some banks use separate debit and credit columns, some a single signed column, some a trailing CR marker. Each needs a rule and the rules do not generalize.
• Fix dates with no year. Registers often print 12/28 and 01/03 with no year. The year comes from the statement period, and a period crossing December means incrementing partway down the column.
• Merge wrapped descriptions. A long ACH memo that spills onto a second line arrives as a row with no amount. Merge it wrongly and you create a phantom transaction.
• Foot the balance. Without this check, an extraction that loses one row out of four hundred looks perfect and is wrong.

None of these are difficult on their own. Together they are a small product with an owner, and every new bank layout is a new edge case. Teams that already run other receipt and invoice data extraction workloads on Azure often find the marginal effort acceptable, because the plumbing exists. Teams starting from nothing usually do not.

When Azure is the right choice

When extraction has to run unattended, at continuous volume, inside software your team operates, and especially when your organization is already on Azure with the compliance boundary drawn around it. Keeping borrower or client financial documents inside your own tenant and region is a genuine reason to accept the build cost, and one no hosted converter can offer.

Custom models are also the right answer when you receive statements from a small, stable set of institutions. Train on those layouts once and the accuracy is high, because you have narrowed the problem the way a purpose-built converter narrows it.

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 a client's year, a CPA building workpapers before a deadline, a lender spreading a borrower's history: the work is bounded, there is no pipeline to automate, and someone opens the result in Excel.

A converter has already written the parser, the per-institution rules, and the footing check, which is the code you would otherwise be maintaining. Uploading the PDF to a bank statement converter returns the XLSX with the running balance in its own column, and the same conversion exports QBO or OFX straight into the ledger. If you want automation without owning the statement layer, a bank statement converter API returns statement-shaped output rather than raw cells.

How Azure compares to Textract and Document AI for statements

Closely enough that existing cloud footprint usually decides it. All three read text and detect tables well, and all three return JSON. Azure is now the one with a dedicated prebuilt bank statement model, which is a genuine edge on US statements. AWS is the only one with a lending-specific feature, Analyze Lending, which classifies and splits mortgage packages. Google has the strongest OCR on difficult scans and handwriting. Azure has the lowest structured rate of the three and the cleanest integration if your organization already lives in Microsoft 365 and Azure. Side by side detail is in the Amazon Textract alternative and Google Document AI alternative comparisons.

The test worth running first

Before committing to any of them, take your worst statement, ideally a scan from a smaller institution, and run it through. Check the row count against the PDF, check that the closing balance foots, and check that debits and credits carry the right sign. That test costs an hour and tells you more than any vendor page, including this one. Once the numbers are clean and in a sheet, the next step is normally to categorize the transactions or run a bank reconciliation.