Google Document AI vs a Custom IDP Pipeline

Short answer: use Google Document AI, AWS Textract or Azure Document Intelligence for anything their prebuilt processors already handle. They are cheap, accurate and immediately available. Build a custom pipeline when your documents are unusual, when per-page pricing at your volume outgrows the convenience, or when the data cannot leave your infrastructure.

We build document AI systems and we route a lot of clients to the managed services. Here is where the line falls.

What the managed services cost

All three publish pricing, which makes this an unusually honest comparison.

Capability	Google Document AI	AWS Textract	Azure Doc Intelligence
Plain OCR / read	$1.50 / 1k pages	$1.50 / 1k pages	$1.50 / 1k pages
Layout	—	—	$10 / 1k
Tables	—	$15 / 1k	—
Forms	$30 / 1k (Form Parser)	$50 / 1k	$10 / 1k (prebuilt)
Custom extraction	$30 / 1k	—	$30 / 1k

Basic OCR is a commodity at roughly $1.50 per 1,000 pages across all three, and you should treat it as one. The gap opens on structured extraction, where Google’s Form Parser at $30 sits well under Textract’s forms-plus-tables combination at $65–70. Google drops to $0.60 per 1,000 for plain OCR beyond 5 million pages a month; Azure’s annual volume commitments can take prebuilt models to around $0.53 per 1,000 at 8M pages monthly.

At 50,000 pages a month through a custom extractor, that is roughly $1,500 — trivial against an engineering budget. At 5 million, it is $150,000 a year and the conversation changes.

Where managed processors genuinely win

Your document is one they already support. Invoices, receipts, passports, driving licences, W-2s, common lending documents. These prebuilt processors are trained on far more data than you will ever assemble, and competing with them is a bad use of money.

You need it working this month. An API call against a prebuilt processor is days of work. A custom pipeline is weeks.

Volume is low or spiky. Per-page pricing with no floor is genuinely good when volume is unpredictable. You are not paying for idle GPUs.

You have no ML capacity. A managed processor needs an engineer, not an ML team, and it does not degrade when nobody is watching it.

If you are in these situations and someone is proposing a custom build, ask them to justify it against a $1,500 monthly bill.

Where they stop

Documents nobody has a processor for. Industry-specific forms, internal paperwork, regional documents outside the major markets, anything with a layout that is yours. Custom extractors help, but you are now training and maintaining a model inside someone else’s framework, with their iteration loop and their constraints.

Validation and business logic. This is the big one and it is consistently underestimated. The managed service returns fields. It does not know that the invoice total must equal the sum of the line items, that this supplier’s dates are DD/MM, that an amount over a threshold needs a second approval, or that a checksum on a document number failed. That logic is yours regardless, and it is where the real accuracy comes from — a confidently extracted value that fails arithmetic is wrong no matter how certain the model was.

Confidence handling you can route on. The APIs return confidence scores. Turning those into calibrated thresholds tuned to your actual error costs, at field level rather than document level, with an exception lane a reviewer can work through quickly, is a system you build. We covered that in intelligent document automation.

Data residency. If documents cannot leave your boundary or your jurisdiction, the managed options are eliminated before pricing is discussed. This is a constraint, not a preference.

Preprocessing on bad inputs. Phone photographs — increasingly the default input — are dominated by skew, glare, low resolution and cropping problems. Deskewing, denoising and contrast normalisation recover more accuracy on real-world documents than any model swap, and you control that layer regardless of who does the recognition.

The architecture most projects should use

The choice is not binary, and treating it as one is the common error.

Use the managed API as the recognition layer. Build everything else — classification routing, validation, confidence calibration, the exception interface, and the downstream integration that actually completes the work. You get commodity accuracy on the hard ML problem and full control over the logic that makes it a system.

This also keeps you portable. If Google’s pricing changes or Azure’s prebuilt invoice model outperforms on your documents, swapping the recognition layer is a contained change rather than a rewrite. Wrap the vendor call behind your own interface from the first commit and that option stays open.

What actually decides the number

Not the model, and not the vendor. Straight-through processing rate — the fraction of documents completing the entire loop with no human touching them — is the metric that maps to labour removed. A pipeline at 97% field accuracy that routes everything to review has saved nothing.

That number is driven by validation quality, threshold calibration and exception design far more than by which vendor recognised the characters. Which is precisely why the recognition layer is the part to buy.

The takeaway

Buy recognition, build judgement. Managed document AI is cheap, accurate and the right default for supported document types at moderate volume. The engineering that earns its cost sits either side of it: preprocessing on the way in, and validation, confidence routing and integration on the way out.

Sources

EpochC builds intelligent document processing and OCR, KYC and identity verification, and the workflow automation that turns extracted data into completed work. See the KYC OCR automation case study — EUR 40,000 a year removed — or start a project.

Google Document AI vs a custom IDP pipeline: how to choose