Document AI services compared

A document AI service reads PDFs, scans, and images — pulling fields out of invoices, forms, contracts, and receipts — so the data can be written into a database without anyone typing. The pieces that do this break into two families.

Specialist OCR services (AWS Textract, Google Document AI, Azure Document Intelligence) are purpose-built for documents. They include features like key-value detection, table extraction, and signature detection. General-purpose vision LLMs (OpenAI Vision, Claude Vision, Gemini Vision) are the same large language models you use for chat, given the ability to see images. They handle novel layouts well; they’re less specialised for high-volume back-office work. Underneath both sits an open-weights DIY tier (Donut, LayoutLMv3, the Qwen 2.5 VL family) — software you run yourself on your own hardware.

The extract-structured-data-from-PDFs piece covers the model-level question. This piece is one layer up: when you need a service — queued processing, batch APIs, schema-aware extraction, audit logs, an SLA — how do the offerings compare, and at what volume does it become cheaper to build the DIY pipeline yourself? Each is the right answer for a specific workload. The decision rule depends on volume, document type, and how much engineering capacity you have to spend.

For under ~10,000 pages/month with mostly standard layouts — OpenAI Vision or Google Document AI. OpenAI Vision wins on flexibility (prompt-driven extraction handles novel layouts without setup); Document AI wins on accuracy for tabular and form-heavy documents. The choice often comes down to which cloud your stack already lives in.

For high-volume invoice or form processing at scale — AWS Textract or Azure Document Intelligence. The per-page pricing on specialist OCR is meaningfully cheaper than vision LLMs at volume, and the structured outputs (key-value pairs, confidence scores, signature detection) are more reliable for back-office automation. Custom adapters / templates earn their keep on your specific document types.

Over 100,000 pages/month, or for sensitive documents — DIY with Donut (or LayoutLMv3, or a fine-tuned Qwen 2.5 VL). The hardware + engineering investment pays back at this volume, the data never leaves your network, and the accuracy on your specific document types can exceed any general-purpose service after fine-tuning. Not the right answer at low volume — the ops burden dominates the savings.

For documents with novel layouts that don’t recur — OpenAI Vision or Claude Vision. The general-purpose vision LLMs handle “I have one weird PDF” better than specialist services because they don’t need a model trained for the specific layout. Cost per page is higher; setup time is zero.

The pricing comparison is asymmetric: specialist OCR services are cheaper per page at high volume; vision LLMs are cheaper to set up and more flexible at low volume. The decision often hinges on whether your documents recur (specialist wins) or vary (LLMs win).

The DIY path with Donut, LayoutLMv3, or a fine-tuned vision model is the right answer when one or more of these triggers fire:

• Very high volume. Above ~100,000 pages/month sustained, the hosted-service bill is a real line item ($1,500–$5,000/month at $15–$50/1,000 pages), and a single engineer with one A100 can match or beat that cost.
• Data sensitivity. Health records, legal documents, classified materials — the same constraints that justify a private RAG setup apply here. No vendor’s compliance posture is acceptable.
• Very specific document types. Invoices from your top three vendors that always have the same layout; forms your specific industry uses that aren’t in any general-purpose model’s training data. Fine-tuning on your own data produces accuracy ceilings the general services can’t match.
• Regulatory requirements that exclude vendor processing. Some jurisdictions and contracts simply forbid sending documents to a third-party cloud. The DIY path is the only path.

If none of these triggers fire, the hosted services are the right answer. The engineering investment of DIY is real — two engineers spending two quarters on it is not unusual — and the maintenance burden is permanent.

Textract. US-centric in language quality and document conventions. Tables in non-Latin scripts are weaker. Handwriting outside English drops accuracy noticeably.

Google Document AI. Enterprise-priced relative to AWS for similar capability; the Custom Extractor is powerful but requires more setup than the comparable Textract Adapter or Azure custom model.

OpenAI Vision. Can hallucinate. It is a general-purpose LLM with image input — when asked to extract a table with seven rows, it will sometimes return six rows or eight rows that look plausible. The fact-verification step is essential for any production use; this is not a service to trust blindly on numbers.

Azure AI Document Intelligence. Narrower set of fully-supported languages than the others (currently ~25 with full feature support, more with OCR only); breadth is improving but lags Google.

DIY pipeline. All the ops burden you’d expect — model serving, GPU monitoring, retraining cadence, eval infrastructure. Not the right tool for a small team without dedicated engineering support; perfectly fine for a larger team that has those capabilities anyway.

For the model-level question (which model handles which document type), see Extract structured data from PDFs. For the DIY pipeline architecture beyond document AI specifically, see Build a private RAG with no third-party calls. For the vector-store side of the post-extraction pipeline, see Vector databases compared.