Azure Document Intelligence Pricing for Bank Statements: Cost Per 1,000 Pages

Last updated August 2026.

Azure AI Document Intelligence charges per page, not per month. For bank statements the meter that matters is the prebuilt model rate of $10 per 1,000 pages, because Microsoft ships a dedicated US bank statement model and it bills as a prebuilt model. Read is cheaper at $0.60 but returns no table structure, custom models cost $30, and ad hoc query fields cost $200. There is a free F0 tier, but it processes only the first two pages of a PDF, so it cannot convert a real statement.

Every figure on this page was read on 26 August 2026 from Microsoft Learn and the public Azure retail prices API for East US in US dollars. Rates differ by region and Microsoft changes them, so check current pricing before you commit budget.

Azure Document Intelligence pricing, meter by meter

There is no subscription. You create a Document Intelligence resource on the standard S0 tier and pay for the pages you analyze. Which meter you land on depends entirely on which model you call, and the spread between the cheapest and most expensive is more than three hundred times.

Two lines on that table cause most of the billing surprises. Read looks like the bargain at $0.60 per 1,000 pages, and for a bank statement it is a false economy: it returns text lines and word positions with no table structure, so you would be rebuilding columns from bounding-box coordinates before you extract a single transaction. Query fields at $200 per 1,000 pages is the other trap. It is twenty times the prebuilt rate, and reaching for it to patch one missing value across a large backlog turns a $50 job into a $1,000 one.

Which meter does a bank statement actually bill on?

The prebuilt meter, at $10 per 1,000 pages. Microsoft ships prebuilt-bankStatement.us, a US bank statement model that reached general availability in version 4.0. It extracts account information, bank and statement details, transaction details and fees, and since the 4.0 GA release it also pulls check tables out of US statements. This is worth spelling out because a number of comparison articles still claim Azure has no bank statement model. That was true once and it is not true now.

You could also run Layout, which costs the same $10 and returns generic tables rather than statement fields. For a US statement the prebuilt model is the better call at identical cost. Custom extraction at $30 only earns its rate when you receive statements from a small, stable set of institutions and can label them once.

The free tier will not convert a real bank statement

Azure has a free F0 tier and the documentation says it lets you test every feature. On a PDF or TIFF it processes only the first two pages, and it caps files at 4 MB against the 500 MB the paid S0 tier allows. A business checking statement usually runs eight to twelve pages.

So an F0 test reads your cover page and part of the first transaction page, then stops. If you evaluate Azure that way and conclude the extraction drops rows, you have measured the tier and not the model. Move the test to S0, where a full statement costs about ten cents, or accept that you have not exercised the multi-page continuity case where statement parsers actually fail.

Commitment tiers, and when they start paying off

Above steady volume Microsoft sells monthly commitments that cut the per-page rate. These are the Azure-hosted prebuilt tiers.

Connected container tiers run lower again, starting at $152 a month for 20,000 pages and reaching $6.00 per 1,000 pages at the top tier, which matters if compliance requires the extraction to run on infrastructure you control. Container pricing otherwise matches the cloud service.

The break-even is straightforward. The 20,000 page tier at $190 works out to $9.50 per 1,000, against $10 pay-as-you-go, so it saves about five percent and only if you actually use the commitment. Below roughly 19,000 pages a month, pay-as-you-go wins. The tiers get genuinely interesting at 500,000 pages and above, where the rate drops twenty to twenty five percent.

What a real statement backlog costs on Azure

Statements are longer than people remember, so the page count is the number worth getting right before you compare anything.

Look at the middle rows and the conclusion is uncomfortable for anyone building a business case on API price. Converting a full year for forty bookkeeping clients costs somewhere around $40 in Azure charges. That is not the expensive part of the project, and it never will be. The expensive part is everything between the JSON that comes back and a workbook someone will sign off on.

The cost the price list does not show

Azure returns structured JSON. It does not write XLSX, it does not write CSV, and it has no QBO, OFX, QFX or QIF export anywhere in the service. Whatever gets statement data into QuickBooks, Xero or Quicken is software you own. The recurring work sits in a predictable list:

• JSON to spreadsheet. Mapping fields and transaction arrays into ordered columns with a running balance.
• Continuity across pages. A register runs for pages and repeats its column headers, which must be dropped rather than treated as transactions.
• Sign normalization. Separate debit and credit columns on one bank, a single signed column on another, a trailing CR marker on a third. The rules do not generalize.
• Dates with no year. A register prints 12/28 then 01/03. The year comes from the statement period and increments partway down the column.
• Wrapped descriptions. A long ACH memo spilling to a second line arrives as a row with no amount. Merge it wrongly and you have invented a transaction.
• Footing the balance. Opening plus credits minus debits must equal the printed closing balance. Without that check, an extraction that drops one row in four hundred looks perfect and is wrong in a way that surfaces during an audit.
• Unlocking PDFs. Microsoft requires password-locked files to be unlocked before submission, so bank-delivered protected statements need a preprocessing step.

Teams that already run other document workloads on Azure often find the marginal effort acceptable, because the plumbing exists. A finance team that has, say, already built invoice data extraction into its accounts payable flow has most of the pattern in place. Teams starting from zero usually discover they have taken on a small product with an owner, where every new bank layout is a new edge case.

Is Azure cheaper than the other options?

On raw per-page rates, Azure is at the low end of structured extraction. Its $10 per 1,000 pages for the statement model sits under Amazon Textract with the Tables feature at $15 per 1,000, well under Textract Forms at $50 and Analyze Lending at $70, on rates we last checked in July 2026. A full cross-vendor breakdown is in OCR API pricing for bank statements, and the platform-by-platform detail sits on the Amazon Textract alternative and Google Document AI alternative pages.

But comparing API rates against each other answers the wrong question, because they are all cheap. The real comparison is between an API plus the parser you maintain, and a converter that has already written the parser. At forty clients a year the Azure bill is about $40 and the build is weeks. That is the trade worth pricing honestly, and it is laid out in full on the Azure Document Intelligence alternative comparison.

How to decide in an afternoon

Take your worst statement, ideally a scan from a smaller institution with a summary box near the register. Run it on S0, not F0, so the whole document is analyzed. Then check three things: does the row count match the PDF, does the closing balance foot, and do debits and credits carry the right sign. That test costs pennies and tells you more than any vendor page, this one included.

If the answer is that you want the output rather than the platform, upload the same file to the bank statement converter and compare the spreadsheet against your JSON. If you want automation without owning the statement layer, a bank statement converter API returns statement-shaped output directly. Once the numbers are clean and in a sheet, the next step is normally to categorize the transactions or run a bank reconciliation.