Best Google Document AI Processor for Invoices and Receipts by Cost Per Document

The short answer: for a one to three page invoice, Form Parser is cheaper than Google's Invoice parser, and most US teams pick the wrong one. Form Parser bills $0.03 a page. Invoice parser bills $0.10 per count, and Google defines one count as up to ten pages, so a one-page invoice pays the full $0.10. The crossover lands between three and four pages. Below it Form Parser wins on price; above it the ten-page block works in your favor and Invoice parser wins.

That is the cost half of the decision. The other half is what you get back, and it is the reason plenty of teams should still pay more. This article works through both, using the rates on Google Cloud's published Document AI rate card as read on 21 August 2026. If you want the whole rate card rather than the invoice slice, we keep a processor-by-processor breakdown of Google Document AI pricing per 1,000 pages.

What a count means, and why it decides your bill

Google attaches a footnote to three rows of its rate card that reads, word for word, "1 count equals up to 10 pages in a document". Those three rows are the Invoice parser, the Expense parser (formerly the receipt parser) and the Utility parser. Every one of them is $0.10 per count.

A count rounds up. There is no partial count. So the same $0.10 buys one page or ten, and the effective cost per 1,000 pages moves by a factor of ten depending on nothing but how long your documents happen to be:

Note the cliff at eleven pages. One page past the block boundary buys a whole second count, and the effective rate jumps from $10.00 back up to $18.18 per 1,000 pages. If your documents cluster just above a multiple of ten, splitting them before the call is a legitimate saving rather than a trick.

Cost per document, processor by processor

Here is what a single invoice actually costs on each of the three processors that could reasonably handle it. Form Parser and Enterprise Document OCR bill per page, so their cost climbs with length. Invoice parser does not move until page eleven.

Enterprise Document OCR is in that table for scale, not as a real option. It is 20 times cheaper than Form Parser and it will not give you a single labeled field. It reads text off the page. Everything after that is code you write and maintain, which is a fine trade at very high volume and a poor one at a few thousand invoices a month.

The part cost tables leave out

Price is only half of it, and picking on price alone is how teams end up rebuilding this twice. The three processors return genuinely different things.

Invoice parser returns typed, normalized entities. You get named fields such as the supplier, the invoice ID, the due date, the currency and the total, plus line items as structured children. Google has already decided what a "total" is and mapped the many ways vendors label it onto one key. Dates come back normalized. That mapping is the product.

Form Parser returns generic key-value pairs. It will find that the string "Amount Due" sits next to "$4,182.00" and hand you both halves. It does not know that "Amount Due", "Balance Due", "Total Payable" and "TOTAL" are the same field, and it will not normalize the date format. That normalization layer is now yours to write, and it is the part that never quite finishes, because every new vendor brings a new label.

So the honest framing is not "Form Parser is cheaper". It is that Form Parser is cheaper per page and moves a mapping problem onto your team. At a hundred invoices a month the price gap is a few dollars and the engineering is the whole cost. At two hundred thousand short invoices a month the gap is real money: $6,000 through Form Parser against $20,000 through Invoice parser, and at that volume you probably have someone to own the mapping.

Receipts are the worst case on this rate card

The Expense parser carries the same $0.10 per count and the same ten-page rule. Receipts are almost always one page. That puts the effective rate at $100.00 per 1,000 pages, which is the most expensive way to read a page anywhere on Google's Document AI price list, and 67 times what Enterprise Document OCR charges for the same sheet of paper.

There is no clever way around it if you need normalized receipt fields, because nothing else on the rate card produces them. What you can do is stop sending receipts you did not need to parse, and batch the ones you do. It is also worth being honest about where receipt extraction sits in the workflow: for employee spend the parsing is the easy half, and the approval, policy check and reimbursement around it are what actually take the time, which is why most finance teams end up running receipts through software that reads the receipt and files the expense in one pass rather than calling a parser directly.

Bank statements bill in a third unit again

If your workload includes statements, note that Google prices the Bank statement parser at $0.75 per classified document, not per page and not per count. It is the single most expensive unit on the Document AI rate card. Pay slip and W2 parsers use the same per-document unit at $0.30. Page count does not enter the price at all, so a two-page statement and a forty-page statement cost the same $0.75. That is the one place on this rate card where long documents are unambiguously good news.

Which processor should you actually use?

Does Google Document AI charge per page or per document?

Both, and that is the root of most Document AI budget misses. Enterprise Document OCR, Form Parser, Layout Parser, custom extractors and the custom splitter and classifier all bill per page. Invoice, Expense and Utility parsers bill per count of up to ten pages. Bank statement, pay slip, W2 and the two document splitters bill per classified document. Custom processor hosting and the provisioned service tier bill per hour. Four units on one rate card, which is why a single per-page number for Document AI is always wrong for some of it.

Is Google Invoice Parser cheaper than AWS Textract for invoices?

For a typical one-page or two-page invoice, no. Google's Invoice parser costs $0.10 a document. Textract's AnalyzeExpense, which is the equivalent operation, is $0.01 a page, so a two-page invoice is $0.02 against Google's $0.10. Textract is five times cheaper on short invoices and the gap narrows only as documents lengthen, because Textract keeps charging per page while Google's count stays flat to ten. At exactly ten pages they meet at $0.10. Our AWS Textract pricing breakdown has the full meter list if you are comparing seriously.

How do I reduce a Google Document AI invoice bill?

Four things, in order of how much they usually save. Move short invoices to Form Parser if you can own the field mapping, which is the three-to-one saving described above. Stop sending pages you will not read, since remittance stubs and terms and conditions bill exactly like the invoice itself on any per-page processor. Batch documents so they fill their ten-page counts rather than straddling them. And check what you have left deployed: a custom processor version costs $0.05 an hour to host whether or not it is called, which Google's own example puts at $438 a year, so a few forgotten test versions quietly cost more than the parsing.

Watch the page limits, not just the price

Synchronous requests do not accept documents over ten pages, which is the same boundary as the count, so anything longer has to go through the batch path regardless of what you are willing to pay. Batch requests take documents up to 200 pages. Those constraints shape architecture more than the rate card does, and we track them separately in our notes on Google Document AI limits.

Try it on your own invoices first

Every number here is arithmetic on a published rate card, and arithmetic cannot tell you whether the fields come out right on your vendors' layouts. That is the thing that decides whether any of this works, and it is cheap to check. Upload one of your real invoices to DocuOCR and look at what comes back before you commit to a processor, a mapping layer, or a bill that turns out to be measured in ten-page blocks.