Google Document AI or Gemini: which should read your PDFs?

The short version

• Google sells two different things under the document AI heading: Document AI processors in Google Cloud, and document understanding in the Gemini API.
• Document AI is billed by the page and Gemini by the token, so which is cheaper depends on how dense your pages are.
• Pre-trained processors cover common document types such as invoices and receipts; anything else needs a custom extractor trained on your own labelled examples.
• A Document AI extractor returns a confidence score per field, which is what lets you route doubtful extractions to a person instead of trusting them.
• Neither product decides what happens when an extraction is wrong, and that decision is most of the engineering work.

What is Google Document AI?

It is a Google Cloud service that turns a PDF or a scan into structured JSON. You create a processor inside a Google Cloud project, send it a document, and get back the text, the page layout, the position of each block on the page and, for processors that extract fields, a set of named entities with a confidence score attached to each one. It is an API, not an application. There is a console for trying processors and labelling documents, but what you ship is a call and a schema.

Processors come in three rough families. General ones read any document and return text and layout without knowing what the document is. Pre-trained specialised ones already know a document type, invoices and receipts being the familiar examples, and return named fields with no training on your side. Custom extractors are the ones you train yourself on your own labelled examples, which is what you need when your documents are not a type Google already covers.

You can call a processor synchronously for a single small document, or in batch from Cloud Storage when you have volume. You also choose a processing region when you create the processor, and the regions available depend on which processor it is, so check that in the console before promising anyone that the data stays inside a particular jurisdiction. The processor catalogue and its prices change often enough that any article about them, including this one, is a pointer to Google's own documentation rather than a substitute for it.

How is this different from sending the PDF to Gemini?

Gemini reads documents too, and for plenty of tasks it is the simpler answer. The difference is what you are buying. A Document AI processor is a fixed pipeline for a document type, with a schema, per-field confidence and a page-based price. Gemini is a general model you prompt, with no schema unless you impose one, no field-level confidence, and a token-based price.

The billing units matter more than they look. Document AI charges by the page, so a dense page and a nearly empty page cost the same. Gemini charges by the token, and Google's own document understanding documentation sets out the token accounting it bills against for PDF pages, which means you can work out a cost per page before writing any code. List prices for the Gemini Developer API are published as a price per million input tokens on the paid tier. Neither figure is the one that decides the project, because what differs between the two approaches is not the price per unit, it is how many times you reprocess a document before you get an answer you are willing to act on.

Behaviour differs as well. A processor's output shape is stable: same fields, same types, every time, with a number telling you how sure it is. A prompted model can describe a field instead of returning it, format a date three ways across a batch, or quietly omit something it could not find. You can constrain that with structured output, and you should, but you are then constraining behaviour rather than relying on a trained schema. The trade is worth it when layouts vary, because a model will make a decent attempt at a document it has never seen and a processor trained on one layout will not.

Where the two options actually differ

Which one should you pick for your documents?

Pick on the shape of your document set, not on the brand. A handful of fixed layouts and a lot of pages points to a processor: the cost is predictable, the output is a schema your downstream code can rely on, and the errors announce themselves as low confidence rather than as fluent prose. A long tail of layouts, a few hundred documents a month, or a task that needs reading comprehension rather than field extraction points to the model. The answer 'just send the PDF to the model' is right more often than vendors of document pipelines like to admit, and wrong exactly when volume and schema stability start to matter.

Plenty of working pipelines use both. Run OCR or layout parsing first so you hold the text and the coordinates, then put a model over that text for the fields that need interpretation. This split is also easier to evaluate, because you can tell a reading failure apart from an interpretation failure instead of staring at one number that went down.

The option people skip is using neither. If your documents arrive as machine-readable PDFs from the same three suppliers, a text extraction library and a set of regexes will do the job, cost nothing per page, and never invent a total. It is worth noticing that serious research comparisons still include an OCR plus regular expression floor as a baseline. If you cannot beat that floor by a margin that justifies the operational weight of a model, the floor is the answer, and saying so early saves a quarter.

Signs you want a trained processor rather than a prompt

• •The same two or three layouts account for most of your volume, and they change rarely.
• •You need the same fields, with the same names and types, on every single document.
• •You want a number per field that tells you when to send the document to a person.
• •Your page count is high enough that per-page pricing beats paying tokens for mostly blank scans.
• •Downstream systems write to a ledger, so a confidently wrong value is more expensive than a refusal.

What does it cost, and what actually drives the bill?

Not the per-page or per-token price, usually. Both are published, and you can model them in an afternoon with a representative sample of your own documents. The number to compute is not cost per page but cost per correctly extracted document, including the review of the ones that came back doubtful.

The real drivers are reprocessing and people. Schemas change, which means running history again. Suppliers change templates, which means retraining or reprompting. Low-confidence fields need somebody to look at them, and that queue has a staffing cost that grows with volume while the API cost per page stays flat. On top of that sits the engineering time to keep the pipeline alive. The US Bureau of Labor Statistics publishes a median annual wage for software developers from its May 2025 establishment survey, and whatever that figure is in your market, a fortnight of it buys a very large number of pages. The build and the upkeep, not the inference, is where document automation gets expensive.

This is also why accuracy targets should be set against a review process rather than in the abstract. A pipeline that extracts 90% of fields correctly and routes the rest to a person is cheaper to run and safer to trust than one that claims 95% and writes everything straight through, because the second one spends its error budget inside your accounts.

How much can published research tell you about your own documents?

Less than you would like, and the good studies are narrow on purpose. One 2026 preprint on templated document extraction scored micro-F1 on 750 held-out cheque images, drawn from a set of 3,748 synthetic cheques, plus a 36-field insurance form task, comparing fine-tuned open-weight vision language models against frontier models, a managed cloud service and an OCR plus regular expression floor. That is a careful experiment. Cheques are still not your documents, and a result on a templated form does not carry over to a scanned packet of mixed correspondence.

Adoption statistics have the same limit at a different scale. Eurostat's enterprise survey of AI use reached 157 000 of the 1.53 million EU enterprises with ten or more employees, which tells you how ordinary this work has become and nothing at all about whether those pipelines return the right invoice total.

What does settle the decision is a held-out set of your own documents, labelled by hand and scored field by field. A hundred real documents is enough to separate the options, and it is a day of dull work that makes every later argument cheap. The framing of that preprint is worth borrowing while you do it: accuracy is one axis, and robustness, cost and governance are the others.

What breaks once this is in production?

The documents, mostly. Photographs of screens instead of scans. A supplier who changes their invoice template without telling anyone. Three documents stapled together and scanned as one file. A table that continues across a page break, so the processor returns two tables and the totals no longer reconcile. The same invoice submitted twice in a month. Handwriting that a human reads instantly and OCR renders as something else. None of these appear in a demo, because a demo uses the clean file somebody chose.

Almost all of them are pipeline problems rather than model problems, which is why the choice between Document AI and Gemini is the smaller half of the project. You need a queue, a retry policy with a cap, somewhere to put documents the pipeline refuses, an audit trail recording what was extracted by which processor version, and a named person who looks at the refusal queue every day. Without that last one the queue silently becomes a bin.

One rule is worth fixing before launch: no extraction writes to a system of record without either a confidence threshold behind it or a human signature. Thresholds then need reviewing, because the one you set during the build reflects the documents you had then. Six months of new suppliers later it is either letting errors through or sending everything to review, and nobody notices until an audit asks.