# Document AI Glossary: 30 Terms, Defined Plainly > Thirty document AI terms, from OCR and parsing to precision, review thresholds and per-page pricing, each linked to the post where it matters. - Source: https://www.zarifautomates.com/blog/document-ai-glossary - Published: 2026-09-26 - Updated: 2026-09-26 - Pillar: Agents & AI Engineering - Tags: document ai, intelligent document processing, ocr, document processing, glossary - Author: Zarif --- This glossary collects the terms the Document AI series uses, in the order you meet them when building a pipeline: reading the page, turning it into data, checking the data, reviewing it, and paying for it. Each definition is short and links to the post where the term does real work. Where vendors use a word differently, the definition says so. Terms were checked against the linked docs on September 26, 2026. ## Reading the page ### OCR Optical character recognition turns an image of text into characters, usually with a bounding box for each word or line. Classic OCR knows what the characters are but not what they mean, so tables, columns and totals were left to templates and rules. [From OCR to vision-language models](/blog/document-ai-from-ocr-to-vision-language-models) covers what changed. ### Text layer A born-digital PDF, one exported from software rather than scanned, carries its text as data inside the file. Reading that layer is faster and cheaper than OCR, and hybrid tools use it whenever it is intact. Scans and photos have no usable text layer and need OCR or a model. ### Vision-language model A vision-language model, or VLM, reads a page image and writes out text and structure directly, such as headings, reading order and tables as HTML. It handles layout far better than OCR, but its output is generated, so it can be plausible and wrong. That risk is why the rest of the series spends so much time on citations, scores and review. ### Hybrid pipeline A pipeline that uses cheap text extraction where it works and calls a VLM only for hard pages or blocks. Marker's fast mode and Extend's auto engine both route work this way. It is the practical default described in [part 1 of the series](/blog/document-ai-from-ocr-to-vision-language-models). ### Layout analysis The step that finds the regions of a page, such as headings, paragraphs, tables, figures and form fields, and puts them in reading order. Good layout analysis is what keeps a two-column page from being read straight across. [Datalab in practice](/blog/datalab-in-practice-marker-surya-chandra) shows the block types it returns. ### Bounding box The coordinates of a region on the page, usually as a rectangle or polygon. Bounding boxes let a reviewer see exactly where a value came from. They are the raw material for citations. ## Turning pages into data ### Parse Converting a whole document into text and structure, typically markdown or HTML plus typed blocks with positions. Parsing preserves what is on the page and does not decide what any value means. See [parse vs extract vs classify vs split](/blog/parse-vs-extract-vs-classify-vs-split). ### Extract Filling a schema you define with values from the document, returned as JSON. Extraction answers "what is the total due", where parsing only reproduces the page. Most vendors run a parse first and bill it on top, as [the cost post](/blog/document-ai-cost-at-scale) explains. ### Classify Deciding what kind of document you have, such as invoice, receipt or contract, so it can go to the right extractor. A classifier's mistakes cascade, because an invoice read with a contract schema returns nonsense. It is one of the four operations in [part 2](/blog/parse-vs-extract-vs-classify-vs-split). ### Split Finding where one document ends and the next begins inside a single file, such as three invoices scanned into one PDF. Datalab calls this segmentation. Without it, fields from different documents can blend into one record. ### Schema The definition of what to extract: field names, types, descriptions and which fields are required, usually written as JSON Schema. The descriptions matter as much as the names, because the model reads them. [Extend in practice](/blog/extend-in-practice-schemas-evals-workflows) walks through one for an invoice. ### Citation A pointer from an extracted value back to the place in the document it came from, such as a block ID or a bounding box. Datalab returns a citation list per field, and Extend can return them when enabled. Citations turn review from searching into confirming, as [the review queue post](/blog/designing-the-document-review-queue) describes. ### Processor version A fixed configuration of a parser or extractor that you can pin, compare and roll back. Versioning matters because a changed schema or model changes outputs you have already stored. [Where Datalab fits](/blog/best-enterprise-ai-document-processing-tools) discusses why pinned, immutable versions help. ## Checking the data ### Ground truth The answer key: the values a careful person reads off each document, in one canonical format per type. Every accuracy number is only as good as its ground truth. [Measuring extraction accuracy](/blog/measuring-document-extraction-accuracy) builds a small one. ### Field-level accuracy Scoring each field on each document separately, rather than giving the whole document one grade. It shows which fields fail, which is what you need to fix a schema or set a threshold. The same post has a script that computes it. ### Precision Of the values the extractor returned, the share that were correct: true positives divided by true positives plus false positives. Low precision means confident-looking wrong values, the dangerous kind. Google Document AI's [evaluation docs](https://docs.cloud.google.com/document-ai/docs/evaluate) use the same definition. ### Recall Of the values actually on the documents, the share the extractor returned correctly: true positives divided by true positives plus false negatives. Low recall means missing fields, which usually end up in review. A wrong value lowers both precision and recall. ### F1 score The harmonic mean of precision and recall, one number that weights them equally. It is convenient for comparing runs but hides which of the two moved. Report precision and recall alongside it. ### Exact and normalized match Exact match counts a value as correct only if it equals the truth as written. Normalized match first applies rules, such as parsing dates or stripping currency symbols, then compares. The choice can move a score by many points, as [the scoring example](/blog/measuring-document-extraction-accuracy) shows, so state which one you used. ### Invented value A value the extractor returned for a field that is not on the document, such as a due date inferred from payment terms. It counts as a false positive. Vision-language models make this failure possible in a way classic OCR did not. ### Evaluation set A frozen collection of documents with ground truth, rerun before every schema, prompt or version change. Extend can build one from a reviewed batch run. Keep it separate from the documents you tune on, or the score measures memorization. ### Business rule validation Deterministic checks on extracted data that do not depend on the model, such as required fields present, line items summing to the subtotal, or currency on an allowed list. They catch the errors with real consequences and never drift. The [n8n invoice pipeline](/blog/invoice-pipeline-in-n8n) runs a set of them in one Code node. ## Reviewing the data ### Confidence score A number attached to an extracted value that estimates how likely it is to be correct. Scales differ by vendor: Azure and Extend use 0 to 1, while Datalab's fast-mode scoring and Extend's Review Agent use 1 to 5. Microsoft's [confidence docs](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/concept/accuracy-confidence?view=doc-intel-4.0.0) describe it as an estimated probability, and Extend's say a high score does not guarantee accuracy. ### Confidence threshold The score below which a field goes to a person instead of straight through. Vendor defaults differ, and even one vendor's docs can disagree, so set your own from a labeled pilot. [The review queue post](/blog/designing-the-document-review-queue) shows how. ### Straight-through processing Documents that pass every check and reach the destination with no human touch. The share of documents processed this way is the automation rate. Microsoft's transparency note uses the term when discussing thresholds. ### Exception A document routed to review because a rule failed, a score fell below threshold or a signal was missing. The exception rate, the share of documents that become exceptions, is the biggest driver of total cost. The [cost post](/blog/document-ai-cost-at-scale) puts a dollar value on each point of it. ### Human in the loop A design where people check or correct machine output before it is used. In document AI this usually means a review queue with approve, correct and reject actions. The same idea for agents is covered in [human approval for agents](/blog/how-to-build-ai-agent-human-in-loop-approval). ### Audit sample A random sample of auto-accepted documents reviewed anyway, to measure the error rate the queue never sees. AWS A2I calls this sampling, and Rossum's docs warn that automating nearly everything leaves little human-checked data to learn from. Sample size depends on the margin of error you want, not on volume. ## Paying for it ### Per-page pricing Charging a rate for each page processed, usually quoted per 1,000 pages. Watch what counts as a page and whether parsing and extraction are billed separately. Google's specialized parsers price per document instead. See [the cost post](/blog/document-ai-cost-at-scale) for rates as of September 2026. ### Credits A vendor's internal billing unit, converted to dollars at a per-credit rate that depends on your plan. Extend bills in credits per page, with different counts per operation and mode. Always convert to dollars per page before comparing vendors, as [Extend vs Datalab vs other parsers](/blog/extend-vs-datalab-vs-other-document-parsers) does. For the full series in order, start at [Document AI now: from OCR to vision-language models](/blog/document-ai-from-ocr-to-vision-language-models). Previous: [document AI cost at scale](/blog/document-ai-cost-at-scale).