Can Azure Document Intelligence Read Bank Statements?

Last updated July 2026.

Azure AI Document Intelligence can read bank statements, but not with a ready-made statement model. Microsoft ships prebuilt models for invoices, receipts, ID documents, W2s, and a handful of other types. Bank statements are not among them, so the practical path is the general Layout model, which detects tables, or a custom model you train on your own labeled statements. Either way 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

Layout is the model most teams end up using. It 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 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.

Why there is no prebuilt bank statement model

It is a reasonable product decision rather than an oversight. Prebuilt models work 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. Microsoft can train one model that finds those on almost any invoice in the world.

A bank statement has almost no stable fields beyond the header. What it has 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. A general model has no reason to know that, and no way to tell you when it has silently dropped a row.

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. None ship a bank statement model. All three return JSON. 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.