Start with the big picture: what the service does and why people use it.

A document, in this guide, means any page-based file that people read: a scanned paper, a photograph of a receipt, a PDF, or a multi-page contract. Computers see a scanned page only as a picture, which is a grid of colored dots. They cannot tell that one group of dots says “Total: 1,250.00”. To use the information, the computer must first recognize the characters and then understand what they mean.

Document AI is a managed Google Cloud service that does both jobs. “Managed” means Google runs the machines, trains the base models and handles the scaling. You send in documents, and you receive structured results, such as “invoice number: INV-2041”, “due date: 15 December” and a table of line items. This turns the unstructured world of pages into the structured world of databases.

The service works through processors. A processor is a ready-to-use or trainable reader that is specialized for a certain kind of job. One processor is great at plain text recognition. Another understands invoices. Another can be trained to read your company’s own special forms. You pick the processor that matches your document, send your files to it, and read the answers.

What Document AI can do

• Read text from printed and handwritten pages, in many languages, using optical character recognition.
• Understand layout, such as headings, paragraphs, tables and lists.
• Extract fields such as names, dates, amounts and addresses.
• Understand special documents such as invoices, receipts, bank statements and identity documents with pretrained models.
• Classify and split documents, for example telling an invoice from a contract, or separating a long scan into individual documents.
• Learn your own documents through custom processors that you train or guide.

Every good tool begins with a pain. Here are the pains of paper and PDFs.

Pain 1: Manual data entry is slow and costly

A person typing invoice details into an accounting system may handle only a few dozen documents an hour. A large company may receive many thousands each day. The work needs many people, and those people could be doing more valuable tasks.

Pain 2: Humans make small mistakes

Typing “1,250.00” as “12,500.00” or swapping two digits in a bank account number is easy when you are tired. Such errors can cause wrong payments, angry customers and costly cleanup work.

Pain 3: Information is trapped

A scanned PDF looks like a document to a person, but to a computer it is just an image. You cannot search it, sort it or add up the amounts. Years of valuable information sit locked in file cabinets and storage folders.

Pain 4: Documents come in countless shapes

Every supplier designs their invoices differently. One puts the total at the bottom right, another at the top. Older software that relied on fixed positions, such as “the total is always at this spot”, breaks the moment a new layout arrives. A modern reader must understand meaning and context, not just coordinates.

Pain 5: Slow processing hurts business

When invoices wait days to be keyed in, suppliers get paid late and early-payment discounts are missed. When loan applications take weeks to process, customers walk away. Faster reading leads to faster decisions.

Pain 6: Compliance and audit demands

Regulated businesses must prove that they checked identity documents, verified income or archived records correctly. Automatic extraction creates consistent, searchable records that are easier to audit.

Eight ideas explain most of what you will meet in the console and the documentation.

Handy words

See the whole family of processors and how your application sits around them.

Document AI is a set of related readers that all work in the same way. You create a processor, send documents to it and receive a structured response. The difference is what each processor knows. Processors fall into a few families.

flowchart TB
  Docs["Your Documents - PDFs, Scans, Photos"] --> DAI["Document AI Service"]
  DAI --> G["General Processors"]
  DAI --> SP["Specialized Processors"]
  DAI --> CU["Custom Processors"]
  G --> G1["Enterprise Document OCR"]
  G --> G2["Form Parser"]
  G --> G3["Layout Parser"]
  SP --> S1["Invoices and Receipts"]
  SP --> S2["Bank Statements and Pay Slips"]
  SP --> S3["Identity Documents"]
  SP --> S4["Tax and Procurement Forms"]
  CU --> C1["Custom Extractor"]
  CU --> C2["Custom Classifier"]
  CU --> C3["Custom Splitter"]
    

General processors

These work on almost any document. Enterprise Document OCR reads text, including handwriting and many languages. The Form Parser finds labels, values, tables and checkboxes in forms without being told what to look for. The Layout Parser understands the structure of a document, such as headings, paragraphs, lists and tables, and can split text into meaningful chunks for search and generative AI.

Specialized processors

These are pretrained for specific, common document types. They already know what fields to look for. Examples include invoices, receipts and expense documents, bank statements, pay slips, identity documents, and certain tax and procurement forms. Because they are pretrained for a document type, they usually give better results with no training effort. The exact list and country coverage differ, so check the catalog.

Custom processors

When your documents are unusual, such as a shipping form that only your company uses, you build a custom processor. A custom extractor finds the fields you define. A custom classifier sorts documents into the types you define. A custom splitter separates stacked documents. Modern custom extractors can use generative AI models to find fields with few or no labeled examples, and you can improve them with examples when more accuracy is needed.

The other parts around the processors

• Your application or pipeline: the code that sends documents and uses the results, perhaps on Cloud Run or Cloud Run functions.
• Cloud Storage: the usual place to keep incoming documents and output results, especially for batch jobs.
• Authentication: service accounts and Identity and Access Management (IAM) control who may call the processors.
• Client libraries and toolkits: helpers that make sending documents and reading results easier in popular programming languages.
• Downstream systems: BigQuery, databases, accounting software and workflow tools that receive the extracted data.

Follow one invoice from your application, through Document AI and back.

sequenceDiagram
  participant App as Your Application
  participant Auth as Google Identity
  participant DAI as Document AI Processor
  participant Model as Reading Models
  App->>Auth: Prove who the application is
  Auth-->>App: Short-lived access credential
  App->>DAI: Send document file to the processor
  DAI->>Model: Read text and detect layout
  Model->>Model: Find fields, tables and entities
  Model-->>DAI: Structured result with confidence scores
  DAI-->>App: Document object with text, entities and locations
  App->>App: Validate, store or send for review
    

Step 1: Prove who you are

Your application runs under a service account, a special identity for programs, and receives a short-lived credential. This avoids storing passwords in code, and lets administrators control exactly what the program may do.

Step 2: Send the document

You send the file, such as a PDF or image, to a specific processor. For small and quick jobs you send the file directly in the request. For large collections you point the service at files stored in Cloud Storage.

Step 3: Read the page

The service first cleans up and analyzes the page image. It finds the text areas, recognizes the characters, detects lines and tables, and works out the reading order. This is the OCR and layout stage.

Step 4: Understand the content

Depending on the processor, further models then work out what the text means. A form parser links labels to their values. An invoice processor recognizes the supplier, the dates, the totals and the line items. A custom extractor finds the fields you defined.

Step 5: Return the structured answer

The result comes back as a Document object. It includes the full text, each page’s details, tables, form fields and entities. Each item has a confidence score and a location on the page, so you can show the original region to a reviewer.

Step 6: Use the result

Your own logic decides what happens next. You might check that the line items add up to the total, compare the supplier against an approved list, store the data in BigQuery, or send low-confidence results to a person.

A document arrives, is identified, read, checked, stored and finally archived. Here is that life story.

Straight-through processing

The goal of many projects is straight-through processing, where clean, high-confidence documents flow all the way from arrival to the business system without any human touching them. Humans focus only on the exceptions. Even a rate of seventy or eighty percent straight-through can transform the workload of a team.

Everything starts with reading the characters correctly.

OCR, short for Optical Character Recognition, is the technology that looks at an image of text and produces the actual characters. Earlier OCR systems struggled with poor scans, unusual fonts and handwriting. Modern machine-learning-based OCR is much better, though it is still not perfect.

What good OCR gives you

• The text itself: a full text version of each page, in reading order.
• Structure: pages, blocks, paragraphs, lines and words, each with a position on the page.
• Language detection: the service identifies the language used in each part of the document.
• Handwriting: recognition of handwritten text in supported languages, usually less accurate than print.
• Confidence per word: so you can find parts the model found hard to read.
• Special features: options such as checkbox and selection mark detection, font style information, and reading of mathematical formulas, available through settings or add-on features.
• Image quality signals: some processors can score how readable a page is, flagging blurry or dark scans.

What makes OCR fail

Digital PDFs versus scanned PDFs

A PDF created directly by software, such as a bill produced by a billing system, often already contains real text inside it, so reading it is easy and accurate. A scanned PDF contains only a picture of each page, and needs full OCR. Document AI handles both, and combining embedded text with image reading can improve quality.

Understanding labels, values, tables, headings and structure in documents of any design.

Form Parser

A form is a page with labels and spaces for answers: “Name: ____”, “Date of birth: ____”. The Form Parser detects these key-value pairs automatically. It also finds tables, including their rows and columns, and detects checkboxes and whether they are ticked. You do not tell it what fields exist. It discovers them from the page itself. This makes it a great first choice when you have many different kinds of forms and do not yet know exactly what you need.

The trade-off is that the labels it returns are whatever text appears on the page. If two forms use “DOB” and “Date of Birth”, your own code must decide that these mean the same thing. If you need consistent field names, a specialized or custom extractor that outputs your own named fields is a better choice.

Layout Parser

The Layout Parser focuses on structure. It identifies headings, paragraphs, lists, tables and other building blocks, and keeps the document’s hierarchy. It can also break a long document into chunks, which are sensibly sized pieces that keep related text together, for example a heading with its paragraphs. These chunks are valuable for search and for generative AI systems that answer questions from documents, because feeding the system well-formed pieces gives better answers than chopping text at random.

Tables

Tables are one of the hardest parts of document reading. Rows may span pages, cells may merge, and lines may be missing. Both the Form Parser and Layout Parser try to rebuild tables as grids of rows and columns. Check the results on your own tricky tables, such as those with merged cells and multiple pages.

Pretrained experts that already know what to look for.

Specialized processors are trained on large collections of a particular document type. They know which fields matter, how those fields usually appear and how to check them. They produce named fields with normalized values, so the output is ready to use with little additional work.

Why use a specialized processor?

• Faster to start: no training or labeling work is needed.
• Better accuracy: trained on many examples of the exact document type.
• Consistent field names: output uses standard names and cleaned values, such as dates and currency amounts in a regular format.
• Built-in logic: some include helpful checks, such as comparing line items with totals.

Limits to remember

• Coverage differs by country and document version. A processor trained for one country’s identity card may not read another’s.
• Unusual layouts or unusual document versions can reduce accuracy.
• Fields you care about may not be in the standard list. For those, use a custom extractor or combine tools.
• Identity document processing supports business workflows, but it does not by itself prove that a document is genuine. Fraud checks need extra steps.

When your documents are special, create a reader that learns them.

Not every document is a common invoice. Companies have their own forms: a cargo manifest, an insurance claim sheet, an inspection report, a land record. Document AI Workbench provides the tools to create processors for such documents without needing deep machine learning skills.

Custom extractor

A custom extractor finds the fields you define. You list the fields, such as “claim number”, “incident date” and “damage description”, then provide guidance. There are two main ways to teach it.

• With generative AI: modern custom extractors can use foundation models to locate your defined fields from little or no training data. You describe the field and may add a few examples, and the model finds it. This is fast to start and works well for many documents.
• With labeled examples: you upload sample documents and mark where each field appears. The more varied and numerous the examples, the more accurate the processor tends to become. Labeling is slower, but it can give higher accuracy and more predictable results for stable, high-volume document types.

Uptraining a pretrained processor

If a specialized processor is almost right but misses a few fields, you can uptrain it. This means starting from the pretrained model and teaching it with a small number of your own labeled documents. The result keeps the general knowledge of the original while adapting to your needs.

Custom classifier and splitter

A custom classifier learns to sort documents into types you define, such as “invoice”, “purchase order” and “delivery note”. A custom splitter learns where one document ends and the next begins in a long scan, such as a batch of loan files scanned as a single PDF. Together they let one pipeline accept mixed piles of paper and route each piece to the correct processor.

Evaluating and versioning

After training, you test the processor on documents it has not seen, and look at measures such as how often fields are found correctly. You can then deploy a specific version, compare it with others and keep the previous version for roll-back. Good practice is to never replace a working production version without testing the new one on a representative sample.

flowchart TD
  Start["What Kind of Document?"] --> Q1{"Is it a common type with a pretrained processor?"}
  Q1 -->|"Yes"| Q2{"Does it give the fields you need?"}
  Q2 -->|"Yes"| A["Use the Specialized Processor"]
  Q2 -->|"Almost"| B["Uptrain the Specialized Processor"]
  Q1 -->|"No"| Q3{"Do you know the fields you need?"}
  Q3 -->|"No - exploring"| C["Use Form Parser or Layout Parser"]
  Q3 -->|"Yes"| Q4{"Do you have many labeled examples?"}
  Q4 -->|"No"| D["Use a Custom Extractor with Generative AI"]
  Q4 -->|"Yes"| E["Train a Custom Extractor with Labeled Examples"]
    

What comes back, how to read it, and how to decide what to trust.

Every processor returns a Document object, usually as JSON, which is a simple text format for labeled values and lists. It may look big at first, but it has a clear structure.

The main parts

• Text: the complete text of the document, in reading order.
• Pages: for each page, its size, detected language, and layout pieces such as blocks, paragraphs, lines and tokens, each with a position.
• Tables: rows, header rows and cells, including references to the text they contain.
• Form fields: pairs of labels and values with positions, produced by form parsing.
• Entities: the named fields found by specialized or custom processors, each with a type, the text mentioned, a cleaned value, a confidence score and its location. Some entities contain smaller entities, such as an invoice line item holding a description, a quantity and a price.

Locations and anchors

Positions on the page are given as normalized coordinates, which are fractions of the page width and height from zero to one. This makes them independent of image size. You can draw a box on the original page for each field, which is exactly what review screens do. Many results refer to the main text by text anchors, which are start and end positions in the document’s text, so your code can pick out the exact piece.

Raw text versus normalized values

An entity often has both the text as written, such as “5th of Dec ’25”, and a normalized value, such as a standard date. Use normalized values for your systems and keep the raw text for review and audit. Always keep both.

Confidence scores

Each entity and many other parts carry a confidence score, a number between zero and one. A higher number means the model is more certain. It is not a guarantee. A confident answer can still be wrong, and a low-confidence answer can be right. The most useful way to use confidence is to set thresholds based on your own tests.

Two ways to send documents, depending on how fast and how many.

Online (synchronous) processing

In online processing, your application sends one document and waits for the answer in the same call. This is ideal when a user is waiting, such as a customer uploading a photo of an ID card during sign-up. Online requests have limits on file size and number of pages, so they suit small documents. Check the limits for your chosen processor, as they differ and can change.

Batch (asynchronous) processing

In batch processing, you point the service at many files in Cloud Storage and ask it to process them in the background. The call returns quickly with a long-running operation, which is a handle you can check later to see whether the job has finished. When done, the results are written as files to an output folder in Cloud Storage. Batch mode handles larger and longer documents and big collections, and is the right choice for overnight jobs and archives of historic paper.

Limits and quotas

There are limits on pages per request, file size, requests per minute and the number of batch operations running at once. Defaults exist and many can be raised on request. Design your system to expect these limits: queue the work, slow down when needed and retry after a pause. Always read the current quota page, because numbers change.

Choosing the location

Processors are created in a location, such as a multi-region in the United States or Europe, or specific regions where offered. Your documents are processed in that location. Choose it to meet your data residency rules and to keep delay low, and remember that not every processor type is available in every location.

How the pieces connect in a real system that handles thousands of documents a day.

A pipeline is a chain of automatic steps. Here is a typical document intake pipeline on Google Cloud.

flowchart LR
  In["Upload to Cloud Storage Inbox"] --> Evt["Event Notification via Pub/Sub or Eventarc"]
  Evt --> Orch["Cloud Run Orchestrator Service"]
  Orch --> Cls["Classifier Processor"]
  Cls --> Spl["Splitter Processor if Needed"]
  Spl --> Ext["Matching Extractor Processor"]
  Ext --> Val{"Checks Pass and Confidence High?"}
  Val -->|"Yes"| Auto["Auto-Approve and Save to BigQuery or ERP"]
  Val -->|"No"| Rev["Human Review Screen"]
  Rev --> Auto
  Orch --> Dead["Dead-Letter Queue for Failures"]
  Auto --> Arc["Archive Original and Result in Cloud Storage"]
    

Walking through the pipeline

• Inbox: files land in a Cloud Storage bucket from uploads, scanners or partner transfers.
• Trigger: a new file creates an event, sent through Pub/Sub or Eventarc, which wakes up the next step.
• Orchestrator: a Cloud Run service decides what to do with each file. For complex flows, Workflows can coordinate the steps.
• Classify and split: the classifier identifies the type, and the splitter separates stacked documents.
• Extract: the right processor reads the document, such as the invoice parser for invoices.
• Validate: business rules and confidence thresholds decide if the data is safe to accept.
• Review: people handle the exceptions, using a screen that shows the original page and highlights fields.
• Deliver and archive: clean data goes to BigQuery, a database or an accounting system, and everything is archived with the original.
• Failures: files that cannot be processed go to a dead-letter queue where engineers can investigate.

Useful validation rules

• Do line item amounts add up to the subtotal and the total?
• Is the date a real date in a sensible range?
• Does the supplier or customer exist in your master list?
• Is this invoice number a duplicate of one already received?
• Do account numbers pass their format checks?
• Are required fields present?

Designing for retries and duplicates

Messaging systems may deliver an event more than once, and networks fail. Make each step idempotent, which means doing it twice has the same effect as doing it once. For example, use the file name and a content fingerprint to detect that a document was already processed, so no invoice is booked twice.

Reading documents is the first step. Generative AI helps you ask questions and write summaries.

Many businesses want more than fields. They want to ask, “What are the termination clauses in these hundred contracts?” or “Summarize this claim file.” Generative AI models, such as Gemini in Vertex AI, are good at this, and Document AI helps feed them well.

The retrieval pattern

Retrieval-augmented generation, often called RAG, is a method where the system first searches your own documents for relevant passages, then gives those passages to a generative model so it can answer using real source material. This reduces made-up answers because the model is guided by your documents.

• Parse: the Layout Parser reads documents and splits them into meaningful chunks that keep headings and tables together.
• Index: chunks are stored in a search system, such as Vertex AI Search or a vector database, so they can be found by meaning.
• Retrieve: when a user asks a question, the most relevant chunks are fetched.
• Generate: a generative model writes an answer using those chunks, and can point to the sources.

Document AI versus using a generative model directly

Modern generative models can accept a document file directly and answer questions about it. This is flexible and quick to try. Document AI processors are more specialized: they return consistent, structured output, including positions and confidence scores, and are designed for high-volume, repeatable extraction. The best choice depends on the job.

Combining them

A common design uses Document AI to read and structure documents, then generative AI for tasks on top, such as summarizing a long contract, explaining a clause in plain words, or drafting a reply. The structured extraction gives accuracy and traceability, and the generative layer provides flexibility.

How to process large volumes quickly, and how to raise accuracy in practical ways.

Scaling the pipeline

Document AI itself is a managed service that scales on Google’s side, but it has quotas, and your own pipeline must respect them. Good habits include:

• Queue the work: use Pub/Sub or Cloud Tasks to absorb bursts and release work at a steady, safe pace.
• Run workers in parallel, but limit the total rate below your quota.
• Retry with backoff: if the service says “too many requests” or has a short problem, wait and try again, waiting longer each time.
• Use batch mode for volume: it manages large collections better than thousands of single calls.
• Request quota increases early before a launch or a big migration.
• Process once: keep a record of finished documents so restarts do not repeat work.

Raising accuracy without new models

Surprisingly, most accuracy gains come from the input and the surrounding logic, not from changing the model.

• Improve the scan: resolution, straight pages, good lighting, clean glass and flat paper.
• Send the right processor: classify first, so an invoice never goes to a receipt parser.
• Split properly: process one document at a time rather than a stack.
• Add validation rules: catch impossible values and mismatched totals.
• Use lookup lists: match extracted supplier names against known suppliers and fix near matches.
• Tune thresholds per field: a name can tolerate a lower confidence than a payment amount.
• Learn from corrections: collect reviewer fixes and use them to uptrain or adjust.

Measuring properly

Create a test set of documents, labeled by people with the correct answers, that you never use for training. Run each new processor version against it and compare. Look at accuracy per field, not just overall, because one important field may be weak while the average looks fine. Keep measuring on fresh samples over time, since suppliers change their layouts and customers send new kinds of documents.

Documents are full of private details. Protect them before, during and after processing.

Controlling access

Use Identity and Access Management (IAM) to control who may call processors, view results and manage settings. Use separate service accounts for separate applications, with only the permissions each needs. This is the principle of least privilege. Avoid sharing keys, and use short-lived credentials wherever possible.

Protecting data at rest and in transit

Connections to Google Cloud services are encrypted. Files in Cloud Storage and results in BigQuery are encrypted at rest by default. For stricter requirements, you can use customer-managed encryption keys through Cloud Key Management Service, where supported, to control and revoke access to the keys.

Data location

Choose processor locations that match your legal and company rules about where data may be processed and stored. Keep the input and output buckets in suitable locations too, since the pipeline spans several services.

Network boundaries

For sensitive projects, security perimeters such as VPC Service Controls can reduce the risk of data leaving a protected boundary, where supported. Private connectivity keeps traffic between your network and Google’s services off the public internet.

Data handling terms

Read Google’s current terms and documentation about how customer documents are processed, whether content is used to improve services, and what is logged or retained. Confirm these points with your legal and compliance teams before processing regulated data, such as financial, health or identity records.

Reducing exposure

• Send only the pages you need, not entire archives without reason.
• Use Sensitive Data Protection to find and mask or remove sensitive details from extracted text before sharing it widely.
• Set retention rules: delete temporary files and outputs when they are no longer needed.
• Restrict reviewers to the documents they handle, and log what they view.
• Protect the results as carefully as the originals, because extracted data is easier to search and misuse.

Auditing

Cloud Audit Logs record administrative actions, and data access logs can be enabled where needed. Keep a record of which processor version produced each result, which supports audits and investigations.

Watch both the health of the system and the quality of its answers.

There are two kinds of monitoring. Operational monitoring asks whether the system is working: are requests succeeding and how fast? Quality monitoring asks whether the answers are still good: is accuracy holding as document layouts change?

Operational signals

Quality signals

• Straight-through rate: the share of documents that need no human touch.
• Reviewer correction rate: how often people change an extracted field, per field and per supplier or form type.
• Confidence distribution: a shift toward lower scores can signal new layouts or poorer scans.
• Validation failures: a rise in mismatched totals points to a reading problem.
• Document mix: new types or languages appearing that the pipeline was not designed for.
• Processing time per document in human review: a hidden cost that can grow quietly.

Logging with care

Logs help you diagnose problems, but they can leak private content. Log file identifiers, processor versions, timings and statuses. Avoid logging the full extracted text or sensitive fields, unless there is a strong reason and strict access control.

Document AI is mainly billed per page. Know what drives the price.

Document AI pricing is usage-based and set by Google, and it can change, so always use the official pricing page and calculator for current numbers. The general shape is stable and useful for planning.

Ways to keep spending sensible

• Choose the cheapest processor that does the job. Do not use a premium extractor when plain OCR is enough.
• Classify before extracting. It avoids running expensive processors on the wrong document.
• Send only needed pages. Remove blank pages, covers and attachments you will not use.
• Reject bad files early. Check file type, size and basic quality before processing.
• Remove duplicates. Do not process the same file twice.
• Remove unused deployed versions. Undeploy test processor versions that nobody uses.
• Count the human cost too. A slightly better and more expensive processor can save more in review time than it adds in price.
• Set budgets and alerts, and limit retries so a bug cannot reprocess a whole archive repeatedly.
• Label resources so billing reports show which team and project spend what.

No tool is perfect. A good architect weighs both sides before choosing.

The main trade-offs, in plain words

• Pretrained versus custom: pretrained is quick but fits only standard documents, custom fits your needs but takes effort.
• Automation versus safety: higher straight-through rates save time but risk more errors without good validation.
• Structure versus flexibility: processors give consistent output, generative models give flexible answers.
• Cost versus accuracy: premium processors and cleaner scans cost more, but can reduce expensive manual correction.

Related tools at a glance

A pattern is a proven way to solve a common problem. An anti-pattern is a tempting mistake that causes pain later.

Helpful patterns

Anti-patterns to avoid

A checklist you can follow from the first day.

Best practices

1. Start with business goals. Decide which fields, accuracy and speed would genuinely help, before choosing tools.
2. Collect a realistic sample. Include good, average and awful documents, and have people label the correct answers.
3. Try pretrained processors first. Move to custom only if they fall short.
4. Standardize scanning. Aim for clear, straight, well-lit pages at a sensible resolution.
5. Classify and split before extracting. One document type per processor call.
6. Validate with business rules. Totals, dates, duplicates and master data checks catch many errors.
7. Set per-field confidence thresholds. Be stricter for money and identity fields.
8. Build a good review screen. Show the original page with highlighted fields, and make corrections quick.
9. Use batch mode for volume and online mode only when someone is waiting.
10. Queue, retry and make steps idempotent. Respect quotas and avoid duplicate processing.
11. Pin processor versions and test new ones on a fixed sample set.
12. Protect the data. Least-privilege access, suitable locations, encryption and retention rules.
13. Monitor quality as well as uptime. Track straight-through and correction rates.
14. Check the latest documentation. Processors, limits, locations and prices change.

Common mistakes

Four illustrative stories show where Document AI fits. The companies below are imaginary examples to teach the ideas.

When Document AI is a strong choice

• You process many documents with varied layouts and need structured data.
• You have standard document types that pretrained processors already understand.
• You need positions and confidence for review and audit.
• You want to feed clean, structured chunks into search or generative AI.
• You prefer a managed service over building and hosting your own models.

When to think twice

• You only need simple text from a handful of images, where a lighter OCR tool may suffice.
• Your volume is very small and manual entry is cheap.
• Your documents are extremely rare or unusual and you cannot gather sample data.
• Your rules forbid sending the documents to an external managed service, or the data location does not meet requirements.

Quick answers to questions that beginners ask most often.