Before learning the tool, it helps to understand the problem it was built to solve.

Documents carry meaning in their shape

A database table is easy for a computer: every column has a name and every row follows the same pattern. A document is the opposite. A scanned invoice stores its meaning in position, size, boldness, tables, logos, stamps, and handwriting. The number “1,533.14” means nothing by itself. It becomes a “total amount” because it sits at the bottom right, next to the word “Total”, under a column of smaller numbers. Humans read that layout without thinking. Computers must be taught to do it.

Businesses across the world still depend on documents to store and convey information, and that information has to be digitized before it becomes useful. Typical examples include medical intake forms at a clinic, receipts for expense validation, identity cards for authentication, tax forms for loan approvals, and contracts that hide key business terms inside long paragraphs. Each of these workflows has the same two steps: get the raw text out, then pick out the specific pieces of data, called fields or entities, that the business actually needs.

Why old approaches break

Early automation relied on templates: draw a box at exact coordinates and read whatever falls inside. This works only while every document looks identical. The moment a vendor changes its invoice design, moves a logo, or adds a line item, the template reads garbage. Rule-based systems and plain OCR (optical character recognition, the technology that turns pictures of text into characters) share the same weakness. They see characters but not structure, and they have no sense of meaning.

Document AI is a document processing and understanding platform that converts unstructured documents into structured data.

The one-sentence definition

Document AI takes unstructured content such as scans, PDFs, and images, and transforms it into structured data: specific fields that fit naturally into a database. It is built on top of products within Vertex AI, with generative AI added so that teams can build scalable, end-to-end, cloud-based document applications without specialist machine learning knowledge.

What you can do with it

The platform groups its abilities into a few clear verbs. Each one maps to one or more processor types that you will meet in the coming chapters.

Where it fits in Google Cloud

Document AI does not live alone. It reads files from Cloud Storage, writes structured results back to Cloud Storage or into BigQuery, and can feed Vertex AI Search or generative AI applications with clean, well-chunked content. Workflows, Pub/Sub, Cloud Run, and Cloud Functions commonly glue the pieces into an automated pipeline. You can think of Document AI as the reading-and-understanding brain, and the rest of Google Cloud as the arms, legs, and filing cabinets.

Six words explain almost every Document AI conversation: processor, version, document, entity, schema, and dataset.

Processor: your project’s private reader

Each Google Cloud project creates its own processor instances. When you create one, Document AI gives you a prediction endpoint, which is simply an address you can send documents to. You choose the processor type based on the job: digitizing, extracting, classifying, or splitting. The processor then applies a version of a model to every file you send.

The Document object: the single most important output

Whatever processor you use, the response is a Document. It stores the full recognized text, the page-by-page layout, detected blocks, paragraphs, lines, and tokens, and the entities that were extracted. Every entity points back to the text span and the position on the page where it was found, which makes verification and visual highlighting possible. Because the shape of the Document is consistent across processors, downstream code can be written once and reused.

Confidence: the machine admitting uncertainty

Entities usually arrive with a confidence value between zero and one. High means the model is quite sure, low means a human should probably look. Smart pipelines use this number as a traffic light rather than ignoring it: green results flow straight to the database, amber results go to review, and red results are rejected or retried.

A bird’s-eye view of how the pieces connect, from the upload bucket to the analytics warehouse.

The three layers

It is useful to think of a Document AI solution as three layers. The ingestion layer collects files and decides when to process them. The intelligence layer is Document AI itself, with its processors and model versions. The consumption layer takes structured output and puts it to work in databases, search, dashboards, and business applications. Keeping these layers separate lets you change one without breaking the others.

flowchart LR
  A["Document sources: scanners, email, apps"] --> B["Cloud Storage landing bucket"]
  B --> C["Orchestrator: Workflows or Cloud Run"]
  C --> D["Document AI processor"]
  D --> E["Document JSON output"]
  E --> F["BigQuery tables"]
  E --> G["Vertex AI Search or RAG store"]
  E --> H["Review queue for low confidence"]
  H --> F
        

Components at a glance

Online versus batch processing

Document AI offers two request styles. Online processing sends one document and waits for the answer in the same call. It is best for interactive applications such as a user uploading a receipt on a phone. Batch processing submits many documents at once, runs asynchronously as a long-running operation, and writes results to Cloud Storage. It is best for backlogs, nightly jobs, and archive digitization.

Every document journey starts by turning pixels into text and layout.

What Enterprise Document OCR does

Enterprise Document OCR detects and extracts text and layout information from many kinds of documents. Beyond raw characters, it returns the structure of the page: blocks, paragraphs, lines, words, and where each of them sits. It supports configurable features so you can tailor the output to your needs, including image quality analysis that scores how readable a scan is, and automatic deskewing that straightens tilted pages.

All Document AI processors can extract text and layout, so OCR is both a standalone product and the foundation under every other processor. Use it on its own when you only need searchable text, for example to make an archive of scanned books searchable, or to prepare high-quality text for training machine learning models.

Useful add-ons

Quality gates: stopping bad scans early

A powerful pattern is to run image quality analysis first, then route the file. A sharp scan continues to extraction. A poor scan is returned to the sender with a request for a better copy. This tiny gate often removes the largest source of downstream errors, because no model can reliably read what a human cannot read either.

When you do not know the fields in advance, the Form Parser finds the structure for you.

What it finds without being told

The Form Parser extracts key-value pairs, tables, selection marks such as checkboxes, and generic fields. A key-value pair is simply a label and its answer, like “Name: Jill Smith”. Crucially, you do not define a schema. The model scans each page and returns the entities it considers interesting. Out of the box it can extract up to eleven generic entity types in addition to checkboxes.

When to choose it

Choose the Form Parser for structured forms and regular tables when you want quick exploration, when the document types vary widely, or when you simply need all the pairs and tables from a page. It is also an excellent first step when you are still discovering what fields your business cares about.

Define exactly the fields your business needs and let a generative foundation model find them.

The idea

The custom extractor lets you define a schema of entities and then returns precisely those entities from your documents. It is powered by generative AI, which means it can produce accurate results out of the box on a wide range of documents, even with little or no labeled training data. It offers three modeling options, and choosing the right one is one of the most important design decisions in a project.

How much data each option needs

Zero-shot, few-shot, and fine-tuned

The foundation model approach has a lovely progression. With no examples it performs zero-shot extraction based on your schema alone. With up to about five labeled documents it can do few-shot prediction, learning from those examples inside the request. With more than about ten labeled documents it can be fine-tuned, producing a customized version tailored to your documents. Because foundation models typically need fewer training documents, they are recommended as the first option for all variable layouts.

Newer helpers for defining the schema

Recent releases have made the schema step much easier. Document-level prompting lets you give an overall description of the document, injecting business knowledge so the model understands context, such as “this is a freight bill where the consignee appears in the second box.” There is also a feature that proposes a schema from a sample document, which you can approve, decline, or edit manually. This saves time and lets you focus on refining the fields instead of inventing them from scratch.

Generative AI answers are only as good as the chunks of text you feed them.

From pages to meaningful pieces

The Layout Parser transforms documents in various formats into structured representations. It makes paragraphs, tables, lists, headings, page headers, and footers accessible as separate elements. Just as importantly, it creates context-aware chunks: pieces of text split along natural boundaries such as sections, rather than cut blindly every fixed number of characters. These chunks are designed to improve information retrieval in generative AI and discovery applications.

Support has grown beyond PDFs and images. Layout parsing for Word, PowerPoint, and Excel family files reached general availability in late 2025, and a Gemini-based layout parser appeared in preview around the same time. Because release status changes quickly, check the current release notes before you commit to a specific variant in a production design.

Why chunking quality matters for RAG

Retrieval-augmented generation, usually shortened to RAG, works by finding relevant text pieces and handing them to a language model as evidence. If a chunk splits a table in half or separates a heading from its paragraph, the model sees confusing fragments and answers poorly. Chunks that carry their heading context and keep tables intact make retrieval more precise and answers more trustworthy.

flowchart TD
  A["Source files: PDF, DOCX, PPTX, XLSX"] --> B["Layout Parser"]
  B --> C["Structure: headings, tables, lists"]
  B --> D["Context-aware chunks"]
  D --> E["Embeddings and index"]
  E --> F["Retrieval for a question"]
  F --> G["Generative model answers with evidence"]
        

Before you can extract the right fields, you must know what kind of document you hold.

Custom classifier

A custom classifier is trained to decide the document type from a set of classes you define, such as invoice, purchase order, bank statement, or identity card. Its answer becomes a routing signal. Invoices go to the invoice extractor, identity cards go to the identity workflow, and unknown documents go to a human. The generative aspect of the product supports few-shot learning and fine-tuning, which means you can reach useful accuracy with fewer samples and improve it through iterative auto-labeling.

Custom splitter

A custom splitter handles composite documents, meaning a single file made of several logical documents. A mortgage package is the classic example: it can contain an application, income verification, bank statements, tax forms, and photo identification, all scanned into one long PDF. The splitter identifies where each logical document begins and ends, and labels each piece with its class. It can be used out of the box or trained from the ground up on your own documents and classes.

flowchart LR
  A["Composite PDF"] --> B["Custom Splitter"]
  B --> C["Pages 1-2: payslip"]
  B --> D["Page 3: bank statement"]
  B --> E["Pages 4-6: tax form"]
  C --> F["Payslip extractor"]
  D --> G["Statement extractor"]
  E --> H["Tax form extractor"]
        

Splitter versus classifier: which to pick

For very common document families, Google ships processors that already know the fields.

Ready-made knowledge

Beyond the general processors, Document AI offers specialized parsers for frequent business documents such as invoices, expense receipts, and identity documents, as well as families aimed at lending and procurement. These processors arrive with fields already defined: for an invoice, that includes supplier details, invoice number, due date, line items, tax amounts, and totals. You get value on day one without labeling a single document.

The specialized processors also support uptraining. Uptraining means taking a pretrained processor and giving it extra labeled examples from your own documents, creating a new version that handles your particular formats better while keeping the pretrained knowledge. Because the catalogue of processors and their available regions changes over time, treat the official processor list as the source of truth when planning.

Workbench is the part of the console where you build, label, train, and measure custom processors.

The workflow in plain steps

Whether you are building a custom extractor, classifier, or splitter, or uptraining a specialized parser, the journey follows the same shape. You create a processor, create a dataset that points to Cloud Storage, define a schema of labels or classes, import documents, label them, split them into training and test sets, train a new version, evaluate it, and finally deploy it. Each step exists for a reason, and skipping any of them usually shows up later as mysterious accuracy problems.

Reading the evaluation numbers

Three measures appear again and again. Precision answers “of the values the model returned, how many were right?” Recall answers “of the values that really existed, how many did the model find?” The F1 score blends both into a single number. A field with high precision but low recall is cautious and misses things. A field with high recall but low precision is eager and invents things. Which is worse depends on the business: missing an invoice due date delays payment, but inventing a bank account number is dangerous.

Minimum data rules to remember

Uptraining a specialized processor requires a minimum of ten documents in both the training set and the test set, with ten instances of each label in each set. Custom extractor fine-tuning on a foundation model starts to become possible once you have roughly ten labeled documents. These are floors, not targets: more varied examples almost always yield a steadier model, especially when the real-world layout variety is high.

A processor is a stable address, but the model behind it keeps changing. Managing that change is a core engineering skill.

Two families of versions

Processor versions fall into two categories. Google-provided versions include stable releases and release candidates, which preview upcoming improvements. Customized versions are those you create through training on your own documents, and each has a type that describes the kind of model used for predictions. Every request uses one of these versions, selected through a default setting or by naming a version explicitly.

Why deprecation matters

Document AI is powered by generative AI, so newer versions use newer foundation models. As foundation models improve, older ones are retired. Earlier stable versions are deprecated roughly six months after the newest stable version is released. Customized versions that depend on an older base version stop returning predictions when that base version is deprecated, which is a surprising failure for teams that forgot about it. Google also announced that a set of legacy processors would be discontinued on June 30, 2026, advising teams to migrate to later versions to avoid service failures.

flowchart LR
  A["New stable version released"] --> B["Test on held-out set"]
  B --> C{"Better on key fields?"}
  C -->|Yes| D["Canary: small traffic share"]
  C -->|No| E["Stay on current version"]
  D --> F["Promote to default"]
  F --> G["Old version deprecated after about six months"]
        

A calendar of responsibilities

What actually happens between sending a file and receiving structured data.

The lifecycle of one request

When a document reaches a processor, several stages run in sequence. First comes preparation: the file is validated, its pages are separated, and images are normalized. Next comes optical recognition and layout analysis, which produces text and positional structure. Then the selected model, whether pretrained, foundation based, or custom, interprets that content to produce entities, tables, or classes. Finally the results are assembled into a Document object, with each value tied to its text location and a confidence score, and returned to the caller or written to storage.

sequenceDiagram
  participant App as Your application
  participant API as Document AI API
  participant OCR as Recognition and layout
  participant Model as Selected model version
  App->>API: Send document to processor
  API->>OCR: Validate pages and read text
  OCR-->>API: Text, layout, positions
  API->>Model: Interpret content with schema
  Model-->>API: Entities, tables, classes, confidence
  API-->>App: Document object
        

What the output contains

Normalization: clean values, not just raw text

Entities are often normalized. A date written in many styles can come back as one standard format, and a currency amount can come back with a separate number and currency. This saves you from writing a mountain of parsing rules and makes database loading much safer. Still, you should validate business rules yourself, such as whether the line items add up to the total.

Quotas, pages, and limits

Each processor type has limits on page counts per request, file sizes, and request rates. Large files are better sent through batch processing, and very large documents can be split into smaller ranges. Capacity reservation is available in preview for teams that need a steady high-volume flow of real-time requests. Because limits are updated from time to time, read the current quotas page before sizing a design.

Putting the processors together into a dependable, automated flow with a safety net for humans.

The reference flow

A strong production pipeline has six stages. Documents land in a Cloud Storage bucket. An event triggers an orchestrator, such as a workflow or a small service. A quality gate checks readability. A classifier or splitter identifies document types. The matching extractor produces entities. Finally, a validation step decides whether results are saved automatically or sent to a person.

flowchart TD
  A["Upload to landing bucket"] --> B["Event triggers orchestrator"]
  B --> C["Quality check with OCR add-on"]
  C -->|Readable| D["Split and classify"]
  C -->|Unreadable| R["Request a better copy"]
  D --> E["Route to matching extractor"]
  E --> F["Validate business rules"]
  F -->|High confidence| G["Write to BigQuery"]
  F -->|Low confidence| H["Human review queue"]
  H --> G
  H --> I["Add corrected files to training dataset"]
        

The human-in-the-loop question

Earlier, Document AI included a managed human-in-the-loop review service, along with a document warehouse product. Both were deprecated in January 2024, with shutdown scheduled for January 2025. Teams that relied on them now build review steps themselves, commonly with a small web application, a ticketing tool, or an existing back-office screen, using the confidence scores and text anchors from the Document object to show reviewers exactly what to check.

Orchestration choices

Where BigQuery and search fit

Structured entities belong in BigQuery tables, where analysts can query totals, find anomalies, and build dashboards. Chunked text from the Layout Parser belongs in a retrieval store for search and generative applications. Keeping both from the same source document gives you rich analytics and rich question answering from one ingestion pass.

Documents are often the most sensitive data a company owns, so protection must be designed in from the start.

The security layers

Documents such as identity cards, payslips, medical forms, and contracts contain personal and confidential details. A responsible design protects them at every stage: who may call the service, where the files are stored, how they are encrypted, where they are processed, and how long they are kept.

Least privilege in practice

The component that uploads files should not be able to read all outputs. The component that calls the processor should not be able to delete the archive. The reviewer application should see only the documents assigned to a reviewer. Separate service accounts per role make these boundaries real and make audit trails meaningful.

Handling personal data responsibly

Some fields, such as national identifiers or bank details, deserve extra care. Consider masking them in dashboards, restricting who can query the raw columns, and storing only what the business truly needs. Check Google’s data processing terms and your own legal requirements to confirm how data may be used, retained, and shared, and involve your compliance team early rather than late.

A pipeline you cannot observe is a pipeline you cannot trust.

What to measure

Operational health and business quality are two different dashboards. Operational health covers request counts, error rates, latency, queue depth, and retry counts. Business quality covers how often results pass validation, the share sent to human review, the correction rate per field, and drift in confidence scores over time. A sudden rise in the review rate often signals that a vendor changed its layout or that a new document type has appeared.

Understanding the cost model

Cost is based on the number of pages processed each month, the relevant quota, and any purchased capacity reservation. Prices differ by processor type. At the time of writing, published list prices showed Enterprise Document OCR at a low per-thousand-page rate, OCR add-ons at a modest additional rate, the Layout Parser at a mid rate that includes initial chunking, the custom classifier at a low rate, and the custom extractor and Form Parser at higher rates, with a summarizer priced in between. Volume tiers and regional differences apply, so always confirm numbers on the official pricing page and in the pricing calculator.

Practical ways to reduce cost

Proven shapes that keep document systems simple, and tempting shortcuts that cause pain later.

Patterns that work

flowchart LR
  A["Production traffic"] --> B["Champion version"]
  A --> C["Challenger version in shadow"]
  B --> D["Results used by business"]
  C --> E["Results compared offline"]
  E --> F{"Challenger better?"}
  F -->|Yes| G["Promote challenger"]
  F -->|No| H["Keep champion"]
        

Anti-patterns to avoid

A checklist distilled from the earlier chapters, written as habits rather than rules.

Choosing the right processor quickly

The same building blocks, assembled differently for different industries.

Short answers to the questions beginners and architects ask most often.

No. OCR is one capability, and it sits underneath everything. Document AI also understands layout, finds key-value pairs and tables, extracts business-defined entities, classifies documents, splits composite files, and prepares chunks for generative AI applications.

Not to start. Pretrained processors and foundation-based extractors work with little or no training data. Experience helps when you evaluate results, design labeling, and tune thresholds, but the console guides most of the work.

Use the Form Parser when you want generic pairs, tables, and checkboxes without defining fields. Use a custom extractor when you need specific named fields with your own meaning and consistent output across varied documents.

It depends on the option. Foundation models can work with none, improve with about five examples in the request, and can be fine-tuned from around ten labeled documents. Custom models usually want tens to a hundred or more, and templates need only a few. Uptraining needs at least ten documents in each of the training and test sets, with ten instances per label.

Customized versions that depend on a retired base version stop returning predictions. That is why you should track deprecation notices and retrain on a newer base before the deadline.

The managed human-in-the-loop service was deprecated in January 2024 and scheduled for shutdown in January 2025. Teams now create their own review step, using confidence scores and text positions from the Document output.

The Layout Parser added general availability support for those Office-family file types in late 2025. Always confirm the current list of supported formats for the specific processor you plan to use.

Use online processing for single documents where a person is waiting. Use batch processing for large volumes, nightly jobs, and archives, where throughput matters more than instant answers.

Match the processor to the need, filter out junk pages, gate unreadable files, avoid duplicate processing, set billing alerts, and review the pricing calculator regularly, since prices and tiers can change.

Document AI processors adhere to Google Cloud’s data processing and security terms, and you control access through IAM, encryption options, regions, and perimeters. Your own design choices around permissions, retention, and masking decide how safe the whole solution is.

Choose the region that satisfies your legal and contractual rules and offers the processors you need. Features vary by region, so check availability before committing.

Understanding what the foundation models add, and where their limits are, prevents both disappointment and overconfidence.

What changed when generative models arrived

Traditional extraction models were trained for one narrow job. A model trained on invoices understood invoices and little else. Foundation models are trained on enormous amounts of text and layout, so they bring broad reading ability before you show them a single example of your own. That is why a custom extractor can produce useful results with only a schema, and why a handful of labeled documents can lift accuracy sharply. The model already understands what a “party”, a “renewal date”, or a “total” usually looks like, and your schema simply tells it which concepts matter to you.

This shift changes project planning. Previously a team spent weeks labeling hundreds of documents before seeing any result. Now the first working version can exist within hours, and labeling effort is spent on improvement rather than on getting started. The project becomes an evaluation exercise: measure, find the weak fields, add targeted examples, measure again.

Prompting at the document level

Document-level prompting lets you add an overall description of the document to a custom processor. You can explain what the document is, who produced it, and any business rules that help interpretation. For example, you might state that in this bill of lading the shipper appears in the top-left box and the consignee in the top-right, or that amounts are always in a particular currency. This injects deep business knowledge that the model cannot guess from the page alone.

Field descriptions work the same way at a smaller scale. A field named “date” is ambiguous, because a document might hold an issue date, a due date, and a delivery date. A field named “payment due date” with a one-line description removes the ambiguity. Good descriptions are often the cheapest accuracy improvement available.

The summarizer and other generative helpers

Document AI also offers a summarizer processor that produces short summaries of long documents, which is handy for triage, search results, and reviewer screens. A reviewer who sees a three-sentence summary next to the extracted fields can decide far faster than one who reads twenty pages. As with all generated text, summaries should be treated as a convenience for people, not as a legal record.

The schema is the contract between your business and the model. A weak contract produces weak results.

Fields, parents, and repeating items

A simple schema is a flat list: supplier name, invoice number, total. Real documents are more structured. An invoice has many line items, and each line item has its own description, quantity, unit price, and amount. A good schema represents this with a parent field that can repeat and child fields that describe each part. This keeps related values together, so the quantity of one line is never confused with the price of another.

Think of the schema as the column design of the database table you will eventually fill. If your database has a table for invoices and another for invoice lines, your schema should mirror that shape. Aligning the two removes a whole layer of messy transformation code later.

Data types and normalization

Each field can carry a type, such as text, date, money, number, or address. Typed fields allow the processor to return normalized values: dates in one standard shape, money with a separate amount and currency, and numbers without thousands separators. Choosing the right type for each field gives you cleaner data for free and makes validation simpler.

Evolving the schema over time

Business needs change. A new regulation adds a field, or a department stops using one. Each schema change affects labeled data and trained versions. Plan for this by versioning your schema along with your processor, recording which version of the schema each labeled document followed, and retraining or re-evaluating after meaningful changes. Treat schema edits like database migrations, not like casual text edits.

Real inboxes are full of the documents that demos never show.

Tables

Tables are where many extraction projects stumble. Tables may span pages, have merged cells, omit gridlines, or change column order between vendors. The Form Parser and Layout Parser both reconstruct tables, and custom extractors can return line items as repeating entities. For multi-page tables, test early with realistic long documents, because a model that handles a one-page table perfectly may behave differently when a table continues on the next page with a repeated header.

Handwriting and stamps

Handwriting recognition is available through the OCR capabilities, but accuracy depends strongly on legibility. Neat block letters usually read well. Fast cursive, overlapping stamps, and signatures over text read poorly. Design your process so that handwritten critical fields, such as amounts written by hand on a cheque or a form, are always confirmed by a person or compared with a printed field.

Languages and scripts

Enterprise Document OCR supports many languages and scripts, and you can pass hints about the expected languages to improve recognition. If your documents mix languages, such as an invoice with English labels and local-language addresses, test that mix specifically. Evaluate each language you support separately, because an overall accuracy number can hide poor performance on a smaller language group.

Photos, skew, and low quality

Photographs taken on phones add perspective distortion, glare, shadows, and blur. Deskewing and image quality analysis help, but they cannot invent detail that was never captured. In customer-facing apps, guide users to take a good picture: show a frame overlay, warn when the image is dark, and let them retake it immediately. Fixing the problem at capture is far cheaper than fixing it after upload.

You cannot improve what you do not measure, and you cannot measure with a poor test set.

Building a trustworthy test set

A test set is a collection of labeled documents the model never saw during training. To be trustworthy it must reflect production: the same mix of vendors, languages, quality levels, and document lengths. If ninety percent of real invoices come from five vendors, the test set should show that skew, but should also contain a deliberate sample of rare cases so that weaknesses are not hidden. Review the test labels with extra care, because every labeling error in the test set becomes a false accusation against the model.

Choosing the right metrics

Precision, recall, and F1 per field are the foundation, but business metrics matter more. Ask what share of documents can pass through with no human touch, how many corrections reviewers make per hundred documents, and how long a document takes from upload to usable data. A model with slightly lower F1 but better confidence calibration may deliver more automation, because its uncertain cases are easier to identify.

Detecting drift

Drift means the real world has moved away from the data your model learned. A supplier redesigns its invoice, a new product line adds unusual line items, or a customer segment starts uploading phone photos. Drift rarely announces itself. It shows up as a slow rise in review rates, a drop in average confidence, or an increase in reviewer corrections on one field.

flowchart LR
  A["Production documents"] --> B["Extraction results"]
  B --> C["Confidence and validation metrics"]
  C --> D{"Drift signal?"}
  D -->|No| A
  D -->|Yes| E["Sample failing documents"]
  E --> F["Label and add to dataset"]
  F --> G["Train new version"]
  G --> H["Evaluate on frozen test set"]
  H --> A
        

Extraction is only the middle of the story. Value appears when results reach analysts, search users, and assistants.

BigQuery for structured analytics

Document AI integrates with BigQuery so that metadata and extracted entities can be stored in tables and queried with standard analytics tools. A common design keeps one table for documents, with identifiers, types, processing time, and processor version, and one or more tables for extracted entities, linked by the document identifier. Recording the processor version beside every row makes it easy to compare accuracy between versions and to find all documents affected by a bad release.

Vertex AI Search and retrieval

For question answering and discovery, chunks from the Layout Parser can be indexed in a retrieval service, including Vertex AI Search, so assistants can find relevant passages. Each chunk should carry metadata such as source file, page range, section heading, and document type. This metadata enables filters, for example “search only contracts signed after a certain date”, and allows the assistant to cite its sources.

Combining both for richer answers

Strong assistants use both stores. A question such as “Which supplier contracts renew this quarter, and what do their termination clauses say?” needs structured dates from the entity tables and clause text from the retrieval index. Designing the pipeline so that both outputs share a document identifier makes this joining natural.

flowchart TD
  A["Source documents"] --> B["Custom extractor"]
  A --> C["Layout Parser"]
  B --> D["BigQuery entity tables"]
  C --> E["Chunk index with metadata"]
  F["User question"] --> G["Assistant"]
  G --> D
  G --> E
  D --> H["Precise values and dates"]
  E --> I["Relevant passages with citations"]
  H --> J["Grounded answer"]
  I --> J
        

A prototype that works on ten files must still work on ten million.

Sizing for volume

Start with the numbers that drive design: documents per day, pages per document, peak arrival rate, and acceptable delay. A steady stream of mixed documents suits an event-driven design, while a nightly flood of scanned archives suits batch jobs. Compare your peak rate with the processor’s request quotas and request increases ahead of launch, since quota changes take time. For steady high-volume real-time traffic, the capacity reservation feature in preview is designed to grant dedicated capacity to selected processors.

Handling failure gracefully

Failures are normal at scale: a file is corrupt, a request times out, a quota is briefly exceeded, or a downstream database is unavailable. The pipeline should classify each failure and react appropriately. Temporary problems deserve retries with increasing delays. Permanent problems, such as an unreadable or password-protected file, deserve a clear rejection and a note to the sender. Unknown problems go to a holding area, usually called a dead-letter queue, where engineers can inspect them without blocking the rest of the work.

Idempotency and ordering

Cloud events may arrive twice or out of order. Design every step so that repeating it is harmless. Use a stable identifier derived from the file, check whether results already exist before writing, and use transactions or unique keys in the database to prevent duplicates. Do not assume documents will be processed in the order they were uploaded.

Resilience across regions

Processors are regional, and features vary by location. If your business requires high availability, consider creating equivalent processors in a second permitted region and routing traffic there during an outage, while remembering that custom versions must be trained or imported for each processor. Rehearse the failover rather than assuming it works.

flowchart TD
  A["Incoming event"] --> B["Check if already processed"]
  B -->|Yes| C["Skip safely"]
  B -->|No| D["Call processor"]
  D -->|Success| E["Write results with unique key"]
  D -->|Temporary error| F["Retry with delay"]
  F --> D
  D -->|Permanent error| G["Reject and notify sender"]
  D -->|Unknown error| H["Dead-letter queue and alert"]
        

Technology succeeds when the organization around it is ready.

A phased rollout

Large document projects fail when they try to automate everything at once. A safer path starts narrow, proves value, and widens gradually. Begin with one document type that has clear volume, a measurable cost, and a motivated business owner. Prove accuracy and savings there, then add types one at a time, reusing the shared pipeline, monitoring, and review tools.

Who does what

When results disappoint, a calm, ordered investigation beats guessing.

Start with the input, then the processor, then the schema

Most accuracy problems come from one of three places. The input may be poor: blurry, skewed, cropped, or password protected. The processor choice may be wrong: a general parser used where a specialized or custom one is needed, or a template model used on varying layouts. The schema or labels may be unclear: ambiguous names, inconsistent labeling, or missing descriptions. Checking these in order resolves most issues quickly.

A calm debugging routine

Every team eventually asks whether to build its own document models, use a managed service, or mix the two.

Three honest options

The first option is to build everything yourself, training models, running recognition engines, and maintaining infrastructure. This offers maximum control and the heaviest responsibility. The second option is to use a managed document platform such as Document AI, where Google operates the recognition, the foundation models, and the scaling, and you configure schemas, datasets, and pipelines. The third option is a combination: use the managed platform for the heavy reading and understanding, and add your own business logic, validation rules, and review tools around it.

For the vast majority of organizations the combined approach wins. Reading documents at high quality is a specialized, fast-moving field, and keeping up with it internally is expensive. The unique value of your business lives in the rules, validations, and workflows around the extracted data, and that is where your engineering effort pays off.

Questions that guide the decision

Avoiding lock-in thoughtfully

Some teams worry about depending on one platform. A practical defense is to keep your own storage of original files and structured results, to keep business rules outside the processor configuration, and to use a clean internal interface between your pipeline and the extraction step. If you ever need to swap a component, only that interface changes while your data and rules remain intact.

When software reads documents that affect money, health, or legal rights, accuracy is also an ethical matter.

Why oversight matters

Documents decide real outcomes: whether a loan is approved, a claim is paid, a patient is registered, or a contract is enforced. Automated extraction speeds these decisions, but errors can harm people, and errors are not spread evenly. Poor scans, unusual names, uncommon languages, and non-standard formats often produce more mistakes, which can mean that some customers are treated worse than others without anyone intending it.

Responsible design therefore measures accuracy across groups of documents, not only overall, and gives people a way to correct mistakes that affect them. It also separates extraction, which reads facts, from decisions, which apply policy. A model that reads a salary figure is not deciding whether to grant a loan, and the pipeline should keep those steps visible and auditable.

Practical safeguards

Privacy by design

Collect only the fields you need, retain documents only as long as policy and law require, mask sensitive values in screens and reports, and restrict who can see raw files. Data minimization is both a privacy principle and a cost saver, because every field you never extract is a field you never need to label, secure, or explain.

A compact reference of terms used throughout this tutorial, handy for review and for explaining concepts to teammates.

One-page decision summary

Document AI turns the slow, error-prone work of reading paperwork into a repeatable, measurable pipeline. It digitizes with OCR, extracts with form, specialized, and custom processors, prepares retrieval-ready chunks with the Layout Parser, and sorts packets with classifiers and splitters. Its strength comes from combining pretrained knowledge and generative foundation models with your own labeled examples, then wrapping everything in quality gates, validation, human review, strong security, and careful version management. Teams that treat it as a living system, with evaluation, monitoring, drift detection, and planned upgrades, get lasting value rather than a one-time demo.